Code that type-checks and passes lint can still render a blank white screen, and an agent that stops at the compiler will tell you it’s finished anyway. My forge command says so in the middle of its visual check, in bold: the phase exists because agents repeatedly skip visual verification and declare success based on compilation alone.
/forge is the command I wrote to close that gap. It turns Claude into a tech lead who answers for production-ready, tested code, and it runs as a loop of plan, execute, verify, test, scrutinize and fix, over and over, until the work meets the standard or a question comes up that only I can answer.
Before any code
The first pass opens with a requirements conversation that Claude can skip only for a bug fix with an error message or a one-line change. It has to play back what it thinks I want and ask about the users, the edge cases, the systems the change touches, what it should leave alone and any performance or security needs. Then it writes a scope manifest, a checklist of every behavior I asked for, and that list becomes the contract for everything after it. Nothing gets built until I approve the plan and the manifest.
Inside each pass
Every iteration runs the same phases in order, and a failing phase gets fixed and re-run before the loop moves on. Type checks run after every three or four files so unverified code never piles up, lint errors get fixed with the rules left switched on, and then the build has to pass before the one phase the command marks as impossible to skip.
That visual check opens every affected page in a real browser, signs in the way the repo’s own instructions describe, and logs whether the page loads, whether the console shows JavaScript errors, whether the new interface is actually there, whether buttons and forms work when clicked and whether the layout holds together without raw tokens showing where text should be. Claude has to take a screenshot or describe what it sees, because “it looks correct” doesn’t count as evidence, and an empty or N/A entry for a change that touches the interface counts as a failed phase.
After that comes an audit for critical dependency vulnerabilities, then unit tests with coverage on every file changed in the session. When a test fails, the instruction is to fix the code and leave the test alone unless the test itself is wrong, and assertions written only to game coverage don’t count. Integration and end-to-end tests follow, and when a user-facing change has no end-to-end test, Claude writes one. My three reviewer agents then go over the work in parallel, and any must-fix finding they raise sends the work back to the build phase. The documentation gets updated and read back against the code.
No quiet deferrals
The last phase re-reads the scope manifest item by item and marks each one done, partial or not started, and anything short of done becomes a must-fix for the next pass. Claude can propose leaving something out of scope, but it has to ask, and I make that call. The command also names the excuses it won’t accept, among them “it’s probably fine” and “the test is flaky”, and the answer to the second one is written right into it: then fix the flake.
When it stops
The loop ends only when every gate passes and the completion checklist is satisfied, when a question comes up that only I can answer, or when something outside the work is broken, such as missing credentials or an infrastructure outage. If five iterations go by without converging, it stops and shows me the full history, since by then the approach needs my judgment more than another round of fixes.
Progress goes into a forge-state.md file in the repo that git ignores, with every iteration’s changes, test counts, browser findings and the reviewers’ verdict, so running /forge continue picks up exactly where a session left off.
One forge skill per repo
The command is about 21 KB of instructions, last revised in June 2026. Each repo gets its own forge skill listing the exact command for every gate, and /forge treats that file as the authority and won’t improvise around it. Today it recognizes three of my repos by name and asks which context to use anywhere else, so pointing it at a new codebase starts with writing that codebase’s forge skill.