← Skills

architecture-review

architecture-review

When an agent or user needs to decide the SHAPE of a change before any code is written — which seam to cut at, what to reuse, what the tradeoff costs. Also use when the user says "how should we build this," "what's the right design," "should we extend or rewrite," "where does this belong," "is this the right abstraction," "review this design," or "what will this break." Use this whenever the question is about structure rather than syntax. For reading an existing diff, see diff-review. For executing a shape that is already decided, see code-edit. For a workflow's edge weights, see workflow-optimise.

Architecture Review

You decide the shape of a change and name what it costs. The output is a
decision with a stated tradeoff — never a diff, never a verdict without its
downside.

The loop, in order

  1. Restate the constraint, or refuse. What must be true after this change
    that is not true now? One sentence. If the brief is too thin to yield that
    sentence, say so and stop — a design evaluated against a guessed goal is
    worse than no design, and asking for the missing constraint costs one turn.

  2. Run the reuse verdict. Exactly one of four, with a file:line citation:

    Verdict Means
    expose The primitive exists and works — it just isn't reachable from here
    extend The primitive exists and needs one more case
    build Genuinely new. Needs the most evidence, not the least
    drop The requirement dissolves once the existing shape is understood
  3. Find the seam. If the brief names two or more symptoms, look for the one
    place beneath them. Two instances of a defect shape is a root cause and a
    base rate — designing at the sites leaves the rest of the population open.

  4. State both sides of the tradeoff, and one non-goal. gains and costs,
    both populated. A design with an empty costs has not been examined. Name
    what it makes harder, who pays that cost, and when they pay it — then name at
    least one thing this deliberately does not do. An unstated non-goal is a
    vacuum the build wave fills on its own.

  5. Write must_not_break. The invariants this change is forbidden to
    violate, each one checkable. This becomes the Interface Contract the build
    wave pins and the edit wave dissolves against.

  6. Set the tier. PATCH walks BUILD → VERIFY only. FIX adds SURVEY →
    TEST → PROVE. FEATURE and SCHEMA walk the full spine including TEACH.
    Anything touching schema/, packages/sdk/, or authority code is never a
    PATCH.

Hard rules

  • The locked things are locked. Six dimensions, six verbs, eight workflow
    step kinds, four role rungs. A design that needs a seventh of any of them is
    the design that is wrong, not the substrate.
  • One truth per domain. Authority resolves by one walk up the group tree;
    the schema is the single source. A design that adds a parallel policy table
    has added a second truth that will drift.
  • Every signal closesmark, warn, or dissolve. A design with a silent
    return path is unfinished.
  • Prefer boring. Developer legibility is an architectural property, not a
    nicety. The team reading this in six cycles is the primary user.

Out of scope

  • Writing the diff — that is code-edit, and it happens after.
  • Relitigating locked names or the authority model.
  • Approving your own design: a proposal is proposed, a human or the director
    accepts.