architect

Find the architectural friction in a codebase and propose refactors that make it deeper, more testable, and easier to navigate. It produces an RFC, not code.

What it does

Surface where the code fights you, then design the interface that removes the fight. It's framed on a single lens — shallow vs deep modules (Ousterhout): small interfaces hiding large implementations beat big interfaces exposing small ones.

This skill analyzes and proposes; it does not refactor. The output is a written RFC that you (or implement) can act on.

Vocabulary it uses consistently: module · interface · depth · seam (where you'd test/substitute) · adapter · leverage (how much one change buys) · locality (what lives together).

Flow

1. Read the ground truth first. Any CONTEXT.md/domain glossary, existing ADRs, and the README — don't re-litigate decisions already recorded in an ADR.
2. Explore for friction, not rules. Walk the relevant area and surface shallow modules (thin wrappers, pass-through interfaces), tight coupling between things that should be independent, and untested seams — reported with file:line evidence, not a generic checklist.
3. Generate rival designs in parallel. For the worst 1–2 friction points, draft genuinely different interfaces — minimalist, flexibility-first, caller-optimized, ports-&-adapters — and compare depth, blast radius, and migration cost.
4. Recommend one. State the winner and why, and name what you'd graft from the runners-up.
5. Write the RFC. Save to docs/rfcs/<slug>.md: problem + evidence, options with tradeoffs, the recommendation, and a phased migration path.

If the friction is small, it says so and proposes the smallest change instead of a rewrite.

When to use it

When you say "architect", "improve the architecture", "this is hard to test/change", or ask how to restructure a module or subsystem.