AGENT SKILL

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}.md file 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

  1. Review the relevant implementation and determine what actually changed.
  2. Update the affected development and design documents to match shipped behavior.
  3. Apply any required decision-record updates tied to real implementation decisions.
  4. Remove obsolete content, duplicate guidance, and placeholder text.
  5. Verify terminology, file paths, cross-references, and examples against the codebase.
  6. 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

Grimblaz
Grimblaz/agent-orchestra

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).

测试与质量前端开发
★ 3
Grimblaz
Grimblaz/agent-orchestra

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).

★ 3
Grimblaz
Grimblaz/agent-orchestra

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).

★ 3
Grimblaz
Grimblaz/agent-orchestra

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.

人力资源Skill与智能体开发
★ 3
Grimblaz
Grimblaz/agent-orchestra

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).

设计师测试与质量前端开发
★ 3
Grimblaz
Grimblaz/agent-orchestra

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).

设计师前端开发
★ 3