guardian-validation-matrix

Selects the minimal test, build, and smoke validation set for Guardian repository changes.

Updated Aug 20, 2026
One-click install
npx skills add https://github.com/hduoc2003/leviathan-guardian --skill guardian-validation-matrix-hduoc2003
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: guardian-validation-matrix
Source: https://github.com/hduoc2003/leviathan-guardian/tree/main/.agents/skills/guardian-validation-matrix
Command: npx skills add https://github.com/hduoc2003/leviathan-guardian --skill guardian-validation-matrix-hduoc2003

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Deciding which tests and builds to run after a change in a large Rust and TypeScript monorepo is error-prone: running everything wastes time, while running too little misses regressions. This Skill maps each changed layer of the Guardian repository to the smallest meaningful verification set. ## Core Features & Use Cases - Layer-based test selection: Classifies changes as server, Rust client, TypeScript client, multisig SDK, browser example, deploy, release, or benchmark, then maps each to exact cargo and npm commands. - Risk-based expansion rules: Escalates to broader checks when changes touch public contracts, auth, signature flows, proposal lifecycle, canonicalization, or browser signers. - Use Case: After editing crates/server/src/services, the Skill directs you to run cargo test -p guardian-server, add integration tests if transport semantics changed, and document any intentionally skipped coverage. ## Quick Start Use the guardian-validation-matrix skill to decide which tests, builds, and smoke checks to run for my change to the Guardian server auth flow.

Frequently Asked Questions about guardian-validation-matrix

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose which tests to run for a monorepo change?▼

Classify the changed layer first, then run the package-local checks mapped to that layer, such as cargo test -p guardian-server for server code. Expand to broader checks only when the change touches contracts, auth, or cross-layer behavior.

When should I run cargo test --workspace instead of package tests?▼

Run workspace-wide tests only when multiple packages across Rust and TypeScript were edited, targeted checks failed suggesting wider fallout, or the task explicitly requests a broad verification sweep. Otherwise prefer package-local test commands.

What validation is needed for TypeScript client changes?▼

For packages/guardian-client changes, run npm test and npm run build inside that package. For the TypeScript multisig SDK, run the same commands in packages/miden-multisig-client, adding upstream example smoke checks when behavior is user-visible.

Are unit tests enough for user-visible example changes?▼

No. When a lower-layer change is observable in examples/demo or examples/smoke-web, add a manual smoke run such as cargo run -p guardian-demo or the browser smoke-test skill. Unit tests do not replace example smoke checks for user-visible behavior.

What should I do when a server contract change affects clients?▼

Combine the relevant package-local commands for both layers and validate at least one upstream consumer, such as an example smoke test. Document any coverage you intentionally skip with a reason rather than implying it was unnecessary.