| name | manage-rules |
| description | Inspect, audit, enable, or disable project live-rules. Use to list rules, check active instructions, explain an injected rule, or clean up rules. |
Manage Rules
Read, audit, and toggle live rules without changing what any rule says. For authoring or editing rule content, use the add-rule skill. The full format is documented in ../add-rule/references/rule-format.md.
For atomic storage, never edit .claude/live-rules/manifest.json. After every rule-file change, run:
node "${CLAUDE_PLUGIN_ROOT}/scripts/sync-atomic-rules.js" --project "${CLAUDE_PROJECT_DIR}"
Find the rules
New workspaces store one rule per Markdown file under .claude/live-rules/rules/; their generated manifest stays beside them. Existing workspaces may still use one Markdown file. Resolve that legacy file in this order:
- If
LIVE_RULES_PATH is set (commonly in .claude/settings.json under env), that path is the
file (project-relative, absolute, or ~-relative).
- Otherwise it is
.claude/live-rules.md at the project root.
If the file does not exist, there are no rules yet; point the user at add-rule to create the first
one.
How to read the files
For atomic storage, inspect every .md rule under .claude/live-rules/rules/. For legacy storage, the file is a sequence of rule sections. Each rule is a frontmatter block between --- fences
followed by its body, and the next --- begins the next rule. Anything before the first fence is a
title or intro and is ignored. Parse each section's frontmatter to get its scope, priority, and
enabled state; the body is the instruction text.
Tasks
List the rules
Parse every section and present a compact table (use the description as the rule's name, falling
back to its position in the file):
| Rule | Scope | Fires when | Priority | Enabled |
|---|
| House style | global | every prompt | 0 | yes |
| React component conventions | glob | editing **/*.tsx | 0 | yes |
| API layer rules | dir | editing under packages/api | 0 | yes |
| Deploy checklist | prompt | prompt matches deploy | 0 | yes |
| Strict lint gate | glob | editing **/*.ts | 0 | no |
Derive the scope the same way the hooks do: no scope fields means global; otherwise list whichever
of globs / dirs / prompt are present. A rule can have more than one scope. If a rule also
declares include:, note it (e.g. "+ includes .claude/.codebase-info/INDEX.md"); include: is a
payload, not a scope, so a rule with only include: is still global.
Audit the rules
Check each rule and report concrete issues (name the rule by its description):
- Broken or empty frontmatter that the parser would skip (e.g. an unterminated
[...], a missing
closing ---, no body at all).
- A stray
--- line inside a body, which the parser reads as the next rule's fence and which will
silently split or merge rules. Suggest replacing it with *** or ___.
- Globs that match nothing in the repo: compile the glob and test it against the tracked files
(
git ls-files, or a recursive listing minus the usual noise dirs). A glob matching zero files is
probably a typo or a stale path.
- Invalid prompt regexes (
/.../flags that does not compile).
- An
include: target that does not exist: resolve each include path (project-relative, or
absolute / ~-relative) and check the file is there. A rule whose includes are all missing is
silently dropped and injects nothing, so a broken path means the rule never fires. Flag it.
- Duplicates / conflicts: two rules giving contradictory instructions, or near-identical rules
that should be merged.
- Oversized rules: a body long enough to crowd the ~10k-char injection budget. Suggest trimming
or splitting.
- Over-broad global rules that would be better scoped (a
*.tsx-only instruction living as a
global rule, so it hits every unrelated prompt).
Summarize findings as a short list of "rule: problem, suggested fix". Only change the file if the user
asks; add-rule is the right tool for rewrites.
Enable or disable a rule
Toggle a rule without deleting it: find its section, set enabled: true or enabled: false in that
section's frontmatter (add the field if it is absent), and save. For atomic storage, run the sync command after saving; it regenerates the manifest from the rule files. Leave the other sections untouched.
The change takes effect on the next prompt or edit. Confirm which rule you toggled and its new state.
Explain what is active
Given a situation ("for a normal prompt", "when I edit src/app/page.tsx", "when I say 'deploy'"),
walk the rules and report which ones would be injected and why, mirroring the hook logic:
- On a prompt: global rules, plus prompt rules whose pattern matches the text, plus dir rules
whose directory contains the session's working dir.
- Before an edit to a file: glob rules matching that file (gitignore-style: a slash-free pattern
matches at any depth; a pattern with
/ is repo-anchored), plus dir rules whose directory contains
it. Global and prompt rules do not fire on edits.
A rule that carries include: only fires if at least one of its included files exists; if they are all
missing it is dropped, so factor that in when explaining why a rule did or did not appear.
This is the fastest way to answer "why did Claude just follow rule X" or "why didn't it".
Guidelines
- Read-and-toggle, not rewrite. This skill lists, audits, and flips
enabled. Send content
changes to add-rule.
- Edit surgically. When toggling one rule, change only that section's frontmatter; do not reflow
or reorder the rest of the file.
- Verify before claiming. When you say a glob matches nothing, actually test it against the repo
file list first.
- Never touch
CLAUDE.md. Rules live only in the live-rules file.
- After any change, remind the user to commit the live-rules file so the team stays in sync.
Success criteria
