// Use when requirements exist and a technical design is needed before implementation begins
Use EVERY TIME you need to run tests, verify tests pass, or check for regressions. ALWAYS use this instead of running eldev directly.
Use when code quality needs improvement after implementation, without changing behavior
Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
Use when a design exists and it's time to break it into tasks and execute with subagent dispatch and review
Use when a new feature request, bug report, or work request needs requirements defined before implementation
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
| name | architect |
| description | Use when requirements exist and a technical design is needed before implementation begins |
Design the technical solution through conversation. Propose approaches with tradeoffs, let the user choose, then detail the chosen design.
Core principle: Lead with options, not answers. The user picks the direction.
/define or provided by user)Look for the most recent *-requirements.md in docs/plans/.
If none found or multiple exist, ask the user which to use. If no requirements exist at all, suggest /define first.
Before proposing anything, understand what exists:
Name specific files and patterns you found. Don't hand-wave about "the existing architecture."
For each approach:
### Approach A: [Name] (Recommended)
**Summary:** One sentence.
**How it works:** Key components and interactions.
**Pros:** Why this is good.
**Cons:** Why this might not be ideal.
**Risk:** What could go wrong.
**Fits existing patterns:** How it aligns with what's already in the codebase.
Lead with your recommendation but explain why the others exist.
Use AskUserQuestion:
One question at a time. Don't dump all decisions at once.
Present in sections, validating each with the user before moving on:
| Section | Content |
|---|---|
| Overview | What we're building and why this approach |
| Components | Each new/modified module with its responsibility |
| Data Flow | How data moves through the system |
| API Surface | Public functions — signatures and behavior |
| Error Handling | What can go wrong and how we handle it |
| Testing Strategy | What to test, at what level |
Design principles to consider:
Derive name from requirements doc (same <name> slug).
docs/plans/YYYY-MM-DD-<name>-design.md
Commit: docs: add <name> design
Design saved. When ready, use
/implementto plan and execute the implementation.
| Mistake | Fix |
|---|---|
| Presenting one design as "the answer" | Always propose 2-3 approaches with tradeoffs |
| Not reading the codebase first | Explore before proposing. Name specific files and patterns. |
| Designing without interviewing | Ask the user which approach. They decide direction. |
| Including full implementation code | Design describes WHAT and WHY. /implement handles HOW. |
| Producing the entire design in one shot | Present section by section, validate each with user. |
| Hand-waving about "existing patterns" | Be specific: "org-gtd-organize.el uses transient at line 42" |
| Not referencing next step | Always end with: "use /implement when ready" |