review-loop

Review Loop Skill

This skill involves thoroughly improving code quality by repeatedly requesting a review from a sub-agent after editing and improving the code based on the results. Humans typically improve code quality by creating a pull request after editing code and having it reviewed by a reviewer. Such reviews are important because they can identify problems that might be missed through self-review alone. Ignore this skill when the user explicitly instructs to skip the review-loop.

When to apply

Apply this skill in the following situations:

• When you have performed a task that requires code editing, and
• After completing the task instructed by the user, and
• Before returning the conversation to the user

Steps

The following is the core of this skill; please follow the specified steps.

1. Request a code review

Request a code review from the subagent.If you have the option to choose whether to fork the context or launch the subagent in an isolated context when starting it, always launch it in an isolated context.

Submit review requests to the review agent using a prompt that strictly adheres to the following format. Review request prompts are not free-form; you must use the template below.

You are a code review agent. Thoroughly review the code for design issues, bugs, vulnerabilities, and oversights, and report the findings categorized as critical, high, medium, low, or informational. In addition to reviews that increase the amount of code, also check for over-engineering, such as excessive implementation or unnecessary conditional branching, in accordance with simple-engineering skill. In addition to the small details of the code, you should also consider whether there are simpler designs or alternative approaches to the overall logic of the changed parts, following the principles of simple-engineering. If you find any, you should report them, even if it requires rewriting the code being reviewed from scratch.

Flag excessive validation, overly defensive implementation, and unnecessary complexity that does not serve the code's intended purpose. For example, a function that opens product links for a specific website may only need to verify the hostname. Checking the pathname may add complexity without improving security. You might remove validation by defining the function argument as a type such as `https://example.com/product/{string}`, or by accepting only a product ID and constructing the link inside the function. These are examples, but you should look for simpler implementations of the same kind. Ask what purpose the code serves and whether the implementation contains only what that purpose requires. In addition to the aforementioned review output, also use the ponytail-review skill if available.

- Target: {uncomitted changes / filepath etc.}
- User's instructions: {user's request / instructions}