llnl
- 33 skills
- 0 followers
- 11 hours ago last updated
- ▌ Kosh · llnl bundleUse Kosh to persist results and files, query them later, and build custom loaders, transformers, and operators for data extraction and slice-aware processing.
- ▌ Nde Report Generator · llnl bundleExtracts features from volumetric, mask, and skeleton .npy files and generates a visual report with specific 3D perspectives.
- ▌
- ▌ Axom Cpp Style · llnlC++ coding style and naming conventions for Axom (primarily src/axom), including formatting via the CMake `style` target.
- ▌
- ▌ Boba Debugging · llnlDebug BoBa code with `checkpoint()`, `always_checkpoint()`, `boba_print(...)`, and debug builds such as `make <target> BOBA_DEBUG=1`. Use when narrowing where a failure occurs, adding temporary runtime breadcrumbs, or printing variable state while a test or example runs.
- ▌ Boba Cali Macros · llnlPlace, move, or review `BOBA_CALI_MARK`, `BOBA_CALI_BEGIN`, `BOBA_CALI_SWITCH`, and `BOBA_CALI_END` in BoBa code. Use when refactoring backend wrappers, splitting algorithms across helper layers, or fixing profiling ownership so CALI scopes match the code that actually owns each phase.
- ▌ Boba Caliper Build Run · llnlCompile and run BoBa with Caliper enabled, capture `CALI_CONFIG=runtime-report` output, and interpret which rows correspond to BoBa profiling regions. Use when profiling a test, tutorial, or miniapp, or when deciding between `BOBA_ENABLE_CALIPER`, `BOBA_ENABLE_CALIPER_EXTERNAL`, and `BOBA_ENABLE_CALIPER_OBJECTS`.
- ▌ Smith Cpp Style · llnlC++ coding style and naming conventions for Smith (primarily src/smith), including formatting via the CMake `style` target.
- ▌ Flux · llnl bundleCommands for running and monitoring jobs on a Flux (flux-framework) HPC scheduler: submitting jobs, checking whether a job is running, reading job output and exit codes, and cancelling jobs. Use this whenever a task involves submitting, monitoring, inspecting, or cancelling work on a Flux cluster, or running builds / test suites / model serving on compute nodes rather than the login node. Trigger it on any mention of `flux submit`, `flux run`, `flux jobs`, `flux batch`, Flux job IDs, or "is my job running / done" on an HPC system where Flux is the main scheduler.
- ▌ Ams Build · llnl bundleBuild and install the AMS library (github.com/LLNL/AMS) from source on an HPC cluster via CMake. Use this whenever the user wants to compile, configure, build, or install AMS, or is choosing between build variants (with/without RabbitMQ, GPU, MPI, Caliper, etc.). ALWAYS use this skill for AMS build/CMake questions even when phrased loosely ("get AMS running on Tioga", "why can't CMake find Torch", "AMS build with RabbitMQ"). It knows how to gather AMS's dependencies two ways: via LLNL Livermore Computing's internal Spack environment or by pointing CMake at manually provided libraries.
- ▌ Changelog · llnl bundleMaintain a CHANGELOG.md in Keep a Changelog format: record new features, changes, and fixes under an Unreleased section, and cut releases. Use whenever a user-facing change ships or the user says "update the changelog", "add a changelog entry", "record this feature/fix", "cut a release", "what changed since <ref>", or mentions release notes or a CHANGELOG. Works for versioned and unversioned projects — fall back to dates plus merge-request or commit IDs when there are no version numbers. Trigger on any notable change worth recording, even without the word "changelog".
- ▌ Codebase Map · llnl bundleBuild and maintain a living architecture wiki for a codebase: one markdown article per module/subsystem plus an index that maps how they fit together. Use whenever the user wants to document, map, or reason about the code's architecture — "map the codebase", "update the architecture wiki", "what does module X do", "how does X connect to Y", "reconstruct the architecture", or onboarding to an unfamiliar repo. Trigger on any mention of an "architecture map", "code wiki", "module map", or keeping architecture docs in sync with the code, even without those exact words.
- ▌ Dmx Local Modeling · llnl bundleImplementation-oriented local `dmx-learn` fitting skill for coding, fitting, diagnosing, and using models on local or in-memory data once the problem structure is known. Prefer explicit `dmx.stats` estimators for ordinary non-Bayesian work and use `dmx.bstats` for Bayesian, variational, DPM, and automatic mixture workflows. Do not use for Spark, MPI, or other distributed estimation workflows.
- ▌ Dmx Test And Quality · llnlUse when adding or updating tests, or when validating dmx-learn changes against the repo's CI quality gates. Covers pytest layout, the shared stats test harness, torch test constraints, and the exact Black, isort, mypy, pylint, and pydocstyle checks used in GitHub Actions.
- ▌ Dmx Expert Orchestrator · llnl bundleMain entry point for local `dmx-learn` modeling requests. Use to scope the problem, infer the observation structure, keep the workflow on local data, and route detailed implementation to narrower repo-local skills or references. Default to explicit `dmx.stats` construction for ordinary non-Bayesian work and route Bayesian, variational, DPM, and automatic mixture work to `dmx.bstats`. Do not use for Spark, MPI, or other distributed estimation workflows.
- ▌
- ▌
- ▌ Build The Tool · llnlGuide for building the tool when asked by the user or testing a code change that requires a new build of the tool
- ▌ HTML Reports Description · llnlGuide for understanding the structure and content of HTML reports generated by the tool
- ▌ Tool Description Error Tracking · llnlGuide for understanding the tool's functionality and usage in error tracking
- ▌ Sundials New Module · llnlAdd a new SUNDIALS module (e.g., NVECTOR_*, SUNMATRIX_*, SUNLINSOL_*, SUNNONLINSOL_*, SUNMEMORY_*, or a new shared component) including source/header layout, CMake wiring, enable/disable options, exported CMake targets, installed component registration, and developer tests/examples/docs updates.
- ▌ Sundials Devs Python Callbacks · llnlGenerate nanobind C++ wrapper code for user-supplied callback functions in the sundials4py Python bindings. Use this skill whenever adding a new user-supplied function (callback) to any sundials4py submodule (arkode, cvodes, idas, kinsol, core/sundials), wrapping a C function-pointer-based API for Python, adding a `python` member to a SUNDIALS C struct that does not yet have one, or when a function cannot be autogenerated by litgen because it takes a function pointer argument. Also trigger when the user mentions "callback wrapper", "user_supplied_fn_caller", "BIND_ARKODE_CALLBACK", "BIND_CVODE_CALLBACK", "BIND_IDA_CALLBACK", "BIND_KINSOL_CALLBACK", or references any *_usersupplied.hpp or *_impl.h file in the context of Python bindings. If the user says something like "wrap this Set callback for Python", "add a new user function to cvodes", or "this object needs a python member for callbacks", this is the skill to use.
- ▌ Sundials Devs Address Pr Comments · llnlFetch and apply GitHub pull-request review comments locally, especially when the task includes reconciling new review traffic, following reply chains from specific reviewers/authors, and keeping a scratch notes file that maps comment IDs to fixes.
- ▌ Lctio Dev · llnlUse when working on LCTIO development setup, editable installs, linting, formatting, type checking, or packaging.
- ▌ Lctio Docs · llnlUse when updating Sphinx documentation, changing docs/source/conf.py, adding Sphinx extensions, or validating documentation builds for this repository.
- ▌ Lctio Retiff · llnlUse when modifying or debugging lctio.retiff, TIFF rewrite behavior, or the retiff CLI.
- ▌ Lctio Contrib · llnlUse when preparing commits, reviewing git history for conventions, or writing pull request summaries for this repository.
- ▌ Lctio Testing · llnl bundleUse when writing or updating pytest coverage for TIFF handling, CLI behavior, or other tests in this repository.
- ▌ Code Review · llnl bundleReview SUNDIALS pull requests using the repository’s correctness, numerical, API, documentation, testing, portability, and maintainability review patterns. Use for GitHub PR reviews or when asked to review changed SUNDIALS source, bindings, build files, examples, or documentation.
- ▌ Sundials Build · llnlBuild, install, and test SUNDIALS from source as an end user or as a SUNDIALS developer. Use when a request involves configuring CMake, selecting compilers/options (MPI, GPU backends, Fortran), building/installing, running CTest, enabling dev/unit tests, or troubleshooting common build/test issues.
- ▌ Sundials Guide · llnl bundleGuide SUNDIALS users to the right package, time-stepping module, nonlinear/linear solver strategy, and initial tuning choices. Use when a request asks which SUNDIALS package to use (CVODE, CVODES, IDA, IDAS, ARKODE, KINSOL), whether to choose explicit vs implicit vs IMEX or multirate methods, how to pick dense/band/sparse/Krylov solvers and preconditioners, or what tolerances, step limits, initial-condition handling, and other starting settings to try.
- ▌ Sundials Devs Update Answer Files · llnlUpdate or add SUNDIALS expected-output answer files after intentional test output changes. Use to refresh .out files embedded in examples, update the sundials-codes/answers repository or test/answers submodule, consume GitHub Actions or Jenkins output_files artifacts, configure SUNDIALS_TEST_ANSWER_DIR or SUNDIALS_TEST_OUTPUT_DIR, or follow the documented workflow in doc/developers/testing/Answers.rst.