Menú
Read a GitHub issue and implement the work described in it
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Check remote server CPU, memory, and GPU availability via SSH
Cold-start into a worktree/clone from a fresh conversation — read the PR, issue, and any status files, figure out where things stand, then STOP and ask the user what to do next. Use for a fresh conversation dropped into a bip-spawn or bip-epic-spawn worktree/clone that already has history (a PR, an in-progress phase, or a stalled worker).
Quick poll of tracked EPICs and code repos for new manuscript-relevant results
Persist manuscript session state before context reset
Cold-start for a manuscript session — the paper is the source of truth and shared context; discuss results, orchestrate research through issues/PRs, and update the paper as threads complete
Spawn a Claude session in a clone for an EPIC issue
| 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 |
Read a GitHub issue and do the work described in it.
/bip-issue-work 123
The argument $ARGUMENTS is the issue number.
gh issue view $ARGUMENTS
gh issue view $ARGUMENTS --comments
Read both the issue body and any comments for full context.
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.
git pull origin main
git checkout -b $ARGUMENTS-<short-description>
Use the issue number as a branch prefix for traceability.
ls PRE-MERGE-CHECKLIST.md 2>/dev/null
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./bip-pr-check as the baseline quality gate.After the pre-merge check:
gh pr create --title "<concise title>" --body "<body>"
Closes #$ARGUMENTS in the body to auto-close the issue on mergeReport 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.
After creating the PR, provide a concise summary that highlights things the user needs to judge:
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.