claude-code-playbook

Log a vault change (note created/edited/deleted) to a running daily changelog note. After any write to the vault, ask the user "should this be logged?" and run this skill on confirmation. Also runs directly when the user says /changelog.

Update a project's README and the relevant vault notes (overview / module map) after a meaningful code change — new feature, new file, new module, or an architectural decision. Should trigger on its own once a coding task is finished, without the user having to ask — skip it for trivial (typo/formatting) changes. Also runs manually when the user says "update the docs" or "document this."

Update "where we left off" tracking for {PROJECT} when a milestone or unit of work closes. Updates Status.md (active milestone + next concrete action) and Milestone_Log.md (chronological record); touches Goal.md/Decisions.md if needed. Called by project-orchestrator at the end of every milestone; also used directly when the user says "log this milestone" or "update status."

Design phase for {PROJECT} — data model, module boundaries, API contract, access control, and any multi-tenancy/security design, before code is written. Called by project-orchestrator before implementation; also used directly when the user says "design {PROJECT}'s X module."

Implementation phase for {PROJECT} — builds the actual code for a module or vertical slice against an existing design. Called by project-orchestrator once a design exists; also used directly when the user says "implement {PROJECT}'s X module."

Main orchestrator for building {PROJECT}. Tracks cross-session continuity, reads "where we left off," routes to the correct phase sub-skill, and runs autonomously. Use when the user says "continue {PROJECT}," "work on {PROJECT}," "{PROJECT} where did we leave off," or /project-orchestrator. This is for the BUILD side of {PROJECT} — not for unrelated day-to-day tasks about it.

Research and data-gathering phase for {PROJECT} — domain knowledge, reference data models, external API details, and a gap analysis against what already exists. Called by project-orchestrator when a module/topic's knowledge is missing; also used directly when the user says "research {PROJECT}'s X module."

Verification phase for {PROJECT} — unit and integration tests, isolation/access checks, and an end-to-end pass over the critical path for a completed slice. Called by project-orchestrator after implementation; also used directly when the user says "verify {PROJECT}'s X module" or "test this."

Formatting rules, folder structure, and note conventions for the Obsidian vault at {VAULT_PATH}. Claude must follow this skill whenever creating or editing any file under {VAULT_PATH}. This is the foundation skill — every other vault-facing skill assumes these conventions.

Record an architectural decision, a resolved bug's root cause, a coding standard, or a system configuration as a structured note in the vault. Use when the user says "remember this," "save this to the vault," "document this decision," or /decision-log.

Process freeform notes and dropped files in {VAULT_PATH}/Inbox.md and {VAULT_PATH}/Inbox_Files/ — classify each item and file it into the correct place in the vault. Use when the user says "process my inbox," "sort my notes," or /inbox-triage.

Aggregate all open tasks across the vault (personal, project-specific, deadline-driven) into one prioritized list. Use when the user asks "what do I need to do," "what's on my plate," "to-do list," or /task-list.

Look up information about a project, decision, or topic by searching {VAULT_PATH} before answering. Use whenever the user asks something like "how does X work," "what did we decide about Y," "remind me what Z was," or references a project/file by name. Always check the vault before answering from general recollection.