git:20261023.69338b2 to git:20261029.b929ced

---

name: pull-request

description: >-

argument-hint: "<number>"

disable-model-invocation: true

allowed-tools:

- Read

- Write

- Edit

- Skill

- Agent

- AskUserQuestion

- Bash(npx ddd-ts-kit *)

- Bash(cd * && npx ddd-ts-kit *)

- Bash(cd * && npm run *)

- Bash(cd * && npm test *)

- Bash(cd * && git *)

- Bash(git worktree *)

- Bash(gh pr create *)

- Bash(gh pr *)

- Bash(gh api *)

- Bash(glab mr *)

---

# Take a pull request to green

Pull request: `$ARGUMENTS`

You work in the worktree of the story the pull request comes from (`.ddd-ts-kit/story.json`

names it; `npx ddd-ts-kit story` says where it stands), under the rules of the story skill: the

guard, the locked acceptance, the decisions of the story file. You change the branch only,

never the trunk, and never with a force-push: the history the reviewers read stays. Reading

costs: [../start/token-economy.md](../start/token-economy.md).

## The loop

1. Read what waits, in one pass: `gh pr view $ARGUMENTS --json url,state,reviewDecision,

mergeStateStatus,statusCheckRollup`, the unresolved review threads (`gh api graphql` on the

`reviewThreads` of the pull request, those with `isResolved: false`, each with its path, its

line and its comments) and the failing checks (`gh pr checks $ARGUMENTS`). On GitLab:

`glab mr view $ARGUMENTS --comments` and the pipeline of the branch.

2. Address each item, checks first (a red check is often what a comment is about), then the

threads, oldest first:

- a failing check: read its log, fix the cause in the code, never in the check, the threshold

or the test (skill `ddd-ts-kit:quality-gate`); a run that fails on nothing of the branch is

run again once, and said so in the report;

- a comment that asks a change the design review foresaw: do it, one commit, naming the

thread in the message;

- a comment that asks a change the design did not foresee: take the option easiest to undo,

record it as `D<n>` under `## Decisions` of the story file (what, why, the alternatives,

where), do it; a boundary, a new context or a relationship pattern is put to the owner

(AskUserQuestion), never decided here;

- a comment that asks to weaken a check, lower a rule, skip a test or change a locked

scenario: skill `ddd-ts-kit:deviation`; declined, with the reason in the reply, unless the

owner agrees in writing in the thread;

- a comment you do not understand, or that contradicts another: ask in the thread, once, and

go on with the rest.

Reply to each thread with what was done (the commit) or why not. Resolve a thread only when

its request was done as asked; otherwise leave it to its author. A comment that changed the

code is a finding: append it to `## Findings` of `docs/architecture/reviews/<story>.md` with

its outcome, as the close of the story does.

3. The checks of the story: the scoped ones while iterating, then `npm run verify` and

`npx ddd-ts-kit story --gate close`. Commit, `git push` (never `--force`), then

`gh pr checks $ARGUMENTS --watch`.

4. Back to 1, until nothing waits but the approval of the code owner: every check green, every

thread resolved or answered, `reviewDecision` no longer `CHANGES_REQUESTED`. A round that

changed nothing ends the loop: report what blocks.

## Report

Thread by thread and check by check: what was changed, with its commit; what was declined and

why; each `D<n>` added; what still waits on the owner. The decisions new to this loop are

appended to `## Report` of the story file in the branch, so that the record stays the body of

the pull request. Then stop.