zheref

build

Take one issue from wherever it sits to a delivery PR standing ready at its human gate. Use when the maintainer invokes /build <CODE>#<issue>, or asks to build, start, release or deliver an issue. Kurapika confirms the mode, builds the issue himself — Hatsu holds no CI plane to route it to — and drives the resulting PR to CON-32 readiness, escalating a stuck effort to G5. Never merges, never applies a G1 mode label.

zheref 0 Updated 3w ago
GitHub

Install

npx skillscat add zheref/hatsu/surfaces-antigravity-skills-build

Install via the SkillsCat registry.

SKILL.md

Build — from an issue to a PR standing at the gate

Nature: Transmuter for machinery, Conjurer for canon/governance, Enhancer for product
code; the mode is named at § 3, and said aloud when it switches mid-run.

Give me an issue; I give you back a PR that is CON-32-Ready at its human gate — or a G5 stop
saying exactly why it could not get there.

Everything after the first PR appears is `sharingan`'s engine —
readiness, unblocking channels, reviewer rounds and the escalation ladder, inherited, never restated;
sharingan wins on PR mechanics, this skill on what precedes a PR. Hatsu has no CI plane to route a
released issue to
(`docs/WORKFLOW.md` § Building an issue with no CI
plane
): Kurapika builds it himself in the mode § 3 confirms, stopping at G5 where a local session
structurally cannot, never pretending a wake occurred.

The phases this composite calls skip their own ## 0.
(`docs/STANDALONE-ENTRY.md` § 4); the plugin root is
PROCESS.md § Authority every phase shares.

1. Invocation

P1 — this run opens with /ten build (`ten` § 6 catches up this phase's
missing prerequisites under its own name; the phases this run calls skip theirs).

/build <product|repo_code>#<issue_number>
nen parse build --grammar "<code>#<n>" --line "<the raw invocation>"
nen repo resolve <CODE> --repo <the target repo's own checkout>

Case-insensitive; a code is resolved, never guessed. A missing argument or configuration item is
asked for and set up inline (missing-argument, missing-configuration;
`WORKFLOW.md` § 4 Ask, set up, continue): nen parse exit 2 or an
unresolved code is the trigger, the registered codes the options, an absent entry set up in
nen/repos.json. If #<N> is a PR, hand straight to
`sharingan` and say so
— § 2's chain-position is the issue-vs-PR
check: its (and nen issue terminus's) exit 1 { issue, refused: true, reason } is the signal,
not a failure
. Say the run started: it holds a bounded CON-25 delegation (§ 5), and an
unannounced delegation is one nobody can end.

A target with no delivery-stage taxonomy is `docs/WORKFLOW.md`
§ A target repository with no delivery-stage taxonomy: never manufacture a --chain-labels map, never apply a nonexistent stage label, and
that path creates no G1 or label authority.

2. Read the issue before touching it — where is it on the chain?

nen issue chain-position --target <owner/name> --issue <N> --repo <the target checkout> \
  --chain-labels "idea=<label>,researched=<label>,approved-team=<label>,approved-direct=<label>,\
building=<label>,in-review=<label>,epic=<label>"

--chain-labels is caller data — the target's own label names per role, from its
nen/labels.json, never guessed. Map building, in-review, idea and epic, the four that
decide whether an unmatched issue is really routable; the rest return under unmappedRoles,
blocking nothing, so omit a role the repository lacks, never a placeholder. An unknown role name
is exit 2, never guessed past.

chain-position reports First move
closed The run ends, naming what closed it and which PR delivered it
building Released, open PR or not (in-review folds in) → § 4
idea Wake Gon to decompose it into an epic; his grammar unratified, he hands it back
epic-awaiting-approval Stop at G1 (row mode-label): the mode label is the maintainer's (CON-4)
epic-approved Children advance wave by wave — § 4
routable Confirm the mode (§ 3), release it (§ 4), then build it
undecidable Never guess: ask for the missing role's label, re-run — a role the repository lacks is omitted, never invented

epic-approved folds both mode labels into one state — read which off the issue's labels;
researched is an input role name, never an output state.

3. The mode is confirmed before anything is released

The issue's bankai:agent/* scope label chooses Kurapika's mode, not a CI agent.

Label present Mode
bankai:agent/naruto — a constitution/governance (CON-{n}) change Conjurer
bankai:agent/yamamoto — a handbook / Stack Matrix / schema / agent-def change Conjurer
bankai:agent/kisuke — machinery only, sanctioned by an existing rule Transmuter
several, spanning lanes a CON-36 chore on an integration/<chore> branch where it needs more than one PR — say so in the ask; the delivery PR is then integration/<chore> → main

With none, propose one and ask — a wrong mode makes a plausible, wrongly shaped PR: a
DECIDE per `jutaisho` § 4, row mode-unknown, once per run. A G1
stop is never a mode question
: for an unapproved epic the ask is the mode label (integration-branch
team delivery or direct-to-main), and only the maintainer applies it (CON-4).

4. Driving the whole chain, and releasing into it

An epic is followed all the way down.

  1. Gon decomposes the idea into an epic with sequenced children (§ 2), watched in session.
  2. G1 is the maintainer's: stop (nen stop --gate G1 …), brief the epic, ask for the mode label;
    nothing below happens until it exists.
  3. Waves advance — always this run's job; Hatsu has no epic-coordinator workflow.
  4. Release the issue into building — the G1-M go-signal (CON-25).
  5. Kurapika builds it himself, in this session, in the confirmed mode.
  6. Each child's PR is driven by `sharingan`'s engine to CON-32
    readiness — nen pr ready's verdict, never eyeballed.

Step 4's label command, its CON-25 carve-out and CON-9's one stage label are
`docs/WORKFLOW.md` § Releasing an issue into building
; every
application is logged: object, label, time.

Steps 3, 5 and 6's machinery — waves, the terminus PR, the --local-cap 2 slots, the nen shu
sequence and its G5 — is that document's § Building an issue with no CI plane
.

Every § 4 step this run performs is one ledger entry (#100), --phase <step-name> in this
section's own vocabulary (decompose, release, build, hanten, remediate, open, …), opened
before the step and closed after it with its exit, every nen shu inside carrying --effort <branch>
— so .nen/phases/<effort>.json holds the authoring and remediation phases, not only those a later
ren, hanten or en opened. Spend is recorded at every § 7 report, never transcribed at the
end; the reviewers' entries are `hanten` § 4's. The argv, the flags, the files
and the branch key are `WORKFLOW.md` § The effort's ledgers.

5. Authority — what this run may and may not do

CON-25's fourth carve-out: a human-invoked skill run holds the delegation its purpose requires,
logged, run-scoped, and those label classes only.

May release the building stage label on the named issue and on children created beneath it
May route bankai:agent/* on children it creates, by scope (§ 3)
No Wake row Hatsu has no CI builder to re-fire; a wake on a PR's other automated participant is `sharingan`'s
Never routes the named issue itself (§ 3 asks — its mode is the maintainer's read), applies a G1 mode label, merges, votes or publishes — § 10

The delegation expires when the run ends. Say when it ends.

6. When it will not move

No CI-wake ladder exists for Kurapika's own build: a stall is reported plainly, in-session — the
blocker, and whether it needs the maintainer.

  • A released issue this session could not finish is 🔵 on hold, naming the blocker — never
    silently abandoned.
  • Where Hatsu cannot do the work at all, that is a G5 naming the gap, not a routing decision.
  • Filing is a legitimate outcome: a real defect elsewhere blocking delivery is filed with
    `file`, linked, and the build held on it.

7. Reporting and the stop

The six-step verified-delivery checklist and the four claims are
`docs/WORKFLOW.md` § Verified delivery — the coordinator's four
claims
, owed in full before any handover, delegated work included.

The reviewer-round policy is `sharingan` § 6's, never restated here.
Progress turns and gate stops are PROCESS.md § Reporting a phase's; a
progress line names the issue, mode, PR, checks and rounds, and what is next.

Gate When The ask
G1 an epic awaits its mode label (row mode-label) DECIDE, with the trade-off
G2/G4 the delivery PR is CON-32-Ready (rows merge, canon-merge) MERGE, the verdict saying everything
G5 a stuck local build, or a capability a local session cannot have DECIDE or DO with a proposed issue — a mode tie is row mode-unknown; a missing installable tool, row missing-tool, is installed, not asked

The run ends when the delivery PR stands Ready, the issue closes, or at a G5 it cannot pass: say
which, and that the delegation has lapsed.

8. Resuming

PROCESS.md § Resuming a run; § 2's chain-position is idempotent, and
docs/Loop/<run-id>/ holds decisions, every logged label application and each build session's
progress.

9. Residue

  • Severity/mode reasoning, § 3's DECIDE brief and § 6's G5 diagnosis stay judgment.
  • One stage label per object (CON-9) is not enforced: nen label apply applies and logs the
    one label it is given.
  • A repository with no project block is built with its own documented commands, said so; the
    declaration is its own change at the declaration gate.
  • The stage-free path's raw issue read (§ 1) is never a chain verdict, and nen issue edit-body's whole-body write is not conditional: a concurrent change goes to the discovery
    protocol, never claimed as an atomic replacement.

10. Hard limits

  • Never merges another's PR, or the chore/integration delivery PR (CON-5/CON-7, rows
    merge/canon-merge); its own is en § 5's, at its terminus (row own-pr-merge, ruling 2026-09-29 (3)).
  • Never applies a G1 mode label, inside a run or outside it, and never routes the entry issue
    without an answer.
  • Never votes, self-reviews, impersonates a reviewer, or casts request_changes (CON-26).
  • Never drives more than two efforts at once (--local-cap 2), or lets two children touch one file.
  • Never claims a CI builder is doing the work — Kurapika builds it, said plainly.
  • Never builds, tests or lints a declared repository from a remembered command line, and never
    manufactures a --chain-labels map or a stage label a repository lacks.
  • Never runs nen shu deploy --run — a G3 act; this run stops at G2/G4.
  • Never publishes a release — G3 is the maintainer's (CON-6, row release-go).
  • Never leaves the delegation open — say when it ends.