Validate a SKILL.md file against the four-tier validation system: Tier 0 (locate),
Tier 1 (standard or marketplace grading per the IS 100-point rubric), Tier 2
(static production gate — allowed-tools accuracy, auth protocol, dead code, tool
safety, orchestration bounds), and Tier 3 (JRig 7-layer behavioral eval, opt-in
via --thorough). Use when creating a new skill, checking skill quality, preparing
for marketplace submission, running deep quality analysis, or gating a skill for
production. Trigger with "validate this skill", "grade my skill", "deep eval",
"check SKILL.md", "validate thorough", "/validate-skillmd".
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Validate a SKILL.md file against the four-tier validation system: Tier 0 (locate),
Tier 1 (standard or marketplace grading per the IS 100-point rubric), Tier 2
(static production gate — allowed-tools accuracy, auth protocol, dead code, tool
safety, orchestration bounds), and Tier 3 (JRig 7-layer behavioral eval, opt-in
via --thorough). Use when creating a new skill, checking skill quality, preparing
for marketplace submission, running deep quality analysis, or gating a skill for
production. Trigger with "validate this skill", "grade my skill", "deep eval",
"check SKILL.md", "validate thorough", "/validate-skillmd".
Schema 3.3.1 enforces the 8-field IS enterprise required-field set at marketplace tier (name, description, allowed-tools, version, author, license, compatibility, tags). Anthropic's spec floor (name + description only) sits underneath; the IS rubric sits on top. Modes:
Standard (default): Mirrors platform.claude.com/docs/en/agents-and-tools/agent-skills/overview exactly. Required: name, description. Everything else is silent unless invalid type/value. Fast (~10 sec).
Marketplace (--marketplace): 8-field enterprise required set + 100-point IS rubric. Missing required fields = ERROR, not warning. The --enterprise flag is a deprecated alias. Fast (~10 sec).
Deep (--deep): Intent Solutions Deep Evaluation Engine — 10 weighted dimensions, trust badges, Elo competitive ranking, optional LLM quality assessment via Groq. Fast (~30 sec).
Thorough (--thorough): Adds Tier 3 JRig behavioral eval on top of Tier 1+2. Runs 7-layer eval across Haiku/Sonnet/Opus. Slow (~10–30 min) and costs ~$2–5 per skill in API spend — opt-in only. Right for production-gating, not iterative authoring.
Performance + cost note: Tiers 0–2 run in seconds and are free. Tier 3 (JRig) is opt-in because behavioral eval across the model matrix is genuinely expensive. Default invocations stay fast; --thorough is for the moment a skill is being promoted to production or marketplace-verified.
For --thorough (Tier 3): JRig CLI on PATH (jrig --version returns ≥ v0.14.0). Install: cd ~/000-projects/j-rig-binary-eval && pnpm install && pnpm build && pnpm link --global. Tier 3 is opt-in; the rest of the skill works without JRig installed.
Kernel schema first (canonical machine spec)
Validate frontmatter structure against references/kernel-schemas/v1/skill-frontmatter.schema.json
FIRST — the kernel-pinned canonical machine spec (@intentsolutions/core@0.5.0, vendored;
the STRICT v2 sibling under kernel-schemas/v2/ is not yet promoted to canonical). The
prose spec references are supporting documentation only; on disagreement the kernel schema
wins. $refs are absolute $id URIs — register every file under kernel-schemas/ to
resolve them. Provenance + refresh: references/kernel-schemas/PROVENANCE.md.
If path provided via $ARGUMENTS, use it directly. Otherwise:
Check current directory for SKILL.md
Ask user with AskUserQuestion
Common locations:
~/.claude/skills/{name}/SKILL.md (global)
.claude/skills/{name}/SKILL.md (project)
Step 2: Run Validator
# Standard tier (default — Anthropic spec exactly)
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py SKILL.md
# Marketplace tier (full 100-point rubric, polish recommendations as warnings)
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --marketplace SKILL.md
# Deep evaluation (10 dimensions, badges, Elo ranking)
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --deep SKILL.md
# Deep + LLM quality assessment via Groq (requires GROQ_API_KEY)
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --deep --thorough SKILL.md
# Deep eval with JSON/markdown/HTML report output
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --deep --report-format json SKILL.md
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --deep --report-format html SKILL.md
# Marketplace + write to compliance DB
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --marketplace --populate-db claude-code-plugins-plus-skills/freshie/inventory.sqlite SKILL.md
# Show D/F grade skills in full scan
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --marketplace --show-low-grades
# Minimum grade gate (exits 1 if any skill below threshold)
python3 claude-code-plugins-plus-skills/scripts/validate-skills-schema.py --marketplace --min-grade B SKILL.md
Default to marketplace tier when the user is preparing for marketplace submission. Use --deep for functional quality assessment beyond structural compliance. The --enterprise flag still works as a deprecated alias for --marketplace.
After Tier 1 grading and before any behavioral eval, run five inline static checks. These catch obvious production blockers in seconds without needing JRig. Always run regardless of mode (standard/marketplace/deep/thorough); each is binary pass/fail.
2.5.1 allowed-tools accuracy
Every tool declared in allowed-tools should actually be referenced somewhere in the skill body or its references//scripts/. Conversely, every tool the skill calls should be declared.
# Extract declared tools (handles CSV string, space-separated, and YAML list forms — schema 3.3.1)
declared=$(python3 -c "import yaml,sys; fm=yaml.safe_load(open('SKILL.md').read().split('---')[1]); t=fm.get('allowed-tools',''); print(t if isinstance(t,str) else ' '.join(t))")
# Each declared base tool (Read, Write, Bash, etc.) must appear in the bodyfor tool in $(echo"$declared" | grep -oE '[A-Z][a-zA-Z]+' | sort -u); doif ! grep -q "$tool""SKILL.md"; thenecho"FAIL: tool '$tool' declared but not referenced in body"fidone
Fail when: tool declared but never used (over-permissive — attack surface) OR tool used but never declared (will prompt user every invocation, defeating allowed-tools).
2.5.2 Auth protocol documented (when applicable)
If the skill mentions an external API (any URL, curl, fetch, MCP server, OAuth flow, API key reference), an authentication method must be documented in the body or in references/auth.md / references/api-surface.md.
# Heuristic: look for API indicatorsif grep -qE "(curl |fetch\(|mcp__|API_KEY|TOKEN|OAuth|Bearer )""SKILL.md"; thenif ! grep -qiE "(authentication|auth method|api key|bearer token|oauth flow|credentials)""SKILL.md"; thenecho"FAIL: external API referenced but no auth protocol documented"fifi
Fail when: API surface is referenced but a future engineer reading the skill couldn't tell how authentication happens.
2.5.3 Dead-code / unreachable-branch sanity
Conditional structures that can never fire (e.g., if false, mutually exclusive guards, sections that contradict an earlier hard-fail).
# Conservative checks — flag for human review, don't auto-fail
grep -nE "^(if false|if \[ false \]|elif false)""SKILL.md" && echo"WARN: literal-false branch found"
grep -cE "^### ""SKILL.md"# If section count grossly exceeds the table-of-contents count → drift
Warn when: a literal-false branch is found OR the body contains sections not present in the table of contents (silent drift).
Fail when: a dangerous combo is declared and the body has no ## Safety Justification section explaining why the wide scope is necessary.
2.5.5 Orchestration bounds
Skills are NOT plugins. A skill should not spawn other skills, delegate to other agents as a primary control flow, or self-coordinate across sessions. That's /skill-creator --forge territory and plugin-level orchestration. Skills do one job.
# Look for orchestration smells in skillsif grep -qE "(spawn another skill|delegate to /|invoke .* skill|orchestrate across|self-coordinate)""SKILL.md"; thenecho"FAIL: skill appears to orchestrate other skills/agents — that belongs at the plugin layer"fi
Fail when: the skill body claims it spawns/orchestrates other skills or agents as the primary control flow. Multi-agent synthesis WITHIN one skill invocation (calling subagents to specialize) is fine and expected; cross-skill orchestration is not.
Tier 2 verdict
All 5 checks pass → Tier 2 GREEN; proceed.
Any FAIL → Tier 2 RED; the skill is blocked from production promotion until resolved. Tier 3 (JRig) does not run if Tier 2 is RED — fail fast.
Only WARN → Tier 2 YELLOW; log warnings to the unified report; Tier 3 still runs.
Default skipped. Tier 3 runs only when the user passes --thorough. Behavioral eval across the model matrix (Haiku / Sonnet / Opus) takes 10–30 minutes per skill and costs ~$2–$5 in API spend. Right for production-gate moments, not iterative authoring.
Prerequisites
JRig CLI on PATH: j-rig --version (note: bin name is j-rig with hyphen, not jrig)
For Tier 3B (7-layer eval): API keys for Haiku, Sonnet, Opus configured per JRig docs
If JRig isn't on PATH, the skill emits a placeholder verdict and a one-line install hint, then continues to Step 3 (grade report) without blocking. Tier 3 absence does not mean a skill fails — only Tier 1+2 are mandatory.
Run JRig's check command on the skill directory (not the SKILL.md path). Returns deterministic pass/warn/error verdicts on package structure: SKILL.md exists + parses, name present, description length, deprecated patterns, time-sensitive content, etc.
# JSON output for parsing into the unified report
j-rig check "$(dirname "SKILL.md")" --json
This is a separate concern from the IS spec-compliance check (Tier 1) — JRig's check is structural, not rubric-based. The Anthropic + AgentSkills.io spec snapshots in 000-docs/ are read by the IS validator (scripts/validate-skills-schema.py), not by JRig directly. The two are complementary: IS validator scores against the spec rubric; JRig verifies the package shape and surfaces structural anti-patterns.
Verdict mapping:
All severity: "pass" → Tier 3A GREEN
Any severity: "warning" → Tier 3A YELLOW (non-blocking; surfaced in unified report)
Any severity: "error" → Tier 3A RED (blocks production promotion)
# Ad hoc invocation — Sonnet only, with no write to the Freshie inventory
j-rig eval"$(dirname "SKILL.md")" --json
# Full model matrix with a durable Freshie evidence row. Run from the repository root.# j-rig receives only a scratch DB; the local recorder owns the Freshie write.
scripts/run-jrig-eval.sh \
--skill-dir "$(dirname "SKILL.md")" \
--plugin "<catalog-plugin-name>" \
--models haiku,sonnet,opus \
--inventory-db freshie/inventory.sqlite
# Skip specific layers (when iterating)
j-rig eval"$(dirname "SKILL.md")" --no-trigger --no-functional --json
Eval spec source: JRig reads <skill-dir>/eval-spec.yaml if present, or use --spec <path> to point at one elsewhere. A spec is currently required — j-rig eval errors if neither is found. (Auto-generating a baseline spec from the SKILL.md frontmatter — should_trigger/should_not_trigger cases derived from the description trigger phrases — is the planned j-rig scaffold-spec <skill-dir> command; until it ships, author the spec by hand or copy skill/eval.yaml as a template.)
Layers:
Trigger quality: precision/recall on user prompts that should and should not activate the skill
Functional quality: task completion + output format match against gold cases
Regression protection: sacred-case suite cannot break (skill is locked-down on these)
Baseline value: skill output beats naked Claude on the same prompt; if not, flag for obsolescence
Model variance: independent pass/fail per Haiku / Sonnet / Opus; flags any model where the skill collapses
All 7 layers pass on all 3 models → Tier 3 GREEN; skill is JRig-Verified.
Any layer fails on any model → Tier 3 RED; report which layer + which model + recommended remediation. Block production promotion.
JRig unavailable → Tier 3 SKIPPED; emit a one-line note in the unified report; do not block.
Persist results to Freshie
JRig writes runtime tables into whatever --db it receives, so it must never receive
freshie/inventory.sqlite. The supported wrapper gives JRig a temporary database under /dev/shm,
captures its JSON, then invokes the repository-owned recorder to upsert only the governed
forge_proofs row:
JRig's runtime tables remain in the temporary database and never enter the Freshie/Dolt export.
The durable integration surface is forge_proofs, written by scripts/record-jrig-proofs.mjs:
SELECT plugin_name, passed, layers_passed, baseline_delta, verified_at
FROM forge_proofs
WHERE verification_type ='tier3-jrig';
Freshie remains the sole local writer of inventory and grade history. A future schema change may
project selected JRig evidence into skill_compliance, but JRig itself still must not write that
database directly:
jrig_passed (boolean)
jrig_tier_blocked (1–7 if any)
jrig_baseline_delta (numeric — skill output vs. naked Claude on same prompt)
Until then, the join above is the integration surface.
Snapshot refresh workflow (quarterly)
Tier 3A reads versioned snapshots, NOT live Anthropic / AgentSkills.io docs. Live-fetching from CI is a rate-limit + flakiness risk. The snapshot refresh is a separate PR cadence:
Quarterly cron (or manual trigger) fetches latest specs from code.claude.com/docs/en/skills and agentskills.io/specification.
Writes to 000-docs/anthropic-skills-spec-snapshot.md + 000-docs/agentskills-spec-snapshot.md.
Opens a PR with the diff.
PR review = the human gate that catches breaking spec changes before they reach validation.
This isolates "the spec changed" events from per-skill validation runs.
Step 3: Present Unified Report (all tiers)
Parse the combined output of Tiers 1–3 (or 1+2 when Tier 3 is skipped) and present:
Production verdict: PASS / FAIL / VERIFIED (when Tier 3 ran and all 7 layers green)
Add TOC to reference files >100 lines (+1 pt modifier)
Add feedback loops for quality-critical workflows (+2 pts utility)
Remove time-sensitive information (+1 pt modifier)
Ensure consistent terminology throughout (+1 pt writing style)
Step 5: Review Structural Advisors
The validator emits INFO-level structural suggestions (marketplace tier):
Split to commands: 3+ kebab-case ## operation-name sections detected without commands/ directory → suggest splitting into individual commands/*.md files
Offload to references: Body sections >20 lines (Output, Error Handling, Examples, etc.) without references/ directory → suggest moving to references/ with relative markdown links
DCI opportunities: Skill performs file existence checks, git operations, or tool version detection without DCI → suggest !command`` directives
Step 6: Auto-Fix (if requested or grade below B)
If grade < B (80), ask user: "Fix issues automatically?"
