بنقرة واحدة
enforce-rules-format
Validate that all rules have proper enforcement classification (enforce/check/guidance)
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Validate that all rules have proper enforcement classification (enforce/check/guidance)
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.