菜单
Surface the architectural rules applicable to a specific crate via `adr-fmt --context <CRATE>`. Use when an agent (especially oracle, moltke, hopper) needs the binding constraints for code in a crate before deciding or editing, or when the user asks "what rules apply to crate X?"
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.
Run `adr-fmt --lint` against the ADR corpus and triage diagnostics by namespace (T0xx template, L0xx links, S0xx supersedes/lifecycle, P0xx parser). Use when the user asks to lint ADRs, check ADR integrity, validate the corpus, or mentions "adr-fmt --lint".
List inbound References and Supersedes citations of a target ADR via `adr-fmt --refs <ADR_ID>`. Use when the user asks who references / supersedes / cites an ADR, wants to assess blast radius before changing an ADR, or mentions "adr-fmt --refs".
Print the ADR domain tree (parent → child via AFM-0020 parent-edge model) optionally filtered by domain prefix, via `adr-fmt --tree [DOMAIN]`. Use when the user wants to enumerate ADRs in a domain, see the architectural hierarchy, or mentions "adr-fmt --tree".
| name | adr-context |
| description | Surface the architectural rules applicable to a specific crate via `adr-fmt --context <CRATE>`. Use when an agent (especially oracle, moltke, hopper) needs the binding constraints for code in a crate before deciding or editing, or when the user asks "what rules apply to crate X?" |
Wrapper around adr-fmt --context <CRATE>. Resolves the set of rules
binding on a given crate by walking ADRs in the crate's domain plus
foundation domains (AFM-0015). Output is a flat, numbered rule list
each tagged with its source ADR + Meadows tier.
Crate name as it appears in adr-fmt.toml [corpus.crates] — e.g.
adr-fmt, cherry-pit-core, cherry-pit-gateway. Not the path; not
the package version.
If the user names a path (crates/adr-fmt) or a binary, normalise to
the crate name before invoking.
cargo run -p adr-fmt --release -- --context <CRATE>
Output structure:
# Architecture Rules
These rules are mandatory constraints for all code in crate `<CRATE>`.
Follow every rule without exception.
### <ADR-ID>. <Title>
- <rule text> [<ADR>:R<n>:L<tier>]
- ...
Tier suffix L1..L5 is Meadows leverage (AFM-0011 / AFM-0012). L1
is highest leverage (paradigm); L5 is parameters. When trade-offs
must be made between rules, higher leverage wins.
When invoked by another agent (oracle, moltke), prefer pointer over body if the rule list is long:
Run the command, capture full stdout.
If output > ~40 lines, write to .ooda/context-<crate>-<ts>.md and
return:
Crate: <CRATE>
Rules: <n> ADRs: <n> Tiers: L1=<n> L2=<n> L3=<n> L4=<n> L5=<n>
Artefact: .ooda/context-<crate>-<ts>.md
Top-leverage (L1–L2):
- <ADR-ID> <one-line summary>
- ...
If short, inline the full rule list verbatim.
[ADR:R:L] is part of the
rule and must be preserved when quoting.SEC-*) appear in every crate's
context — that's AFM-0015 working as intended, not duplication.| Caller | Why |
|---|---|
oracle | Architectural input to moltke's Decide phase |
moltke | Constraint set for option enumeration |
hopper | Pre-flight check before editing code in <crate> |
| user | "What governs this crate?" |