Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/flyfission/nuclear-grade-context-engineering/ng-questiongit clone --depth 1 https://github.com/FlyFission/nuclear-grade-context-engineeringWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00806 |
| Opus 5 | $0.00000 | $0.00403 |
| Sonnet 5 | $0.00000 | $0.00161 |
| Haiku 4.5 | $0.00000 | $0.00081 |
Grade A, and why
ng-question scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ng-question
Portable command prompt generated from skills/questioning-attitude/SKILL.md. Edit the skill, then run python tools/ng.py gen-commands; do not edit this file by hand.
Challenges the assumptions behind a change before an agent builds, merges, or releases, and names the one fact that would change the decision. Use when a request, plan, diff, dependency, agent action, public claim, or release is vague, high-stakes, or easy to talk yourself into. Do not use for a tiny, obvious, easy-to-undo edit, or when someone wants a formal guarantee.
Use when
- A request is vague, high-stakes, or easy to talk yourself into.
- A diff, plan, dependency, prompt, model, tool, or release claim needs a skeptical second look.
- A reviewer asks "what are we assuming?" or "what would make this wrong?"
- An agent is about to get power over files, commands, the network, credentials, approvals, or releases.
- You see the warning signs of mistakes: too many files, stale memory, hidden links between parts, a messy workspace, grabbing the first answer, or pressure to be done.
Do not use when
- The task is a tiny edit with obvious proof and no new trust boundary.
- An incident is live and you must contain it before you analyze it.
- Someone is asking for a formal guarantee, a certification, a safety analysis, or regulatory approval.
Inputs
- The request, issue, pull request, diff, or path to the change record.
- The files, dependencies, prompts, models, tools, data, and release items the change touches.
- What you already know, what you are assuming, the evidence you have, and the gaps.
- Any related past records, lessons from operation, or source notes.
Prompt text
Question this change the Nuclear-grade way.
Inputs:
- request/diff/change record:
- affected items:
- known assumptions:
- evidence available:
- limits or deadlines:
Return:
- the decision question in one sentence
- the work type(s), all that apply (a production defect is brownfield and defect-fix), and the questions each forces
- the archetype (Prototyper, Builder, Sweeper, Grower, Maintainer), the drift that posture is prone to, and the mode floor it implies
- the evidence that would change the decision
- the assumptions that must be true
- known facts, unknowns, danger words, and worries about how good the sources are
- facts to check before work continues
- warning signs, signs an agent is about to slip, steps where mistakes are likely, and hidden reasons to treat this as a Standard change
- evidence needed before you execute, verify, review, decide, or save the approved version (the baseline)
- conditions that should make you pause or ask for help
- the next thing to produce: Quick proof, Standard spec, context pack, handoff, self-check, a record of what stays under control (the controlled items), or a release decision
Trust facts over confidence. Do not imply formal verification and validation, compliance, certification, safety, security, or regulatory adequacy.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 66 lines · 0 tokens per session scan A 979c2e56eb53
ng-question is a command published in the GitHub repository FlyFission/nuclear-grade-context-engineering (33 stars, last pushed 24d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 806 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
coder-eval-implement-plan
Implement an approved codereval plan phase by phase with risk-scaled per-phase review, then a final code review.
capture-feedback
Quick feedback capture with structured signals.
auto-run
PitWay: Manage auto-run authorization for automatic task continuation.
task-integrate
PitWay: Apply a dispatched task's worktree commit to the main tree.
milestone-list
PitWay: List every milestone with a concise one-line status.
fix
Universal debugging and fix application with semantic code analysis.