Development
Leave the campground cleaner than you found it
The Boy Scout rule is simple: every change leaves the code a little better than it was. Agents are bad at it in both directions — they either touch nothing beyond the ask or wander off rewriting files nobody mentioned. This package holds the line. The change is scoped and confirmed at a gate before any design; the design is presented and approved at a second gate before any code; and the cleanup is bounded to the files the change already opens.
After implementation, the changed code is reviewed from three angles — an architecture anti-pattern review, the OWASP Top 10 assessment and the Clean Code assessment — with findings classified as blocking, non-blocking, pre-existing in a touched file, or pre-existing elsewhere. Blocking findings are always fixed. A bounded few of the pre-existing ones in touched files are fixed too. The rest become follow-ups, which is what keeps the change reviewable.
Boy Scout Coding
Free
Pro and up · included with your license
Anyone using a coding agent on a codebase they have to keep maintaining. It is the package that shows what approval gates are for: the agent does the work, and the two decisions that matter stay with you.
What runs
The workflows inside
Boy Scout Coding
Six stages, two behind human gates. A scoped change request with acceptance criteria and explicit out-of-scope, confirmed at a gate; a design with approach, rejected alternatives, exact files and contracts, error handling, security, test strategy and risks, approved at a second gate; implementation edit-unit by edit-unit against the project's own build command; a three-angle review; then unit tests iterated until coverage of the changed lines reaches the target, measured from the project's own coverage report.
How a run goes
Step by step, in the order the engine enforces
- 1
Say what needs to change
Free text is fine. The workflow turns it into a change request with acceptance criteria and an explicit out-of-scope list, and stops at a gate until you confirm it.
- 2
Approve the design before a line is written
The agent proposes an approach, the alternatives it rejected, the exact files and contracts it will touch, and how it will test. Nothing is edited until you approve.
- 3
Implement against the build
Each edit unit is verified with the project's own build command before the next begins.
- 4
Review from three angles, fix what blocks
Anti-patterns, OWASP and Clean Code, scoped to the changed lines. Blocking findings are fixed; pre-existing findings in untouched files are recorded, not fixed.
- 5
Prove the coverage
Unit tests are written and iterated until the changed lines reach the target, read from the project's real coverage report — with a gate if it falls short. Nothing is committed; version control stays yours.
What you get
At the end of a run
- ✓A change report: the request, the approved design, what was changed and why
- ✓The modified working tree, uncommitted, with the build passing
- ✓A coverage figure for the changed lines from the project's own report, and a follow-up list of what was deliberately left alone
Read next
Related packages
- Code Quality →
Run a full ISO/IEC 5055 and Clean Code assessment of any codebase with your coding agent, every check its own verified step. Free with every CodyCody plan.
- Security Review →
A source-level OWASP Top 10 assessment and a STRIDE threat model with trust boundaries, built by your coding agent one verified step at a time. Free from Pro.