nuclear-grade

Plugin nuclear-grade from marketplace nuclear-grade in FlyFission/nuclear-grade-context-engineering. Commands read from the repo's manifest — 4 days ago.

Skills (31)

• breaking-down-the-work

  Splits scope into a product-first work breakdown that follows the 100% rule, keeps pieces from overlapping, uses outline numbers, and gives every piece a dictionary entry. Use when an epic, feature, or new subsystem needs a clean split into deliverables, or one source of truth before folders or work

• briefing-an-agent

  Prepares focused context for an AI agent, reviewer, verifier, or releaser at the start of a task, with a clear role, goal anchor, authority, evidence to produce, forbidden actions, and stop conditions. Use when an agent or reviewer is about to begin work and needs bounded context before it starts. D

• checking-facts

  Checks factual assertions (numbers, quotes, dates, versions, API or tool behavior, what a source actually says) against primary sources read this pass, confirming each load-bearing fact by a second independent means. Use before a packet, doc, review, or release note relies on a fact. Do not use for

• checking-legal-and-safety-wording

  Reviews public text for license, warranty, compliance, safety, security, certification, and fitness claims that go too far, then rewrites them to stay inside the real limits. Use when shipping or editing public docs, READMEs, or rollout copy. Do not use for internal code comments, or for deciding ac

• checking-release-readiness

  Records a ship, block, defer, or ship-with-risk decision that ties baseline, evidence status, residual risk, rollback, monitoring, and handoff together. Use when a packet, PR, release, dependency change, or agent-authority change approaches merge. Do not use early in development before evidence exis

• checking-source-claims

  Checks that the way you cite source families, agencies, standards, or borrowed ideas is honest and does not claim too much. Use when public docs, templates, skills, change records, or rollout copy point to outside sources. Do not use for private notes, or for checking whether code actually works.

• checking-what-a-change-affects

  Screens what a controlled change might leave out of date across docs, tests, skills, commands, templates, checkers, prompts, releases, saved versions, and evidence, and names the triggers to re-check. Use when a change touches a controlled item. Do not use for a single edit that nothing else depends

• choosing-what-to-control

  Decides which code, prompts, models, tools, dependencies, docs, tests, evals, releases, or claims need their approved state tracked. Use when scoping what a change puts at risk or what must stay reviewable. Do not use for scratch work that nothing else depends on.

• closing-stale-packets

  Brings an abandoned or half-filled change packet to an honest terminal state by completing it, closing it with a recorded rationale, or deleting it. Use when ng status flags a scaffold or invalid packet, a long session left a draft behind, or work was abandoned mid-packet. Do not use for an actively

• creating-change-records

  Creates or updates Quick or Standard change records, adds the required files, and refreshes what each claim must prove for an evidence-backed pull request. Use when starting or revising a change record. Do not use for a one-off throwaway script, or for work that belongs in an existing record rather

• deciding-who-decides

  Decides who holds authority for a change — the agent at the edge or a human gate — by matching decision rights to reversibility, evidence, and consequence, and names the escalation trigger. Use when an agent could act on something irreversible, trust-bearing, or thinly evidenced. Do not use for triv

• declaring-intent

  States what an agent intends to do and why before a critical or irreversible action, so a reviewer can challenge the thinking and not just the result. Use before deploys, migrations, public claims, or trust changes that deserve a stated intent, expected result, abort criteria, and backup. Do not use

• double-checking-before-acting

  Checks a critical agent action against its exact target, expected result, and stop condition before and after execution. Use when an agent is about to make a critical edit, run a command or migration, use a credential or tool, change a dependency or model, make a public claim, or affect a release. D

• handing-off-work

  Hands off unfinished work with a closed-loop briefing of state, changed conditions, remaining scope, authority limits, and open evidence. Use when AI-agent, reviewer, verifier, releaser, or resumed-thread work transfers to a new owner. Do not use when the same owner continues uninterrupted with full

• learning-from-experience

  Turns incidents, near misses, bad handoffs, review surprises, escaped bugs, and signals from real use into lasting fixes to your safeguards. Use after something went wrong or nearly did and a future safeguard should change. Do not use during a live incident, which comes first, or to blame someone.

• organizing-project-folders

  Designs a clean folder and file layout as real architecture, building it from a work breakdown or an existing tree, grouping by what changes together and what happens to it, with platform-safe sortable names and a short note per folder. Use when laying out a repo or agent workspace, deciding where a

• proving-claims

  Builds claim-to-evidence trace rows with statuses, gaps, tests, evals, reviews, and narrower non-claims. Use when a packet asserts something a reviewer must trust. Do not use to make the final ship decision, judge public legal wording, or invent evidence that does not exist.

• questioning-attitude

  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 tin

• rating-change-risk

  Picks Quick, Standard, or a stronger human-reviewed mode based on consequence, how easy it is to undo, and how much is unknown. Use when you start a change to code, docs, dependencies, AI power, releases, or public claims and the right level of care is unclear. Do not use for a tiny easy-to-undo edi

• recording-a-known-good-version

  Records the version everyone agreed is correct, the evidence behind it, and what would make that record out of date. Use when a standard change ships, when prompts, models, tools, dependencies, docs, or release items are accepted, or when a lesson forces a re-record. Do not use for a tiny local edit

• recording-what-an-agent-did

  Captures an agent run's tool calls, decision points, inputs, outputs, token use, and approval steps as a clear, repeatable record linked into the packet trace and verification record. Use when how the agent got there matters for debugging, auditing, cost review, or defending a release decision. Do n

• reporting-shared-defects

  Routes a defect found in a shared or supplied artifact (a shared prompt, skill, dependency, model, eval, or template) to the downstream teams, agents, and releases that depend on it, not just a local fix. Use when a discovered defect affects others who consume the same artifact. Do not use for a def

• responding-to-incidents

  Runs a live incident the stabilize-first way — name a commander, separate facts from hypotheses, prefer reversible actions, communicate on a cadence, and drive corrective actions to closure. Use when production is broken, data is at risk, or an agent action caused harm. Do not use for routine non-in

• reviewing-code-quality

  Reviews a diff or module for slipping standards, favoring deletion over rearranging, and ends in one honest verdict. Use when a change risks oversized files, needless layers, feature logic leaking into shared code, or clever indirection. Do not use for a trivial obvious edit, or for a check that is

• running-a-review-panel

  Convenes several reviewers on one frozen evidence packet, names the diversity axis each seat actually varies, preserves dissent, and verifies every finding against live source before it counts as actionable. Use when a trust-bearing or irreversible verdict currently rests on a single reviewer, or on

• staying-on-mission

  Tests the current work against a written, lasting mission anchor and forces one choice, re-anchor, escalate, or stop. Use when an agent keeps finishing tasks but the work drifts from the goal, scope creeps, the same action repeats in a loop, or standards slip one small step at a time. Do not use for

• stress-testing-agent-changes

  Attacks your own agent change, tool grant, dependency, model, or release on purpose, across risk types such as prompt injection, gaining extra power, unsafe output, and tool misuse, and records what you tried, what happened, and the leftover risk. Use when a change widens an agent's power, data acce

• tracking-deficiencies

  Keeps a standing register of known deficiencies so flaky tests, noisy alerts, unowned services, and recurring incidents get aged, owned, and fixed or formally risk-accepted instead of quietly normalized. Use when a known problem will outlive a single change. Do not use for a one-off lesson already c

• using-nuclear-grade

  The always-first router for AI-assisted work. Perform a bounded read-only preflight, then state the mode and controlling fact before mutation or external effect; route to the matching record and proof. Use at the start of any change, repo adoption, or release call. Do not use for a throwaway experim

• verifying-final-artifacts

  Verifies the delivered artifact a consumer actually receives (a figure, chart, PDF, SVG, screenshot, compiled build, or deployed response) by regenerating it fresh and directly observing the output, not the source that produces it, and ends in one honest verdict. Use when the deliverable is a produc

• vetting-outside-code-and-models

  Checks dependencies, models, APIs, SaaS tools, generated files, and vendor claims against how you will actually use them, the proof you have, the gaps, and the release impact. Use when any of these affect evidence, permissions, data, releases, or public trust. Do not use for an internal cleanup with

Slash commands (30)

• /nuclear-grade:ng-baseline

  Records the version everyone agreed is correct, the evidence behind it, and what would make that record out of date.

• /nuclear-grade:ng-breakdown

  Splits scope into a product-first work breakdown that follows the 100% rule, keeps pieces from overlapping, uses outline numbers, and gives every piece a dictionary entry.

• /nuclear-grade:ng-classify

  Picks Quick, Standard, or a stronger human-reviewed mode based on consequence, how easy it is to undo, and how much is unknown.

• /nuclear-grade:ng-close-packet

  Brings an abandoned or half-filled change packet to an honest terminal state by completing it, closing it with a recorded rationale, or deleting it.

• /nuclear-grade:ng-code-review

  Reviews a diff or module for slipping standards, favoring deletion over rearranging, and ends in one honest verdict.

• /nuclear-grade:ng-context-pack

  Prepares focused context for an AI agent, reviewer, verifier, or releaser at the start of a task, with a clear role, goal anchor, authority, evidence to produce, forbidden actions, and stop conditions.

• /nuclear-grade:ng-decide-authority

  Decides who holds authority for a change \u2014 the agent at the edge or a human gate \u2014 by matching decision rights to reversibility, evidence, and consequence, and names the escalation trigger.

• /nuclear-grade:ng-deficiency

  Keeps a standing register of known deficiencies so flaky tests, noisy alerts, unowned services, and recurring incidents get aged, owned, and fixed or formally risk-accepted instead of quietly normalized.

• /nuclear-grade:ng-drift-check

  Tests the current work against a written, lasting mission anchor and forces one choice, re-anchor, escalate, or stop.

• /nuclear-grade:ng-fact-check

  Checks factual assertions (numbers, quotes, dates, versions, API or tool behavior, what a source actually says) against primary sources read this pass, confirming each load-bearing fact by a second independent means.

• /nuclear-grade:ng-folders

  Designs a clean folder and file layout as real architecture, building it from a work breakdown or an existing tree, grouping by what changes together and what happens to it, with platform-safe sortable names and a short note per folder.

• /nuclear-grade:ng-impact

  Screens what a controlled change might leave out of date across docs, tests, skills, commands, templates, checkers, prompts, releases, saved versions, and evidence, and names the triggers to re-check.

• /nuclear-grade:ng-incident

  Runs a live incident the stabilize-first way \u2014 name a commander, separate facts from hypotheses, prefer reversible actions, communicate on a cadence, and drive corrective actions to closure.

• /nuclear-grade:ng-intent

  States what an agent intends to do and why before a critical or irreversible action, so a reviewer can challenge the thinking and not just the result.

• /nuclear-grade:ng-learn

  Turns incidents, near misses, bad handoffs, review surprises, escaped bugs, and signals from real use into lasting fixes to your safeguards.

• /nuclear-grade:ng-legal-check

  Reviews public text for license, warranty, compliance, safety, security, certification, and fitness claims that go too far, then rewrites them to stay inside the real limits.

• /nuclear-grade:ng-new

  Creates or updates Quick or Standard change records, adds the required files, and refreshes what each claim must prove for an evidence-backed pull request.

• /nuclear-grade:ng-panel

  Convenes several reviewers on one frozen evidence packet, names the diversity axis each seat actually varies, preserves dissent, and verifies every finding against live source before it counts as actionable.

• /nuclear-grade:ng-prove

  Builds claim-to-evidence trace rows with statuses, gaps, tests, evals, reviews, and narrower non-claims.

• /nuclear-grade:ng-question

  Challenges the assumptions behind a change before an agent builds, merges, or releases, and names the one fact that would change the decision.

• /nuclear-grade:ng-red-team

  Attacks your own agent change, tool grant, dependency, model, or release on purpose, across risk types such as prompt injection, gaining extra power, unsafe output, and tool misuse, and records what you tried, what happened, and the leftover risk.

• /nuclear-grade:ng-report-defect

  Routes a defect found in a shared or supplied artifact (a shared prompt, skill, dependency, model, eval, or template) to the downstream teams, agents, and releases that depend on it, not just a local fix.

• /nuclear-grade:ng-self-check

  Checks a critical agent action against its exact target, expected result, and stop condition before and after execution.

• /nuclear-grade:ng-ship-review

  Records a ship, block, defer, or ship-with-risk decision that ties baseline, evidence status, residual risk, rollback, monitoring, and handoff together.

• /nuclear-grade:ng-source-check

  Checks that the way you cite source families, agencies, standards, or borrowed ideas is honest and does not claim too much.

• /nuclear-grade:ng-trace

  Captures an agent run's tool calls, decision points, inputs, outputs, token use, and approval steps as a clear, repeatable record linked into the packet trace and verification record.

• /nuclear-grade:ng-trust-check

  Checks dependencies, models, APIs, SaaS tools, generated files, and vendor claims against how you will actually use them, the proof you have, the gaps, and the release impact.

• /nuclear-grade:ng-turnover

  Hands off unfinished work with a closed-loop briefing of state, changed conditions, remaining scope, authority limits, and open evidence.

• /nuclear-grade:ng-verify-artifact

  Verifies the delivered artifact a consumer actually receives (a figure, chart, PDF, SVG, screenshot, compiled build, or deployed response) by regenerating it fresh and directly observing the output, not the source that produces it, and ends in one honest verdict.

• /nuclear-grade:ng-what-to-control

  Decides which code, prompts, models, tools, dependencies, docs, tests, evals, releases, or claims need their approved state tracked.

Subagents (5)

• educator

  PROVE Educate stage. Use after the verdict to lock in the approved baseline and turn operation into a lesson — record the baseline, OPEX/lessons, and any charter update into .nuclear/. Do not use to build product code, decide ship/block, or run the change.

• judge

  PROVE Verdict stage. Use to make the ship / block / defer / ship-with-named-risk decision on the presented evidence — read-only and context-separated from the runner, but still coupled through the orchestrator and possibly model/resources. Do not use to build, gather new evidence, or write code.

• observer

  PROVE Observe stage. Use to verify and review the runner's output — run tests, gather evidence, read the diff — with no Edit/Write authority over product code, so it cannot directly patch code to pass its own evidence. Do not use to build, plan, or decide ship/block.

• planner

  PROVE Plan stage. Use to turn a request into a plan ready for human acceptance — question, discover, specify, plan — writing only to the change packet, never product code. Dispatch first, before any building. Do not use to edit code, run commands, or decide ship/block.

• runner

  PROVE Run stage. Use AFTER a human explicitly authorizes execution of an accepted plan, to edit code, write files, and run commands strictly inside that plan's boundary. May fan out to parallel execution sub-agents on independent slices. Do not use to plan, to decide ship/block, or before the execut

Similar plugins