REVIEW
Grump this plan
Also Grump <file>, Grump this diff and Grump this project. The agent reviews, gives a verdict and updates the ledger.
How it works
A skill your agent reads, plus a rules file and a ledger.
GrumpyDev is a plain-text skill for the coding agent you already use. Install it in a project, answer at most four questions, and ask for a review when you want one. There is no account or service, and nothing runs in the background.
Commands
STATUS
Grump status
Lists every unresolved issue across all ledgers, by severity. Changes nothing.
ACCEPT
Grump accept GD-004
Marks an issue accepted, with your reason, and offers to record it in .grump so it is not raised again.
SYNC
Grump sync
After you edit .grump by hand, rewrites the constraints block in each agent file from it.
Later: Grump update or Grump remove. Update shows you the diff for each skill file and replaces them after you confirm. Remove asks before deleting .grump or the ledgers. Reviews only start on an explicit Grump request.
What a review checks
The work against the repository.
The agent reads the plan or diff, then the code, config, schema, deploy files and docs it touches. Every finding says where, what happens, and the fix.
FAILURESClaims the code contradicts, mixed versions during a deploy, retries and partial failure, units and time zones, concurrency.
OWNERSRules copied into several places, helpers bypassed, code reaching into another unit's internals, layers pointing the wrong way. Copies are counted.
TOUCHEDProblems already in the files the work edits or uses, marked pre-existing, with fix first, fix now, or record as debt. Nothing outside those files.
DEFERREDSteps that say "research" or "TBD": answered from the repository when it can, otherwise tracked, and NEEDS INFO when they block the core of the plan.
FITInfrastructure, complexity or time the project doesn't need, judged by what you told the agent, the plan,
.grump and the docs. Something you said in the chat counts even if it was never written down. It never makes a real bug less serious.GRUMP REVIEWREVISE
REVISE - step 3 edits a batch's private rows, so credits change what Ledgerly receives but never reach the database.
GD-001 HIGH NEW
Where: plan step 3; src/invoices/batch.ts:30-44. commit() writes only status, so the CSV shows the gross amount while Ledgerly holds the net. Fix: add an InvoiceBatch method, or send credits separately.
GD-002 MEDIUM NEW (pre-existing)
Where: src/export/nightlyCsv.ts:21. Divides every amount by 100, so JPY is 100x too small. The plan edits this loop: fix it in this change with formatMinor().
Ledger: .grumpydev/reviews/docs-plans-credit-notes-md.md
The ledger
Each reviewed target gets .grumpydev/reviews/<target>.md: a table of issues with severity, status, the condition that closes each one, and a dated entry per review. History is never deleted.
Problems that predate the work go in .grumpydev/reviews/project.md instead, with stable IDs. A later plan that touches the same file inherits them instead of rediscovering them, and fixing one closes it everywhere. Run Grump this project once to seed it with a full audit of boundaries, duplicated rules and the fix history behind them.
Verdicts
APPROVE
Nothing material is wrong.
APPROVE WITH CONCERNS
Sound work; named concerns, often pre-existing.
REVISE
Fix the HIGH issues first.
REJECT
The approach cannot work.
NEEDS INFO
Undecided questions block the core of the plan: do the discovery first, then plan on the answers.
The rulebook
.grump
Your project's rules, in a file you own. Reviews judge the work against it: they never suggest changing a pin, never re-argue a settled decision, and report known debt only when new work spreads it.
Pins, constraints, decisions and boundaries are copied into a marked block in each agent context file you choose, so the agent writing the code follows them before any review happens.
.grumpYOURS TO EDIT
# Project doctrine
## Purpose
Customer invoice portal for one client.
## Platform pins
- PHP 7.4. The client's licensed ionCube module only
loads on 7.4. Local Docker runs 8.2 for convenience.
## Constraints
- The vendor's SOAP billing API is mandatory.
## Accepted decisions
- Deployment is an FTP upload. No containers.
## Boundaries
- Money rules live only in src/Money.php.
## Known debt
- src/Legacy/SoapGateway.php: no timeouts.
## Settings
- Ledger: on