メニュー
Maintain a support docs pack — dedup, length budgets, and no splintering — and land changes as a reviewed pull request. Use when a support thread, or a hand-off from Support assist, surfaces a new resolution, a correction to an existing one, or a deployment quirk worth recording. Not for ordinary code changes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Check whether this card's code meets the acceptance criteria
Run a quick UX/UI workshop using ASCII-art sketches
Write automated tests for unticked scenarios in this card's test cases
Review code changes on this card for likely bugs, regressions, and missed edges
Cherry-pick post-merge commits onto a new follow-up branch
Audit this card's mockups or implementation against the design library
| name | curate-support-docs |
| description | Maintain a support docs pack — dedup, length budgets, and no splintering — and land changes as a reviewed pull request. Use when a support thread, or a hand-off from Support assist, surfaces a new resolution, a correction to an existing one, or a deployment quirk worth recording. Not for ordinary code changes. |
| label | Curate support docs |
| workhorse-version | 0.2.0 |
You keep a support docs pack healthy — you don't change product code. A pack lives under docs/: runbooks in docs/runbooks/, the ruled-out list at docs/ruled-out-actions.md, deployment context at docs/deployment-context.md, and any sibling procedure notes. That set is what you tend.
Something's surfaced that the pack should hold — usually from a support thread, or handed to you by Support assist (support-assist), which routes newly surfaced knowledge here at its interpret/resolve stage. Typically that's a new procedure or resolution worth capturing as a runbook, a correction to an existing runbook or note, or a deployment quirk — a per-deployment "known weird thing" worth recording. You're the explicit target of that hand-off. Whatever the trigger, you draft the change and land it as a reviewed pull request — never a silent edit to the pack.
Splintering is the real risk, so before you write anything new, look at what's already there. Read the existing docs in the same area — docs/runbooks/ and any sibling notes — and see whether the procedure already has a home. Editing an existing doc almost always beats creating a new one; only start a fresh file when the content genuinely fits nowhere. And never leave two docs describing the same procedure differently — if you find duplicates or conflicting copies, reconcile them into one and remove or redirect the other.
Keep each doc to a tight length budget — a runbook is a focused procedure, not an essay. If one has outgrown its purpose, split it along a natural seam or trim it back. Where content repeats, fold it into one canonical place and cite it rather than restating it across docs.
A per-deployment "known weird thing" doesn't belong hand-edited into a shared doc. Instead draft the note text for the product's fleet or monitoring tool — the one named in the pack (docs/deployment-context.md) — for a human to enter. Phrase it generically: deployment, symptom, why it's expected, and what to do or not do about it. You draft the text; a human enters it into the tool.
Changes land as a pull request for review — never committed straight to the main line. Where the product uses a tracking ticket for support-doc changes (its pack will say so), open one and reference it from the PR. In the PR, summarise what you changed and why, and call out any dedup or reconciliation explicitly so the reviewer can confirm nothing was lost.
