Update to fstack

{
  "description": "Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.",
  "included_files": [
    {
      "relative_path": "references/design-red-flags.md",
      "size_in_bytes": 1977
    },
    {
      "relative_path": "references/rationale-template.md",
      "size_in_bytes": 3085
    },
    {
      "relative_path": "references/runner-prompt.md",
      "size_in_bytes": 3111
    }
  ],
  "name": "architect",
  "skill_md_contents": "---\r\nname: architect\r\ndescription: \"Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.\"\r\nmenu-description: settle types and module shape before writing code that crosses a function boundary\r\n---\r\n\r\n# Architect\r\n\r\nDesign before implementing. Sketch types, function signatures, class shapes, and module boundaries with `not implemented` bodies and pseudocode. Synthesize across multiple model perspectives, then fill in code against the chosen sketch. If implementation proves the sketch wrong, throw it out and redesign.\r\n\r\n**Platform note.** On Codex, the Claude tool names, `claude-*` slugs, and Claude built-in skills named below are Claude defaults. Resolve them via [`codex-tools.md`](../engineer-mode/references/codex-tools.md).\r\n\r\n## Start\r\n\r\nOpen a todolist with one entry per phase before starting. Autonomous mode without checkpoints needs the list to show phase position and keep phases from silently disappearing.\r\n\r\n1. Ground\r\n2. Sketch\r\n3. Agree\r\n4. Implement\r\n5. Scrap\r\n\r\n## Phase A: Ground the problem\r\n\r\nBuild a real mental model of every system the new code touches. Run the **how** skill over the relevant subsystems. Critique mode if existing structure is the constraint or the design must push back on it.\r\n\r\nNaming a file isn't grounding. Produce the traced model `how` prescribes. If the design redefines ownership or layering, also run the **why** skill on the existing shape so the rationale becomes a constraint, not a guess.\r\n\r\nSkip Phase A only when the work is genuinely greenfield with no surrounding system to integrate.\r\n\r\n## Phase B: Sketch\r\n\r\nRun the **arena** skill with the design-sketch task and the Phase A grounding artifacts. Pass `references/runner-prompt.md` as each runner's prompt. Each candidate produces a design package shaped per `references/rationale-template.md`: the caller's usage written first, then the type sketch, function signatures, module map, and prose rationale derived from it.\r\n\r\nUse your configured architect runners (defaults in [Models](#models)).\r\n\r\nDesign it twice. Require at least two structurally distinct candidates before synthesis, even when the first looks sufficient. This is the **exhaust-the-design-space** principle skill made concrete. Whole-shape alternatives, not point fixes inside one shape.\r\n\r\nScreen every candidate against [`references/design-red-flags.md`](references/design-red-flags.md) before synthesis. Reject or revise shallow modules, information leakage, temporal decomposition, and pass-through methods.\r\n\r\nCompare viable candidates on interface depth. Prefer the design that hides more complexity behind a smaller, simpler public surface. A rich interface can keep call chains short by concentrating capability instead of scattering it across layers.\r\n\r\nArena returns one synthesized design package. The synthesis decision populates the rationale's \"Synthesis decision\" section.\r\n\r\n## Phase C: Agree (opt-in)\r\n\r\nDefault: proceed directly to implementation with the synthesized design. No human checkpoint.\r\n\r\nOpt in to a checkpoint when the invoker explicitly asks: \"/architect with checkpoint,\" \"stop and show me before implementing,\" or similar. Then surface the synthesized design and pause for sign-off.\r\n\r\nThe synthesis can ship as its own commit either way. That's the \"scaffold first\" mode of the **foundational-thinking** principle skill; subsequent commits read as filling in bodies against a stable contract. Planned and scoped breakage during fill-in is fine, per the **outcome-oriented-execution** principle skill. For adversarial pressure on the design before implementing, run the **interrogate** skill on the synthesized sketch.\r\n\r\nIf the human pushes back on the shape (in a checkpoint or after the fact), treat that as Phase A evidence. Re-ground and re-run Phase B before writing more code.\r\n\r\n## Phase D: Implement against the sketch\r\n\r\nReplace `not implemented` bodies with code, pseudocode with logic. The synthesized sketch is the contract.\r\n\r\nDeviations from the sketch are signal worth surfacing, not friction to absorb silently. If a function needs a parameter the sketch didn't anticipate, ask whether the sketch was wrong, the requirement was missed, or the implementation is overreaching. Surface it; don't bolt it on.\r\n\r\n## Phase E: Scrap when the architecture is wrong\r\n\r\nIf implementation keeps producing friction the sketch can't absorb, throw the sketch out. Don't bolt fixes onto a wrong design, per the **redesign-from-first-principles** and **fix-root-causes** principle skills.\r\n\r\nThe signal is a *pattern*, not single instances. Tells:\r\n\r\n- The same shape of workaround appearing repeatedly across unrelated code.\r\n- Multiple unrelated edge cases that all need special-case branches.\r\n- Types that need escape hatches (`any`, casts, optional fields always set in practice) to compile.\r\n- The \"we need a lock\" reflex when the sketch said the state wasn't shared.\r\n- Callers having to know the abstraction's internal rules to use it.\r\n- Two or more independent Phase D deviations of the same shape across the implementation. Surfacing deviations is Phase D's job; a repeated pattern of them is Phase E's trigger.\r\n\r\nUse judgment. A few edge cases don't condemn an architecture. Some problems are legitimately complex; complexity in the data is not complexity in the design. The rewrite signal is repeated friction of the same shape, not single hard cases.\r\n\r\nWhen you scrap:\r\n\r\n1. Re-run the **how** skill over what's been built. The implementation lessons enter the new design as inputs, not vibes.\r\n2. Redesign as if the new constraints had been day-one assumptions, per redesign-from-first-principles.\r\n3. Subtract before adding, per the **subtract-before-you-add** principle skill. The new sketch should be smaller than the old one before it grows.\r\n4. Return to Phase B and re-run arena.\r\n\r\n## Outputs\r\n\r\nThe caller's usage is written first and the type sketch derived from it. One file with new types and signatures for small changes; module map plus type definitions for larger work. The rationale ships alongside, shaped per `references/rationale-template.md`, including the usage sketch and the synthesis decision.\r\n\r\n## Models\r\n\r\nRole defaults live in repo-root `models.json`. `/setup-fstack` writes a per-harness override sheet that wins at runtime.\r\n\r\n- architect runners: `claude-opus-5`, `claude-fable-5`, `claude-sonnet-5`\r\n"
}