메뉴
Update project-facing documentation after a user-visible behavior, configuration, operation, or workflow change.
| name | update-project-docs |
| description | Update project-facing documentation after a user-visible behavior, configuration, operation, or workflow change. |
| metadata | {"version":"1.1.0"} |
Use this skill when a change affects user-visible behavior, configuration, operations, or developer workflows and project-facing documentation must stay in sync.
Use documentation-and-adrs first when it is unclear whether the change needs an
ADR, project documentation, interface documentation, a runbook, or no durable
documentation. Use write-adr as well when the change records a durable
architectural, product, data, security, or workflow decision.
Use this skill when you need to update:
Use write-adr instead when the main task is recording a durable architectural
decision rather than updating usage or operational documentation.
List what changed from a reader's perspective, for example:
If the change is not reader-visible, keep documentation updates minimal and explain why no durable docs changed.
Inspect existing documentation before editing. Prefer updating the canonical source that readers already use instead of creating duplicate explanations. Match the existing documentation's terminology, heading style, link style, and level of detail unless those conventions are inaccurate for the change.
If a documentation page is generated, synced, or derived from another file, edit the source of truth instead of the generated target unless the project explicitly requires a local exception.
Common surfaces include:
Make focused edits that preserve the existing structure and style.
If the change introduces or modifies configuration, document:
When the change affects operations, document practical details such as:
If the project maintains release notes or a changelog, add or update the relevant entry. If no durable release file exists, prepare a concise handoff note that covers:
Review the final documentation as a reader would.
Create, update, or review Agent Skill directories and SKILL.md files for valid frontmatter, structure, portability, progressive disclosure, and validation readiness.
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
Discover and run the project's local formatting, linting, static analysis, test, and build checks before handoff.
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Add logs, metrics, traces, profiling, or operational notes for meaningful workflows without unsupported performance claims.
Design stable APIs, module contracts, schemas, component boundaries, command interfaces, or other public integration surfaces that are predictable, documented, and hard to misuse.
