From cc-power-user
Transform a GitHub issue into a production-ready pull request with automated PR review. Executes full workflow including refinement check, code generation, RL loop, testing, PR creation, automated review, feedback application, and re-verification before marking ready for human review.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cc-power-user:github-issue-to-pr [issue-number|issue-url][issue-number|issue-url]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Transform ONE GitHub issue into a production-ready PR. Automated PR review and feedback application happen BEFORE marking the PR ready for humans.
Transform ONE GitHub issue into a production-ready PR. Automated PR review and feedback application happen BEFORE marking the PR ready for humans.
Assigned issue: [ISSUE_URL_PLACEHOLDER] — work on this one only.
These rules apply to every phase. Do not restate, just follow.
/tmp/<project-name>/.worktree/<issue-number> — all work happens there.Logging format (mandatory):
[PHASE-X] [ACTION|RESULT|DECISION|COMPLETE] message
[RL-LOOP-N] [ACTION|RESULT|DECISION] message
All three checks must pass.
Read the issue. It must have WHAT, WHY, HOW sections. If missing:
Issue #N is not refined. Run the
github-issue-refinerskill from this plugin first (e.g./cc-power-user:github-issue-refiner N), then re-run this workflow. STOP.
Do not refine automatically.
Query the issue's Projects V2 status. Must be "Ready" (option ID READY_OPTION_ID_PLACEHOLDER).
gh api graphql -f query='
query {
repository(owner: "<your-org>", name: "<your-repo>") {
issue(number: <issue-number>) {
projectItems(first: 10) {
nodes {
fieldValueByName(name: "Status") {
... on ProjectV2ItemFieldSingleSelectValue { optionId name }
}
}
}
}
}
}
' -q '.data.repository.issue.projectItems.nodes[0].fieldValueByName | {optionId, name}'
If not "Ready", report current status and STOP. The user must move it to Ready (via refinement or manually).
mkdir -p /tmp/<project-name>/.worktree
git worktree add /tmp/<project-name>/.worktree/<issue-number> -b feature/issue-<issue-number>
cd /tmp/<project-name>/.worktree/<issue-number>
On failure: git worktree list && git worktree repair, then retry.
Confirm WHAT/WHY/HOW present (verified in Phase -1) and current directory is the worktree. Proceed to Phase 1.
Update before any sub-agent delegation. This signals work started, prevents duplicate work, makes progress visible.
Skip if GitHub Projects V2 is not configured for the repo.
ISSUE_NUMBER=<issue-number>
ISSUE_NODE_ID=$(gh issue view $ISSUE_NUMBER --json id --jq .id)
PROJECT_ITEM_ID=$(gh api graphql -f query='
query {
node(id: "'$ISSUE_NODE_ID'") {
... on Issue {
projectItems(first: 10) { nodes { id project { id } } }
}
}
}
' --jq '.data.node.projectItems.nodes[] | select(.project.id == "PROJECT_ID_PLACEHOLDER") | .id')
gh api graphql -f query='
mutation {
updateProjectV2ItemFieldValue(input: {
projectId: "PROJECT_ID_PLACEHOLDER"
itemId: "'$PROJECT_ITEM_ID'"
fieldId: "STATUS_FIELD_ID_PLACEHOLDER"
value: { singleSelectOptionId: "IN_PROGRESS_OPTION_ID_PLACEHOLDER" }
}) { projectV2Item { id } }
}
'
If the mutation fails: STOP and report. Do not proceed.
See the github-project-integration skill for the full transition reference.
Read the phase2-codegen skill first.
Three steps: 2A delegate → 2B validate handoff → 2C commit.
Map the issue's HOW section to a single developer agent (or several, run in dependency order). Customise this table for your stack:
| Area of change | Developer agent |
|---|---|
| Backend / API | backend-developer |
| Frontend | frontend-developer |
| CLI | cli-developer |
| Marketing site | website-developer |
| Docs site | docs-site-developer |
For cross-cutting changes (small config/docs), the orchestrator can self-implement instead of delegating.
Run in parallel when independent, sequentially when one service depends on another. Prompt template:
Implement issue #[N] in workspace /tmp/<project-name>/.worktree/[N] on branch feature/issue-[N].
## WHAT
{WHAT_SECTION}
## WHY
{WHY_SECTION}
## HOW
{HOW_SECTION}
## STANDARDS
Test coverage ≥80%. Linting and type checking must pass. Follow this project's
existing conventions (the developer agent already has stack-specific guidance).
## HANDOFF (MANDATORY — return this exact structure)
## IMPLEMENTATION COMPLETE
### Files Modified
- `path/file.ext` - description
### Tests Added
- Total new tests: X
- Coverage: Y%
- All passing: true/false
### Quality Checks
- Linting: pass/fail
- Type checking: pass/fail
- Formatting: pass/fail
### Key Architectural Decisions
1. [Decision] - [Justification]
### Blockers or Concerns
None | [details]
### Ready Status
TRUE | FALSE - [reason]
## RULES
- Write code to the worktree.
- Run tests/linting locally.
- DO NOT commit or push.
- Return the handoff above.
Required: Files Modified, Tests Added (counts/coverage), Quality Checks, Decisions, Ready Status. Gates: Ready=TRUE, all tests passing, linting passed, coverage ≥80%, no blockers. If any fail, re-delegate with specific fixes; do not commit.
cd /tmp/<project-name>/.worktree/[N]
git add .
git commit -m "$(cat <<'EOF'
feat: [brief description]
[detailed description from WHAT/WHY]
Implementation:
- [key change 1]
- [key change 2]
Tests: X new, Y% coverage
Quality: Linting pass, Type checking pass
Implements: #[N]
EOF
)"
git push origin HEAD
Proceed to Phase 3.
Read the phase3-rl-loop skill first.
iteration = 0
while not all_gates_passed and iteration < 10:
iteration += 1
run pre-commit; fix all failures; do NOT commit yet
commit & push from worktree
wait for GitHub Actions; collect all job outputs
read PR review comments; categorize blocker/suggestion/nit
if all CI green and no blockers: break
apply fixes (delegate to specialist if appropriate); next iteration
if iteration == 10: document remaining issues, request human help, STOP
Specialist delegations during the loop (only when the relevant agent exists in your install):
golang-lint-fixer for Go).openapi-schema-manager).security-guardian.Exit criteria (ALL true): pre-commit pass · CI green · zero blocker comments · coverage maintained or improved · no security findings · performance acceptable.
Read the phase4-pr skill first.
Trigger pre-PR QA delegations as applicable, fix any critical/high findings, then:
security-guardianarchitecture-guardianbug-finderStep sequence:
Closes #N.ai-generated, ready-for-review, complexity label. Create labels if missing.pr-reviewer; parse findings.gh pr ready $PR_NUMBER → PR no longer draft.IN_REVIEW_OPTION_ID_PLACEHOLDER) — skip if Projects V2 not configured.The plugin ships a default set; override per project as needed.
Developers: backend-developer, frontend-developer, cli-developer, website-developer, docs-site-developer
QA: security-guardian, architecture-guardian, bug-finder, pr-reviewer
Stack-specific specialists (optional, use only if installed): e.g. golang-lint-fixer, openapi-schema-manager
Read these at the top of the corresponding phase:
phase1-refinement — refinement templates (only relevant if invoked via the refining command; this workflow assumes refinement is already done)phase2-codegen — code quality standardsphase3-rl-loop — error handling and recoveryphase4-pr — PR template and checklistquality-gates — shared gates (single source of truth)github-project-integration — Projects V2 IDs and status transitionsnpx claudepluginhub shaharia-lab/claude-power-user --plugin cc-power-userGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.