# Nuke Prompt

> Use when a prompt must be engineered, not improvised — "nuke prompt", "write a system prompt for…", "harden this prompt", "my agent ignores its instructions" — compiling a rough prompt idea or a misbehaving existing prompt into a production one, proven by a breaker wave before hand-off.

- Skill: `b4r7x/nuke-prompt` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add b4r7x/nuke-prompt`
- Raw SKILL.md: https://api.skillmd.com/api/skills/b4r7x/nuke-prompt/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: b4r7x (https://skillmd.com/u/b4r7x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/b4r7x/nuke-prompt

---


# 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

1. **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.
2. **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.
3. **The breaker wave is never skipped.** An unbroken prompt is unproven; light may shrink the wave, never to zero.
4. **Writes only under `.nuke/`** plus the destination file the user names. No `git add` / `git commit` / `git stash`.
5. **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.