system-design

# System Design Decision Tree Architecture-level decision framework invoked by the implementation planning command. Takes feature context, supplies the caller with a targeted question bank, then synthesizes structured trade-off decisions for the caller to insert into its artifact. This skill is pure expertise. It does not read or write project files, does not drive user dialogue, does not assign identifiers. The caller owns the interactive loop; this skill owns the decision trees, question bank, and output contract. Decisions produced here are architectural (choose pattern X over pattern Y because of trade-off Z). Implementation rules (timeouts, library choices, API shapes) live in code-level rules files and are out of scope. --- ## How It Works **Input:** structured context object from the caller — functional scope (from spec), technical requirements (from PRD), and user flows (from ux). May be supplemented with answers elicited from the user. **Output:** single markdown block — `### System Design Analysis` with `#### Required Behaviors` and `#### Architectural Decisions`. Caller integrates into its artifact. **Pipeline:** triage → load minimum references → supply question bank → receive answers → synthesize decisions. **Boundary:** the caller runs the interactive loop with the user. This skill does not prompt the user directly; it returns the question set and ordering, and the caller executes the dialogue. --- ## Step 1: Triage Classify the subject. Multi-catego...