Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
Turn ideas into fully formed, architecture-compliant designs through collaborative dialogue.
Start by reading current project context:
git log --oneline -10CLAUDE.md, .claude/rules/architecture.mdThen ask questions one at a time to refine the idea:
Propose 2–3 different approaches with trade-offs. Lead with your recommendation and explain why. Don't skip this — even if one approach is clearly better, naming the alternatives prevents blind spots.
Before presenting any design, verify it complies with the project's non-negotiable constraints:
| Constraint | Rule |
|---|---|
| Dependency direction | Views → Services → Models (never backwards) |
| Business logic | All business logic in core/services/ — never in views or serializers |
| Serializer pattern | Dual pattern: nested read (BuildingSerializer(read_only=True)), _id write |
| Soft delete | All models use AuditMixin + SoftDeleteMixin — default querysets exclude deleted |
| Cache invalidation | New models need signal handlers in core/signals.py |
| Frontend state | Server state via TanStack Query, client state via Zustand (auth only), forms via RHF+Zod |
| CRUD pages | Use useCrudPage hook — never build CRUD state management from scratch |
| Mock policy | Tests mock ONLY external boundaries — never internal code or libraries |
| No inline suppression | Never use # noqa, # type: ignore, eslint-disable — fix the actual code |
| Lint compliance | All code must pass ruff check, mypy, npm run lint, npm run type-check |
If a proposed design violates any of these, flag it explicitly before proceeding.
Once you understand what you're building, present the design in sections of 200–300 words. After each section, ask whether it looks right before continuing.
Cover:
Write the validated design to a prompt file:
prompts/<NN>-<topic>.md
Following the existing prompt format (see prompts/00-prompt-standard.md as reference).
Ask: "Ready to implement?" If yes, use /new-feature to execute.