菜单
ALWAYS USE if you are the builder. Use after every implementation pass — update living docs, maintain diagrams (Mermaid for formal, ASCII for loose), reconcile plan with reality, update ARCHITECTURE.md when system shape changes. Documentation is a core output, not an afterthought.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | builder-living-docs-k |
| type | knowledge |
| description | ALWAYS USE if you are the builder. Use after every implementation pass — update living docs, maintain diagrams (Mermaid for formal, ASCII for loose), reconcile plan with reality, update ARCHITECTURE.md when system shape changes. Documentation is a core output, not an afterthought. |
| user-invocable | false |
Knowledge skill — Living documentation: what to update, when, how to keep diagrams honest.
Your primary job is code. But living docs are a core output — not a side quest you skip when tired. The next agent inherits what you leave behind. If the docs lie, the next session starts broken.
After implementation, these must reflect reality:
Changed system shape? → Update ARCHITECTURE.md
Changed data flow? → Update or create flow diagram
Changed class structure? → Update class diagram / ERD
Changed module boundaries?→ Update component diagram
Changed API contracts? → Update integration docs
Built something new? → Create living doc near the code
If you touched it and the docs don't match, you're not done.
Formal structure → Mermaid. Class diagrams, ERDs, sequence diagrams, state machines — anything with strict relationships and types. Mermaid renders cleanly, diffs well, and is parseable.
classDiagram
class Order {
+id: UUID
+status: Status
+place()
+cancel()
}
Loose structure → ASCII. Component layouts, data flows, system overviews, dependency arrows — anything showing how things fit together conceptually. ASCII is fast, flexible, and needs no tooling.
Request → Auth → Router → Handler → DB
↓
Response
Rule of thumb: if the diagram has types, fields, or method signatures — Mermaid. If it shows flow, boundaries, or composition — ASCII.
Plans are foresight. Living docs are hindsight. Your job is bridging the gap.
As you build, reality diverges from the plan. This is expected. Your duty:
{name}_decisions.md with what changed and whyDon't copy the plan into living docs. The plan says "here's what we intended." The living doc says "here's how it works now." Both exist. They tell different stories.
Living docs live near what they describe:
design-docs/ → system-level (repo root)
{package}/design-docs/ → package-level
{test-dir}/design-docs/ → test-level
Link every new living doc from ARCHITECTURE.md. If it's not linked, future agents won't find it.
Docs evolve. As understanding crystallizes:
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.
Cross-repo visibility for agent loops. Lists running, completed, and crashed loops. Reads the registry and per-repo tracking logs. Shows tmux attach commands. Use when checking what loops are active, what ran recently, or loop details.
Capture feedback about wf, util, or vault plugins and file it as a GitHub issue for improvement. Use after any session where the tooling fell short — wrong agent behavior, missing skill coverage, misleading prompts, workflow friction, or convention gaps. Only for generic plugin improvements that would help ANY project, not repo-specific config. Files to JSai23/claude-tooling with the plugin-feedback label.
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.