The reviewer reads a change and writes the same report every time. I built it because a review that only reads the summary will miss the file, and a scan of the wrong tree will bless the wrong code.
The week of January 19
The review has to open the files. A summary is not the review. The title uses the date of the change, not the date I ran the report. The report goes in a database I can search, not a folder of pages. The security section says what was scanned and what it found.
The week of February 16
The review got a short command-line path, the same treatment as the other daily tools. The morning session should see the summary. It should not pull the raw report into the conversation.
The week of March 2
A review of the harness itself found 18 issues. I applied the fixes in one commit, and it broke skills that had been working. I reverted the whole commit the same day. One fix, then a real run, then the next fix.
The week of April 6
I wrote down what the automation is for. Every review has the same shape. The security scans run on the change, including when nobody is at the machine. The report is a file I can hand someone, and the same result is stored where I can find it later.
The week of April 13
The skill was one file of about a thousand lines, and a lot of it was one project's paths and one team's habits. I split it so the steps stay in one place and the project notes sit beside them. I ran the new skill next to the old one, and I kept the report shape the same so the comment step and the approve step did not have to change. A block that had already been turned off came out. I did not want a dead instruction riding along.
The week of April 20
The lookup assumed one branch folder name. When the author's folder had a different name, the scan fell through to my branch, so the security tools were reading my packages and not theirs. I changed the lookup to find the author's folder and to refresh it before the scan.
The refresh those steps already named did not exist yet. Every run fell through to a tool that asked to sign in, which fails when nobody is sitting there.
The week of April 27
I wrote the refresh. It can run with a key and nobody at the keyboard, which the older command could not, because I want the morning scan on today's code and not on whatever was last pulled.
The first full pull of my own branch took about 7 minutes. The next one, with nothing new, finished in under 2 seconds.
I looked at a third review skill, with several agents exploring in parallel, and I did not build it. The verify step at the end never called the specialist agents I already have. It called one general pass. The gap is the call, not a new product. That wiring is not in yet.
The week of June 8
A newer, more expensive model is an optional second pass on that verify step. I started a comparison against the default. I did not make it the default. The comparison was not finished, so I am not going to say which one won.
The week of October 5
A review now asks, once, whether a raw SQL statement is the standard for that area or just the shortest way through this one change. It asks on the first statement the change adds or edits, and it names the other lines. That question does not decide the review.
A statement written above the data layer is a separate finding, and I set it at Medium. The general rule for a layer violation is higher. The first draft would have let the same statement be graded both ways, and a higher grade can send the change back. I did not want that coming out of a finding I had already set lower.
Where it is
The steps are split from the project notes. The morning refresh exists, and it has pulled a branch with nobody sitting there. The verify step still makes one general pass. The second model is optional, and I have not picked a winner.