Take one issue from wherever it sits to a delivery PR standing ready at its human gate. Use when the maintainer invokes hatsu: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.
Install
npx skillscat add zheref/hatsu/build Install via the SkillsCat registry.
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 hatsu:ten build (`ten` § 6 catches up this phase's
missing prerequisites under its own name; the phases this run calls skip theirs).
hatsu: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 innen/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 itsnen/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: aDECIDE 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.
- Gon decomposes the idea into an epic with sequenced children (§ 2), watched in session.
- G1 is the maintainer's: stop (
nen stop --gate G1 …), brief the epic, ask for the mode label;
nothing below happens until it exists. - Waves advance — always this run's job; Hatsu has no epic-coordinator workflow.
- Release the issue into
building— the G1-M go-signal (CON-25). - Kurapika builds it himself, in this session, in the confirmed mode.
- 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.
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, anddocs/Loop/<run-id>/ holds decisions, every logged label application and each build session's
progress.
9. Residue
- Severity/mode reasoning, § 3's
DECIDEbrief and § 6's G5 diagnosis stay judgment. - One stage label per object (
CON-9) is not enforced:nen label applyapplies and logs the
one label it is given. - A repository with no
projectblock 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
main(CON-5/CON-7, rowsmerge/canon-merge), its own PR anywhere, or the
chore/integration delivery PR. - 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-labelsmap 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, rowrelease-go). - Never leaves the delegation open — say when it ends.