architect
Skill626 starsChanged 4 months agoMITView on GitHub
Use when the user asks to architect, run or continue the autonomous software factory, turn a goal into a hardened tracker issue plan, dispatch builder jobs, grade finished work, diagnose blockers, or finish a factory run.
174 other projects use a version of this.
Adopted by
Most recently taken up by
- Yeachan-Heo/oh-my-claude-sisyphustheir own version, first seen Nov 8, 2026
- caidanw/skillstheir own version, first seen Nov 8, 2026
- pascalorg/editortheir own version, first seen Nov 8, 2026
- Yeachan-Heo/oh-my-claudecodetheir own version, first seen Nov 8, 2026
- naman10parikh/pennytheir own version, first seen Nov 8, 2026
- afawfawffaf/my-skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use ecosystem-reference, fractal-delegation and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
naman10parikhSkillecosystem-reference
Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.
Also in 5 projects that use this
naman10parikhSkillfractal-delegation
Also in 5 projects that use this
tristanphvnSkillketchup-video
Catch the user up like /keel:ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /keel:ketchup-video.
Also in 14 projects that use this
jaydubya818Skillfigure-it-out
Use when novel or multi-phase work needs an auditable workflow and no narrower playbook fits.
Also in 55 projects that use this
ianclearySkillprinciple-explain-the-number
Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.
Also in 29 projects that use this
eryzerzSkillmake-bot-ui
Use when building a custom UI (page, dashboard, buttons) that should wake a Grok Bot over a webhook, when the user must provide a webhook sender key, or when exposing that UI on Tailscale.
Also in 20 projects that use this
- +6 more from naman10parikh
Other versions174 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 174
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- pascalorg/editor★ 25ksame name
- backnotprop/pstack★ 3.8ksame name
- agenticnotetaking/arscontexta★ 3.5ksame name
- jsmastery-pro/skills★ 1.4ksame name
- SethGammon/Citadel★ 927same name
- moeru-ai/xsai★ 667same name
- Hainrixz/the-architect★ 562same name
- Trevoke/org-gtd.el★ 485same name
164 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- adversarial-reviewSkill
- architect-fastSkill
- architect-researchSkill
- codebase-designSkill
- final-reviewSkill
- frozen-checksSkill
- integrateSkill
- tddSkill
- to-issuesSkill
- to-specSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 2 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 162 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 57
No approval gate exists anywhere.
- Distinctive: line 78
Read in authority order: CLAUDE.md/AGENTS.md, README.md, architecture docs, active spec, open issues, reports, checks, branches.
- Very specific: line 80
Run skills/architect/ground.ps1|.sh <run> and rule on its typed exit: 0 GROUND: OK proceed (read FRONTIER: for ready issues).
- Very specific: line 82
STOP halt before dispatch.
- Very specific: line 136
Run loop.md ## Factory block procedure to completion: dispatch ready issues to the cap, sleep, wake on events, grade with the check-runner, …
- Distinctive: line 153
When every build issue closes, run the closing test pass: builder-built suites plus every frozen RUN item at the factory branch head, raw …
- Very specific: line 180
Stop and ask the human when: docs/STOP or docs/runs/<run>/STOP exists.
“Common” is measured: kept by at least 6 in 10 of the 162 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Architect
You are the orchestrator: the session the human already opened, not a config role. The repo is memory; tracker issues are the durable coordination state. You ground, dispatch strategist work, freeze, dispatch builders, rule, merge, and digest. Strategists design and review; builders implement; the watchdog detects; the check-runner grades. Never collapse these roles.
Stage skills own each stage's craft; this file owns order, invariants, and
seams. Invoke stage skills explicitly — a stage skill returns here and never
invokes a peer. Mechanics: dispatch.md (templates, routing), loop.md
(event loop), tracker.md (modes), research.md (fan-out). Rationale:
DESIGN.md.
Hard Rules
- Not in the tracker means it did not happen. Issues and comments are the coordination log; job reports and git evidence mirror there.
- Checks freeze in git before dispatch. Frozen checks live under
docs/checks/, freeze at one commit, then are read-only; a builder edit there is an automatic FAIL. A frozen RUN command's dependency files — the tests, validators, and scripts it executes — share that surface: out of MAY TOUCH by default; in-bounds edits must be disclosed in the job report and re-verified before a green counts. - Nobody grades their own work. Builders report raw evidence; the check-runner grades every frozen RUN item; one fresh strategist runs the final review — the loop's only model review — reporting and decomposing, never editing. Never merge over a red checkrun; never skip the final review without a recorded ruling.
- The orchestrator writes implementation code only on a third strike
(loop.md
## Failure ladder), graded like any builder's work. It never reads large diffs; strategist or read-only verification subagents do. - Fresh builder per issue, worktree-isolated. On blockers or wedged worktrees, answer durably and respawn from the issue and frozen check.
- Roles are set before decomposition. The orchestrator is this session; strategist and builder models come from config and dispatch rules. Failure never moves builder tier.
- Builders never commit. The orchestrator owns commits, merges, and closure, after checkrun evidence.
- Execution-conflict check is mandatory. PHASE 0 states the plan and every conflict with the slice's spec, checks, job authority, or live dependencies with evidence, or what was checked before finding none.
- No silent fallback. Record every precondition, blocker, missing tool, and sandbox limit; fix the input or route to a hard stop.
Timed-ruling protocol
No approval gate exists anywhere; the human steers by editing the spec,
commenting rulings, vetoing digests, or docs/STOP. Every human question
routes through this protocol, human present or not — never a blocking
question UI:
- Print question, options, recommended default in-session; mirror as a
RULING PENDINGtracker comment naming the default. - Arm ~5 minutes: detached background
sleep 300whose exit wakes the loop (foreground sleep with raised timeout where background wakes don't exist). - Answer first: apply and kill the timer. Timer first: apply the default,
record
RULING (auto, 5m silence): <decision> - <why>on the tracker. Irreversible or destructive choices resolve silent to the non-destructive path;docs/STOPis absolute.
Procedure
0. Ground
At every factory block boundary. Load codebase-design first and use its
glossary exactly.
- Read in authority order:
CLAUDE.md/AGENTS.md,README.md, architecture docs, active spec, open issues, reports, checks, branches. - Run
skills/architect/ground.ps1|.sh <run>and rule on its typed exit: 0GROUND: OKproceed (readFRONTIER:for ready issues); 2GROUND: STOPhalt before dispatch; 3GROUND: DRIFTrule on the tracker/git disagreement; 5GROUND: ERRORfix the script input. Detection only. - Resolve roles: orchestrator is this session;
strategistandbuildersfrom.architect/config, then~/.architect/config, then dispatch.md## Model alias table. Verification subagents run at the builders model.
1. Intake
Feed the goal straight in — no question batch; open questions become timed
rulings recorded as ## Assumptions.
Preflight per tracker mode (tracker.md ## Preflight per mode). Canary
each candidate backend once — list tools, git log -1 --oneline, reply
CANARY: SHELLS_OK|DEGRADED; on DEGRADED select the fallback backend and
record the substitution. Never switch backend mid-wave.
Dispatch a fresh strategist to write the spec with to-spec; it returns
SPEC DRAFT: <path> plus RULING NEEDED: questions. Rule them and fold the
outcomes into ## Assumptions — the strategist never commits or touches the
tracker. Cut factory/<run> and commit the spec there; main stays untouched
until the closing PR. One run per checkout; concurrent runs get their own
worktrees (.architect/runs/<slug>). Create the tracking issue (spec
pointer, assumptions digest, run marker, manifest path) and write the
manifest — a local gitignored run artifact like all of docs/runs/ and
docs/jobs/. Append status breadcrumbs to
docs/runs/<run>/status-events.jsonl as JSONL with time, stage,
state, and optional note; stages are spec, harden, publish,
freeze, closing-test, final-review, fix-wave, integrate, and
finish.
2. Harden
Dispatch one fresh strategist over the committed draft. It runs
adversarial-review: attacks the spec, folds surviving findings into a
revised spec, compiles it into issue drafts with to-issues
(publish-ordered under docs/runs/<run>/issues/), drafts graded checks with
frozen-checks under docs/checks/<run>/ (each issue links its check),
then stress-tests its own decomposition, executing every draft RUN item and
resolving every pointer. It returns the revised spec, issue drafts, check
drafts, and findings ledger; it never commits or touches the tracker.
3. Publish and freeze
Rule on the drafts, commit the revised spec, publish the sub-issues with
native edges (dispatch.md ## Issue conventions), and own the freeze
commit — committed on the factory branch and pushed. preflight.ps1|.sh
verifies worktree, freeze, and a frozen-file spot-check; builders still
FIRST-ACTION verify. Record freeze SHA, stress result, and plan on the
tracking issue. Re-planning is orchestrator-owned: diagnose, optionally fan
out researchers (research.md), amend spec/issues/checks in git and
tracker, respawn fresh. Builders never re-plan.
4. Factory loop
Run loop.md ## Factory block procedure to completion: dispatch ready
issues to the cap, sleep, wake on events, grade with the check-runner, merge
through postflight, ladder failures, respawn blocked jobs fresh. Builders
default to codex-CLI jobs (codex/best); Claude-native Agent-tool jobs
(architect-builder def) are the config alternative and codex-absent
fallback. Status requests: run skills/architect/status.ps1|.sh <run> and
print verbatim; use -Compact / --compact only for debugging or scripts
that need the legacy line tree. Post-freeze rulings are append-only in
docs/jobs/<run>/<issue-slug>-rulings.md, mirrored to the issue. Calibrate
open-ended reviews verbatim: "Flag only gaps that affect correctness, the
stated requirements, or documented project invariants -- cite file:line
evidence for every finding. Do not report stylistic preferences." Record
docs debt as it accrues; codify diagnoses through integrate's docs pass,
never mid-run.
5. Finish
When every build issue closes, run the closing test pass: builder-built
suites plus every frozen RUN item at the factory branch head, raw output
captured. Then one fresh strategist (MEDIUM effort, worktree from the
factory branch head) always runs final-review, dispatched by citing the
installed user-level skill text by explicit path, with the test-pass output
and every rulings file in its dispatch block. It reports and decomposes,
never edits. REVIEW: GREEN: post the verdict and go to integrate.
REVIEW: FINDINGS n=<count>: harvest the review spec, fix-issue drafts,
and check drafts; discard the reviewer worktree; run the frozen-checks
freeze gate over every draft RUN command (amendments recorded as rulings);
commit them as the fix-wave freeze; update the tracking-issue body's freeze
record (prior SHAs stay in comments); file the fix issues as sub-issues;
post verdict plus fix list as the digest. Dispatch the fix wave through the
wave machinery at the builders tier: single review cycle, no re-review; a
fix issue closes by merge or recorded ruling (ruling-closed findings land
in the digest as residual risks).
Then dispatch one integrate subagent (integrate stage skill) — never the
orchestrator — after the fix wave merges, a GREEN verdict, or a recorded
ruling skips the review. Its dispatch block carries the change-context
digest: shipped issues, diffstats, rulings pointers, docs debt, domain
language changes. First step is the docs pass; then remaining merges,
ship-time conflict resolution, PR or markdown finish prep, and the digest
draft. The orchestrator rules on the result and posts the digest.
Hard Stops
Stop and ask the human when: docs/STOP or docs/runs/<run>/STOP exists;
an irreversible or destructive action is needed; two consecutive KILL
decisions occur; a blocker collides with a recorded assumption; scope grows
beyond the hardened spec; required tracker preflight cannot be satisfied.
Maintenance
Re-read against each new model generation; delete what models now do
unprompted — Hard Rules are invariants, the rest is prunable. Re-run
docs/evals/trigger-prompts.md. No feature ships without evidence in
DESIGN.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

