Agent Guidance

AI agents working in this repo should treat Nuclear-grade as a way to gather evidence, not a brand to show off. The idea is simple. Keep a questioning attitude. Use small habits from Human Performance Improvement (HPI). And keep the approved version under control for AI-assisted software work. In practice that means: question assumptions, write down what the change must do, brief the work, double-check risky actions, and hand off cleanly. Keep the controlled files, the evidence, the decisions, the version everyone agreed is correct, and the release stance all linked together.

Default behavior

• Start with this file and the right change record. Follow links into README.md or WORKFLOWS.md only when the task needs them; do not preload either wholesale.
• Treat instruction conflicts as blockers, not judgment calls: name the conflicting sources, apply the host's documented precedence, and stop before the affected action if precedence does not resolve them.
• Use the lightest mode that is still honest. For a purely administrative, instantly reversible change that crosses no trust boundary, the lightest honest mode is the administrative floor: no packet, the commit message is the record. Any trust boundary, dependency, public claim, or hard-to-reverse step makes it at least a Quick packet.
• Tie every claim to evidence.
• Name the controlled items when you change prompts, models, tools, dependencies, docs, skills, commands, templates, checkers, or releases.
• Hand off the work when you delegate it, pick it back up, or pass it to a reviewer, checker, or releaser with work still open.
• Double-check yourself before risky edits, risky commands, public claims, a trust change to a dependency, model, or API, or a release action.
• Use lessons from real operation (OPEX) when a near miss, a bad handoff, a review surprise, or an operating signal should update a lasting control.
• Declare your intent and reasoning before a critical action, so a reviewer can challenge the thinking, not just the result.
• Match authority to the evidence: decide reversible, well-evidenced work at the edge; escalate anything irreversible, trust-bearing, or thinly evidenced to a person.
• Halt unsafe or unclear work and surface the concern; raise known deficiencies so they are owned, not normalized.
• Hand off so the next owner is more capable, not more dependent.
• Prefer links and short status labels over long, repeated text.
• Run the right tests and checker commands before you say the work is done.

Verification routing

Do not invent a new proof path for routine edits. Use the pre-PR commands in CONTRIBUTING.md, then narrow only when the change is clearly smaller than a full run:

• docs-only wording: git diff --check plus the nearest public-doc or token test;
• template, skill, command, or checker behavior: the targeted pytest file plus python tools/ng.py doctor .;
• worked-example evidence: re-run the example validator or example test named in the change record.

If you skip a full pre-PR run, say why the narrower proof still covers the files you changed.

Authority boundaries

Agents must not assume they may:

• change the release stance without a ship-readiness record;
• make bigger claims about where the ideas come from;
• add compliance or assurance claims;
• edit security-sensitive, credential, network, or production-facing material without clear permission;
• invoke "authority to information" to skip a required human gate on an irreversible or trust-bearing action;
• treat their own confidence or a fluent intent statement as evidence, or rubber-stamp another agent's output as an independent check;
• overwrite change records or templates without saying so.

Skill loading rule

Load skills by trigger, not by inventory. First screen the work for risk, evidence, decision-rights, public-claim, trust-boundary, handoff, release, incident, or hard-to-reverse triggers. Then load the smallest skill set that can change the action, evidence, gate, decision right, claim wording, or handoff. Use the decision matrix in CORE.md to route the trigger; treat SKILLS.md as a discovery catalog, not a preload list. If a trigger is present or ambiguous, load the matching skill or state the specific evidence showing why it is not needed. Confidence is not evidence.

Completion standard

Every completion report names:

• the files it changed;
• the change record or reasoning it used;
• the evidence it ran;
• the gaps still open.

Add triggered details only when they apply: handoff, self-check, OPEX, or trust records when used or required; intent and decision rights for critical actions; and boundary wording for public claims. Do not pad routine completions with not applicable declarations.

Boundary note

Agent work in this repo does not create formal verification and validation, compliance, certification, safety, security, regulatory adequacy, or legal advice. None of those.