system-design-session

System Design Session Skill

[!IMPORTANT] Run an interactive system design session that turns a product goal into a scoped, evidence-qualified architecture and handoff.

Optional args: slug=, ticket=<id/url>, mode=interactive|autonomous|channel, channel=, auto_continue=true|false, profile=business|hybrid|technical.

Instructions

When the user asks to perform this workflow, execute the following steps:

System Design Workflow

Goal

Goal: Produce an evidence-qualified system design and handoff to design-solution, holding unresolved material decisions and distinguishing design readiness from implementation or operations.

Steps

1. Load context. Read the product goal and relevant architecture. Review-existing mode uses current traffic/incident evidence when available. Load system-design-methodology and only relevant siblings: system-design-data-architecture for consequential flows, system-design-mobile-client for client/SDK concerns, and common-architecture-diagramming only for a selected view.
2. Classify independently. State mode (new design | review existing | interview practice), depth (quick | full), and surface (backend | mobile/client | SDK/library | full stack; mixed may name multiple). Quick uses labeled assumptions; full confirms consequential gates. Escalate quick for hard constraints or irreversible choices. Interview practice follows system-design-interview-coaching; the candidate designs, then receives the practice loop and six-criterion debrief.
3. Intake and estimate. Follow system-design-methodology/references/four-phase-process.md exit predicates. Bound intake to journeys, scope, inputs/outputs, trust/ownership boundaries, quality scenarios (trigger, environment, response, measure, owner), and assumptions. Ask at most 3 blocking questions per turn. Estimate only decision-relevant quantities; label target/estimated/measured and provenance. Confirm material scope and shaping estimates before physical choices in full sessions.
4. Trace before binding. Describe each consequential journey logically: source/sink, payload/purpose, transformations, authoritative owner/derived copies, invariant, user-visible outcomes, verification. Use system-design-data-architecture/references/flow-contracts.md; do not duplicate C1. Bind accepted decisions to physical components/stores/contracts afterward. Link applicable FLOW-* design records through REQ-* -> HLD-* -> CMP-* -> LLD-* -> VER-*; FLOW-* is not an outcome field.
5. Select views and deep dives conditionally. Choose zero or more from the named question, risk, surface, and time. Dataflow explains movement/authority; sequence ordering/acknowledgment; state lifecycle; ERD relationships; deployment placement. Prose/table is sufficient. No component, queue, store, specialist, or diagram quota. Practice uses commitment -> adverse timeline -> mechanism revision -> changed constraint -> evidence-based debrief.
6. Hold material decisions. Full sessions do not commit affected design or claim readiness while a material owner/invariant, compliance/residency, or topology-changing budget decision remains unresolved. Record it in decision_needed; preserve other gaps in missing_evidence. Quick sketches may proceed with explicit assumptions, never false readiness.
7. Score and hand off. Run the declared-profile, scope-aware nine-axis system-design-review scorecard and independent system-design-review/references/semantic-evaluation.md. Use applicable denominators and justified N/A. Semantic soundness requires >=85%, no applicable zero, and no hard failure; any failed material gate blocks readiness regardless of aggregate. The six-criterion interview rubric is separate. Preserve existing outcome fields/statuses; design evidence does not prove implementation or operations.
8. Prepare warranted delivery slices. Only when independent post-decision docs/diagram slices are warranted, define exact files, AC, evidence, checks, and integrator before execution. Use configured project/account/data-eligible routing; lead retains decisions/final review. Allow one focused correction, then configured eligible fallback or BLOCKED. Disclose executor/model/settings, correction/fallback, and actual usage/cost or unavailable. This gate grants no model/provider execution authorization, including premium execution; workers must not change policy/profile settings, invoke unapproved model execution, or claim unrun checks.