Menü
Validate that all rules have proper enforcement classification (enforce/check/guidance)
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.
Basierend auf der SOC-Berufsklassifikation
Add a new linter to vigiles's cross-referencing engine as one cohesive, type-enforced unit — a LinterAdapter in the LINTERS registry, with the conformance test enforcing docs + site parity so no site is forgotten
Deep linter reference for authoring or debugging a vigiles enforce() rule — plugin tables, AST selectors, type-aware rules, auto-fix, and edge cases for ESLint, Ruff, Pylint, RuboCop, Stylelint, and Clippy. Use when you need the exact rule name or config for a specific linter, not for running a linter. (JVM/Go linters — detekt, ktlint, Checkstyle, golangci-lint — and Cedar have no deep-dive file yet; their reference lives in docs/linter-support.md.)
Hunt for real bugs in the vigiles CLI/codebase with a parallel expert fan-out, then FIX them directly — source-trace each defect to file:line, add a regression test, commit per theme. Use when asked to dogfood vigiles, find/fix bugs across the CLI the source-traced way, or fan out agents to audit the tool on itself.
The purpose, UX flow, and modern-minimalist design bar for the vigiles.sh landing site (site/). Use whenever designing, editing, adding to, or reviewing any site/ component, hero, section, or marketing copy — read it BEFORE touching site/, and hold every change against it. Not for docs/ or the app itself.
Render a local web page / built site and capture full-page screenshots (desktop + mobile) using the pre-installed Chromium. Use when asked to screenshot, render, or "see how it looks" for the vigiles landing site (site/), the audit report (report/), or any local HTML/dev server. Handles the scroll-reveal gotcha (below-the-fold cards captured blank) automatically.
Synthesize a recurring code-review rule into a custom lint rule — gated by an independent soundness test that abstains rather than ship a checker it can't prove sound
| name | enforce-rules-format |
| description | Validate that all rules have proper enforcement classification (enforce/check/guidance) |
| disable-model-invocation | true |
Validate that every rule in the project's instruction files has a proper enforcement classification, and fix any that are missing.
Check which format the project uses:
v2 (spec-based): Look for CLAUDE.md.spec.ts or any *.spec.ts files. If found, this is a v2 project — rules must use enforce(), check(), or guidance().
v1 (hand-written): Look for CLAUDE.md, AGENTS.md, .cursorrules. If found without a spec file, this is a v1 project — rules need **Enforced by:** or **Guidance only** annotations.
For v2 specs:
The TypeScript type system already prevents unannotated rules — you can't create a rule without calling enforce(), check(), or guidance(). So focus on:
enforce() rules reference real linter rules? Run npx vigiles compile to check.enforce()? Check linter configs for matching rules.check() assertions that could be delegated to a linter? Suggest enforce() instead.npx vigiles compile
npx vigiles discover
For v1 hand-written files:
Scan for ### headings. Each must have one of:
**Enforced by:** \linter/rule-name``**Guidance only** — reason<!-- vigiles-disable -->Report missing annotations with a summary table.
For each issue found:
enforce("linter/rule") (v2) or **Enforced by:** \linter/rule`` (v1)guidance() (v2) or **Guidance only** (v1)If the project uses v1 format, suggest migrating to v2 specs for type safety:
Your rules could benefit from type-safe specs. Run the
adopt-specskill to convert your CLAUDE.md to a typed .spec.ts file.
Run the appropriate command:
# v2
npx vigiles compile && npx vigiles check
# validate
npx vigiles check
Report the validation result.