---
name: architect
description: "Sketch types, signatures, and module structure before writing code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping straight to code would lock in the wrong shape."
license: MIT
metadata:
  adapted-from: "cursor/plugins/pstack/skills/architect"
  version: "1.0.0"
---

# Architect

Design before implementing. Sketch types, function signatures, class shapes, and module boundaries with `not implemented` bodies and pseudocode. Explore more than one shape, choose deliberately, then fill in code against the chosen sketch. If implementation proves the sketch wrong, throw it out and redesign.

Open a todo list with one entry per phase before starting: Ground, Sketch, Agree, Implement, Scrap.

## Phase A: Ground the problem
Build a real mental model of every system the new code touches. Trace the actual code paths and name the data shapes. Naming a file is not grounding. If the design redefines ownership or layering, also investigate why the existing shape is the way it is, so the rationale becomes a constraint. Skip Phase A only for genuinely greenfield work with no surrounding system.

## Phase B: Sketch (design it twice)
Produce at least two structurally distinct candidate designs before choosing, even if the first looks sufficient. These are whole-shape alternatives, not point fixes inside one shape (Exhaust the Design Space). For richer exploration, run the **arena** skill with the design-sketch task and the Phase A grounding.

Screen every candidate for design red flags before choosing: shallow modules (big interface hiding little), information leakage across modules, temporal decomposition (structure mirrors execution order rather than the domain), and pass-through methods that add no value. Reject or revise these.

Compare viable candidates on interface depth: prefer the design that hides more complexity behind a smaller, simpler public surface.

## Phase C: Agree (opt-in)
Default: proceed directly to implementation with the chosen design. Opt in to a human checkpoint only when the invoker asks ("architect with checkpoint", "show me before implementing"). For adversarial pressure on the design before implementing, run the **interrogate** skill on the sketch.

## Phase D: Implement against the sketch
Replace `not implemented` bodies with code and pseudocode with logic. The sketch is the contract. Deviations are signal worth surfacing: if a function needs a parameter the sketch did not anticipate, ask whether the sketch was wrong, the requirement was missed, or the implementation is overreaching.

## Phase E: Scrap when the architecture is wrong
If implementation keeps producing friction the sketch cannot absorb, throw the sketch out rather than bolting on fixes. The signal is a *pattern*, not single instances: the same workaround shape recurring, many special-case branches, types needing escape hatches (`any`, casts, always-set optionals), a "we need a lock" reflex when the sketch said state was not shared, or callers needing to know the abstraction's internals. When you scrap: re-ground, redesign as if the new constraints were day-one, subtract before adding, and return to Phase B.

## Outputs
Write the caller's usage first and derive the type sketch from it. For small changes, one file with new types and signatures. For larger work, a module map plus type definitions. Ship a short rationale alongside naming the usage sketch and the design decision.

## Kiro adaptation
Delegate parallel design candidates via `invoke_sub_agent`. Route the hardest design reasoning to the strongest available model by role; Kiro selects the actual model. Do not hardcode model identifiers.