Bankai handbooks — the resolved set, cited, never improvised

No fixed mode. This skill is consulted from whichever mode is doing the work that needs a
citation — most often Enhancer (building in a Bankai-consuming product repo), sometimes Transmuter or
Conjurer. Name that mode when you invoke this; this skill only resolves the set the citation draws
from.

The handbooks in <reference-repo> are the single canonical source for Bankai work. Load the right
ones and no more — a rule cited from memory is a rule that has already drifted, and this is not a
hypothetical: the retired skill's own "always load" list went stale twice, by its own repo's
history, not by passive drift. 3a463b4 (2026-08-08) added ux-baseline.md to handbooks/INDEX.md's
table without touching the retired skill's hardcoded list; c711f4e (2026-08-20) added
quality-baseline.md to that same table and edited the retired skill file itself in the same
diff — yet still left its "always load" prose at three files, never reconciling it against the
table it grew in the very same commit. Two chances to fix it, in the very act of touching the file,
both missed: the set is five files today (§ 2 below; recorded live in
docs/ab/bankai-handbooks.md § 1, verified directly against both commits). This is exactly the
repeated maintenance failure the read handbooks/INDEX.md fresh every time rule exists to
prevent, not a one-off oversight — resolve fresh, every time; never carry a fixed list forward from a
previous session or from this file's own prose.

<reference-repo> is FROZEN, at the tag contracts/reference.gates.json's header names (v0.11.3 as
of this port — verify the checkout you point at actually sits on that tag with git -C <checkout> describe --tags before trusting it, since a stale local clone can silently drift off the pin).
Never write to it — no PRs, no branches, no issues, nothing. A handbook gap found while resolving
is a finding to raise to the human (§ 4), never something this session fixes by opening a <reference-repo>
PR.

The two-read-path split CON-13 describes — CI reads <reference-repo> live from a checkout;
build/local agents auto-load a product repo's generated, pinned .claude/rules/ mirror of it —
collapses to ONE path here. nen canon resolve computes the identical resolved set, live and
deterministically, straight from a <reference-repo> checkout: there is no reason left to trust a
possibly-stale mirror when the live computation is this cheap and this exact. Point --repo at
the checkout, never at a product repo's mirror.

---

1. Resolve the scenario

nen repo scenario --repo <reference-repo checkout> --target <owner/name>

A missing argument or configuration item is asked for and set up inline (missing-argument,
missing-configuration; `WORKFLOW.md` § 4 Ask, set up, continue): a
repository the caller did not name is asked for, never assumed. The registry is the frozen
<reference-repo>'s, so a target it does not record is reported in the verb's own words and raised
as a § 4 finding — never set up by writing to it.

Reads the scenario value recorded for <owner/name> in that checkout's registry —
nen/repos.json — the registry the frozen <reference-repo>
still carries and nen reads through the fallback — verified live against the real registry: <product-repo-A> → swiftui-tca-uzf-v2, <product-repo-B>
→ compose-uzf-v2, <scaffold-repo> → <reference-repo> (the self-review/machinery scenario — no
product code, BC-{n} citations only, and this repo is ALSO a genuine registry consumer, distinct from
its separate maintained_tools ownership entry).

Finding against the retired skill's prose, not the binary. The old bankai-handbooks skill said
the scenario comes "from .github/workflows/bankai.yml". Verified live: nen repo scenario never
reads that file — it reads the value recorded for the target in the registry (nen/repos.json,
which Naruto/CON-14 keeps factual against the live workflow file by
hand, one layer removed. The
distinction matters when the two disagree: resolve from the registry, the way the verb does, never
by opening bankai.yml yourself.

• --repo is a path to a checkout, always a <reference-repo> one — never an owner/name slug —
  and it is required: omitted, the verb refuses at exit 2 by name (nen v0.2.0, #73, closes
  zheref/nen#28; verified live at v0.3.0), never a silent cwd default.
• --target is an owner/name slug — never a product code. nen repo scenario refuses a code
  outright, verified live at v0.3.0: --target takes an owner/name repository slug and 'RA' is not one.
  If you only have a code, resolve it first with nen repo resolve <CODE> --repo <reference-repo checkout> — since nen v0.2.0 --repo is valid on the token form too ("the same flag its siblings
  take, valid with and without a token", nen repo --help; verified live: nen repo resolve BC --repo <path> from an unrelated cwd resolves), which closes the finding this port filed against v0.1.0
  (docs/ab/bankai-handbooks.md § 2.3: the token form read the registry from the process's cwd
  regardless). --from is the no-token form's flag only and is refused beside a token.
• No GH_TOKEN needed anywhere in this skill. Both verbs here are pure local-file reads against
  the checkout on disk — verified live with no token exported at all.
• Exit 1 → still covers two unrelated failure classes that share the same code — re-verified
  against v0.3.0, and nen's v0.2.0 changelog (#73) split the scenario refusal by cause without
  moving the invocation mistakes off 1:
  • <owner/name>'s scenario cannot be read from this registry. Since v0.2.0 the verb gives a
    distinct reason for each state, so you no longer open the file to tell them apart: the checkout
    carries no registry (<checkout>/nen/repos.json: no such file … or, until v0.4.0, the legacy 'schemas/repos.json'); the target is not recorded anywhere in it ("not as a consumer, a
    product-code value, a maintained tool, or a pending onboarding"); or it is recorded but not as
    a consumer — under maintained_tools, pending_onboarding, or only as a product_codes value —
    and "only a consumers[] entry carries a 'scenario' field". Relay the sentence; it is the
    diagnosis.
  • RETIRED at nen 0.7: an invocation mistake now exits 2, not 1 (zheref/nen#93). A
    missing --target, and a --target that is not an owner/name slug, both refuse at exit 2
    across the sixteen verbs of the repo, labels, pr and issue families — verified live at
    the pinned 0.7.0, where v0.6.0 answered 1 to both (docs/ab/bankai-handbooks.md
    § Retired at nen 0.7). The refusals also gained the sentence that says which flag is which:
    "It is the GitHub side of the pair; --repo names a checkout on disk and is never used to
    address the API."
• Exit 2 → an invocation mistake: an omitted or malformed --target, an omitted --repo,
  or a --repo path that does not exist on disk. Fix the command — asking for whichever value the
  session cannot supply — and never read exit 2 as "no scenario."

The exit code is now load-bearing, and reading it is the point of the change. "You typed it
wrong" and "the thing you asked for did not work" want different reactions, and a retry wrapper
honouring that distinction retries a 1 and gives up on a 2 — so the wrong code turned a
forgotten flag into a loop. So: exit 1 is a finding about the registry — one of the three
causes above, each with its own sentence — and exit 2 is a finding about the command. The
refusal text is still what you relay, because it is the diagnosis; the code is now what you branch
on. Recorded in full, with both transcripts, in docs/ab/bankai-handbooks.md
§§ 2.2–2.3, finding 5 of § 4, and § Retired at nen 0.7.

2. Resolve the handbook set

nen canon resolve --repo <reference-repo checkout> --target <owner/name> \
  --always-load <paths from handbooks/INDEX.md's "Always load" table, comma-separated> \
  --stack-dir handbooks/stacks \
  --json

--always-load is caller data — read fresh from handbooks/INDEX.md's own "Always load" table, at
the same checkout, every time. It is not looked up by the verb; you supply it. It is also not stable:
the table has already grown twice while the retired skill's own copy of it sat frozen (three files →
four → five, § above). Verified live at the frozen tag, it resolves to:

handbooks/uzf-core.md, handbooks/security-baseline.md, handbooks/ux-baseline.md,
handbooks/release-policy.md, handbooks/quality-baseline.md

— UZF-{n}, SEC-{n}, UX-{n}, REL-{n}, QA-{n} respectively. Read the table yourself before
every resolve rather than pasting this list from memory next session — that is exactly the drift
this section exists to name.

--stack-dir handbooks/stacks is the fixed directory layout, not caller data — it does not change per
scenario and needs no re-reading.

--always-load and --target both refuse outright (exit 2, "is required") when omitted. --repo
does not — leave it off and the verb silently falls back to the process's own cwd rather than
refusing (verified live). Never omit it.

The verb computes, in one call, both halves the old skill's title promised: the always-load set
(echoed back for confirmation) and exactly one stack handbook, derived directly from the scenario
nen repo scenario returned — never looked up in a table of its own. Today's scenario → stack →
rule-prefix mapping, read from handbooks/INDEX.md's own stack table at resolve time, never memorized:

Scenario	Stack handbook	Rule-ID prefix	Recorded consumer today
swiftui-tca-uzf-v2	handbooks/stacks/swiftui-tca-uzf-v2/architecture.md	SW-{n}	<product-repo-A>
compose-uzf-v2	handbooks/stacks/compose-uzf-v2/architecture.md	KT-{n}	<product-repo-B>
react-uzf-v1	handbooks/stacks/react-uzf-v1/architecture.md	RC-{n}	none yet (zheref/kro-pwa is pending onboarding onto it)
<reference-repo>	handbooks/stacks/<reference-repo>/architecture.md	BC-{n}	<scaffold-repo> (self-review, no product code)

react-uzf-v1 and <reference-repo> are not in the retired skill's table. It listed only
swiftui-tca-uzf-v2/SW-{n} and compose-uzf-v2/KT-{n}. Both of the others are real, live
scenarios today — resolve from handbooks/INDEX.md, never from this table once it, too, is a
session old.

Never load another stack's folder. The verb enforces this structurally — it returns exactly one
stackHandbook path, never a list — so there is nothing to improvise here even under pressure to check
"just one more."

3. Report

Quote the resolved set; do not summarize it:

<owner/name>  (scenario: <scenario>)
  always load: <alwaysLoad, joined>
  stack handbook: <stackHandbook>

Then cite findings by rule ID, drawn only from the files just resolved: UZF-{n}, SEC-{n},
UX-{n}, REL-{n}, QA-{n} from the always-load set; SW-{n} / KT-{n} / RC-{n} / BC-{n} from
whichever ONE stack file resolved for this repo. Never improvise a policy that is not written in one of
these files, and never cite a rule ID belonging to a stack folder other than the one that just
resolved.

4. When a rule is missing or ambiguous

The retired skill routed this to CI Yamamoto (a handbook/schema gap) or Naruto (a governance gap) per
CON-37, both landing a canon-lane PR <reference-repo> merged at G4. <reference-repo> is frozen — neither
exists to act on it, and no PR can land there anymore. Surface the gap as a finding instead: name the
file, the scenario, and what is missing or contradictory, then stop at G5 for the human to decide
where it actually gets resolved — a Hatsu-side documentation note, or an Akatsuki canon decision once
that repo exists. Never draft a fix that reads as though the question were already settled: an OPEN
gap stays OPEN (claude/agents/kurapika.md § Conjurer, "An OPEN item stays OPEN").

5. What this skill must never do

• Hardcode the always-load set or the scenario/stack table across sessions. Both drifted twice
  already, by the same repeated maintenance failure of an edit not reconciling a table it grew in the
  same diff (§§ 1–2 above); re-read handbooks/INDEX.md at the pinned checkout every time, never from
  this file's own prose.
• Read nen repo scenario's exit code alone as the diagnosis. Exit 1 covers both "this
  registry cannot give a scenario" (three distinct reasons, in the text) and an invocation mistake
  (missing/malformed --target); read the refusal text to tell them apart (§ 1).
• Load more than one stack folder, or guess a scenario when nen repo scenario refuses one.
• Improvise a policy that is not written in one of the resolved files, or cite a rule ID from a
  file that did not resolve for this repo.
• Treat "not a consumer" as "not a Bankai repo." Since nen v0.2.0 the refusal itself says
  whether the target is recorded under pending_onboarding / maintained_tools / a product_codes
  value — report which one it actually is, in the verb's own words.
• Open, edit, comment on, or otherwise write to <reference-repo> to fix a handbook gap. It is frozen;
  file the finding and stop at G5 instead (§ 4).
• Fall back to a product repo's .claude/rules/ mirror when a live <reference-repo> checkout is
  available. Resolve from the checkout — the mirror is no longer this skill's source now that the verb
  exists to compute the same thing live.
• Pass a product code to --target. Resolve it to owner/name first, from inside the <reference-repo>
  checkout (§ 1).