validate-change
Skill73 starsChanged 58 days agoApache-2.0View on GitHub
Choose and run the right NeMo Fabric validation matrix for a change instead of using one fixed test list
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ltatarev/skillstheir own version, first seen Aug 9, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ltatarev/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository25 other files it gives its agents.
- AGENTS.mdAGENTS.md
- check-release-deploymentsSkill
- contribute-adapterSkill
- contribute-apiSkill
- contribute-docsSkill
- create-beta-tagSkill
- create-rc-tagSkill
- create-release-tagSkill
- draft-release-notesSkill
- karpathy-guidelinesSkill
- maintain-ciSkill
- maintain-packagingSkill
- prepare-code-freezeSkill
- prepare-prSkill
- python-testsSkill
- qualify-harborSkill
- review-doc-styleSkill
- small-fixSkill
- update-project-versionSkill
- code-reviewSkill
- swebench-debuggingSkill
- nemo-fabric-build-adapterSkill
- nemo-fabric-integrateSkill
- alternateSkill
- defaultSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 7 are distinctive, and 17 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
17
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Use karpathy-guidelines alongside this skill for implementation or review work.
- Distinctive: line 17
Use this skill to choose the smallest validation set that still covers the surfaces touched by a change.
- Very specific: line 24
If Rust code changed, run cargo fmt --all -- --check and just test-rust.
- Very specific: line 25
If Python code or a Python-facing adapter changed, run just test-python.
- Very specific: line 26
If the TypeScript adapter contract or one of its source schemas changed, run just test-typescript.
- Very specific: line 28
If crates/fabric-core changed in a way exposed through Python, run both the Rust and Python suites.
- Very specific: line 30
If the PyO3 bridge or package metadata changed, run just build-python and cargo check -p fabric-python --locked.
- Very specific: line 32
If public configuration types changed, confirm the schema snapshot tests in just test-rust pass and review generated schema diffs.
- Distinctive: line 34
If an adapter or integration changed, run its focused tests.
- Very specific: line 35
If a Cargo or Python manifest or lockfile changed, run uv run --no-project python scripts/licensing/license_diff.py --base-ref origin/main, …
- Very specific: line 39
If the TypeScript manifest or npm lockfile changed, inspect the complete npm dependency tree and license fields, confirm the package still …
- Very specific: line 43
If documentation or examples changed, run just docs when practical and verify documented commands against the current repository.
- Distinctive: line 45
If code changes alter APIs, commands, paths, packaging behavior, telemetry semantics, or documented best practices, update dependent …
- Distinctive: line 54
Run Rust formatting and tests.
- Very specific: line 56
Use python-tests, run focused pytest tests first, then run just test-python.
- Very specific: line 60
Run the focused adapter tests under tests/adapters, then just test-python.
- Very specific: line 62
Use qualify-harbor for real inference and container checks across the adapter catalog or a developer subset.
- Very specific: line 69
Run the Rust, Python, and TypeScript suites and review changes under schemas/, the checked-in Python adapter-contract representations, …
- Very specific: line 73
Use contribute-docs and review-doc-style.
- Very specific: line 76
Use maintain-ci or maintain-packaging, then run the recipes and checks whose behavior changed.
- Distinctive: line 122
Before review or handoff:
- Distinctive: line 124
Verify README and docs entry points still match current package names and paths.
- Very specific: line 126
Verify examples use current just recipes and public commands.
- Distinctive: line 127
Call out checks that were not run and why.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Validate a Change
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 to choose the smallest validation set that still covers the surfaces touched by a change.
Mandatory Rules
- Format changed files with the language-native formatter before the final test pass.
- If Rust code changed, run
cargo fmt --all -- --checkandjust test-rust. - If Python code or a Python-facing adapter changed, run
just test-python. - If the TypeScript adapter contract or one of its source schemas changed, run
just test-typescript. - If
crates/fabric-corechanged in a way exposed through Python, run both the Rust and Python suites. - If the PyO3 bridge or package metadata changed, run
just build-pythonandcargo check -p fabric-python --locked. - If public configuration types changed, confirm the schema snapshot tests in
just test-rustpass and review generated schema diffs. - If an adapter or integration changed, run its focused tests.
- If a Cargo or Python manifest or lockfile changed, run
uv run --no-project python scripts/licensing/license_diff.py --base-ref origin/main, review the transitive license changes, then run theattributions-rustandattributions-pythonpre-commit hooks. - If the TypeScript manifest or npm lockfile changed, inspect the complete npm
dependency tree and license fields, confirm the package still has zero
production dependencies, run the
attributions-nodepre-commit hook, and run its package and audit checks. - If documentation or examples changed, run
just docswhen practical and verify documented commands against the current repository. - If code changes alter APIs, commands, paths, packaging behavior, telemetry
semantics, or documented best practices, update dependent maintainer skills in
the same branch. Because the consumer skills under
skills/restate SDK guide, Pydantic model, and Rust type details, update them in parity whenever those surfaces change.
Start With the Change Shape
- Rust core, CLI, or shared runtime semantics changed Run Rust formatting and tests. Add Python tests when the behavior is exposed through the SDK, and run relevant tests for CLI behavior.
- Python SDK or PyO3 binding changed
Use
python-tests, run focused pytest tests first, then runjust test-python. Rebuild withjust build-pythonwhen native code or packaging changed. - Adapter behavior changed
Run the focused adapter tests under
tests/adapters, thenjust test-python. - Harbor integration changed
Use
qualify-harborfor real inference and container checks across the adapter catalog or a developer subset. Retain its complete catalog report; deterministic tests alone do not establish an all-harness integration pass. Runtests/integrations/test_harbor_runner.pyandtests/python/test_adapter_capabilities.py, thenjust test-python. For host admission changes, verify metadata inspection without harness SDKs or task discovery, selected telemetry claims, and task-side descriptor drift rejection before startup. - Schema or public contract changed
Run the Rust, Python, and TypeScript suites and review changes under
schemas/, the checked-in Python adapter-contract representations, generated TypeScript sources, and generated API references. - Documentation-only change
Use
contribute-docsandreview-doc-style. Runjust docsfor docs-site or generated-reference changes. - CI or packaging changed
Use
maintain-ciormaintain-packaging, then run the recipes and checks whose behavior changed.
Core Validation Matrix
just test-rust
just test-python
just test-typescriptCommon Targeted Commands
# Rust
just build-rust
just test-rust
cargo fmt --all -- --check
cargo check -p fabric-python --locked
# Python and native extension
just build-python
just test-python
uv run --no-sync pytest -k "<pattern>"
# TypeScript adapter contract
just build-typescript
just test-typescript
just pack-typescript
# Documentation
just docs
# Dependency licenses
uv run --no-project python scripts/licensing/license_diff.py --base-ref origin/main
uv run pre-commit run --all-files attributions-rust
uv run pre-commit run --all-files attributions-python
uv run pre-commit run --all-files attributions-node
# Justfile and patch hygiene
just --fmt --check
git diff --checkHygiene Checks
Before review or handoff:
- Verify README and docs entry points still match current package names and paths.
- Verify examples use current
justrecipes and public commands. - Call out checks that were not run and why.
- Run
git diff --check.
References
- Python test guidance:
python-tests - Build and test recipes:
justfile - Python CI:
.github/workflows/ci_python.yml - Rust CI:
.github/workflows/ci_rust.yml - TypeScript CI:
.github/workflows/ci_typescript.yml - Documentation CI:
.github/workflows/fern-docs.yml - Public Python contract:
docs/python-sdk-contract.md - Public adapter contract:
schemas/SCHEMA.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

