Drive a target repository's backlog to zero open actionable issues, in severity order, as gate-ready PRs. Use when the maintainer asks to work the backlog, clear open issues, run the loop, or keep a repo current. Kurapika triages, sequences build and sharingan across at most two efforts, cuts tags and runs the fan-out at severity-batch boundaries, and renders the per-cycle status board as a Rikugan. Never merges main; G2/G4/G3 stay the maintainer's.
Install
npx skillscat add zheref/hatsu/backlog-loop Install via the SkillsCat registry.
Shared policy: `PROCESS.md` § Standalone entry.
Backlog loop — drive a backlog to zero, in severity order
Nature: Manipulator, with each advanced issue switching to whatever mode
`build` § 3 confirms for it. Name the mode when it switches.
Hatsu holds no CI plane, so "advance an issue" is a pointer: turning a routable issue into a
PR is `build`'s job, driving it to CON-32 readiness is
`sharingan`'s, and this skill's own job is the concurrency arbitration, the
ordering and the batch-boundary layer. Neither engine is re-described here.
nen backlog fetch|order, nen loop slots, nen pr staleness, nen tag cut, nen fanout compute|record, nen changelog collate|completeness|fragment-required, nen report data|render andnen stop are this skill's own verbs. build/sharingan's verbs are never re-invoked here.
1. Invocation
P1 — this run opens with hatsu:ten backlog-loop (`ten` § 6 catches up this phase's
missing prerequisites under its own name; the phases this run calls skip theirs).
hatsu:backlog-loop <repo_code>nen parse backlog-loop --grammar "<repo>" --line "<the raw invocation>"
nen repo resolve <CODE> --repo <target repo checkout>The code resolves against the registry, never from memory; an empty line (exit 2) or an
unresolved code is the trigger to ask, the registry's real codes as the options. A missing argument or configuration item
is asked for and set up inline (missing-argument, missing-configuration;
`WORKFLOW.md` § 4 Ask, set up, continue).
Say the run has started. A named run holds a bounded CON-25 delegation (§ 3); a delegation
nobody announced is one nobody can end.
The phases this composite calls skip their own § 0 and inherit P1–P4 from this run
(`STANDALONE-ENTRY.md` § 4).
2. The cycle
Re-run on every fetch trigger: at start, whenever an issue reaches its gate (a PR merges or goes
Ready), and whenever the monitor (§ 6) sees a PR state change.
- Fetch every open issue, fresh —
nen backlog fetch --repo-slug <owner/name> --json, never
cached, never capped; omit--limitentirely, and never render atruncated: truefetch as
complete. - Triage anything with no
bankai:severity/*label (§ 4). - Order the queue (§ 5).
- Advance up to two efforts (§ 5a).
- Check batch boundaries — a severity batch fully merged fires a tag-cut and fan-out (§ 7).
- Report the status board (§ 8).
3. Authority
CON-25's third carve-out — the run-scoped standing delegation the constitution names for this
skill by name, not the fourth carve-out's per-skill table.
It may propose and apply bankai:severity/* on an untriaged issue, logged, and hand an issue tobuild, which applies bankai:stage/building under its own delegation.
It may not do anything § 11 forbids: a G1 mode label, any merge, any review vote, a release
(G3, the maintainer's alone, CON-6), a tag outside a § 7 boundary, or a wake.
CON-46(c-i)'s stale-chore-merge carve-out is retired here, never exercised
(PROCESS.md § History).
4. Triage & briefing
Untriaged (no bankai:severity/*). Propose a severity with one line of reasoning, then apply
it under the carve-out:
nen label apply <CODE>-IS-#<N> --label bankai:severity/<level> --repo-slug <owner/name> \
--reason "<why, for the ledger>" --runThe severity taxonomy is read from the target's nen/labels.json and nowhere else, never
hard-coded. Pass --repo <the target's checkout> so the label validates against that file, not
against the checkout the loop happens to run from.
bankai:handbook-question items and design calls need a decision, not a fix. Brief the
maintainer at G5 (§ 8) with a DECIDE ask: what is being asked, the options, the recommendation and
why. Never guess a policy call and never close one unanswered — an unanswered question is a
briefed row, not a resolved one.
Routing an issue to a mode is build's § 3 question, not this skill's. This skill decides only
when an issue's turn comes up.
5. Priority order
nen backlog order --rows-from <path> --severity-order critical,high,medium,low \
--blocks <ids> --affects-consumers <ids>--rows-from is not backlog fetch --json's output: reshape each row to{id, severity, createdAt, number} first, severity read off the label. The verb validates that file
at the read seam and refuses a fetch document, or a row missing id, at exit 2 naming file, row
and field. What stays this skill's judgment on top: critical pre-empts everything in flight, alow is deferred behind anything higher still open, and an issue that blocks another or affects
consumers is named as such rather than merely ranked.
5a. Advancing an effort
Work at most TWO efforts at a time. Never three. Mechanized, not eyeballed:
nen loop slots --efforts efforts.json --local-cap 2 --jsonEvery effort here is "plane":"local" — Hatsu holds no ci plane, so a slot frees only once a PR is
both "ready":true and "prompted":true, meaning the maintainer has actually been shown the
ask. --local-cap 2 is required — a guard chosen, never assumed; --efforts resolves against
the process cwd, so pass an absolute path.
When a slot is free, take the next row nen backlog order returned (respecting § 5's judgment
layer) and hand it to `build` (hatsu:build <CODE>#<N>); once a PR exists,
`sharingan` (hatsu:sharingan <CODE>#<N> to <G2|G4>) takes it the rest of
the way.
nen pr staleness: this skill reads the same two conjuncts sharingan reads and never themergePermitted field — this run carries no merge delegation, ever.
The wake channel lives in sharingan (§ 5). This skill never calls nen wake fire/verify
— it recognises, from what sharingan reports back, that an effort is CI-authored, and keeps counting
it against the same two-slot cap.
Never two efforts touching the same file. No verb governs this; sequence them and say so.
6. The monitor
Between cycles keep watching PR check transitions, new reviews, new comments, merges, and new or
relabelled issues. A merge or a state change is a fetch trigger — go back to § 2. No scheduled sweep
stands behind this run; polling is in-shell and in-session.
7. Tag-cut, fan-out and release
| Trigger | Action |
|---|---|
All critical merged |
tag-cut + fan-out. Nothing releases while a critical is open |
All high merged, changes unreleased |
tag-cut + fan-out; do not pause medium work |
All medium merged, no critical/high open |
tag-cut + fan-out + prepare the official release with developer-facing notes — then stop at G3 |
low merged |
tag-cut, hold the fan-out |
A cut is permitted only at a boundary above, after the changelog-collation release PR the
maintainer merges, never past a refused tag capability, never on an --at that is not an ancestor oforigin/main; a band that "looks finished" is not a boundary. The cut itself, the CON-36 live-chore check, an active RELEASE_HOLD, changelog.d/, latest
and the CON-22 fan-out computation are `getsuga`'s lane; this skill reaches
a boundary and hands over. If the tag capability is refused, HALT and hand the maintainer the exact
command — never route around a refusal, never write latest for a tag that does not resolve
(CON-14).
8. The status board — the register, every cycle
Rendered, never hand-formatted. The per-cycle status board is a Rikugan, rendered
through the register variant, via `backlog-board` § 3 — one collapsible
row per issue and PR in the queue, the desk carrying this cycle's asks, grouped by gate and ranked —
never hand-authored HTML or a markdown table.
Beyond the register, state every cycle the briefed items awaiting a decision, the blocked items and
what blocks them, and every label applied under the delegation (issue, label, time), objects named
as PROCESS.md § Reporting a phase says.
Every place this run reaches a gate is a gate event in
`WORKFLOW.md` § 4's stop shape — nen stop --who Kurapika --gate <Gn> [--notified] board.md, the register as the linked page — and never a banner on a progress report.
When the maintainer is needed, do not stop. Notify, record it on the register, and continue on
other efforts. Only a genuinely empty actionable queue ends a cycle.
9. Conflict discipline
One worktree per effort, per build/sharingan's conventions; cascade main whenever it
moves (nen pr cascade-main --repo <path> [--trunk main]).
10. Ending the run
The run ends when the actionable queue is empty: every open issue delivered as a PR standing at its
gate, briefed and awaiting a decision, or blocked with its blocker named. Say the run has ended so
the delegation lapses. The final report is the final Rikugan (backlog-board § 3) —
one effort, a cleared desk, written to <reports.dir>/<YYYY-MM-DD>-<effort>.html — carrying every
issue with its state, every PR's verdict verbatim, every label with its time, and what is on the
maintainer's plate. This skill never resumes itself — re-invoke it.
11. Hard limits
- Never merges
main, a chore/integration branch, or its own PR anywhere. - Never self-reviews, never impersonates a reviewer, never casts
request_changes— binding even
when the finding is real. - Never applies a G1 mode label — human-only, inside a run or outside it.
- Never fires or verifies a wake itself (§ 5a).
- Never cuts a tag outside a § 7 boundary, never auto-pushes one without
--push, and never
publishes the release — that is G3, the maintainer's alone. - Never exceeds two concurrently-driven efforts, and never lets two touch one file.
- Never hand-formats the status board — it is the register variant (§ 8).
- Never closes a briefed policy call unanswered.
- The run-scoped delegation expires when the run ends. Say when it ends.
History: PROCESS.md § History; dated live verifications:docs/ab/backlog-loop.md.