메뉴
Refine selected backlog items or whole backlog sources into implementation-ready work. Use when asked to clarify, decompose, or prepare work across Markdown, Backlog.md, GitHub Issues, Linear, or another supported provider.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Draft or revise external communication in the user's concise, direct, informal voice. Use whenever Codex is asked to write, draft, reply, post, or comment on the user's behalf, including posting comments for them without an explicit "as the user" instruction. This skill controls wording only and never grants permission to send or post.
Use when working with a Backlog.md project or its `backlog` CLI/MCP, including creating, reading, refining, updating, completing, or archiving tasks and managing dependencies or milestones.
Resolve and operate on backlog sources consistently across loose Markdown, Backlog.md, GitHub Issues, Linear, and other supported providers. Use whenever a backlog command or skill reads or changes provider-backed work.
Resolve human decisions, missing inputs, stale blockers, and decision-only backlog items. Use when asked to unblock work or persist answers across Markdown, Backlog.md, GitHub Issues, Linear, or another supported provider.
Coordinate multiple local agents working from the same backlog or work queue with bounded Worklease claims. Use when selecting, claiming, heartbeating, checkpointing, handing off, or releasing shared work.
Explicit full implementation-review method for correctness, security, performance, maintainability, tests, and likely future failure modes. Use only when a full-review trigger applies to a branch, PR, commit range, changed files, or completed backlog item; do not use for light or style-only review or backlog state mutation.
| name | backlog-refine |
| description | Refine selected backlog items or whole backlog sources into implementation-ready work. Use when asked to clarify, decompose, or prepare work across Markdown, Backlog.md, GitHub Issues, Linear, or another supported provider. |
Use backlog-source-workflow to resolve the requested source/items, dependencies, provider operations, and claims. Refine only the selected product scope; do not reprioritize unrelated work.
Read the full items, repository guidance, relevant code and history, related issues, and dependency contracts. Refine prerequisites before dependents. An item may be fully specified but ready after <item>; do not mark it blocked merely because its prerequisite is unfinished.
Claim each item before changing it. Independent items in the same ready wave may be explored in parallel, but the claim holder owns provider writes and reconciles shared interfaces.
Preserve product intent while adding only what an implementation agent needs:
Prefer an item-local checklist:
### Implementation tasks
- [ ] T1 — one coherent, verifiable outcome
- [ ] T2 — the next coherent outcome
Keep inseparable production code, call sites, fixtures/migrations, and tests in one task. Split at independently useful behavioral or subsystem boundaries, not by file, layer, or “write tests.” Preserve checked tasks and stable IDs.
Create separate provider items only when the result is independently deliverable, exposes real dependency order, or enables useful parallel work. Persist parent/dependency relationships, map every original acceptance criterion to an owner, and reread the resulting graph. If the provider cannot safely create or relate items, keep item-local tasks instead.
Investigate missing paths and unclear references through search, history, call sites, generators, related items, and repository conventions. Record whether a path moved, is generated, belongs to a prerequisite, or will be created by this item.
Use an established or reversible default for routine engineering choices. Ask the user only when a consequential product or ownership decision is absent from available evidence and a guess risks materially wrong behavior. If that decision truly stops progress, record the evidence and objective unblock condition as a blocker; ordinary technical difficulty is not blocked.
Before release, verify the selected items are coherent, the dependency graph is acyclic, tasks and acceptance criteria have clear ownership, open questions have a disposition, and a fresh implementation agent can proceed without chat context. Persist and verify the refined specification and readiness checkpoint, then release the claim. Commit local changes only when authorized by repository or user instructions; remote provider changes need no shadow file or empty commit.