Adopt skills from NeMo Relay

.agents/skills/contribute-api/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: contribute-api
+description: Contribute a new NeMo Fabric public API surface safely, with Rust, CLI, Python, schema, adapter, and documentation parity in mind
+author: NVIDIA Corporation and Affiliates
+license: Apache-2.0
+---
+
+
+# Contribute A New API Surface
+
+## Companion Guidance
+
+Use `karpathy-guidelines` alongside this skill for implementation or review
+work. Keep changes scoped, surface assumptions, and define focused validation
+before editing.
+
+Use this skill when contributing a public API addition or behavior change to the
+runtime or bindings.
+
+## Default Guidance
+
+- Start from the shared Rust core behavior first
+- Decide whether the CLI, PyO3 binding, Python SDK, type stubs, schemas, or
+  adapter contract must expose the new surface
+- Keep every affected public surface in parity
+- Update docs and examples in the same branch
+
+## Minimum Acceptance
+
+- Public behavior is clearly described
+- Every affected public surface is covered
+- The validation matrix matches the changed surfaces
+- PR notes explain the user-facing change
+
+## References
+
+- `validate-change`
+- `review-doc-style`
+- `docs/python-sdk-contract.md`
+- `justfile`

.agents/skills/contribute-docs/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: contribute-docs
+description: Contribute documentation or example changes that stay aligned with NeMo Fabric public behavior
+author: NVIDIA Corporation and Affiliates
+license: Apache-2.0
+---
+
+
+# Contribute Docs Or Examples
+
+## Companion Guidance
+
+Use `karpathy-guidelines` alongside this skill for implementation or review
+work. Keep changes scoped, surface assumptions, and define focused validation
+before editing.
+
+Use this skill for docs-only or example-heavy changes.
+
+## Rules
+
+- Prefer the documented public API, not internal shortcuts
+- Keep package names, repo references, and build commands current
+- Update entry-point docs when examples or reading paths change
+- In MDX files, top-of-file comments must use JSX comment delimiters:
+  `{/*` to open and `*/}` to close. Do not use HTML comments for MDX SPDX
+  headers.
+
+## Checklist
+
+- [ ] `README.md` or `docs/index.yml` updated when entry points changed
+- [ ] Relevant getting-started or reference docs updated
+- [ ] Example commands still match current package names and paths
+- [ ] Relevant adapter or example `README.md` files updated when examples
+      or adapters have changed.
+- [ ] New or regenerated MDX files use `{/* ... */}` for top-of-file SPDX comments
+- [ ] Run `just docs` when the docs site changed
+
+## References
+
+- `README.md`
+- `docs/index.yml`
+- `review-doc-style`

.agents/skills/karpathy-guidelines/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: karpathy-guidelines
+description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
+author: https://github.com/forrestchang/andrej-karpathy-skills ; NVIDIA Corporation and Affiliates
+license: MIT, Apache-2.0
+---
+
+# Karpathy Guidelines
+
+Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

.agents/skills/maintain-ci/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: maintain-ci
+description: Maintain and review NeMo Fabric GitHub Actions workflows with minimum permissions, pinned action SHAs, deterministic caching, lockfile-backed tools, and local validation
+author: NVIDIA Corporation and Affiliates
+license: Apache-2.0
+---
+
+
+# Maintain GitHub Actions CI
+
+## Companion Guidance
+
+Use `karpathy-guidelines` alongside this skill for implementation or review
+work. Keep changes scoped, surface assumptions, and define focused validation
+before editing.
+
+Use this skill when a change touches `.github/workflows/*.yml` or
+`.github/workflows/*.yaml`, or when reviewing CI behavior for security,
+reliability, or reproducibility.
+
+## Standards
+
+- Put `permissions:` on each job that needs token access.
+- Avoid workflow-level permissions unless the repository intentionally centralizes
+  them and the inheritance tradeoff is documented.
+- Keep third-party actions pinned to full commit SHAs and preserve the readable
+  version comment after the SHA.
+- Prefer action-native or ecosystem-native caching over generic
+  `actions/cache`.
+- Use lockfiles or dependency manifests to drive cache invalidation.
+- Keep deploy and publish permissions isolated to the jobs that need them.
+- Read both caller and callee when a workflow uses `workflow_call`.
+- Keep documentation publish and preview credentials isolated to the Fern docs
+  workflow.
+- Keep local commands aligned with the corresponding `justfile` recipes when
+  they provide equivalent behavior.
+
+## Permission Model
+
+- `contents: read` is the default minimum for checkout-based build, test, docs,
+  and packaging jobs.
+- `pull-requests: read` is required for PR metadata lookup jobs.
+- `pages: write` and `id-token: write` should be limited to Pages deployment
+  jobs and any caller that invokes them through a reusable workflow.
+- For reusable workflows, the caller must grant every permission the called
+  jobs require. The callee cannot elevate beyond what the caller provides.
+
+## Caching
+
+- Prefer `astral-sh/setup-uv` cache support with `cache-dependency-glob`
+  anchored to `uv.lock`.
+- Prefer `Swatinem/rust-cache` with explicit `shared-key` and `workspaces`
+  instead of ad hoc target-directory caching.
+- Avoid caching generated outputs that can hide stale behavior unless the repo
+  already relies on them deliberately.
+
+## Review Checklist
+
+- [ ] Each job has the minimum permissions it needs
+- [ ] Reusable workflow callers grant only the scopes their callees require
+- [ ] Every external action is pinned to a full SHA
+- [ ] Cache settings are tied to lockfiles, manifests, or explicit tool versions
+- [ ] Secrets are only passed to the jobs that consume them
+- [ ] Python, Rust, and documentation jobs remain aligned with their lockfiles
+      and `justfile` recipes
+- [ ] Concurrency, branch filters, and documentation publish guards still
+      reflect repository intent
+
+## Validation
+
+Start with the narrowest useful checks:
+
+```bash
+just --fmt --check
+```
+
+Use ripgrep to inspect the workflow graph before editing:
+
+```bash
+rg -n "uses:|permissions:|secrets:|concurrency:|cache|just " .github/workflows
+```
+
+If local lint passes but the question is whether GitHub will authorize the run,
+inspect GitHub's permission model and the upstream action or reusable workflow
+source instead of assuming local success proves remote success.
+
+## Canonical References
+
+- `.github/workflows/ci_python.yml`
+- `.github/workflows/ci_rust.yml`
+- `.github/workflows/fern-docs.yml`
+- `Cargo.lock`
+- `uv.lock`
+- `docs/package-lock.json`
+- `justfile`
+- `maintain-packaging`
+- `validate-change`

.agents/skills/maintain-packaging/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: maintain-packaging
+description: Maintain NeMo Fabric Rust and Python package metadata, module paths, native artifacts, lockfiles, and release-facing build surfaces
+author: NVIDIA Corporation and Affiliates
+license: Apache-2.0
+---
+
+
+# Maintain Release And Packaging Surfaces
+
+## Companion Guidance
+
+Use `karpathy-guidelines` alongside this skill for implementation or review
+work. Keep changes scoped, surface assumptions, and define focused validation
+before editing.
+
+Use this skill when a change affects how NeMo Fabric is built, packaged, named, or
+consumed outside the source tree.
+
+## Audit Areas
+
+- Rust `Cargo.toml` package names and workspace metadata
+- Python and maturin packaging in `pyproject.toml`
+- Python package metadata in `python/pyproject.toml`
+- Native extension naming and placement under `python/src/nemo_fabric`
+- Dependency resolution in `Cargo.lock` and `uv.lock`
+- Documentation tooling metadata in `docs/package.json` and
+  `docs/package-lock.json`
+- CI workflows, install commands, and example commands
+- `justfile` build, test, clean, and documentation recipes
+
+## Checklist
+
+- [ ] Package names, import paths, and module names are internally consistent
+- [ ] Generated artifacts still land where downstream consumers expect
+- [ ] Docs and examples use the current install/import/build commands
+- [ ] CI references the same package names as local workflows
+- [ ] Public packaging changes are reflected in release-facing docs
+- [ ] Workspace, Python, and lockfile versions remain aligned where required
+- [ ] The editable maturin build still produces `nemo_fabric._native`
+
+## References
+
+- `pyproject.toml`
+- `python/pyproject.toml`
+- `Cargo.toml`
+- `Cargo.lock`
+- `uv.lock`
+- `docs/package.json`
+- `docs/package-lock.json`
+- `.github/workflows/ci_python.yml`
+- `.github/workflows/ci_rust.yml`
+- `justfile`