メニュー
Build and sharpen the project's domain terminology inline or via a batch glossary scan. Use when pinning down ubiquitous language, recording a domain decision, grill-with-docs crystallises a term, or refreshing docs/glossary.md.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Voice, tone, and format for the public Codemap docs (`apps/docs`, built with Blume). Use when authoring or editing apps/docs prose — landing, guides, concepts, recipes, reference, generated API — or deciding headline grammar, benefit framing, peer framing, or anti-pitch wording.
Repo-wide docs framework — what `docs/`, `docs/plans/`, `docs/research/`, `.agents/`, or any other doc-bearing surface in this repo looks like, what lifecycle each doc follows, and how to keep cross-references intact when slimming or moving content. Use when authoring or editing any `docs/**`, `docs/plans/**`, `docs/research/**`, `.agents/rules/**`, `.agents/skills/**`, or any new doc-bearing folder. Defines the lifecycle types (Reference / Roadmap / Plan / Audit / Research), the existence test every doc must pass, the closing-state lifecycles (delete + lift; never "Slim & keep in plans/"), the substrate variants (single `audit.md` vs `audits/<topic>.md`; conditional `glossary.md`), the surface tiers (repo-wide / per-tooling-area), and the cross-reference preservation discipline (grep before slim; preserve rule numbers cited from source). The Tier-2 priming layer at `.agents/rules/docs-governance.md` cites this skill and extends with codemap-specific bits only.
Bring a branch to pristine, maximum production readiness without changing PR intent — spawn parallel Task subagents (never inline review), fix in-bounds findings, loop autonomously until clean or pass cap, then report once. Use after a tracer-bullet commit (lite), before PR is done (full), on "harden", "harden-pr", "pristine", "review until clean", "production-ready pass", or "harden-pr reconcile". Invoking this skill authorizes one harden commit at cycle end. NEVER stop mid-loop to ask about commits, babysit, or the next pass. NEVER redesign the feature or change observable runtime behavior.
The product north-star — four Codemap tenets (structural over semantic, predicate-as-API, local-first / agent-native surfaces, honest scope). Use when making a design, API, or architecture decision, evaluating a trade-off, justifying a feature, or writing/reviewing a docs/plans entry.
Keep apps/docs in sync with merged product changes. On each run, audit recently merged PRs against docs content, update only drifted pages, regenerate API MDX when public exports/JSDoc drifted, verify with blume validate/check/build/audit, and open or update a docs/* PR — or report a clean no-op.
Delta-driven dependency upgrades — a script gathers the evidence, you read the artifact and judge. Use when the user asks to upgrade, bump, or CVE-audit dependencies.
| name | domain-modeling |
| description | Build and sharpen the project's domain terminology inline or via a batch glossary scan. Use when pinning down ubiquitous language, recording a domain decision, grill-with-docs crystallises a term, or refreshing docs/glossary.md. |
Actively build and sharpen the project's domain model as you design. Reading docs/glossary.md for vocabulary is a one-line habit any skill can do — this skill is for when you're changing the model, not just consuming it.
Codemap deltas for this repo:
docs/adr/ — current decisions live in docs/architecture.md; closed history in docs/audits/<topic>.md; in-flight in docs/plans/<name>.md. See docs-governance.docs/glossary.md at the repo root (Tier B: one repo-wide surface, no per-feature subtrees). See grill-with-docs/ARTIFACTS.md./
├── docs/
│ ├── glossary.md ← canonical ubiquitous language (single)
│ ├── architecture.md ← current structural decisions
│ ├── audits/<topic>.md ← closed decisions
│ └── plans/<name>.md ← in-flight decisions
Create files lazily — only when you have something to write.
When the user uses a term that conflicts with docs/glossary.md, call it out immediately.
When the user uses vague or overloaded terms (e.g. "query" for both a cataloged recipe and ad-hoc SQL, or "file" for both a FileRow TS shape and the files SQLite table), propose a precise canonical term.
Stress-test domain relationships with specific edge-case scenarios (homonym symbols across files, recipe vs ad-hoc query drift, hub vs barrel ranking, fan-in vs fan-out impact direction).
When the user states how something works, check whether the code agrees (src/db.ts, src/parser.ts, recipe loader, adapter layer). Surface contradictions — use codemap query for structural facts before Read/Grep.
When a term is resolved, update docs/glossary.md right there — don't batch. Use GLOSSARY-ENTRY.md.
docs/glossary.md is glossary only — no implementation details, not a spec or scratch pad.
Only when the decision is hard to reverse, surprising without context, and the result of a real trade-off. Route to architecture.md, plans/, or audits/ per docs-governance — not ADRs at repo root.
When the user asks to extract or refresh the full glossary (not one term at a time), follow GLOSSARY-SCAN.md.
Done when: resolved terms are in docs/glossary.md; contradictions with code surfaced or filed as follow-up.
docs-governancegrill-with-docs/ARTIFACTS.md