Best for
- A second pair of eyes on every change before it is committed
- Teams that want their written rules actually enforced
- Catching schema, dependency and security issues early
What you give it
- The change (it reads git status and git diff)
- Your project's rules file and decision records
- Anything the change is not allowed to touch
What you get back
- A verdict: PASS, PASS WITH NOTES, or STOP
- Findings grouped as RED, YELLOW and observations, each with file:line and the rule touched
- Questions for you where a rule is ambiguous
How it works
- Reads your rules file and the decision records you list.
- Gets the change with git status and git diff (staged and unstaged).
- Checks each changed file against the nine checks below.
- Reports RED (needs approval), YELLOW (proceed carefully) and observations.
- Never edits anything: it reports to you.
Example
You: Review the staged changes.
Result: STOP. RED: prisma/schema.prisma line 412 adds a column — data-model changes need approval (rule 1). YELLOW: package.json adds a dependency not in your approved list. Observation: two unrelated files were reformatted.
Limits — please read
- It can only enforce rules you have written down.
- It reads code; it does not run it (use the Test Runner for that).
- A PASS is not a security audit: use a dedicated review for sensitive changes.