architect-boot
Skill145 starsChanged 20 days agoMITView on GitHub
Use when architecture work starts or a tech-stack or pattern decision emerges — injects the project ADR index (docs/adlc/memory/adr/, legacy .adlc/memory/adr/ fallback) as session context and suggests the decision for capture via /architect-specify (never writes drafts itself); invoked from team-boot's Class Boots catalog.
In this repository48 other files it gives its agents.
- architect-analyzeSkill
- architect-clarifySkill
- architect-implementSkill
- architect-initSkill
- architect-specifySkill
- writing-skillsSkill
- change-bootSkill
- change-clarifySkill
- change-initSkill
- change-publishSkill
- change-specifySkill
- evals-analyzeSkill
- evals-clarifySkill
- evals-implementSkill
- evals-initSkill
- evals-specifySkill
- evals-validateSkill
- factory-cleanSkill
- factory-initSkill
- factory-intentSkill
- factory-learnSkill
- factory-missionSkill
- factory-orchestratorSkill
- factory-queueSkill
- factory-releaseSkill
- factory-reviewSkill
- factory-runbookSkill
- factory-setupSkill
- factory-ticketsSkill
- mission-briefSkill
- product-analyzeSkill
- product-bootSkill
- product-clarifySkill
- product-implementSkill
- product-initSkill
- product-roadmapSkill
- product-specifySkill
- team-bootSkill
- team-constitutionSkill
- team-diagnoseSkill
- team-discoverSkill
- team-initSkill
- team-levelupSkill
- team-repairSkill
- team-setupSkill
- team-skillsSkill
- workspaceSkill
- tech-radar-bootSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Never defer to session end.
- Very specific: line 50
If neither exists but docs/adlc/memory/adr/ADR-*.md or legacy .adlc/memory/adr/ADR-*.md files do, synthesize a lean table from each file …
- Very specific: line 56
When no local memory index exists in the current working directory and the directory sits inside a workspace (detected via a .gitmodules …
- Very specific: line 64
Check .adlc/drafts/adr/ for ADR-*.md files with status: proposed in frontmatter.
- Very specific: line 119
Never write a draft (or any file) yourself — /architect-specify writes the .adlc/drafts/adr/ draft when the user runs it, and …
- Distinctive: line 123
Add/refresh rows in Team Context & Decisions (ID | Name | Type | Rel | Status | Clarify) for every ADR-class decision detected this session …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
architect-boot
Overview
One of the five class boots surfaced by team-boot's Class Boots
catalog. team-boot injects the always-relevant team context (constitution,
CDR index, skills registry) at session start; this skill loads the
architecture decision layer on demand — the Accepted ADR index from
project memory — and pairs it with a capture suggestion so new architecture
choices are routed to /architect-specify rather than evaporating. The boot
never writes files: it suggests the capture skill, and the user runs it.
Reading decisions and recording decisions are one loop: existing ADRs inform the work; decisions made during the work flow back into the same record system through the capture skill.
When to Use
Invoke at the START of a matching task — before planning the todo list and before implementation — so the ADR context informs planning. Never defer to session end.
Invoke when:
- Starting architecture work (system design,
AD.mdgeneration, cross-subsystem refactoring, dependency changes). - The session turns architectural mid-flight: a tech-stack choice, pattern selection, or "we chose X over Y" moment emerges.
- Reviewing or validating an architecture and you need the decision backdrop.
For technology selection, also invoke tech-radar-boot — radar context
should inform the ADR.
Core Process
Step 1: Locate the ADR Index
From the current working directory (do NOT walk up parent directories):
- Primary:
docs/adlc/memory/adr/adr.md(generated/architect-implement; rows start| ADR) - Fallback:
.adlc/memory/adr/adr.md(legacy layout, legacy)
If neither exists but docs/adlc/memory/adr/ADR-*.md or legacy
.adlc/memory/adr/ADR-*.md files do, synthesize a
lean table from each file (ID from filename; Sub-System/Decision/Status
from frontmatter or first heading). If the directory is empty or absent,
report 0 ADRs — never fabricate rows.
When no local memory index exists in the current working directory and the
directory sits inside a workspace (detected via a .gitmodules marker in an
ancestor), read the workspace root's docs/adlc/memory/ index instead
(the dual-read order applies: docs/adlc/memory first, legacy
.adlc/memory fallback).
Step 1b: Read the ADR Drafts Index
Check .adlc/drafts/adr/ for ADR-*.md files with status: proposed in
frontmatter. These are draft ADRs pending clarification. Collect ID /
Title / Type / Status / Date from each file. If the directory is empty or
absent, report 0 pending drafts.
Absent Context
If team-boot injected no team context this session (no Team Context & Decisions section in the first user message — unconfigured project or hook failure): say so in one line, emit the section heading with a 0 ADRs matched (no team context injected — run /team-setup) source line, and continue the task on the directly-read ADR index. Never treat a missing injection as an empty record set. Recovery: run /team-diagnose.
Step 2: Inject ADR Context (Output Contract)
Emit before the task answer:
## ADR Context
| ID | Sub-System | Decision | Status |
|--|--|--|--|
| ADR-001 | lanes | Workflow lanes over flat queue | Accepted |
_Searched N ADRs, K matched._
## Drafts Pending Review
| ID | Title | Type | Status | Date |
|----|-------|------|--------|------|
| (from .adlc/drafts/adr/) |
_N pending drafts — run /architect-clarify to review._- Render ID / Sub-System / Decision / Status from the index (the full index
also carries Date, Decision Makers, File — read the individual
ADR-*.mdwhen a task matches a row). N= total index rows;K= rows relevant to the current task. K MUST equal the table rows shown. 0 rows matched → emit the section heading + the_Searched N ADRs, K matched._line only — no table. A 0-row table header collapses into unrendered single-line markdown; never emit one. Emit the section as markdown blocks — heading, table rows, and counts line each on their own lines.
Step 3: Suggest Architecture Decision Capture
| Trigger | Action |
| Tech stack choice, "we chose X over Y" | ADR → suggest /architect-specify (pull tech-radar-boot context first) |
| Pattern selection, structural refactor | ADR → suggest /architect-specify |
| ADR-class decision already in the ledger | verify the suggestion was surfaced; if not, re-surface |
Emit one line per detected decision, in the visible response:
_Suggested capture: <decision name> → run /architect-specify._Never write a draft (or any file) yourself — /architect-specify writes the
.adlc/drafts/adr/ draft when the user runs it, and /architect-clarify
gates it afterwards.
Add/refresh rows in Team Context & Decisions (ID | Name | Type | Rel |
Status | Clarify) for every ADR-class decision detected this session —
including ones from before this boot was invoked. Mirror each decision as a
task-list todo (suggest /architect-specify → matching clarify skill at
session end for drafts that exist); after
code-modifying tasks, add a trailing todo to sweep Team Context & Decisions until
Unrecorded: 0 pending · Unclarified: 0 drafts (a draft leaves Unclarified
only via its clarify skill or an explicit user handoff to a named clarify or execute skill). At session end,
deliver the clarify prompt naming each uncaptured decision (ID + capture skill)
and each captured ADR draft in .adlc/drafts/adr/ (ID + clarify skill); if the
user defers clarify, mark those rows handed off.
Failure Handling
- Missing index + missing records → emit the section heading +
_Searched 0 ADRs, 0 matched._only — no table — and continue the user's task; never block. - Unparseable index rows → skip malformed rows, note the skip count.
Red Flags
- Fabricating ADR rows or inflating K beyond the table shown.
- Injecting the index but ignoring the capture suggestion — the pairing is the point.
- Writing a draft (or any file) yourself — the boot only suggests;
/architect-specifywrites. - Walking up parent directories to find
.adlc/. - Tech-selection ADRs recorded without radar context when the radar is available.
Verification
- ADR Context table emitted with
_Searched N ADRs, K matched._(K = table rows). - Detected ADR-class decisions added as Team Context & Decisions rows.
- No files written; each detected ADR-class decision carries a
_Suggested capture: … → run /architect-specify._line. - Tech-selection decisions routed through
tech-radar-boot→/architect-specify.
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.

