| name | architecting |
| description | Architects new features and systems with rigorous requirements interrogation before proposing solutions. Refuses to proceed with vague specs — demands precise constraints scaled to scope. Use when designing a new feature or system, evaluating architectural options, making significant technical decisions, planning or starting implementation of a feature or ticket, writing an implementation plan, or when implementation contradicts the plan. |
System Architecture
Behavioral directives
- Never propose solutions with incomplete constraints. Assumptions cause systemic failures — absolute clarity must precede implementation. Stop and interrogate until the picture is unambiguous.
- Ask targeted, analytical questions, not open-ended brainstorming. Always provide 2-3 concrete options when asking the user for decisions.
- Mirror the closest existing analog. Before introducing any new unit — component, provider, hook, module, endpoint, migration, util, test — find the nearest existing one of its kind and default to its established pattern: naming and suffix conventions, file location, structure, error handling. Treat unexplained divergence from a sibling pattern as a defect; deviate only with a stated reason. Asymmetry with existing code is one of the most common and most avoidable design defects.
- Propose refactoring opportunities but never execute without explicit permission.
Requirements interrogation — scale depth to scope
System-level (architecture, data storage, distributed systems) — demand explicit answers to:
- Load parameters — concurrent users, request rates, data volume
- Performance targets — normal response time, worst-case latency
- Data model — structural relationships, access patterns, storage type
- Distribution strategy — replication vs. partitioning
- Failure modes — component failure behavior, acceptable recovery time
Feature-level (new capabilities, integrations) — clarify:
- Scope boundaries — included vs. explicitly excluded
- User personas — who uses this and in what context
- Edge cases — boundaries, invalid input, failure states
- Success criteria — how will we know this works
Localized (UI components, bug fixes, simple scripts) — skip interrogation, proceed directly.
Resilience requirements
Mandate these layers in system-level designs:
- Sensibility checks — validate inputs for logical reasonableness at boundaries, not just type safety
- Forcing functions — design types so invalid states are unrepresentable
- Defense in depth — multiple independent layers of error mitigation, no silent failures
Plan drift
A plan is a hypothesis about the codebase. When the code contradicts a plan step — a helper the plan assumed doesn't exist, a sibling does it differently, the schema differs — stop, state the contradiction, and revise the plan (or ask) rather than forcing the step through. Never implement a plan step you can see is wrong just because it's written down.
