Documentation finalization
Skill Grimblaz/agent-orchestra/skills/documentation-finalization
Documentation finalization workflow for accuracy, cleanup, and design-doc maintenance. Use when updating implementation-facing docs, synchronizing design documents with shipped behavior, or removing obsolete documentation. DO NOT USE FOR: formal specification drafting (use specification-authoring) or source-code implementation decisions (use implementation-discipline)From its SKILL.md
npx -y skills add Grimblaz/agent-orchestra --skill documentation-finalizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.6 KB, as published. Nobody here has run it
Documentation Finalization
Reusable documentation-finalization process for implementation and design updates.
When to Use
- When implementation changed names, behavior, file paths, or architecture references in docs
- When a design document in
Documents/Design/must be created or updated for the current domain - When obsolete placeholders, duplicate guidance, or stale references must be removed before completion
- When documentation work needs a consistent finalization checklist rather than ad hoc edits
Purpose
Make documentation reflect the shipped state of the repository. Treat deletion of stale content as first-class work, and verify every technical statement against implementation before leaving the documentation phase.
Documentation Areas
Development Docs
- Update current-state, setup, architecture, and workflow documents to match the implementation
- Replace outdated file paths, names, timelines, and phase markers
- Remove "not yet implemented" language once behavior exists
Design Docs
- Keep terminology aligned with actual classes, methods, scripts, headings, and behaviors
- Refresh examples, formulas, schemas, and interaction descriptions to match current behavior
- Remove placeholders such as
TBD,coming soon, or obsolete alternative designs
Decision Docs
- Update existing ADRs when a shipped decision changed
- Create or refine decision records only when implementation introduced or documented an actual decision
- Remove obsolete decision records only when a newer source of truth fully supersedes them
Domain Design Docs
- Prefer updating an existing domain file when the feature extends an established design area
- Create a new
Documents/Design/{domain-slug}.mdfile only when no current domain doc covers the feature area - Keep domain docs focused on the current design state, not as per-issue changelogs
Documentation Maintenance Responsibilities
The documentation specialist is responsible for maintaining:
- CHANGELOG.md: Update BEFORE merge - add entry during PR documentation finalization.
- NEXT-STEPS.md: Update BEFORE merge - update priorities during PR finalization.
- QUICK-START.md: Update when tooling or setup instructions change.
- Documents/Decisions/: Create new decision records from issue body design content during the implementation phase - keep existing ADRs accurate.
- ROADMAP.md: Update when present - reflect milestone and priority changes from implemented features.
See also: Experience-Owner for customer framing documentation.
Finalization Workflow
- Review the relevant implementation and determine what actually changed.
- Update the affected development and design documents to match shipped behavior.
- Apply any required decision-record updates tied to real implementation decisions.
- Remove obsolete content, duplicate guidance, and placeholder text.
- Verify terminology, file paths, cross-references, and examples against the codebase.
- Run markdown formatting and repo validation before handing off completion.
Quality Checks
- Match code names, signatures, entity names, and workflow labels exactly
- Verify file paths, section cross-references, and command examples still exist
- Remove stale future-tense statements once the work shipped
- Prefer consolidation over duplication when multiple docs describe the same rule
- For domain design docs, describe the stable domain behavior rather than issue-by-issue history
Conciseness Guidelines
- Target roughly 150-250 lines per permanent document when practical
- Split a document when it serves multiple unrelated purposes or becomes hard to navigate
- Prefer linking to the authoritative doc instead of restating the same guidance in multiple places
- Value deletion as much as addition when reducing confusion
Validation
- Run
markdownlint-cli2 --fix "**/*.md" - Run
pwsh -NoProfile -NonInteractive -File .github/scripts/quick-validate.ps1 - When agent markdown is edited, confirm the
tools:frontmatter still matches the capabilities described in the body
Gotchas
| Trigger | Gotcha | Fix |
|---|---|---|
| Updating docs from intent instead of code | Documentation drifts toward the plan rather than the shipped state | Verify names, paths, and behavior against the current implementation |
| Trigger | Gotcha | Fix |
|---|---|---|
| Turning a domain design doc into issue notes | The file becomes a changelog and stops reflecting the current UX | Rewrite the doc around current domain behavior and delete drift |
Frame Ports Filled By This Skill
| Port | Work adapter | Auto-N/A adapter | Explicit-skip adapter |
|---|---|---|---|
implement-docs | agents/Doc-Keeper.agent.md; adapters/implement-docs-adapter.md | adapters/implement-docs-auto-na-adapter.md | adapters/implement-docs-explicit-skip-adapter.md |
In /spine-run, the implement-docs port resolves through adapters/implement-docs-adapter.md as the work adapter executed by Senior Engineer. Hub-flow dispatch uses agents/Doc-Keeper.agent.md directly. This split-declaration state is documented in Documents/Design/frame-architecture.md; see footnote § (split-declaration #612).