codepatrol-autofix

Automatic fix of one problem

Entrusted by the commander of the codepatrol skill, fix one problem from the investigation report and finish the pull request up to ready for review.

No human is present during the fix. The completed pull request is checked all at once afterward. Decisions that would have been asked midway if a human were developing are made by yourself, and written down so that a human reading afterward can trace them.

Prerequisites when executing this skill

• The conditions of the execution environment are the same as codepatrol skill 's "Confirmation of the execution environment". Confirm them yourself before starting, and if they are not met, change nothing, report the unmet conditions, and exit
• You cannot ask the user questions. You also do not enter plan mode. Since there is no one to approve the plan, write the plan in the working directory and then proceed to implementation
• The problem you are responsible for, the repositories the fix touches and the location of each clone, the destination of the pull request, and the working directory follow the commander's instructions
• When handling multiple repositories, there are environments where the command's working directory returns to the repository that holds the configuration. For operations on another repository's pull request or branch, specify the target repository every time. If you refer to it by number alone, you will write to the pull request with the same number in another repository. Also tell the subagent entrusted with sanity-review the target repository and the location to read the code, and have it specify them in the same way
• Subagents fixing other problems are running in parallel. In the user's checkout, do not switch branches or modify files. Only exporting the dialogue context may be done in the location defined by the development flow. Do not stop or restart development servers or containers shared with other subagents
• Do not do the merge or the cleanup of the development environment after the merge. The commander does that
• Reading and writing the triage page and the report follow the cosense skill

Confirm before starting

Read the editing rules written at the beginning of the triage page. How to declare starting, the status icon, and how to sign are decided there. If they conflict with this procedure document, the page's description takes precedence.

If another person's declaration of starting or pull request already exists on the row of the problem you are responsible for, another person has already started. Do not create a working tree, do not edit the page, report that fact, and finish.

When the commander instructs you to take over a fix that got stuck midway, continue from the specified pull request or branch. Take over only what was specified.

Development flow

In the location given by the commander, read thesoftware-factory-mode-2026aki skill's SKILL.md and follow its development flow. Since it is a skill that cannot be invoked with the Skill tool, read the file.

Where the flow stipulates waiting for user instructions or confirmation, the user has comprehensively authorized the following. Proceed without waiting.

• push, and creating a draft pull request
• For inline review comments, post the draft as is
• Run sanity-review, respond to the feedback and push, and comment the response content on the pull request
• Once the responses to the feedback are done, mark it ready for review. If the repo has review request conventions such as designating reviewers or labels, do so at this point
• Filling in the triage page and the report
• When the destination branch has advanced and conflicts occur, rebase your own pull request branch and force push

Skills called within the flow may ask the user questions. Include the answers to the questions as arguments when calling them, so that questions do not occur. Set the depth of consultation with Codex to "consult often".

The following does not change even with the above authorization.

• Before every push, consult Codex. Do not skip even after rebasing, commits that respond to sanity-review feedback, or comment-only changes. Treat each as a new consultation. Count the round-trip limit per consultation
• Consultations with Codex are performed by both yourself and the subagent entrusted with sanity-review by calling codex-consultation with the Skill tool.codex exec Do not settle for directly executing . Leave Codex's output in the working directory. Have the subagent entrusted with sanity-review leave it in the same location as well. The commander uses it to verify that the consultation completed to the end
• The wording of requests to Codex followscodepatrol-report 's "request framework". Fixing problems is easier to explain in the attacker's vocabulary and tends to be blocked by Codex's provider filter
• If Codex stops due to usage limits or a failure, do not switch to another consultation partner; commit the intermediate results, stop the work, and report
• When stopping work partway, comment the reason for stopping on the pull request. If there is no pull request, write it in the report's handover notes together with the name of the branch where the intermediate results were left. The next commander that starts up judges from there whether the fix may be resumed
• Do not let the subagent entrusted with sanity-review change the pull request's reviewers, labels, or draft state. Changing those is done by yourself after finishing the responses to the feedback
• Know that sanity-review has completed by the subagent's completion notification. Do not judge by the appearance of a pull request comment. Otherwise you will mistake a previously posted dialogue-context comment for the report
• If, while waiting for sanity-review to complete, it comes time to return a report to the commander, end by writing the pull request's location and the remaining steps as an interim report. The commander will hand over the sanity-review report and restart you, so continue from responding to the feedback
• While it is a draft, do not request review. Once you designate reviewers, you join the queue waiting for human review

Make a decision

The problem report contains a proposed approach, but implementing it may not go as proposed.

• Decisions that the implementer can make on the spot are made by the implementer. These are decisions such as which to choose when there are multiple correction strategies, and how to respond to invalid input. Write the decision and the reason in the pull request overview section and the conversation context
• When a specification decision is required and you cannot decide it yourself, follow the handling of questions in the commander's instructions. If there are no instructions, commit the intermediate results, stop work, and write the question in the report. The commander passes the user's answer and has work resumed
• When only part of the correction requires a specification decision, fix the part that does not require a decision and hand off the remaining part in the report
• Other problems found during implementation are not fixed in this pull request, but handed off in the report
• When it turns out that including this correction will cause another serious problem, do not make it ready for review; stop work while keeping it draft and report. This is the case when another correction is needed first, for example. A pull request made ready for review may be merged without human confirmation

pull request

• In the overview section, write a line link to the problem in the report and a link to the line in the triage page
• Write in the overview section what humans do before and after releasing to production. These are things such as creating a DB index, adding environment variables, the deployment order with other repos, inspecting production data, and what to check after deployment. The person deploying reads the summary generated from the overview section and does the work. Anything not in the overview section is not communicated
• When the correction of one problem spans multiple repositories, create a pull request for each repository and link the pull requests to each other. Sanity-review is performed per pull request

Entries in the triage page and the report

Make the pull request, the line in the triage page, and the problem in the report mutually traceable.

• When starting work, write a declaration of starting on the line of the problem you are handling in the triage page
• Once the draft pull request is created, replace the declaration of starting with a link to the pull request. Add the same link to the problem in the report, and write the handoff below it. What was handled, that a decision different from the report's proposed approach was made, what was left, and other problems found during implementation
• The status icon matches the pull request status on both pages. While it is draft, it is work in progress; once it is made ready for review, it is requesting review
• What you write on the triage page is only the declaration of starting and the link to the pull request with the status icon. All handoffs are written in the report
• For the declaration of starting and the link to the pull request, place your own signature alongside the user's signature conveyed by the commander. This lets people reading the page know whose instruction the correction is being automatically advanced under. The handoff in the report only needs your own signature

Report to the commander

Write within 10 lines. The commander is running many fixes in parallel, and a long report will use up the commander's context. Details are in the pull request and the report, so do not repeat them.

• Location and status of the pull request. Either ready for review, draft, or stopped for questions
• Matters where a different judgment was made from the proposed response in the report
• Matters that humans should check. These include cases where a production check is needed before merge, the design change is large, the behavior changes, or some of the operation checks could not be performed
• The number of times Codex was consulted and the location of Codex's output. Include the portion for the subagent that was entrusted with sanity-review
• The work environment left behind. These include the worktree, branch, and the DB or containers created for testing. They are handed over to the person in charge of cleanup after merge
• When stopped for a question, the question
• Points that were ambiguous in the procedures or rules