// Maintain project documentation synchronized with code. Keep feature specs, API contracts, and README current with init-project standards. Use when updating docs after code changes, adding new features, or ensuring documentation completeness.
| name | Documenting Code |
| description | Maintain project documentation synchronized with code. Keep feature specs, API contracts, and README current with init-project standards. Use when updating docs after code changes, adding new features, or ensuring documentation completeness. |
All documentation follows init-project conventions:
docs/feature-specs/F-##-slug.yaml, docs/user-stories/US-###-slug.yamltitle, status, last_updated fieldsReference /file-templates/init-project/CLAUDE.md for full conventions.
Required docs (from init-project template):
docs/product-requirements.yaml - Project goals, scope, features, success metricsdocs/feature-specs/F-##-*.yaml - One per F-## featuredocs/user-stories/US-###-*.yaml - One per user storydocs/user-flows/*.yaml - Primary user flowsdocs/api-contracts.yaml - API endpointsdocs/system-design.yaml - Architecturedocs/data-plan.yaml - Metrics and data storagedocs/design-spec.yaml - UI/UX specificationsBefore making changes, understand what exists:
docs/product-requirements.yaml for feature list and current statusdocs/feature-specs/ for existing feature documentationdocs/api-contracts.yaml for API coverageFor feature changes:
docs/feature-specs/F-##-*.yaml with new requirementsdocs/api-contracts.yamldocs/product-requirements.yaml if scope changedFor new features:
docs/feature-specs/F-##-slug.yaml following init-project templatedocs/api-contracts.yaml if applicabledocs/user-stories/US-###-slug.yaml if neededChecklist before finalizing:
title, status, last_updated)Keep main README current:
Update specific documentation:
/manage-project/update/update-feature # Update feature specs
/manage-project/add/add-api # Add API endpoints
/manage-project/update/update-design # Update system design
/manage-project/update/update-requirements # Update success metrics
Validation commands:
/manage-project/validate/check-consistency # Verify all IDs linked correctly
/manage-project/validate/check-coverage # Verify no orphaned docs
/manage-project/validate/check-api-alignment # Verify API alignment
Bash utilities (from docs/ directory):
./check-project.sh # Full validation
./list-features.sh # Show all features
./list-stories.sh # Show all stories
./list-apis.sh # Show all API endpoints
F-##-slug.yaml following templateapi-contracts.yaml and corresponding feature specsDefines required structure, frontmatter format, and best practices for SKILL.md files. Use BEFORE creating or editing any skill - this is the spec to follow, not optional reference.
Diagnose and fix bugs through systematic investigation, root cause analysis, and targeted validation. Use when something is broken, errors occur, performance degrades, or unexpected behavior manifests.
Systematically evaluate code changes for security, correctness, performance, and spec alignment. Use when reviewing PRs, assessing code quality, or verifying implementation against requirements.
Systematically trace code flows, locate implementations, diagnose performance issues, and map system architecture. Use when understanding how existing systems work, researching concepts, exploring code structure, or answering "how/where/why is X implemented?" questions.
Coordinate concurrent task execution through agent delegation. Plan independent work, manage dependencies, and execute multiple agents simultaneously. Use when handling multiple unrelated tasks, research investigations, or layer-based implementations that can run concurrently.
Create structured implementation plans before coding. Use when breaking down complex features, refactors, or system changes. Validates requirements, analyzes codebase impact, and produces actionable task breakdowns with identified dependencies and risks.