plugins/build/skills/check-resolver/SKILL.md
Audit a root-level resolver — verify AGENTS.md pointer, managed-region integrity, filing-table coverage against disk, context-table actionability, and trigger-eval pass rate. Use when the user wants to "audit a resolver", "validate routing table", or "find dark capabilities".
npx skillsauth add bcbeidel/wos check-resolverInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Evaluate a root-level resolver in three tiers: deterministic artifact and path checks (no LLM), per-dimension semantic evaluation (one locked-rubric LLM call), and cross-artifact reachability + staleness against disk state.
This skill follows the check-skill pattern. Tier-1 detection is in 3 scripts emitting JSON envelopes via _common.py (11 rule_ids total). Tier-2 has 4 judgment dimensions read inline by the primary agent. Tier-3 cross-artifact checks are mechanized as Tier-1 rule_ids (dark-capability) or opt-in (--run-evals).
The audit rubric mirrors the authoring principles in resolver-best-practices.md. When the principles doc changes, the dimensions follow.
Also fires when the user phrases the request as:
Walk up from the target directory looking for RESOLVER.md. The first ancestor with one becomes the resolver root; all checks scope to that resolver and its subtree.
Locate three artifacts at the resolver root:
RESOLVER.mdAGENTS.md (for the pointer check).resolver/evals.yml (sibling to RESOLVER.md)Report: "Found resolver at <resolver root>. Auditing N filing rows, M context rows, K eval cases."
If no RESOLVER.md is found anywhere up to the filesystem root, emit FAIL and stop — nothing to audit. To audit every resolver in a repo with nested resolvers, run this skill once per resolver root.
Invoke the three detection scripts:
python3 plugins/build/skills/check-resolver/scripts/check_pointer.py <resolver-root>
python3 plugins/build/skills/check-resolver/scripts/check_resolver.py <resolver-root>
python3 plugins/build/skills/check-resolver/scripts/check_evals.py <resolver-root>
Each script emits a JSON array of envelopes. Parse stdout per script. The combined Tier-1 rule set:
Script-to-rules map (11 Tier-1 rule_ids):
| Script | rule_ids | Severity |
|---|---|---|
| check_pointer.py | pointer-present | fail |
| check_pointer.py | pointer-resolves | fail |
| check_resolver.py | markers-present | fail |
| check_resolver.py | filing-paths-resolve | fail |
| check_resolver.py | context-paths-resolve | fail |
| check_resolver.py | filing-rows-unique | fail |
| check_resolver.py | context-rows-unique | fail |
| check_resolver.py | dark-capability | warn |
| check_resolver.py | mtime-stale | warn |
| check_evals.py | evals-parse | fail |
| check_evals.py | eval-pass-stale | warn |
Each finding's recommended_changes is canonical — copy it through verbatim. recommended_changes is REQUIRED on every finding.
Tier-2 exclusion list. Any FAIL in pointer-present, pointer-resolves, markers-present, filing-paths-resolve, context-paths-resolve, filing-rows-unique, context-rows-unique, or evals-parse excludes the resolver from Tier-2 — a malformed or unreachable resolver shouldn't burn LLM budget.
WARN findings (dark-capability, mtime-stale, eval-pass-stale) never exclude. They surface alongside Tier-2 findings.
For resolvers that passed the Tier-2 exclusion gate, evaluate against the 4 judgment rules at references/check-*.md:
| File | Dimension | Severity |
|---|---|---|
| check-filing-coverage.md | D1 — every depth-1 directory classified (filing / context / out-of-scope / ambient / delegated) | warn |
| check-context-actionability.md | D2 — context rows list 1-4 concrete entries, not vague prose | warn |
| check-eval-representativeness.md | D3 — evals exercise both filing/context routing; ≥1 case per filing row; ≥15% negative | warn |
| check-brief-presence-and-content.md | D4 — .briefs/<slug>.brief.md exists with 5 H2s; So-what is specific | warn |
Evaluator policy: see check-skill-pattern.md §Evaluator policy. Read all 4 rule files first, then evaluate the resolver in one LLM call.
Include RESOLVER.md verbatim in the Tier-2 prompt — never summarize. Include the directory scan output, .resolver/evals.yml, and .briefs/<slug>.brief.md (if present).
Dark-capabilities scan. Mechanized as Tier-1 dark-capability (already part of check_resolver.py's output). For every directory under the resolver root (depth 1–2), classify as: in-filing, in-context, in-out-of-scope, ambient (.git, node_modules, dist, build, .cache, .venv, target, __pycache__, .resolver), or delegated (nested RESOLVER.md). Anything unclassified surfaces as warn. Subdirectories of a filing dir are not auto-classified.
Managed-region drift. Currently judgment-evaluated as part of D1 (filing-coverage). Future work could mechanize as a separate Tier-3 rule that diffs the live managed region against a fresh regeneration.
Optional: --run-evals. When invoked with --run-evals, execute each case in .resolver/evals.yml against a Claude call with RESOLVER.md in context. Each failing case surfaces as a Tier-3 finding. This step is opt-in (slow and costs LLM calls).
Merge findings from all three sources (3 detection scripts' JSON envelopes + 4 Tier-2 judgment findings + optional --run-evals results) into a unified table:
| Tier | rule_id | Location | Status | Reasoning |
|------|---------|----------|--------|-----------|
Sort: fail before warn before inapplicable; Tier-1 before Tier-2 before Tier-3 within severity. Each finding's Recommendation: line copies through recommended_changes verbatim.
Close with:
Resolver audited — no findings orResolver audited, N findings (X fail, Y warn)Ask exactly once:
"Apply fixes? Enter y (all), n (skip), or comma-separated numbers."
For each selected finding, route per the recipe in recommended_changes:
/build:build-resolver --regenerate; missing filing rows → /build:build-resolver --add-filing <type>.After each applied fix, re-run the affected Tier-1 script (or re-judge the Tier-2 dimension). Terminate when the user enters n or exhausts findings.
recommended_changes is canonical; copy it through.pass envelope..resolver/evals.yml) is missing, the affected Tier-1 rule emits fail — do not collapse downstream rules to silent skip.recommended_changes. Each rule's recipe constant is canonical guidance sourced from resolver-best-practices.md. Copy it through; do not paraphrase.RESOLVER.md verbatim in the Tier-2 prompt — never summarize.--run-evals is passed; eval execution is slow.git diff / git checkout.Chainable to: /build:build-resolver --regenerate (rebuild managed region); /build:build-resolver --add-filing <type> (add missing filing row).
tools
Use when the user wants to "audit a help skill", "review my plugin index", or "verify my help-skill is up to date". Audits a plugins/<plugin>/skills/help/SKILL.md against the help-skill rubric — coverage, freshness, frontmatter fidelity, plus five judgment dimensions and a trigger-collision check.
tools
Use when the user wants to "scaffold a help skill", "add a /<plugin>:help command", or "build a plugin index skill", or wants to give a plugin an orientation surface that lists its skills and common workflows. Produces a SKILL.md at plugins/<plugin>/skills/help/SKILL.md.
tools
Audits pair-level integrity of a primitive-pair (the artifact `/build:build-skill-pair` produces) by walking the four required artifact slots — principles doc, `build-<primitive>/SKILL.md`, `check-<primitive>/SKILL.md`, and the `primitive-routing.md` registration — and reports cross-artifact issues a per-SKILL.md checker cannot see: missing principles doc, divergent principles paths between halves, absent routing registration, missing build→check handoff. Per-half structural compliance with the unified pattern (`check-skill-pattern.md`) is delegated to `plugins/build/_shared/scripts/check_skill_pattern.py`. Use when the user wants to "audit a skill pair", "review a primitive pair", or "validate the skill pair for X". Not for auditing a single SKILL.md — route to `/build:check-skill`. Not for re-distilling a stale principles doc — route to `/build:build-skill-pair`.
tools
Audits a project's top-level README.md against 28 deterministic checks across seven scripts (secret scanning, H1 uniqueness & position, heading-hierarchy skips, section presence & order, TOC threshold, line count & length, code-block language tags, shell-prompt prefixes, smart quotes in code, relative-link resolution, fragment-anchor resolution, image alt text, badge/image byte size, destructive-command flagging, pipe-to-shell patterns, TLS-disable instructions, non-reserved hostnames/IPs, emoji in headings, LICENSE file presence & link, CONTRIBUTING link, TODO/FIXME/XXX markers, README gitignore status) plus seven judgment dimensions and a Tier-3 cross-README collision check. Use when the user wants to "audit a README", "lint a README", or "run linters on README.md". Not for sub-package READMEs (different rubric) or docs-site pages (different toolchain).