b4r7x Nuke Prompt
nuke-spec's sibling for prompts (map: references/family-map.md): compile intent into a prompt the same way spec compiles a feature into a build spec — requirements first, structure second, adversarial proof third. The chain mirrors the code side: prompt → eval as spec → verify; the hand-off recommends nuke-eval on the result, because a prompt that was never evaluated is a prompt that will be edited by vibes next week.
Arguments
[mode] — light (default) | full | plan (preflight, print, STOP).
<goal> — what the prompt must make the model do (inline text), or a path to an existing prompt to harden.
--ask — pause at the preflight plan for confirmation; default is no gate — the plan prints and the run starts (references/preflight.md). Clarifying questions are content, not a cost gate — ambiguity always asks regardless.
Modes
Tier vocabulary and platform mechanics: references/model-tiers.md.
| light (default) | full | |
|---|---|---|
| Requirements distiller | session | session |
| Prompt architect (loads nuke-think when installed) | session | top |
| Breakers | 2 · worker | 3 · session |
| Break → fix cycles | cap 2 | cap 3 |
| Cost stance | lean: one architect, small breaker wave | costs do not matter |
Mandates
- Clarifying questions are protocol. Target model/platform, input variety, output consumer (human or parser), and failure cost shape everything — genuinely ambiguous → up to 5 targeted questions BEFORE the plan gate. Never invent a requirement.
- Every requirement is testable. "Sound professional" is a wish; "never uses first person" is a requirement. Untestable asks are rewritten with the user or moved to non-goals.
- The breaker wave is never skipped. An unbroken prompt is unproven; light may shrink the wave, never to zero.
- Writes only under
.nuke/plus the destination file the user names. Nogit add/git commit/git stash. - Structure serves the model named in preflight. Current prompting guidance for that model family is looked up (docs tool / web search) at Phase 2, not recalled from training.
Artifacts
run_dir = .nuke/<YYYY-MM-DD>-<HHmmss>-prompt-<slug>/ — fresh per run; on collision append -2, -3, ….
| File | Role |
|---|---|
plan.md |
Goal, clarification answers, target model, requirement list, wave, tiers |
prompt.md |
The compiled prompt (also written to the user-named destination) |
breaks.md |
Breaker findings with verbatim transcripts, fixes, cycles |
Pipeline
Phase 0 preflight (clarify → plan → apply) → Phase 1 requirements → Phase 2 draft → Phase 3 breaker wave ⇄ fix (cap 2/3) → Phase 4 hand-off (STOP)
Phase 0 — Preflight
Read references/preflight.md and follow its plan-then-apply gate. Prompt specifics: resolve the goal (inline text or existing file — an existing prompt is also read for what it silently promises); identify the target model/platform and where the prompt will live; clarify per Mandate 1; print the plan block and apply it (gate only with --ask).
Phase 1 — Requirements (session)
Distill into numbered PR-## requirements, each testable (Mandate 2): task success criteria, output contract (format, length, schema), refusal policy, tone constraints, injection posture (what user content must never override). Plus non-goals — what the prompt deliberately does not handle. Existing-prompt hardening: requirements are extracted from the current prompt AND the reported misbehavior; the misbehavior becomes an explicit requirement.
Phase 2 — Draft (architect)
The architect (loads nuke-think when installed; consults local prompt-engineering skills when present, and current guidance for the target model per Mandate 5) writes the prompt: role and context first, constraints stated positively where possible, output contract explicit, few-shots only where a requirement needs demonstration — each few-shot cites the PR-## it serves. Every PR-## maps to a prompt element; the mapping is recorded in prompt.md as a comment block or companion table.
Phase 3 — Breaker wave ⇄ fix
Breakers with assigned stances — injection (user content that tries to override the system) / conflict (instructions that contradict each other or the prompt's own rules) / edge-input (malformed, empty, wrong-language, oversized) — each attacks the draft against the target model where callable, else by adversarial reading, and reports findings in the family schema (requirement violated, the attacking input verbatim, the failing output verbatim or the predicted failure with its reasoning trace, proposed fix, refutation attempt). Architect fixes; breakers re-attack what changed. Cap per mode; cap hit → open findings reported honestly.
No model access → breakers work by adversarial reading only and every finding is marked predicted (not executed); the hand-off says so.
Phase 4 — Hand-off (STOP)
Write the final prompt to its destination. Report: requirement count and mapping, breaker findings fixed vs open, cycles used, artifact paths, calibration line appended to .nuke/calibration.log (format in references/preflight.md). Close with the chain line: "Run nuke-eval with target <destination> to build the eval set that keeps this prompt honest — breaker findings in breaks.md are ready-made adversarial cases." Never start building the eval set here.