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.