Use when a repo, project, or area has accumulated several design/spec/plan docs and needs ONE coherent, top-down design document that synthesizes them and routes a reader to the right spec for depth. Create or update after a release or major implementation cycle, when onboarding needs a current architectural view, or when it is unclear which spec is current versus superseded. Trigger phrases: "update the design doc", "sync the design doc", "design-doc", "compile the design", "give me a top-down view of the design".
Phase 2 of design thinking. Synthesize understanding into a precise problem definition and spec. Produces a spec with explicit success/failure criteria. Input: context brief from /understand. Invoke after Understand, or when Ideate reveals the spec is too vague.
Entry point for the 5-phase design thinking process. Assesses current state and routes to the appropriate phase skill. Each phase runs in an isolated agent session and produces a concrete artifact. Phases: understand → define → ideate → prototype → test. Invoke when starting any non-trivial problem or creative task.
Phase 3 of design thinking. Generate and select an approach, then produce a concrete implementation plan. Input: spec from /define. Invoke after Define, or when Prototype reveals a fundamental design issue requiring replanning.
Phase 4 of design thinking. Execute the plan to produce a working artifact. Input: plan from /ideate and spec from /define. For code: uses superpowers execution skills. For writing/creative: produces the draft artifact. Invoke after Ideate.
Phase 5 of design thinking. Audit the implementation against the spec. Produces an audit document. Input: implementation from /prototype + spec from /define. Invoke after Prototype. NOT the same as /design-doc — this evaluates a specific implementation cycle, not the system's full architecture.
Phase 1 of design thinking. Map the problem space thoroughly before defining or solving. Produces a context brief. Invoke at the start of any non-trivial problem, or when a later phase reveals the problem was not well understood.
Use when the user wants to compile a set of pulled sources into a structured, cross-linked wiki. Natural triggers: "/ingest", "compile these papers into a wiki", "synthesize my sources", "ingest the X papers focusing on Y", "build me a wiki page per method from these papers". Distinct from /pull (fetches sources) and /sota (produces a state-of-the-art review). Input: a folder of Markdown sources (typically `./sources/`). Output: cross-linked pages in `./wiki/` with per-source summaries and synthesis pages.