From vigiles
Edits vigiles .spec.ts files to update CLAUDE.md and AGENTS.md by adding linter rules, filesystem checks, guidance, sections, key files, or commands.
npx claudepluginhub zernie/vigilesThis skill uses the workspace's default tool permissions.
Edit a `.spec.ts` file to update the project's instruction files. The spec is the source of truth — CLAUDE.md and AGENTS.md are compiled build artifacts that must not be edited directly.
Improves CLAUDE.md files by wrapping conditional instructions in <important if> blocks to counter irrelevance warnings and boost adherence in Claude Code.
Guides creation of .claude/rules/ files for path-scoped project conventions using TDD workflow: RED (test gaps), GREEN (write rule), REFACTOR (optimize). Triggers on 'add rule', 'create convention', 'scope guideline'.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Share bugs, ideas, or general feedback.
Edit a .spec.ts file to update the project's instruction files. The spec is the source of truth — CLAUDE.md and AGENTS.md are compiled build artifacts that must not be edited directly.
$ARGUMENTS — What the user wants to change. Examples:
Look for spec files in the repo root:
CLAUDE.md.spec.ts — source for CLAUDE.mdAGENTS.md.spec.ts — source for AGENTS.md*.spec.ts matching instruction filesIf no spec exists, suggest: npx vigiles setup
Read the spec file. It's a TypeScript file that exports a claude() call with these fields:
import { claude, enforce, guidance, check, every } from "vigiles/spec";
export default claude({
// Optional: output target (defaults to "CLAUDE.md")
target: "CLAUDE.md",
// or multi-target:
// target: ["CLAUDE.md", "AGENTS.md"],
// Prose sections — become ## headings in compiled output
sections: {
positioning: "What this project does...",
architecture: "How the codebase is structured...",
},
// File paths verified to exist at compile time
keyFiles: {
"src/index.ts": "Main entry point",
},
// Commands verified against package.json
commands: {
"npm run build": "Compile the project",
"npm test": "Run all tests",
},
// Rules — three types
rules: {
// enforce() — backed by a linter rule, verified to exist AND be enabled
"no-any": enforce(
"@typescript-eslint/no-explicit-any",
"Use unknown and narrow with type guards.",
),
// check() — filesystem assertion run by vigiles
"test-pairing": check(
every("src/**/*.service.ts").has("{name}.test.ts"),
"Every service must have tests.",
),
// guidance() — prose only, no enforcement
"research-first": guidance("Google unfamiliar APIs before implementing."),
},
});
Based on what the user asked for:
Adding a rule:
enforce() if a linter rule exists, check() for filesystem conventions, guidance() for prose-onlyenforce(): find the actual linter rule name (e.g., eslint/no-console, @typescript-eslint/no-explicit-any, ruff/T201)rules object with a descriptive keyUpdating a section:
sections. Sections are plain strings or tagged template literals with file(), cmd(), ref() for verified references# or ## headers inside sections — they break the document structureAdding a key file or command:
keyFiles or commands. The compiler verifies these exist at compile timepackage.jsonAfter editing the spec, run:
npx vigiles compile
This regenerates the compiled instruction file(s). Review the output for any errors:
stale-file — a key file path doesn't existstale-command — a command isn't in package.jsoninvalid-rule — a linter rule doesn't exist or is disabledsection-has-header — a section contains # headers (break into separate named sections)npx vigiles check
If the PostToolUse hook is installed (via npx skills add zernie/vigiles), compilation happens automatically after you save the spec.
enforce() rules are verified — the compiler checks the rule exists AND is enabled in your linter config# or ## headers — use separate named sections instead