# Release Doc Writer

> 提测文档 / 上线文档 / 发布文档 / test handoff / release doc / launch notes / 补上线范围 / 发布证据 → write, fill, or review test-handoff and release-document substance from Git/config/deploy/verification evidence without owning release orchestration, merge authorization, or production mutation.

- Skill: `ccoalm/release-doc-writer` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add ccoalm/release-doc-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ccoalm/release-doc-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: ccoalm (https://skillmd.com/u/ccoalm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ccoalm/release-doc-writer

---


# Release Doc Writer（提测 / 上线文档编写）

Use this skill when the task is to write, fill, review, or update test-handoff, release, or launch documentation: delivery scope, config changes, migrations, dependencies, scripts, worker/queue decisions, verification evidence, rollback notes, MR handoff notes, or Feishu/Lark handoff sections.

This skill owns **document substance and evidence discipline**. It does **not** authorize deployment, merge, tag, production mutation, branch reset, or overall release orchestration. For full production release coordination, use `release-coordination`.

## Skip / route

- Full production release lifecycle, MR merge authorization, tag gate, pipeline follow-up, post-release reset → `release-coordination`.
- Rollout/canary/rollback strategy or live deploy/config control plane → `platform-release-engineering`.
- Risk gate decision before release → `feature-risk-router`.
- What tests to run or how to prove behavior → `testing-strategy`.
- Active production error or failed smoke → `defect-diagnosis`.
- Pure wording polish after facts are fixed → `tighten-doc`.
- Actual Feishu/Lark API mechanics → the corresponding document tooling.

## Evidence workflow

1. **Establish source range** — identify repo/service list, base ref, head ref, and whether the evidence is commit log, changed-file summary, line-level diff, CI output, runtime state, or document read-back.
2. **Write scope from evidence** — group by user-visible or operational capability; do not infer scope from branch names, MR titles, memory, or another model's summary alone.
3. **Scope confirmation handoff** — if the actual diff/log scope is broader or narrower than the stated release intent, stop and route the release decision back to `release-coordination` before writing it as settled fact.
4. **Config gate** — before writing “no config change”, check config definitions/defaults, usage sites, deployment/config surfaces, and absent-value behavior enough to justify the claim.
5. **Operational sections** — inspect touched migrations, jobs, dependencies, external services, workers, queues, scripts, and enable/disable flags; record enabled, intentionally disabled, deferred, and not-run decisions.
6. **Testing scope section** — write planned/needed test coverage from confirmed diff; route full matrix or command design to `testing-strategy`.
7. **Verification section** — list only tests, CI, smoke, runtime checks, logs, or metrics actually run or observed. Otherwise say `未验证 / 待验证`.
8. **Rollback notes** — write concrete rollback constraints evidenced by diff/config/data/runtime state; route strategy design to `platform-release-engineering`.
9. **Read back edits** — after editing collaborative docs, re-fetch the edited section and comment state when available.

## Comment-safe document editing

- Inspect the target section and existing comments before editing.
- Avoid full-document replacement when comments or anchors exist.
- Preserve existing structure: table stays table, list stays list, heading hierarchy stays unchanged.
- Replace placeholders or target cells/blocks narrowly; append only when no placeholder exists.
- Do not overwrite unrelated sections.

## MR handoff boundary

If the task includes preparing MR/PR handoff text, the release document should be updated first and the MR description should cite the document and decisions. Creating or updating an MR is not merge authorization; route merge authorization and lifecycle sequencing to `release-coordination`.

## Minimal checklist

- [ ] Repos/services and base/head refs recorded.
- [ ] Scope based on Git diff/log or equivalent first-hand evidence.
- [ ] Scope mismatch, over-broad branches, or target-ref drift routed back to `release-coordination` instead of being written as confirmed.
- [ ] Testing scope section output from diff evidence, or imported from `release-coordination`, and not treated as executed verification.
- [ ] Config/default/usage/deploy surfaces checked.
- [ ] Migrations/jobs/dependencies/scripts/workers/queues checked where touched.
- [ ] Enabled, disabled, deferred, and not-run decisions documented.
- [ ] Verification claims match actual evidence depth.
- [ ] Collaborative doc edits are narrow and comment-safe.
- [ ] Edited section read back.
- [ ] Final response states evidence depth and gaps.

## References

- `references/release-evidence-workflow.md`
- `references/comment-safe-release-doc.md`
- `references/release-testing-scope-section.md`