| name | bip-issue-work |
| description | Read a GitHub issue and implement the work described in it |
| allowed-tools | Bash, Read, Edit, Write, Glob, Grep, Task |
/bip-issue-work
Read a GitHub issue and do the work described in it.
Usage
/bip-issue-work 123
The argument $ARGUMENTS is the issue number.
Workflow
Step 1: Read the issue
gh issue view $ARGUMENTS
gh issue view $ARGUMENTS --comments
Read both the issue body and any comments for full context.
Step 2: Brainstorm clarifying questions
Think hard about the issue requirements. If you have any clarifying questions, STOP and ask them before writing any code.
Once everything is clear, proceed.
Step 3: Create a feature branch
git pull origin main
git checkout -b $ARGUMENTS-<short-description>
Use the issue number as a branch prefix for traceability.
Step 4: Implement
- Use code from the issue as a starting point when provided
- Follow CLAUDE.md guidelines for the project
- If you start deviating significantly from the issue, STOP and discuss
- Continue until the issue is done and all tests pass
Step 5: Pre-merge check
ls PRE-MERGE-CHECKLIST.md 2>/dev/null
- If
PRE-MERGE-CHECKLIST.md exists: read it line by line and verify every numbered item. For each item, either confirm it passes or explicitly state why it is not applicable (e.g. "item 4: parity — skipped, no alignment code changed"). Do not rely on memory — re-read the file fresh each time. Issue-lead approval does not substitute for this: the lead evaluates issue scope; the checklist catches cross-cutting concerns (citations, formatting, README sync) that the issue body won't mention.
- Otherwise: run
/bip-pr-check as the baseline quality gate.
Step 6: Fix review findings
After the pre-merge check:
- If the review found concrete issues (stale comments, dead code, missing docs, etc.), fix them immediately and re-run affected checks.
- If the review raised real design questions (e.g., "should this be architected differently?"), STOP and present the question to the user before proceeding.
Step 7: Create the PR
gh pr create --title "<concise title>" --body "<body>"
- Include
Closes #$ARGUMENTS in the body to auto-close the issue on merge
- Do NOT manually close the issue — GitHub handles it when the PR merges
Report findings in the PR body. If the work involved experiments or benchmarks, include key results (tables, numbers, conclusions) directly in the PR body. Don't just point at branch files — the PR body is the permanent record.
Step 8: Summary for the user
After creating the PR, provide a concise summary that highlights
things the user needs to judge:
- Underlying bugs or tech debt discovered during the work (even if worked around)
- Structural concerns — places where the fix is a workaround rather than a root-cause fix
- Performance implications of the approach taken
Record any deferred work in the PR body DEFERRED section (one line
per item, with rationale per the DEFERRAL RULE). In EPIC mode the
issue-lead will scan these at terminal completed and file the
legitimate ones as follow-up issues; standalone users can review the
list and run /bip-issue-next for the ones worth filing. Either way,
do not list follow-ups in this summary — the PR body is the source of
truth.