- Ask the user if you need to load a MOOSE conda environment, and if so, what the name of the conda environment is
- If
./tmap8-optorrun_teststhrows an error, stop and ask the user - Pre-commit hooks handle all formatting and input file validation on every
git commit— do not invokeclang-format,black, orhit formatmanually moose/framework/contrib/hit/hit check <file>.iis available to validate input files during development — use it before committing
- Browse
doc/content/to understand documentation standards and existing patterns before starting work - Before writing a new C++ class, look through existing MOOSE classes in the codebase to confirm expected syntax and patterns
- Documentation in
doc/content/may not accurately reflect current code behavior — once you identify a class to use in an input file, find its C++ implementation and read it to confirm the class does what you expect before writing the input file
- Every new class requires a MOOSE TestHarness test in
test/tests/before committing - Every new class requires a MooseDocs page following existing TMAP8 doc structure
- Never hardcode physical parameters — first check if it is already defined in
doc/content/source/utils/TMAP8PhysicalConstants, and if not available, expose everything throughaddParam - Code is unit-agnostic; units live in input files only
- Before writing an input file, look through existing MOOSE and TMAP8 classes to confirm object names and parameter syntax
- Use
moose/framework/contrib/hit/hit check <file>.ito validate before committing - Use
./tmap8-opt -i <file>.ito run input files - Write parameter values in the units the reference source used; use the MOOSE units system for conversion — the units system is self-documenting and does not require inline comments
- State the unit system at the top of every input file in a comment block
- Run tests only when
.C,.h, ortest/tests/files change - Run only the affected module:
./run_tests -j<N> --re <module>
- Every session must be associated with a GitHub issue on
idaholab/TMAP8; ask the user for the issue number at the start of the session if one is not provided, or create one if the user instructs you to - SQA requirement: When creating a GitHub issue with
gh, you must use the appropriate template from.github/ISSUE_TEMPLATE/; read the available templates first, select the one that fits (e.g.bug-report.mdfor bugs,feature-request.mdfor new features or tasks), and populate all sections in the template body — passing a bare description without following the template structure is not acceptable - Before committing, copy the current session's
.jsonlfile intodoc/content/agent/<issue-number>/. For Claude Code sessions the file is the most recently modified.jsonlunder~/.claude/projects/<repo-slug>/; for Codex sessions check the equivalent Codex session directory. Do not remove old session files already in that directory — append the new one alongside them.
- Commit at minimum after: every input file that successfully runs, every test that passes or fails, and every new class added
- If a test or run failed, commit the failure state first (include the full error message in the commit body), then commit the fix separately
- Every commit must reference the associated GitHub issue (e.g.
Refs #<issue-number>orCloses #<issue-number>as appropriate) in the commit message - Every commit must include an updated copy of the session
.jsonl— before staging, copy the current session file from~/.claude/projects/<repo-slug>/<session-id>.jsonltodoc/content/agent/<issue-number>/and stage it; this is a critical SQA requirement. Do not remove session files already present in that directory — if multiple Claude/Codex sessions contribute to the same branch and issue, all session files must be kept. - Every commit must include these trailers:
Refs #<issue-number>
AI-assisted: true
AI-model: <model name>
AI-version: <model version>
Co-Authored-By: <model name> <noreply@anthropic.com>
- If the linked issue already contains a complete Reason/Design/Impact description, the PR body should contain only the closing reference (e.g.
Closes #<issue-number>) — do not duplicate the issue content or leave template sections empty - If the PR introduces physics/modeling decisions, non-obvious AI reasoning, or tests not described in the issue, add those as a short addendum below the issue reference
- Never merge autonomously
- Modify existing passing tests without explicit user instruction
- Modify the build system without explicit user instruction
- Make physics modeling decisions without flagging them to the user
- Suppress or bypass test failures