agentleFS
Sign inStart free
neomatrix369neomatrix369/AgentVetter/CLAUDE.md

AgentVetter

CLAUDE.md12 starsChanged 3 months agoMITView on GitHub

IMPORTANT: This project has a knowledge graph. ALWAYS use the code-review-graph MCP tools BEFORE using Grep/Glob/Read to explore the codebase. The graph is faster, cheaper (fewer tokens), and gives you structural context (callers, dependents, test coverage) that file scanning cannot. Fall back to Grep/Glob/Read only when the graph doesn't cover what you need. Never write code before a slice stub exists AND a branch is created. When /enhanced-flow-planner detects continuation mode: 1. Run plan-health-check 2. Run plan-modifier to add the…

We split this CLAUDE.md into the rules it gives an agent

10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use detect_changes for code review.

    line 36
  2. Very specific:

    Use get_affected_flows to understand impact.

    line 37
  3. Very specific:

    Use query_graph pattern="tests_for" to check coverage.

    line 38
  4. Very specific:

    When /enhanced-flow-planner detects continuation mode:

    line 46
  5. Very specific:

    Run plan-modifier to add the slice to TRAIL.md + PROGRESS.md + a slice stub file under docs/plan/slices/

    line 48
  6. Very specific:

    Create a branch: git checkout -b slice/<N>-<short-name>

    line 49
  7. Distinctive:

    Only then write code

    line 50
  8. Distinctive:

    Every piece of work — however small — goes on a branch:

    line 58
  9. Very specific:

    When creating or updating a PR with /create-pr or /update-pr, include a Checklist section in the generated body (after Test Results, before …

    line 74
  10. Distinctive:

    Leave "No secrets" always unchecked — the reviewer confirms this manually

    line 89

≈ “Common” is an estimate: at least 1 in 5 of the 25,680 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
CLAUDE.md
<!-- code-review-graph MCP tools -->

MCP Tools: code-review-graph

IMPORTANT: This project has a knowledge graph. ALWAYS use the code-review-graph MCP tools BEFORE using Grep/Glob/Read to explore the codebase. The graph is faster, cheaper (fewer tokens), and gives you structural context (callers, dependents, test coverage) that file scanning cannot.

When to use graph tools FIRST

  • Exploring code: semantic_search_nodes or query_graph instead of Grep
  • Understanding impact: get_impact_radius instead of manually tracing imports
  • Code review: detect_changes + get_review_context instead of reading entire files
  • Finding relationships: query_graph with callers_of/callees_of/imports_of/tests_for
  • Architecture questions: get_architecture_overview + list_communities

Fall back to Grep/Glob/Read only when the graph doesn't cover what you need.

Key Tools

ToolUse when
detect_changesReviewing code changes — gives risk-scored analysis
get_review_contextNeed source snippets for review — token-efficient
get_impact_radiusUnderstanding blast radius of a change
get_affected_flowsFinding which execution paths are impacted
query_graphTracing callers, callees, imports, tests, dependencies
semantic_search_nodesFinding functions/classes by name or keyword
get_architecture_overviewUnderstanding high-level codebase structure
refactor_toolPlanning renames, finding dead code

Workflow

  1. The graph auto-updates on file changes (via hooks).
  2. Use detect_changes for code review.
  3. Use get_affected_flows to understand impact.
  4. Use query_graph pattern="tests_for" to check coverage.

Slice-first rule (MUST NOT skip)

Never write code before a slice stub exists AND a branch is created.

When /enhanced-flow-planner detects continuation mode:

  1. Run plan-health-check
  2. Run plan-modifier to add the slice to TRAIL.md + PROGRESS.md + a slice stub file under docs/plan/slices/
  3. Create a branch: git checkout -b slice/<N>-<short-name>
  4. Only then write code

"Keep it simple" narrows scope. It does not bypass the slice stub or the branch. The stub is the requirement contract — without it there is no acceptance criteria and no gate evidence. The branch is the delivery unit — without it there is no reviewable PR.

Branch-before-commit rule (enforced by hook)

Never commit directly to main. The pre-commit hook blocks it.

Every piece of work — however small — goes on a branch:

git checkout -b <type>/<short-description>   # feat/ fix/ docs/ slice/ chore/

Emergency override (coordinators only, never for feature work):

ALLOW_MAIN_COMMIT=1 git commit ...

The hook allows merge commits through automatically. Everything else on main is blocked.

PR Composition

When creating or updating a PR with /create-pr or /update-pr, include a Checklist section in the generated body (after Test Results, before Closes):

## Checklist

- [x] `./scripts/quality-gates.sh` passes locally
- [x] New tests added or updated (or change is docs-only)
- [x] Docs updated where applicable
- [ ] No secrets or credentials committed

Auto-tick rules:

  • Tick quality-gates and tests if the Test Results section shows all stacks passing
  • Tick docs if the commit subjects mention docs/chore/refactor (no new behaviour)
  • Leave "No secrets" always unchecked — the reviewer confirms this manually

This mirrors .github/PULL_REQUEST_TEMPLATE.md so human-opened and skill-opened PRs share the same Checklist structure.

Download now (ZIP)

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. neomatrix369/tripwire★ 12100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository2 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free