Architect

Design the shape of a non-trivial module, API, or system before implementing it. Use when a design decision has more than one reasonable answer, when introducing a new abstraction or interface, or when getting the shape wrong would be expensive to undo.From its SKILL.md

Install

npx -y skills add vasu-devs/Forge --skill architect

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.2 KB, 932 tokens by cl100k_base, as published. Nobody here has run it

 █████╗ ██████╗  ██████╗██╗  ██╗██╗████████╗███████╗ ██████╗████████╗
██╔══██╗██╔══██╗██╔════╝██║  ██║██║╚══██╔══╝██╔════╝██╔════╝╚══██╔══╝
███████║██████╔╝██║     ███████║██║   ██║   █████╗  ██║        ██║
██╔══██║██╔══██╗██║     ██╔══██║██║   ██║   ██╔══╝  ██║        ██║
██║  ██║██║  ██║╚██████╗██║  ██║██║   ██║   ███████╗╚██████╗   ██║
╚═╝  ╚═╝╚═╝  ╚═╝ ╚═════╝╚═╝  ╚═╝╚═╝   ╚═╝   ╚══════╝ ╚═════╝   ╚═╝

Architect the shape first

Code is easy to write and hard to reshape. The interface you choose outlives the implementation. This skill produces a deliberate design instead of the first one that compiles.

1. Search before you build

Before designing anything custom, decide where this work belongs on the ladder:

Adopt — a library/tool already does this well. Use it.
Extend — something close exists; extend it.
Compose — combine existing pieces.
Build — only when the above genuinely don't fit.

Check package registries, the existing codebase, and installed skills/MCP tools first. Report what you found and why you're building rather than adopting. Most "new" problems are solved problems.

2. Design it twice (at least)

Never ship the first design. Generate 2-3 genuinely different designs, each forced apart by a different constraint:

minimize the interface surface
maximize flexibility
optimize the common case
imitate a known, well-understood paradigm
survive failure well (idempotency, partial-failure, retries, backpressure)

If subagents are available, dispatch them in parallel — one design each — so the options don't converge. Then compare.

3. Judge on depth, not effort

A deep interface is small but hides significant complexity (good). A shallow one is a large surface over a thin implementation (bad — it just relocates complexity onto callers).
Optimize for ease of correct use and hardness of misuse.
Do not rank designs by how much code they take to implement — that's the cheapest part and the wrong axis.
Record the decision, including the losers. Output a short comparison (each design × how it scores on the constraints / its key failure mode) and one sentence per rejected design saying exactly why it lost. A design chosen with no written loser isn't a decision — it's the first thing that compiled.

4. Earn every abstraction

Deletion test: imagine deleting this module. If the same complexity reappears, duplicated across N callers, the module earned its place. If not, you're abstracting for its own sake — don't.
Two-adapter rule: one adapter is a hypothetical seam; two real adapters prove a seam exists. Don't introduce an interface for a single implementation "in case." (This is forge:principles #2 applied to structure.) Exception: a test double or an external-boundary port (network, clock, third-party API, persistence you'll mock in tests) is the second adapter — seam it.

5. Name and record

Name every concept in the project's ubiquitous language — one canonical term per idea, aliases explicitly retired. Update CONTEXT.md.
Record an ADR only when the decision is hard to reverse and surprising without context and a real trade-off. Capture the decision and why, not file locations (those rot).

Exit

Hand the chosen shape to forge:plan to break into vertical slices, then forge:tdd to build.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most architecture codebase skills give in 932 tokens

Counted across 858 of the 1,304 authors here whose files we hold, read 2026-09-06

Apply the deletion test to identify shallow modulesin 32 of 858, across 31 files
Read domain glossary and ADRs before exploringin 22 of 858, across 19 files
Use Tailwind and Mermaid via CDN for reportsin 21 of 858, across 18 files
Document architecture decision recordsin 20 of 858, across 12 files
Offer to record ADRs for rejected candidatesin 17 of 858, across 14 files
Limit primary navigation to four to seven itemsin 17 of 858, across 7 files
Write HTML report to the system temp directoryin 17 of 858, across 14 files
Read product marketing context before asking questionsin 16 of 858, across 6 files
Use Mermaid graph TD for visual sitemapsin 15 of 858, across 5 files
Ensure every page has at least one internal linkin 15 of 858, across 5 files
Use ASCII tree format for page hierarchy draftsin 15 of 858, across 5 files
Enforce lowercase URLs with hyphensin 15 of 858, across 5 files

Said here and by no other author read

Search existing libraries before building custom solutions
Generate at least two distinct design options
Force designs apart using different constraints
Optimize for ease of correct use
Require two adapters to justify an interface
Use project ubiquitous language for naming

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.