提测文档 / 上线文档 / 发布文档 / 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.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add ccoalm/ccl-skills --skill release-doc-writer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Release Doc Writer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ccoalm-release-doc-writer)More formats (shields.io, HTML) on the badges page.
---
name: release-doc-writer
description: 提测文档 / 上线文档 / 发布文档 / 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.
---
# 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`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!