zheref

amaterasu

Build and start the app for the declared launch target from the maintainer's core working directory — never from a worktree — and hand back the exact command that did it, copied verbatim out of the dry run. Runs as phase four of `ren`; invoke `hatsu:amaterasu [<target>]` by name to relaunch or switch targets. A disconnected device is reported by its declared name and falls back only to the declared simulator; a session in a worktree reports the command instead of running it.

zheref 0 Updated 4w ago
GitHub

Install

npx skillscat add zheref/hatsu/amaterasu

Install via the SkillsCat registry.

SKILL.md

Amaterasu — the app, running, on your machine

Nature: Transmuter. It runs declared machinery and a long-running local process; it writes no
code and sends nothing (a deploy is G3).

Build what I am working on and start it on the target I said, from the directory I actually work
in, and tell me the exact command so I can run it myself.

Phase four of ren, after `kokusen`; it never pushes or opens anything. Every rule of the declaration it executes is
`docs/LAUNCH-MIGRATION.md` § Launch declaration rules
.

0. Standalone entry

`docs/STANDALONE-ENTRY.md` (§ 4 for a composite's skip; plugin
root per PROCESS.md § Authority every phase shares). Cold it adds P1
and P2, read with § 3 — whether this is a worktree, a session in one reporting the command
rather than running it
. The launch shows the tree on disk, not a commit: name uncommitted
paths.

1. Invocation

hatsu:amaterasu [<target>]        # <target> names a key of nen/contract.json → project.launch

With no argument the target is nen/workflow.json → launch.default. There is no built-in default
and none is ever guessed
— a wrong build on a wrong device is not undone by relaunching. 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
launch target set up through `jujutsu`.

What the declaration says What amaterasu does
project.launch absent or empty record no launch target declared; skipped, naming nen/contract.json, and continue
launch.default null, no argument, no declared targets the same, naming launch.default
launch.default null but targets are declared, no argument the case that asks, the declared targets as options
an argument naming an undeclared target the trigger to ask: name it, the declared targets as options (or one set up through jujutsu), never a near-match

Asking on the no-launch case is the defect: a question the configuration answered, asked every
ren turn, trains the maintainer to dismiss it — no question, stop or bell; continue.

§ 1a · The profile. Under nen/workflow.json → profile fast, `ren` § 2a
skips this phase and the launch line reads deferred by profile fast; the next standard or thorough turn, or hatsu:amaterasu by name, launches — nothing built or moved (mukai has no launch step).
Named by the maintainer, it runs under any profile.

2. The parameters, and the completion the launch owes

Value File → key
The default target and the disconnected-device fallback nen/workflow.json → launch.default, launch.fallback
The targets — verb, args, device, after-steps, lane, artifact nen/contract.json → project.launch.<target> (LAUNCH-MIGRATION)
The verb's command line, and where it runs project.verbs.<lane>.<verb>, project.lanes.<lane>.cwd

nen shu dev|run --target <name> executes the whole block — the probe, the lane's verb with
args appended, the after-steps with both substitutions. With no nen/workflow.json
(PROCESS.md § Invocation and parsing) there is no launch.default
and no launch.fallback: with targets declared, name them and ask; with none, § 1's no-launch
case.

Physical-device completion. The lane must build for the target's actual platform — check the
dry run's lane, destination, artifact substitution and after-steps first. An iPhone target
wired to a simulator build is an incomplete declaration
(a simulator .app named in after[] is no
device artifact): repair it within authorized scope or record the blocker through
the discovery protocol. Success is the device build, its install and
the launch, each reported
; a dry run or build-only result is launch incomplete, and missing
install/launch steps are a declaration gap even at exit 0. Record discovery is Nen's shared launch
resolver's
(nen#204); a temporary normalizer stays
linked with owner and removal condition; no extraction key is added to an older binary.

3. The core working directory, never a worktree

A launch runs from the maintainer's own checkout and nowhere else — not a git worktree, a
subagent's copy or a temporary clone. From a worktree it is another tree's build racing theirs on
one port, derived-data directory and bundle id; a fresh worktree fails the
declaration's own preconditions
, and launching writes to a SHARED device, so isolation buys
nothing.

nen will not stop you (cwd: renders the worktree, silently), so the rule is this skill's:
core is nen wc worktrees --repo <any checkout> --json's core, passed as --repo; and a
parallel subagent effort never launches
, reporting § 4's dry-run argv verbatim and stopping.

Then nen wc swap --status --repo <core>. An active swap (`amenotejikara`)
is named in the launch line — branch or commit, view or take — since core builds that tree. A status that does not answer (exit 1/2) is refused: no launch on a
half-swapped core.

§ 3a · The one sanctioned exception — validating a declaration from a non-core checkout, since
`jujutsu` § 6 hands off a declaration PR nothing has run. Only when all
four
hold: the maintainer's written delegation names the device and the target; the purpose is
a declaration under review, never a turn's launch, ren's phase four or a composite; no other
session holds the app
; and the report says so, in these words — "validation launch from a non-core checkout: <path>; delegation names device <name> and
target <key>; declaration PR <url>"
— with the preconditions satisfied by hand. Everything
outside those four is forbidden.

4. Resolving the device, the dry run, and the command you paste

The probe's three outcomes are LAUNCH-MIGRATION's; what this skill does with each:

Outcome What amaterasu does
Present and usable substitute its id into {device.id} in the after-steps
Present but NOT usable Refuse; never the simulator fallback — it is plugged in, one tap from working. With readyWhen, nen already refused at exit 5 (device, state seen, states accepted): relay it and name the on-device step that closes it (`jujutsu` § 3). With no rule nen reports it resolved: read the probe's state column and report the missing readyWhen as a declaration defect
Absent Report it by name — "<device.name> is not connected; the probe saw: <what it listed>" — then fall back to launch.fallback, saying so and naming it
Absent, launch.fallback null say so and stop: plugging one in is an on-device act, picking another a guess
No device declared straight to the dry run
nen shu <verb> --repo <core working directory> [--lane <lane>] --dry-run [--json]
nen shu <verb> --repo <core working directory> --target <name> [--lane <lane>]
  • <verb> is project.launch.<target>.verb, exactly — dev or run, closed; nen carries no
    target across the two (the other is exit 2 naming the fix). With --target, the declared verb
    is checked before the lane's seat
    , so an exit 4 there is a real seat, quoted as one.
  • Dry run and pasted argv: PROCESS.md § Running a declared verb —
    copied, never re-typed.
  • One bare line whether or not the target declares args (nen appends them); a --lane
    contradicting project.launch.<name>.lane is exit 2 naming both
    .
  • dev/run are long-running: --json without --dry-run is exit 2, and the launch is never
    backgrounded
    to free the terminal — say the app is running and what holds it.
  • Exit codes per claude/agents/kurapika.md § The shu verbs; here 1 is a declared step
    failing — say which: build, install or launch — hand authored-code failures to
    `rasengan`, a failed install or launch being incomplete delivery; 3 an
    excluded host, a G5, never retried; 4 a real seat, quoted, then the repository's documented
    command run and said; 5 the program not on PATH.
  • The after-steps are nen's, in the same --target call, nothing by hand. Quote the dry run's
    substitutes: line
    , not artifacts: — what the child receives, not what the build produces.

5. Residue

By hand: § 3a's four conditions. Reading device state with no readyWhen is residue with a fix, lapsing when a
jujutsu PR writes the rule. No default target ever, no -- passthrough (an undeclared argv
is an unreviewed one), and nothing in nen stops a long-running child.

6. Authority and hard limits

  • Permitted: run the lane's declared build/dev row from the core working directory, run a
    declared device probe, run the declared after steps, hand back the exact command.
  • Not permitted: nen shu deploy --run in any form (G3, row release-go); any push, commit,
    PR, label or release. Not a gate event: a disconnected
    device with no declared fallback is a stop-and-say, and an unsupported host (3) is its one G5.
  • Never launches from anything but the core working directory, except under § 3a's four
    conditions, said in its own words; never from a parallel effort; and never reaches § 3a from a
    composite
    .
  • Never falls back to a simulator for a present-but-unusable device, to an undeclared device, or
    silently; never invents a target, and never asks when the declaration already answered (§ 1).
  • Never types a shu subcommand the target did not declare, or drops --target to get past exit 2.
  • Never substitutes a plausible command for a declared one, re-types the pasted command from
    memory, or runs the bare lane verb for a target that declares args.
  • Never claims the app is running on a dry run or unread exit code.