Pr Fixup

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/pr-fixupThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Wait for CI and automated reviews on a PR, fix valid failures and comments, disposition every review thread, verify, and push in the primary conversation.

---
name: pr-fixup
description: Wait for CI and automated reviews on a PR, fix valid failures and comments, disposition every review thread, verify, and push in the primary conversation.
---

# PR Fixup

Use this workflow directly in the user-started primary conversation. Do not
launch a verifier, implementer, or other remediation subagent. A read-only
`pr-poller` is the sole exception: launch it only when the user explicitly asks
to wait for or monitor PR updates. For a cost-controlled workflow, the user may
switch the same conversation to the lower-cost implementation/test model before
starting CI remediation.

Use `gh` by default; auth or transport errors leave state unknown, never clean.
If `gh` returns an authentication error such as 401, use the structured GitHub
connector/API fallback for PR, check, and review data. Avoid dumping full
HTML/diffs. Map GraphQL thread IDs to REST comment IDs before replies, and
refresh current-head state after pushes and review aggregation.
If `gh auth status` reports a stale or invalid credential while `gh auth token`
returns a usable token, propagate it explicitly to the affected command, for
example `GH_TOKEN="$(gh auth token)" scripts/pr-await <PR>`; use the same
prefix for `scripts/pr-state` and `gh run` calls. Keep the token out of command
output and logs. If token retrieval fails, use the structured connector
fallback instead.

## Pipeline

Create a visible checklist:

1. Gather PR state
2. Resolve an authorized PR merge conflict
3. Fix failing CI checks
4. Triage every review thread
5. Apply valid fixes and record every disposition
6. Commit, rerun affected checks, and push
7. Re-check the new head
8. Report

## 1. Gather PR State

Before the first GitHub call, obtain any network approval required by the
runtime. If the runtime denies access, stop until the user authorizes access.

Run `scripts/pr-state --compact <PR>` and `scripts/pr-resolve list <PR>`.
Load [review-evidence.md](references/review-evidence.md) for snapshot fields,
review classification, hidden threads, and access fallbacks.
Capture each helper's stdout, stderr, and exit code once per evidence round,
then inspect that bounded snapshot. Do not fan out repeated `pr-state` calls
while diagnosing one head; repeated API reads can consume the available rate
budget and turn a usable snapshot into transport blockage.
For cross-repository PRs, use the snapshot's delivery fields as the push target.

Then run `gh pr view <PR> --json state,baseRefName,headRefOid,mergeable,mergeStateStatus,reviewDecision`.
Require matching head SHAs before triage. Verify the base SHA against the
current base-ref tip. Refresh mismatched metadata before attributing failures.
If the PR is merged or closed, stop. For a merge, report
`mergedAt` and `mergeCommit.oid`.

Treat peer alerts as advisory until their SHA matches the current head.
If captured output is empty, truncated, or invalid, rerun the command directly
and save its unmodified output to a file.
Capture stdout and stderr separately and preserve the exit code.
An empty capture cannot prove that the PR is clean.

If GitHub reports a conflict, load
[merge-conflicts.md](references/merge-conflicts.md) before CI or review triage.
An explicit fixup request authorizes conflict resolution within that request.
Otherwise, report the conflict without changing the branch.

If the base advanced without conflicts, use that reference's advanced-base
procedure. Base advancement alone does not require a branch update.
Record the head, base, synthetic merge, and focused test results.
If either input SHA changes, repeat the relevant validation.
Keep the helper's exit code unchanged and report any separately verified base drift.

For related or stacked PRs, use the semantic-conflict procedure in the same
reference. Reconcile changed contracts and stable IDs before delivery.

For pending checks, load [waiting.md](references/waiting.md).
Use `scripts/pr-await` and its final exit code.
For queue membership or enqueue/dequeue requests, load
[merge-queue.md](references/merge-queue.md).
For queue removals or failed synthetic checks, also load
[ci-troubleshooting.md](references/ci-troubleshooting.md).
Ordinary PR-head checks do not validate a merge-group commit.

Directly supplied review findings need current-source validation even without
a GitHub thread. Apply valid fixes within the user's authorization.
Do not invent comment IDs or resolutions for findings without a thread.
An explicit request to run PR fixup authorizes concise GitHub replies and
resolution for every unresolved review thread listed by
`scripts/pr-resolve list <PR>` once that thread's disposition is complete. This
defines the fixup scope, so do not ask a separate approval question for these
writes. A request to address selected comments authorizes writes only for those
threads; a review-only request authorizes no GitHub writes.

If `reviewDecision=REVIEW_REQUIRED` and `mergeStateStatus=BLOCKED`, report the
human approval gate. Green checks do not authorize self-approval or merging.

## 2. Fix CI Failures

Before changing code, confirm every reported failed check, its `run_id`, and
the parent workflow/job status. A failed job can be visible while its workflow
is still in progress; confirm its conclusion and failing step before treating
it as reproducible code evidence. Use
`scripts/run-quiet gh-run -- gh run view <run-id> --log-failed` so large logs do
not flood the conversation. If it returns only GitHub request/transport lines
or no failure text, treat logs as unavailable and, after terminal state, use
`scripts/pr-state --job-log <job_id>`. For temporary gaps or aggregate-only
logs, use the same fallback; it handles plain-text and ZIP responses and emits
bounded context. Follow `references/ci-troubleshooting.md`. Reproduce the failing
scope locally. For Go lint, use `bash scripts/lint-go-changed <changed-go-files>`
from the repository root, including any file named by the failure. Follow
`apps/backend/AGENT

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   !CAUTION B 89 / 100

   first audit · source 786d4817799e

Questions about Pr Fixup

• github.com/kdlbs/kandev/tree/main/.agents/skills/pr-fixup — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology