mcpField
A
architect

architect

github.com/yeachan-heoOther40.7k8 installsUpdated today
Repository

About architect

architect is a design skill for changes that cross module or API boundaries. It compares competing designs, records why one was chosen, and passes the decision and invariants to implementation without implementing the change itself.

Key features

  1. 01Frames problems and invariants
  2. 02Explores competing designs
  3. 03Compares boundaries and migration costs
  4. 04Records decisions and rejected options
  5. 05Hands off design to implementation

Use cases

  1. 01Planning a new module
  2. 02Changing a shared API or signature
  3. 03Choosing a data shape for multiple consumers

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill architect

After installing, type/architectin Claude Code to confirm it loaded.

Bundled filesreferences/design-red-flags.mdreferences/rationale-template.md

Details

From the project README

Architect

Design before steel. When a change crosses a function boundary, explore competing shapes first and commit to one with a written rationale — the cheapest moment to reject a design is before it has code on it.

When to use

  • new module, new API, changed signature other files call
  • a data shape that more than one consumer will encode
  • the user asks for a design or says "before you build this..."

When not to use

  • contained single-file changes — build directly
  • reviewing an existing design — review

Workflow

  1. Frame: name the problem in one sentence, the consumers of the design, and the invariants it must preserve.
  2. Explore 2-3 competing designs in parallel — dispatch oh-my-claudecode:architect subagents, each producing: the core types, the module boundary, the API surface, and how each invariant is preserved. Distinct shapes, not variations of one idea.
  3. Compare criterion by criterion: API surface size, boundary clarity, invariant preservation, migration cost, deletion ease. Tie-break toward the smaller API and cleaner boundary (minimal-code-discipline).
  4. Record the decision: chosen design, why the losers lost, and an accepted-deviations register the implementation will reconcile against (each deviation: what changed vs the sketch, and the acceptance source).
  5. Hand off: the design and its invariant list travel with the execute brief; implementation reconciles deviations rather than rediscovering the design.

Rules

  • No design is recorded without at least one rejected alternative and the reason it lost.
  • Types before wiring; data shapes before functions that move them.
  • The output is a design plus a decision record, never an implementation.

Comments

Markdown supported