SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsnuke-blitz

nuke-blitz

Coding & development

View repository

Updated 10-15 17:23

About this skill

Nuke Blitz

The fast lane between nuke-code and the pipeline (map: references/family-map.md). The ceremonies buy quality with orchestration — preflight, run_dir, waves, fresh-session handoffs; nuke-code caps at everyday scale. Blitz takes the middle: a medium-sized, single-deliverable task executed NOW, in this session, under the same invariants — falsifiable contract, gates with a baseline, one fresh validator, the family finding schema — with the orchestration cut away.

Core principle — same doctrine, shortest path: final quality is bounded by the strongest verifier, so speed is taken from planning overhead and delegation latency, never from the validator or the gates.

Arguments

plan — run CALL + PLAN, print the snap-plan block, STOP — nothing executed, nothing written. <task> — inline text or a path to a brief file. --ask — gate on the snap-plan block before GO; default is no gate: the block prints and the build starts.

The lane — countable boundaries, checked at CALL

Situation Move
Inline-sized: 1 file AND ≤~30 lines AND no contract change run nuke-code inline mode (BUILD charter + narrowest gate) and say so — blitz machinery would outweigh the change
In lane: ≤~10 touched files AND ≤~600 estimated changed lines AND ≤5 done-criteria AND one deliverable blitz executes
Oversized but clear STOP → recommend nuke-exec (task mode)
Oversized and ambiguous, or multiple independent deliverables STOP → recommend nuke-spec → exec

In-lane escalations, mid-run: hard design call (expensive to reverse, or two shapes with no nameable winner) → nuke-think before code · a bug whose cause is unproven after 2 fix attempts → nuke-debug discipline · ask names look/design or a new UI surface → nuke-creative light charter + nuke-design build charter during GO.

Mandates

  1. Speed never eats verification. The baseline, the gates, and the fresh validator are non-negotiable; every cut comes from ceremony — no run_dir, no waves, no handoffs — never from evidence.
  2. One clarification round, max. Ambiguity that changes what gets built → up to 3 targeted questions, batched, asked once. Everything else becomes a named assumption in the snap plan and the hand-back. Never invent a requirement; never ask what a file read answers.
  3. Escalate by count, never absorb. The lane table binds: a task that fails it at CALL is redirected before any code; one that outgrows it mid-run is checkpointed honestly with the numbers that tripped.
  4. No artifacts, no git. No run_dir — the hand-back carries the evidence (the nuke-code divergence, deliberate). Writes touch only the task's own files. Never git add / git commit / git stash; no .bak files.
  5. Main context stays thin when delegating. Workers receive paths and their own batch, never each other's files or the orchestrator's reasoning.
  6. Never claim success past a dirty state. A failing gate, an unmet criterion, or an open finding leads the hand-back.

CALL — the quick call

  1. Contract. Restate the ask as 2–5 falsifiable done-criteria + non-goals + constraints from the project instruction files, read now — not recalled. A brief file with falsifiable criteria is consumed as-is. Genuine ambiguity → Mandate 2's single round.
  2. Recon-lite. Consume .nuke/repo-map.md when present and fresh; otherwise skim only what the task touches — manifests, the target area's structure and exports. Resolve the gate rows for the touched path prefixes, and the file-type → skill map plus the review roster from ONE listing of the local skill library (references/stack-adapters.md).
  3. Lane check. Apply the lane table. Out of lane → STOP with the named recommendation and the tripping numbers.

PLAN — the snap plan

  1. Reuse, then shape. One reuse sweep first: grep for existing helpers, components, and utilities matching the task's nouns; the snap plan carries reuse: <file:symbol> | none — searched: <terms>, and a shape that reimplements a found symbol names why reuse loses. Then ≥2 genuinely different shapes, one-line trade-off each, winner named in a ≤5-line decision note that ships in the hand-back. A purely mechanical change may collapse to one shape with a stated reason; the done-criteria are never skipped.
  2. Cut and staff. Cut the touched files into disjoint batches. ≥2 disjoint batches AND ≥5 files → delegate: up to 3 parallel worker implementers, one per batch. Otherwise the session builds solo. Tiers: the blitz table in references/model-tiers.md.
  3. Print the snap-plan block — then GO immediately. --ask → gate first (AskUserQuestion where available: run / adjust / escalate to a ceremony); plan → print and STOP.
## Nuke Blitz — <task one-liner>
contract: 3 done-criteria · 1 non-goal · assumptions: 1 (named)
reuse: <file:symbol> | none — searched: <terms>
shape: <winner one-liner> (rejected: <strongest alternative>)
files: 7 in 2 batches · build: 2 workers + session | session solo
review: <roster — validator MUST load>
validator: session (fresh) | top (risk flag: <flag>) · fix-loop cap: 2
gates: <rows for touched prefixes> · baseline: <pass | pre-existing listed>
go — no gate (--ask to pause · plan to stop here)

GO — the build

  1. Baseline. Run the resolved gate rows once BEFORE editing. Broken tooling → fix it (max 2 attempts) and note it in the hand-back; a real pre-existing failure → recorded in the snap plan, the run proves no NEW failures — fixing it is offered, never silently adopted. A gateless area → gates: NONE — validation is review-only per references/stack-adapters.md; never validate silently against nothing.
  2. Build under the nuke-code BUILD charter — read before editing, neighbors are the style guide, mapped skills loaded for every touched file type, minimal diff, no defensive noise, a behavior test in the same diff where behavior changed, boring beats clever. Delegated batches: each worker gets the contract verbatim, its own batch, its skill list, and the nuke-lean charter; batches are disjoint by construction — two agents never write the same file.

SEAL — before the word "done"

  1. Gates. Re-run the resolved rows, narrowest first, output captured verbatim.
  2. One fresh validator. Solo build → session fresh (the everyday floor: equal tier but fresh); delegated build → session (one tier above the workers); any risk flag — public API, auth/security, concurrency, data migration, new dependency → top. It receives the task text, the contract, the diff, the printed review roster, and repo access — never the author's or workers' reasoning; the missing anchoring is the design. Charter: load every roster skill and name them in the report; verdict every done-criterion (met | partial | unmet, file:line + one verbatim quoted line each), then hunt what the change introduced via the four charter bundles of references/lens-catalog.md over the diff and its blast radius, and close with the fit verdict — fit: simplest sound shape | better shape exists: <one-liner> — the chosen shape judged against the nuke-lean design rules and the current stack idiom. Findings use the family schema (lens + severity + justification, file:line, quoted source, numbered trace, proposed fix, refutation attempt); a finding missing a field is invalid and must not be reported.
  3. Fix loop. Every confirmed finding of any severity is fixed. A better shape exists verdict that is cheap to adopt becomes a finding and is fixed; an expensive one is named in the hand-back as an option, never silently absorbed. Fresh revalidation each cycle; cap 2. Cap hit or unfixable → honest hand-back, open list first.
  4. Hand-back, verdict first:
BLITZ: clean — validator: 0 findings · gates: pass
done-criteria: 3/3 met (validator-verified)
gates: <verbatim tail>
reuse: <the snap-plan line, as executed>
shape: <decision note>
review: <roster skills the validator actually loaded>
fit: simplest sound shape | better shape exists: <one-liner> (left as option)
assumptions: <the Mandate-2 list, or none>
cycles: 1

or the honest open list: findings by severity, failing gates with output, exactly where it stopped.

Degradations

  • No subagents → build solo and validate inline: explicit role switch, diff re-read from disk (git diff, never memory), same charter and schema, hand-back marked validator: inline (degraded).
  • No per-agent model overrides → every role inherits the session model; risk flags still apply the platform's maximum effort/thinking dial where one exists (ceiling rules: references/model-tiers.md).
  • Claude Code: delegated batches as parallel Agent calls; pass model/effort per the blitz table in references/model-tiers.md. Other CLIs: batches sequentially, each in a fresh context, same validation protocol.