← all publishers

idaholab

@idaholab source repo

Report this profile Claim this profile

• 10 skills
• 0 followers
• 8 hours ago last updated

1. ▌
   Code Review · idaholab

   <!--
   0
   installs
2. ▌
   Chunked File Writer · idaholab

   Write source files incrementally in small chunks instead of one large Write. Use whenever creating or generating any file longer than ~80 lines (scripts, modules, reports, configs), or when the user asks to "write the script/file/module". Prevents API stream timeouts on this network by keeping every single tool call small.
   0
   installs
3. ▌
   Resolving Merge Conflicts · idaholab

   <!--
   0
   installs
4. ▌
   Codegraph · idaholab

   Use CodeGraph to navigate MOOSE and avoid reinventing functionality it already has (MOOSE's "use existing functionality, don't reimplement it" rule - AGENTS.md, Simplicity First). Use this whenever writing or changing MOOSE C++/Python - before adding a new function, class, material, kernel, action, or utility - to check whether MOOSE, libMesh, MetaPhysicL, or MathUtils already provides it; to find the call sites and blast radius of a change; or to compare a new object against an existing sibling. CodeGraph is preferred but optional here: if the index is absent, fall back to grep/Read and suggest setting it up rather than blocking.
   0
   installs
5. ▌
   Pr Create · idaholab bundle

   Audit a prepared MOOSE branch for applicable AGENTS.md instructions, MOOSE contribution standards, tests, documentation, and PR readiness; draft and, only after explicit approval, push the branch and open a draft GitHub pull request against next. Use when someone asks to create, open, prepare, or submit a MOOSE PR. Do not use this to review someone else's PR or to address feedback on an existing PR.
   0
   installs
6. ▌
   Pr Review · idaholab bundle

   Review a MOOSE pull request or local branch against MOOSE's contribution standards: applicable AGENTS.md guidance, the MOOSE Code Standard (SCS), the SQA testing rules (every test is a requirement, with requirement/design/issues), required documentation stub pages for new objects, and PR governance (issue references, scope, required-vs-suggested phrasing). Use this whenever someone wants to review MOOSE changes or asks "review this PR", "review my branch", "is this ready to merge", "check my changes before I submit", or wants pre-submission feedback on code in the MOOSE framework or its modules - even if they never say the word "review". This is the MOOSE-aware review layer; it complements the generic /code-review and /security-review skills and defers to them for deep correctness and security analysis rather than duplicating that work.
   0
   installs
7. ▌
   Run Tests · idaholab

   Use when running or debugging MOOSE regression tests (run_tests / TestHarness) in the MOOSE framework itself or any MOOSE-based application (e.g. bison and other downstream apps). Covers locating run_tests, scoping to a subset of tests, and interpreting failures.
   0
   installs
8. ▌
   Verify Changes · idaholab bundle

   Select and run focused builds, tests, and executable checks for MOOSE changes, with a mandatory environment gate, protection against stale binaries, and evidence-based results. Use when someone asks to build, test, or verify MOOSE work; before claiming that changed MOOSE behavior works; or when another MOOSE workflow needs verification for a pull request, review response, bug fix, or feature.
   0
   installs
9. ▌
   Pr Address Review · idaholab bundle

   Address feedback on an existing MOOSE pull request by retrieving review threads and summary comments, classifying each item, applying accepted changes under MOOSE and AGENTS.md guidance, running verification, and drafting evidence-based replies. Use when someone asks to address PR comments, respond to a review, implement review feedback, or prepare a PR revision. Never resolve a non-trivial conversation; leave it to the reviewer.
   0
   installs
10. ▌
    Brittle Numerics Root Cause · idaholab

    Use when a numerical calculation or test gives different results under compiler flags, optimization level, hardware, thread count, or execution order. Treat this as a symptom that some part of the algorithm is ill-conditioned (near-singular solve, an algebraically-truncated slowly-converging series, large cancelling terms) — not as flaky-test noise to suppress by pinning flags, loosening tolerances, or blindly regolding. Walks through instrumenting for real per-iteration data, finding the actual non-robust mechanism, validating a targeted fix against that data, and anticipating the blast radius on other tests before regolding.
    0
    installs