菜单
End-to-end issue-to-coding workflow. Accepts an issue number or description, handles CR plan polling, merges plans into issue body, creates worktree and branch, outputs ready-to-code summary. Use to start work on an issue without manually walking through the issue-planning flow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Generate a PM handoff prompt for context-window turnover. Captures static config, live GitHub state, in-flight thread state, and memory summary into a self-contained prompt for a fresh PM thread. Bootstraps `.claude/pm-config.md` on first run. Triggers on "pm-handoff", "handoff", "context turnover", "new pm thread", "thread turnover".
Scan open issues for staleness and suggest closures. Detects issues solved by merged PRs, no-activity issues (30+ days), superseded issues, and potential duplicates of already-closed issues. Presents recommendations for user confirmation — never auto-closes. Triggers on "pm-clean", "stale issues", "clean backlog", "close stale".
Active PM orchestrator — manages issue pipeline, tracks coding threads, ranks the open backlog (OKR-aware) against a business goal, and suggests next work. Cold-starts from GitHub state or resumes from a /pm-handoff prompt. Triggers on "pm", "project manager", "orchestrate", "what should I work on", "rank issues".
Re-scan the current repo and update `.claude/pm-config.md` with fresh infrastructure and architecture detection while preserving user-edited sections (Role, OKRs, Team, Notes, Dependency Rules, Workflow Rules), then run a stale-cleanup pass to prune long-abandoned worktrees and branches. Use this after major milestones, new service integrations, or significant directory restructuring. Triggers on "pm update", "update pm config", "refresh pm config", "rescan repo".
Capture-only thread mode for drafting and opening well-structured GitHub issues. Puts the thread into issue-capture mode — the only job is creating, editing, and closing issues (no implementation, no worktrees, no /start-issue). Always reflects before writing (1–3 scope/clarifying questions), creates canonical 6-section bodies with functional-first tone, runs dedup search, suggests labels, supports batch + cross-references, and prints the issue URL as the closing line of every create/update. Supports /update <N> <statement>, natural-language edit-in-place, and retract. Invoke as `/issue-maker [rapid-fire] [--export-prompt]`.
Manage the OKRs section of `.claude/pm-config.md`. Show current objectives, set new ones, or get AI-suggested updates based on recent work. OKRs drive `/pm` ranking. Use this whenever you want to view, set, or update project OKRs, objectives, key results, or goals. Triggers on "pm okr", "set okrs", "show okrs", "suggest okrs", "project goals", "objectives".
| name | start-issue |
| description | End-to-end issue-to-coding workflow. Accepts an issue number or description, handles CR plan polling, merges plans into issue body, creates worktree and branch, outputs ready-to-code summary. Use to start work on an issue without manually walking through the issue-planning flow. |
| triggers | ["start issue","start work","kick off issue","begin coding"] |
| argument-hint | <issue-number | 'description of new issue'> |
Automate the full issue-to-coding flow: create issue (if needed) → wait for CR plan → merge plans → create worktree + branch → output ready-to-code summary. Replaces 5-10 minutes of manual setup per issue.
Parse $ARGUMENTS:
42 or #42): treat as an existing issue number. Strip any leading #. Set ISSUE_NUMBER=$ARGUMENTS and skip to Step 2."Add dark mode toggle"): this is a new issue to create. Go to Step 1a./start-issue 42) or a description (e.g. /start-issue \"Add dark mode toggle\")."Only when a description was provided.
## Acceptance Criteria section with placeholder checkbox items derived from the descriptionISSUE_URL=$(gh issue create --title "<title>" --body "<body>")
ISSUE_NUMBER=$(echo "$ISSUE_URL" | grep -oE '[0-9]+$')
cr-plan-on-issue.yml workflow will auto-post @coderabbitai plan within ~30s. Record ISSUE_CREATED_AT=$(date -u +%s) so Step 3 knows to use the "< 10 min" polling path.gh issue view "$ISSUE_NUMBER" --json number,title,body,state,createdAt --comments
state != "OPEN": stop and report "Issue #$ISSUE_NUMBER is $state — cannot start work on a closed issue."TITLE, BODY, and CREATED_AT (from the createdAt JSON field) for downstream steps.CREATED_AT. Use a portable approach (Python or gdate on macOS if available; otherwise derive from the recorded ISSUE_CREATED_AT when the issue was just created by this skill).CR's plan is identified by a comment from coderabbitai (no [bot] suffix — issue comments use the bare name). Use .claude/scripts/cr-plan.sh for detection — it encapsulates the canonical substantive-plan filter (cr-plan-filter.py: reject the issue-enrichment/Issue-Planner boilerplate and "actions performed" ack lines, then require >200 chars of stripped content plus a heading or numbered step — issue #541) and the 60s polling loop.
Exit codes: 0 plan found (printed to stdout), 1 no plan, 3 issue not found/closed, 4 gh/env error (network, missing python3, or filter failure). Run .claude/scripts/cr-plan.sh --help for full usage.
CR may still be generating the plan. Poll for up to 10 minutes, stopping early once the issue ages past 10 minutes from createdAt:
if PLAN=$(.claude/scripts/cr-plan.sh "$ISSUE_NUMBER" --poll 10 --max-age-minutes 10); then
: # plan captured
else
case $? in
1) PLAN="" ;; # timeout — no plan
*) PLAN=""; echo "cr-plan.sh failed" >&2 ;;
esac
fi
Do a single check for an existing CR plan comment:
PLAN=$(.claude/scripts/cr-plan.sh "$ISSUE_NUMBER" || true)
.github/workflows/cr-plan-on-issue.yml) should have already posted @coderabbitai plan when the issue was opened. Do NOT manually trigger it unless you have confirmed the workflow failed for this specific issue. Filter runs to the issues event and match by displayed title so a failure on an unrelated issue doesn't cause a false manual-trigger here:
gh run list --workflow=cr-plan-on-issue.yml --event issues --limit 20 \
--json databaseId,displayTitle,status,conclusion,createdAt,event \
--jq ".[] | select(.displayTitle | test(\"#${ISSUE_NUMBER}\\\\b\"))"
status before conclusion — a run with status: "queued" or status: "in_progress" has no final conclusion yet and must not be treated as success or failure:
status != "completed" (queued / in_progress): the workflow is still running. Wait up to 5 minutes, re-querying every 60s. If it completes during the wait, re-evaluate. If still not completed after 5 minutes, treat it as stalled and fall through to the manual trigger branch below.status == "completed" and conclusion == "success": the workflow succeeded. Skip the manual trigger and proceed to Step 4 without a plan — CR simply produced no plan comment.status == "completed" and conclusion in the blocking set (failure, timed_out, action_required, startup_failure, stale): the workflow ran but failed — fall through to the manual trigger branch.status == "completed" and conclusion is non-blocking (cancelled, neutral, skipped): do not assume failure. Skip the manual trigger and proceed to Step 4 without a plan. The workflow was intentionally aborted or bypassed; manually re-posting @coderabbitai plan would be unjustified.@coderabbitai plan and poll every 60s for up to 5 minutes:
gh issue comment "$ISSUE_NUMBER" --body "@coderabbitai plan"
PLAN=$(.claude/scripts/cr-plan.sh "$ISSUE_NUMBER" --poll 5 || true)
Note: Use
coderabbitai(no[bot]suffix) for issue comments. PR reviews usecoderabbitai[bot].
Do NOT post this plan yet — it gets merged in Step 5.
This creates one canonical planning document the coding agent can work from.
current_body=$(gh issue view "$ISSUE_NUMBER" --json body --jq .body)
merged_plan="<merged plan — files, steps, risks, verification>"
# Export CURRENT_BODY BEFORE the python heredoc so the subshell inherits it.
export CURRENT_BODY="$current_body"
# Strip any existing "## Implementation Plan" section (everything from the
# header to EOF or to the next top-level heading) so re-runs of /start-issue
# don't create duplicate plan sections.
stripped_body=$(python3 - <<'PY'
import os, re, sys
body = os.environ["CURRENT_BODY"]
# Remove "## Implementation Plan" through EOF or the next "## " heading.
body = re.sub(r"\n*##[ \t]+Implementation Plan\b.*?(?=\n##[ \t]|\Z)", "", body, flags=re.DOTALL)
sys.stdout.write(body.rstrip() + "\n")
PY
)
new_body="${stripped_body}
## Implementation Plan
${merged_plan}"
gh issue edit "$ISSUE_NUMBER" --body "$new_body"
gh issue edit --body replaces the entire body, so the fetch-strip-rewrite pattern is required to preserve the original description AND prevent duplicate ## Implementation Plan sections when /start-issue is re-run on the same issue.if [ -n "$PLAN" ]; then
gh issue comment "$ISSUE_NUMBER" --body "Implementation plan merged into issue body (Claude's analysis + CodeRabbit's recommendations). Ready for work."
else
gh issue comment "$ISSUE_NUMBER" --body "Implementation plan added to issue body (Claude's analysis only — CodeRabbit plan was not available). Ready for work."
fi
"Add dark mode toggle" → add-dark-mode-toggle.issue-$ISSUE_NUMBER-$SLUGif git worktree list | grep -q "issue-$ISSUE_NUMBER-"; then
echo "A worktree already exists for issue #$ISSUE_NUMBER:"
git worktree list | grep "issue-$ISSUE_NUMBER-"
exit 0
fi
ROOT_REPO=$(.claude/scripts/repo-root.sh 2>/dev/null || true)
if [ -z "$ROOT_REPO" ] || [ ! -d "$ROOT_REPO" ]; then
echo "ERROR: could not resolve root repo path" >&2
exit 1
fi
# Defensive guard: only pull main if the root repo is actually on main.
# Mirrors the pattern used by wrap/merge skills.
CURRENT_BRANCH=$(git -C "$ROOT_REPO" branch --show-current)
if [ "$CURRENT_BRANCH" != "main" ]; then
git -C "$ROOT_REPO" checkout main
fi
git -C "$ROOT_REPO" pull origin main --ff-only
WORKTREE_PATH="$ROOT_REPO/.claude/worktrees/issue-$ISSUE_NUMBER-$SLUG"
git -C "$ROOT_REPO" worktree add "$WORKTREE_PATH" -b "issue-$ISSUE_NUMBER-$SLUG"
cd "$WORKTREE_PATH"
pull fails (diverged history), stop and report to the user — do not force-pull. If checkout main fails (uncommitted changes in the root repo), stop and report — do not stash or discard changes.First, check chip availability per .claude/reference/chip-launching.md, then branch. The handoff content is the same in both delivery modes — only how it reaches the user differs:
mcp__ccd_session__spawn_task present): call spawn_task once for this issue with title / prompt / tldr / cwd (shape under "Chip construction" below). Print only the short summary — issue, title, **Model:** line, one-line rationale — in the reference's exact format. Do not also print the fallback block, or the same work is offered twice.A failed spawn_task is treated as unavailable (per the reference): print the full fallback block instead. Do not retry the spawn. The handoff always ends with exactly one of: a chip, or a printed block — never neither.
Print a compact summary to the user. This block is the pre-chip baseline — emit it byte-for-byte identical to what /start-issue printed before chips existed (same heading, fields, plan/AC sections, and closing "Ready to code…" line), so a CLI or headless thread cannot tell this feature exists:
## Ready to code — Issue #{N}
**Title:** {TITLE}
**Branch:** issue-{N}-{slug}
**Worktree:** {WORKTREE_PATH}
**CR plan:** {included | not available}
### Implementation Plan
{top-level bullets from the merged plan — files, key steps, risks}
### Acceptance Criteria
{unchecked checkbox items from the issue body}
---
Ready to code. Start with step 1 of the plan above. Run the dual-CLI local review per `cr-local-review.md`, fix all valid findings, and rerun until the required clean gate is reached before pushing.
.claude/reference/chip-launching.md is authoritative for chip semantics — this table only maps the skill's existing variables onto its params:
| Param | Value |
|---|---|
title | Verb-first, ≤60 chars, includes the issue number — built from ISSUE_NUMBER + TITLE (e.g. Fix #42 stale worktree warning) |
prompt | The complete self-contained coding-thread prompt: the **Model:** line, then a blank line, then the content of the fallback block above reproduced verbatim (the fence delimiters are not part of the prompt; everything between them is). The Model line is the only addition — the block's own text is never reworded to suit the chip |
tldr | 1–2 plain-English sentences from TITLE / the merged plan: what the session will do and why. No file paths, no jargon |
cwd | WORKTREE_PATH — the worktree created in Step 6 |
cwddeliberately differs from/pmand/prompt, which pass the repo root. By Step 7,/start-issuehas already created an issue-specific worktree, so the launched thread must start there — repo root would land it in the wrong checkout, on the wrong branch. This is an intentional divergence, not an inconsistency with the shared contract.
Chips carry no model preset, so the **Model:** {MODEL} — {REASON} line MUST appear both at the top of the chip's prompt text (so the spawned session sees it) and in the visible short summary (so the user can set the picker before clicking).
Record the returned task_id immediately, before any dependent step — an unrecorded chip cannot be withdrawn. /start-issue has no Active Work table, so track it session-locally, keyed by issue number, and say so in the summary; the chip stays dismissable for this session only. If the issue already has a live chip recorded in this session, skip the spawn rather than offering it twice. dismiss_task hygiene and print-on-demand replay ("print the full prompt for #N" re-emits that chip's prompt verbatim — Model line and block — in the fenced form fallback would have printed; the chip stays offered) follow the reference — do not restate its rules here.
Chips need a {MODEL} and a {REASON}. Use this lightweight, role-based rule over the canonical roster (Fable 5, Opus 4.8, Sonnet 5, Haiku 4.5 — see .claude/rules/subagent-orchestration.md "Model Selection"):
CLAUDE.md, skills, or orchestration — instruction-adherence work where literal-following models misfire.{REASON} is a short phrase naming the dominant driver (e.g. rules + skill wiring, single-file code change). Do NOT replicate /prompt's Heavy/Standard/Light multi-signal pipeline — /start-issue is single-issue and has no model concept beyond this rule. When /prompt already produced a recommendation for the issue, prefer it.
Stop after delivering the handoff. Do NOT start coding automatically — the user may want to review the plan first. Offering a chip is not launching a thread: spawn_task only puts a chip in front of the user, and their click is the only launch path. Never click for them, and never do the coding thread's work yourself — via the Agent tool or otherwise — in place of a chip they haven't clicked.
git worktree list shows an existing worktree for issue-$ISSUE_NUMBER-*, stop and report the path instead of creating a duplicate (see Step 6).gh not authenticated or repo lookup fails: stop and report the underlying gh error to the user./start-issue 42 — start on existing issue #42: read issue, get CR plan, merge plans, create worktree, ready to code./start-issue "Add dark mode toggle" — draft and create a new issue, wait for CR plan, merge plans, create worktree, ready to code./start-issue — prompts for input when no argument is supplied.