Menu
Create or update a pull request with a Summary / Validation steps / References body, including `Closes
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | stoker-create-pr |
| description | Create or update a pull request with a Summary / Validation steps / References body, including `Closes |
Create a pull request (or update one that already exists on this
branch) using a fixed body template that the AFK loop and humans
both produce identically. This skill is the single source of truth
for the Rubin profile's PR shape: title format, body sections, and
the Closes #N / PRD: #N / Jira: <url> trailer conventions.
stoker-implement delegates here for its PR step. Humans invoke it
directly for hand-driven PRs.
This is the Rubin variant of the default stoker-create-pr. It keeps
the default's create-vs-update logic and multi-task Closes #N
regeneration verbatim, and layers two Rubin conventions on top: a
DM-XXXXX:-prefixed title for tickets/DM-XXXXX... branches, and a
Jira: <url> line in References.
Collect these values. Use the first available source for each:
prd-task whose work this PR delivers. Sources
in order: current conversation context (e.g. the implement-phase
prompt) > auto-detect by branch (see below) > ask the user
(optional — solo PRs without a tracked task are allowed).### Parent PRD field, when the
task is part of a PRD breakdown. Optional.git branch --show-current).tickets/<KEY>... (the <KEY>
segment, e.g. tickets/DM-12345-add-foo → DM-12345) > the task
issue's ### Jira Key field > none. Optional — u/<login>/<desc>
branches and ticket-less PRDs have no Jira key.### Jira URL
field > constructed as https://rubinobs.atlassian.net/browse/<key>
when a Jira key is known > none.If no task is in context, search by branch:
gh issue list --label prd-task --state open --json number,title,body --limit 50
Find the issue whose ### Branch field matches the current branch
name. Extract ### Parent PRD, ### Jira Key, and ### Jira URL
from that issue's body.
git status -sb
If the branch has no remote tracking branch or has unpushed commits:
git push -u origin HEAD
If the push fails (non-fast-forward, permission denied, network),
do not retry or rebase from this skill. Surface the failure to
the caller (stoker-implement routes to the stuck path; humans get an
error message).
gh pr list --head <branch> --json number,title,body,state,baseRefName --limit 1
Three cases:
Title.
DM-XXXXX: <concise description>. The description is a concise summary of what this PR
accomplishes; keep the whole title under 70 characters.u/<login>/<desc> branch or ticket-less
work), use a plain concise descriptive title under 70 characters.Body. Use the template below verbatim.
gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
Regenerate the body from the branch's full scope so Summary, Validation steps, and References reflect every task that has landed, not just the first.
Enumerate every commit since the PR's base. Use baseRefName from
the gh pr list JSON; do not hardcode origin/main:
git log origin/<baseRefName>..HEAD --format='%H%n%s%n%b---'
Take the union of Closes #N trailers from those commits, the
Closes #N lines already in the existing PR body's References
section, and the currently-picked task. (Refs #N trailers used
by stuck WIP commits naturally don't surface here, so stuck work
never leaks into References or Summary.)
For each unique N, fetch the issue:
gh issue view <N> --json number,title,body,state
Pull manual-QA bullets from the issue's ### Acceptance criteria
field (if present) for the Validation steps section. Also re-read
the ### Jira Key / ### Jira URL fields here so the Jira:
reference stays correct after the first task.
Compose a fresh body using the template:
Closes #N per referenced task, sorted
ascending; then PRD: #<parent_prd> (omit if none); then
Jira: <url> (omit if no Jira key). Sorted + deduped is
idempotent by construction.Apply:
gh pr edit <pr_number> --body "$(cat <<'EOF'
<body>
EOF
)"
Leave the existing PR title unchanged on update — it already
carries the DM-XXXXX: prefix from creation.
After create or edit, print the PR URL so the caller can surface it
to the user (or the comment-and-close steps in stoker-implement).
## Summary
<1–3 bullets describing what this PR does and why, in user / PRD-
level language. Draw ground truth from the commits on this branch;
draw user-facing framing from the task issue title.>
## Validation steps
<Bulleted manual-QA checklist for verifying the change. Omit anything
CI runs automatically (no linting, type-checking, or automated test
suite items). Only manual verification.>
## References
- Closes #<task_issue>
- PRD: #<parent_prd> <!-- omit if no parent PRD -->
- Jira: <jira_url> <!-- omit if no Jira key -->
Rules for the References section:
Closes #<task_issue> so the task auto-closes on merge.PRD: line if there is no parent PRD.Closes # line if there is no task issue (a hand-driven
PR with no tracked task).Jira: line if there is no Jira key.Closes #N per referenced
task, sorted ascending. There is a single Jira: line per PR (all
tasks on a branch share one ticket).For a branch tickets/DM-45678-run-harness-flag:
## Summary
- Add `--harness` flag to `stoker run` so an iteration can be locked
to a single harness regardless of profile defaults.
- Validate the harness name against the registered-harness registry
and fail fast on unknown values.
## Validation steps
- Run `stoker run --harness codex 1` against a fixture issue and
confirm the implement+review phases both invoke codex.
- Run `stoker run --harness foo 1` and confirm it exits with a
non-zero code before any container work starts.
- Run `stoker run 1` (no flag) and confirm behavior is unchanged.
## References
- Closes #45
- PRD: #41
- Jira: https://rubinobs.atlassian.net/browse/DM-45678
The PR title for that branch would be
DM-45678: Add --harness flag to stoker run.
stoker-implement
and direct human use. Keep the body shape stable — the AFK loop's
multi-task PR-update logic depends on the exact section names and
trailer format above.### Jira URL field (written interactively by
stoker-prd-to-issues) or is constructed from the key in the branch
name. The sandbox AFK loop is GitHub-only — it has no Jira creds,
MCP, or firewall egress to Jira.Co-authored-by: trailer (signing, if configured, is
self-identifying).git show and the GitHub UI cover
that.Add follow-up `prd-task` issues to an existing PRD so the stoker AFK loop picks them up and appends commits to the open PR, propagating the Jira Key/URL and commenting back on Jira. Use for review-derived fix-ups on an open PR, or for ad-hoc adjust/refactor ideas that should feed back into the AFK loop instead of being done interactively — in a Rubin stoker-installed repo.
Write a Product Requirements Document seeded from a Rubin/DM Jira ticket (via the Atlassian MCP), interviewing the user and exploring the codebase, then submit it as a GitHub issue using the stoker `prd` Issue Form and comment back on Jira. Use when the user wants to write a PRD, plan a feature, or create a product requirements document — especially from a `DM-` ticket — in a Rubin stoker-installed repo.
Break a PRD GitHub issue into independently-grabbable `prd-task` issues using tracer-bullet vertical slices, applying Rubin branch naming and propagating the Jira Key/URL onto each task, then comment back on Jira. Use when the user wants to break a PRD into tasks, convert a PRD to issues, or create implementation tickets — in a Rubin stoker-installed repo.