output_skills/design/align/SKILL.md
Presents a proposed approach in progressive confirmable chunks with recommended decisions and alternatives. Use when aligning on a design, plan, or technical approach before implementation.
npx skillsauth add lexler/skill-factory alignInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
STARTER_CHARACTER = 🎯
Synchronize the mental model between you and the user before implementation begins. Discrepancies found during implementation are expensive — find them now while changes are free. Your job is to make your thinking visible so the user can spot where your understanding diverges from theirs.
Propose, don't ask. Think first, then present your thinking for confirmation. The user's job is to spot divergence and course-correct, not to generate the approach.
Each level deepens understanding. Confirm before going deeper.
Goal → Big Picture → Straightforward Details → Non-obvious Decisions (one by one)
State what you understand the goal to be and why it matters. A sentence or two. This catches the deepest misalignment — if you're solving the wrong problem, nothing else matters.
Confirm with AskUserQuestion before going deeper.
Present the overall shape of the approach: how do the pieces relate, what's the high-level flow. ASCII diagram. A few sentences, not a page.
Confirm with AskUserQuestion before going deeper.
Decisions where there's really only one reasonable approach. No ⭐/❌ needed since there are no real alternatives. The user confirms or flags exceptions.
Group items by topic. Anchor each group with an ASCII diagram — not just for file structures, but for any group: roles and their responsibilities, control flow, communication between components. The diagram is what makes a group scannable. Present one group at a time, confirm, move to the next group.
Each item: one line stating the decision. Save the "why" — it's obvious.
Decisions with real tradeoffs, multiple valid approaches, or where your recommendation might surprise the user.
First, present a brief index of what's coming — just the problem titles, no recommendations. This lets the user see the scope.
Then walk through each one (or small related groups) with:
Confirm each with AskUserQuestion before moving to the next.
When the user rejects a recommendation, check whether downstream items are affected. If so, flag which ones need revisiting.
When the user corrects something, re-present the full updated version (diagram, section, whatever was corrected) before asking to proceed. Don't just show the delta. The user needs to see the corrected whole — it often triggers additional corrections they wouldn't have noticed otherwise.
development
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.
development
Writes tests without mocks using Nullables. Use when writing tests, especially testing code with external I/O (HTTP, files, databases, clocks, random numbers), designing infrastructure wrappers or replacing mocking libraries.
testing
Scannable BDD tests written in domain language. Use when doing BDD.
development
Writes approval tests (snapshot/golden master testing) for Python, JavaScript/TypeScript, or Java. Use when verifying complex output, characterization testing legacy code, testing combinations, or working with .approved/.received files.