Bootstrap branch-context on an existing PR. Writes issue-brief.md from the linked issue(s) + current PR state, and backfills pr-decisions.md with decision-bearing entries from already-resolved review threads. Use when picking up a PR mid-flight (yours or someone else's) without prior local context.
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.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Bootstrap branch-context on an existing PR. Writes issue-brief.md from the linked issue(s) + current PR state, and backfills pr-decisions.md with decision-bearing entries from already-resolved review threads. Use when picking up a PR mid-flight (yours or someone else's) without prior local context.
Adopt PR -- bootstrap branch-context on an existing PR
Populate issue-brief.md and pr-decisions.md for a worktree whose PR already
exists and has history.
When to use
You checked out an existing PR and the branch-context files are empty
templates (or absent).
You are picking up someone else's PR.
Your own PR predates the branch-context setup and you want to backfill.
Do not use this for fresh work with no PR yet -- write the brief from the linked
issue directly.
Startup
Bootstrapping presumes the linked issue describes a real problem. If you have
not confirmed that, skim the issue before adopting -- authorship (a bot,
contributor, or automated sweep) is not proof the problem is real.
Read CLAUDE.md for project context.
Instantiate the branch-context instances if they do not exist:
If there is no linked issue and the body has no problem description worth
linking, proceed with issues: [] (free-text problem) -- ask the user whether to
continue or abort.
Step 3 -- Study the existing diff
Understand the code before synthesizing the brief:
git fetch origin main 2>/dev/null || git fetch origin master
MERGE_BASE=$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD origin/master)
git diff --stat"$MERGE_BASE"..HEAD
git log --oneline "$MERGE_BASE"..HEAD
Map the changes: which files/modules are touched, which tests exist on the
branch (existing tests are implied success criteria), which public symbols
changed, any notable new abstractions.
Step 4 -- Write issue-brief.md
Use the schema in issue-brief.template.md. Adaptations for adoption:
related_pr: the PR URL (not TBD -- the PR already exists).
branch: git rev-parse --abbrev-ref HEAD.
Success criteria -- derive from the issue text and from tests already on
the branch (each existing test is a de facto criterion; cross-reference them
in the table).
Affected surface -- extract from the diff, not from a planning pass.
Constraints -- include anything reviewers have already emphasized in
comments (e.g. "must preserve backwards-compat" from a maintainer reply).
Write to .claude/skills/branch-context/issue-brief.md, overwriting the
template.
Step 5 -- Backfill pr-decisions.md from resolved threads
Fetch resolved review threads via the GraphQL API:
For each resolved thread, read the full conversation, then classify:
Decision-bearing -- the thread debated two or more options, or a reviewer
flagged a concern and the author adjusted the code (e.g. "use kwargs over
positional", "renamed the public method", "moved the helper to a different
module").
Noise -- typo fixes, "nit: missing docstring", "good catch thanks",
resolved without a code change. Skip these.
For each decision-bearing thread, append an entry (Source is the root comment's
url):
.claude/skills/branch-context/append-pr-decision.sh \
--title "thread: <short title>" \
--decision "<one-line summary of what was decided>" \
--why "<one-line reason, quoting reviewer or author if concise>" \
--source"<thread URL>" \
--iter "-"
Decision budget: aim for <=10 entries. If more resolved threads than that seem
worth logging, you are probably over-including noise -- re-apply the filter.
Step 6 -- Seed an "adoption" meta-entry
Append one final entry marking the boundary between backfilled decisions
(everything above) and live-logged ones (everything below):
.claude/skills/branch-context/append-pr-decision.sh \
--title "adopted PR #<N> at <DATE>" \
--decision "Branch-context bootstrapped from existing PR + issue(s). Decisions above are backfilled from resolved threads." \
--why "PR predates the branch-context setup" \
--source"<PR URL>" \
--iter "-"
Do not open a new PR (it already exists). Do not commit anything to the branch
during adoption -- only read, classify, and write the two branch-context files.
Do not re-classify unresolved threads during adoption -- just report the count.
Do not log every resolved thread -- only decision-bearing ones. The decisions
log is meant to reward reading; diluting it with noise defeats the point.
Every backfilled entry must have a thread URL in Source:. If you cannot find
one, you are over-inferring -- skip it.
If the existing brief/decisions files are already populated (not templates),
the user's Startup confirmation governs whether to overwrite.
