M07-L04 — Build the review skill and handoff

Recording transcript

A useful review procedure finds supported correctness issues and leaves clean work alone. In this lesson, we will evaluate the firmware-review skill and write a concise handoff. Start with checkpoint eight. It contains the second skill, normal and fault policy, synthetic replay, and basic assertions. The capstone's thresholds and commands are still future work at this stage.

Open the firmware-review skill under dot agents, skills, and firmware-review. Read the description before the body. The task is a bounded review of embedded firmware or shared C++ policy for actionable correctness issues. It is not a request to rewrite the entire repository or perform an unrelated security audit. A clear boundary makes both selection and output easier to evaluate.

The procedure begins with the exact diff, nearby callers, applicable requirements, and relevant evidence. It examines timing, invalid input, stale data, recovery, bounds, conversions, and useful tests. These are inspection lenses. The reviewer does not need to invent one finding in every category. A clean diff can legitimately produce no supported correctness issue.

A finding should name a file and location, a concrete trigger, the resulting consequence, and a check or source that supports it. A vague warning about timing is difficult to act on. A statement that a last sample remains current after its age exceeds the freshness limit identifies a behavior the engineer can reproduce. The report should also distinguish executed evidence from a prediction.

We will use the supplied stale-policy defect. Keep checkpoint eight active in a checkout cloned from the history bundle so the review skill remains available. Inspect the bounded difference from checkpoint seven to the fault-stale tag using the command in the written lesson. That diff changes the polling expiration path. We are reviewing it without switching away from the checkpoint containing the skill.

This setup detail matters. The fault-stale snapshot is based on checkpoint seven and does not itself contain the second skill. A skill file cannot be discovered in a folder where it is absent. Keeping checkpoint eight active while supplying the exact fault diff makes the review reproducible. Execute the faulty source later in a separate exercise copy so the review workspace remains preserved.

Ask for review without repair. The requirement says that a sample from timestamp one thousand is still current at four thousand but stale at four thousand and one. The mutation disables expiration, leaving the cached reading current when it should be unavailable. The expected finding connects that trigger to the polling path and output consequence. It does not merely complain about formatting.

Inspect the actual response independently. Follow its file reference and compare the claim with the requirement. If the tool ran a reproducer, preserve the command and result. If it reasoned from source alone, label the consequence predicted until tested. The expected finding described in this lesson is an acceptance criterion, not a substitute for the response your run actually produced.

Now evaluate a clean case in a disposable copy. Consistently rename a local variable without changing behavior and ask for a bounded review. First confirm that your rename is actually consistent. The desired reviewer behavior is an accurate assessment, not a compulsory defect. A report that invents a correctness problem to fill its format is a finding about the review procedure.

For the unrelated case, start a fresh task and ask for a small README sentence improvement without changing firmware. Do not name the review skill. This checks whether ordinary documentation stays outside the firmware-review procedure. Explicitly selecting the skill would change the test and make unwanted implicit activation harder to evaluate.

Record selection and output quality separately. When the interface exposes a skill read or activation, keep that evidence. If it does not, avoid inferring selection solely from the shape of the answer. You can still evaluate whether the output was useful and supported. Unknown selection should remain unknown rather than becoming an invented pass.

After these cases, write a short handoff. Name the active source, completed work, actual receipts, open questions, and one bounded next action. The supplied checkpoint-eight handoff asks for a negative-infinity assertion that leaves production behavior unchanged. It is a useful restart task because the requirement already exists and the expected change can remain small.

If you already added that assertion while extending the testing chapter, use a fresh checkpoint-eight copy for the restart exercise. Duplicating the same test would not demonstrate new behavior. A preserved starting state also makes it easier to compare what the fresh session discovers and changes without relying on the old conversation.

The review procedure also preserves action boundaries. Reading a diff and identifying a defect does not automatically request a repair, upload, or remote publication. If the task is review-only, report the supported finding and its verification status. Runtime permissions still govern available operations; a sentence inside the skill cannot grant capabilities that the environment does not provide.

Your submission contains the skill version, defect review, clean review, unrelated task, and handoff. Preserve actual prompts and results. A static format check can confirm that the skill package is well formed, but it cannot establish runtime selection or a supported review finding. Keep those evidence categories distinct in the final note.

Pause here to complete the cases and handoff. If a weakness appears, make one repair that addresses the observed cause and repeat the affected cases. A narrower description should still select relevant reviews. Stronger evidence wording should reduce unsupported findings without hiding genuine defects. Keep the failed attempt so the improvement can be assessed.

You now have a second reusable procedure with a practical evaluation set. Its value comes from helping you inspect a bounded change and preserve evidence, not from producing many findings. In the next lesson, a fresh session will use the repository handoff to complete one small test change and show whether this context can carry useful work across a conversation boundary.

Download transcript