원클릭으로
finish
Use when a plan's PR is ready to merge — marks the plan completed, checks PR status, merges to main, and syncs local main
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when a plan's PR is ready to merge — marks the plan completed, checks PR status, merges to main, and syncs local main
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user asks for a daily summary, standup, or wants to know what they did today — e.g. "daily summary", "standup", "what did I do today", "summary for slack", "daily update".
Use when the user says "let's discuss", "lets discuss", "I want to discuss", "can we discuss", "let's brainstorm", "lets brainstorm", "I want to brainstorm", or any variation asking to discuss/talk through/brainstorm an idea before coding — this takes priority over other requests in the same message. Also use before any creative work to discuss features, designs, or behavior changes through collaborative dialogue before writing code
Use when you have a written implementation plan to execute
Use when a feature or change needs an implementation plan with concrete tasks, file paths, and test steps before coding begins
Audits and optimizes GitHub profile pages — profile README, metadata fields, pinned repositories, stats widgets, and contribution visibility. Use this skill whenever the user asks to improve, create, review, or optimize their GitHub profile, or mentions "profile README", "GitHub bio", "pinned repos", "GitHub stats", "contribution graph", or "GitHub presence". Also trigger when someone says things like "make my GitHub look good", "I want a better GitHub profile", "help me stand out on GitHub", "set up my GitHub page", or "optimize my developer profile". Works for both personal profiles and organization profile pages.
Use when comparing libraries or frameworks, evaluating approaches or architectures, investigating a technology or topic, finding best practices, deep-diving into a subject, doing competitive analysis, or researching academic papers. Triggers on: "research", "compare", "evaluate", "deep-dive", "investigate", "best practices for". Not for: simple file lookups (use explore directly), quick fact checks, or tasks requiring code changes.
| name | finish |
| description | Use when a plan's PR is ready to merge — marks the plan completed, checks PR status, merges to main, and syncs local main |
Complete the plan lifecycle: mark it done, merge the PR, sync local main.
implement has opened the PRDon't use when:
implement to create onediscussBefore checking anything else, inspect the human review state:
gh pr view [PR-NUMBER] --json reviewRequests,reviews,comments
A. Check for pending human review requests:
Look at reviewRequests — any entries mean a human hasn't reviewed yet.
B. Check for unresolved review comments:
Look at reviews for:
state: "COMMENTED" — has comments that may need addressingstate: "CHANGES_REQUESTED" — blocking, must fixLook at comments for:
isMinimized: false — active comments (not resolved)RULE: ALL comments must be resolved (minimized) before merging. There is no "non-blocking" exception — every single unresolved comment blocks the merge. If the user wants to skip resolving a comment, they must explicitly say so (e.g., "ignore this comment," "non-blocking," "skip this one").
C. Decision gate — ask the user if there are pending reviews:
If
reviewRequestsis non-empty (pending human reviewers):
- STOP and ask the user: "@X hasn't reviewed yet. Wait or merge anyway?"
- If user says wait, stop and report back
- If user says proceed, continue to Step 2
If there are
CHANGES_REQUESTEDreviews:
- STOP and fix the issues (see Step 1a below)
If there are
COMMENTEDreviews from bots or humans:
- Read the latest comment body — if it says "no new issues found" or similar, continue
- If it lists issues to fix, go to Step 1a
Only after reviews are clear, check technical readiness:
gh pr view [PR-NUMBER] --json state,statusCheckRollup,reviewDecision,mergeable
Verify all of:
OPENstatusCheckRollup must reach a terminal state (COMPLETED) with a non-empty conclusion. If any entry has status: "IN_PROGRESS", status: "QUEUED", or no status/conclusion at all, it means a check is still running — WAIT and re-check. Poll every ~30 seconds until all checks reach COMPLETED state, regardless of whether they are currently passing or failing. A bot review comment saying "safe to merge" does NOT mean the check is done. Do not proceed until every statusCheckRollup entry is COMPLETED with a non-empty conclusion. Once all checks are COMPLETED:
"SUCCESS" or "SKIPPED" → proceed to merge"FAILURE", "TIMED_OUT", or "ACTION_REQUIRED" → go to Step 1aAPPROVED (or no review required)MERGEABLEIf any check is still running, wait (~30s) and re-check with the same command. Loop until all are COMPLETED. If CI is failing, go to Step 1a.
A. Read each outstanding comment/issue — understand what needs to change
B. Fix on the feature branch:
git checkout [feature-branch]
# Make the fix
git add -A && git commit -m "fix: address review comment — [summary]"
git push origin [feature-branch]
C. Respond to the comment:
gh pr comment [PR-NUMBER] --body "Fixed — [explanation of what changed]"
D. Re-check reviews — go back to Step 1 from the top (check reviews/comments first)
E. Loop until:
APPROVED (or no review required)MERGEABLEF. If a comment doesn't require a code change (e.g., "nice work", general feedback):
gh pr comment acknowledging the feedbackG. If you're blocked (can't reproduce an issue, need clarification):
CRITICAL: Do NOT skip unresolved review comments or failing CI. Loop until everything is green. Every comment must be resolved — there is no "non-blocking" category. If the user wants to leave a comment unresolved, they must explicitly say so.
gh pr merge [PR-NUMBER] --squash --delete-branch
Use squash merge by default to keep main history clean. If the user prefers merge commits, use --merge instead.
git checkout main
git pull origin main
Move the plan file to the done/ archive:
mv docs/plans/plan-NNN-<feature>.md docs/plans/done/
Edit docs/plans/README.md:
done/plan-NNN-<feature>.md)Commit the update:
git add docs/plans/README.md
git commit -m "docs: mark [plan-name] as completed (PR #[number])"
Tell the user:
| Issue | Action |
|---|---|
| Pending human reviewers | Ask user: wait or merge anyway? |
| CI still running | Wait and re-check until all checks reach COMPLETED state, then evaluate results |
| CI failing | Fix on feature branch, push, re-check (loop until green) |
| Review comments unresolved | Fix each issue, push, reply to comment, re-check (loop until ALL comments are resolved — no non-blocking exceptions) |
CHANGES_REQUESTED review | Fix the requested changes, push, re-check |
| Bot review with issues | Fix the issues, push, re-check |
| Bot review clean ("no new issues") | Continue to next step |
| Merge conflicts on PR | Do NOT merge locally. Ask user to resolve on the branch. |
| PR already merged | Skip merge step, sync main, update index |
| Plan not in README.md | Add it to the Completed Plans section with the PR number |
statusCheckRollup entry reaches COMPLETED state before evaluating results