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)
- License 许可
- MIT
- 最近更新
- 2026-08-16
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- documentation-finalization
- description
- 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)
02 资源文件 3
03 SKILL.md 正文
<!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; applies to repository documentation and agent markdown updates. --> <!-- markdownlint-disable-file MD041 MD003 -->
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).
04 同仓库更多 Skills
webapp-testing
Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).
verification-before-completion
Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any "I'm finished" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).
validation-methodology
Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).
upstream-onboarding
Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.
ui-testing
Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).
ui-iteration
Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).