ack-code-review

Ack Code Review

Continue advancing remediation based on the code review report. The responsibility of this skill is not to initiate a complete review again, but to consume existing review conclusions, make technical judgments item by item, and fix the issues that should be adopted to a runnable, verifiable, real implementation state.

Core Objectives

Complete the following closed loop:

1. Read the review report
2. Split each review issue
3. Judge whether each item is adopted
4. Perform incremental fixes for adopted issues
5. Give clear technical justification for non-adopted issues
6. Output remediation results in a fixed structure

Applicable Scenarios

Prefer to use in these scenarios:

• The user requests "fix according to code review"
• The user requests "continue remediation according to the review report"
• The user provides review Markdown and wants to decide which opinions to adopt and implement
• The user emphasizes that the current code has already been partially fixed and wants to continue fixing on the existing basis
• The user requests continuing transformation according to the implementation plan and review basis, rather than improvising

If what the user wants is "do a review again", do not use this skill; switch to a review-initiation skill.

Input Parsing

Prefer to read $ARGUMENTS：

1. If $ARGUMENTS is a file path, read the file directly
2. If $ARGUMENTS is a piece of Markdown or text, treat it as the review report content
3. If $ARGUMENTS is empty, first infer candidate review reports in the repository, then confirm with the user

When the user does not provide a review report, do not directly assume that a certain file is the target. Prefer to infer candidates by file semantics:

• Markdown files that were recently added or recently modified and whose filenames contain review、code-review、findings、audit Markdown file
• Markdown or text files with similar semantics such as review reports, remediation records, audit conclusions, etc.
• If common directories exist in the repository, such as docs/reviews/、reviews/、review/, then use these directories as supplementary candidate sources

After inference is complete, give the user a brief confirmation, for example:

我找到了候选审查报告 A/B，默认建议使用 A。请确认。

Continue only after the user confirms.

Working Principles

Always comply with the following constraints:

1. Incremental modification, do not overturn and rewrite
2. Every change must align with the implementation plan or review basis
3. It is forbidden to use TODO, stub, mock, or empty branches as placeholders
4. Do not skip issues in the review because they are complex
5. Continue advancing based on the current code state as the baseline, and do not erase existing fix results
6. After fixing, verify; do not stop merely at completing code edits

If the prompt given by the user conflicts with the current code state, take the current repository facts as authoritative and explain the conflict clearly.

Step 1. Establish remediation context

First collect three types of input:

• review_report: the review report itself
• implementation_basis: implementation plan, design document, requirements description, acceptance criteria
• code_scope: the modules, directories, branches, or diff scope involved in the current changes

Processing order:

1. First read the review report
2. Then find the implementation basis
3. Narrow down the code scope

If the user has not explicitly provided an implementation approach, do not stop immediately. First infer from the following sources:

• The approach mentioned in the user's current session
• Design documents, planning documents, and requirements documents in the repository
• The goals, constraints, and acceptance requirements cited in the review report

If a complete implementation basis still cannot be found:

• You can continue to handle those review issues that "can be judged based only on code correctness"
• For issues that clearly depend on approach judgment, mark them as "to be confirmed" and explain in the output that the basis is insufficient

Step 2. Break down review issues one by one

Break the review report into atomic issues; one issue should express only one judgable and actionable point.

For each issue, extract:

• Number or title
• Original description
• Severity level
• Location information
• Suggested modification approach
• Associated implementation approach constraints

If the review report is written in a scattered way, proactively organize it into an "issue list"; do not copy an entire vague paragraph and start modifying code.

Step 3. Decide whether to accept

After reading references/decision-rules.md , make a three-way decision for each issue:

• 采纳
• 不采纳
• 待确认

Judgments must be based on evidence, not on catering to the review's tone.

Acceptance criteria

The following situations should usually be accepted:

• The review points out a real bug, boundary error, missing test, or risky implementation
• The current implementation is inconsistent with the approach, requirements, or existing architectural constraints
• The review points out issues that affect correctness, stability, or maintainability
• Although the review comment is not expressed precisely, the core issue holds

Non-acceptance criteria

The following situations are usually not accepted:

• The review is based on a misreading, and the code already satisfies the requirement
• The suggestion conflicts with the implementation approach, project architecture, or explicit constraints
• The suggestion would introduce greater damage, while the issue itself does not exist
• The review is only a style preference and brings no clear benefit

To-be-confirmed criteria

Only in these situations should it be kept as 待确认：

• Key context is missing, making it impossible to judge safely
• Review comments conflict with each other
• Whether to accept depends on business rules, and there is no evidence in the repository or session

Do not push all issues that should be judged on your own to the user.

Step 4. First provide a remediation plan, then start modifying code

Before actually modifying files, first organize a brief remediation plan, at least explaining:

• Which issues are planned to be accepted this time
• Which modules each issue will modify
• Which issues are explicitly not accepted, and why
• Which issues are temporarily to be confirmed, and what information is missing

If the change span is large, prioritize fixing the highest-risk issues first.

Step 5. Execute incremental fixes

Only modify code for issues that are "accepted".

When fixing, comply with the following requirements:

• Minimize changes based on the current implementation
• Prioritize reusing existing abstractions, tests, and module boundaries
• When multiple files are involved, complete the structural adjustment in one pass
• Do not leave half-finished logic
• If you find that the root cause of a review item is deeper than what the report states, fix it along the root cause as well.

If an issue has already been partially fixed, do not redo it in an overwriting manner; complete the remaining gaps on top of the existing fix.

Step 6. Verify the fix results

After completing the changes, you must run verification directly related to the changes:

• Unit tests
• Integration tests
• lint / typecheck
• Verification of the minimal reproducible scenario

Choose the most probative verification method based on the actual changes; do not mechanically run everything, and do not skip running anything at all.

If verification cannot be executed due to environment constraints, explicitly state the unverified items and the reasons.

Step 7. Output according to the fixed structure

The final output must use the following structure, and the content must retain only information directly relevant to this task.

1. Modification description

• List item by item which review issues were resolved this time
• State which part of the implementation plan each item corresponds to; if there is no complete plan, explain where the basis comes from
• Whether structural adjustments are involved; if so, explain the reasons for the adjustments
• Which issues were not adopted, and the technical reasons
• Which issues still need confirmation, and the missing context

2. Code modifications

• Explain the files that were changed
• Summarize the modification points each file is responsible for
• If the user explicitly requests that the complete code be shown, then provide the complete runnable code grouped by file
• By default, do not paste the full text of extremely long files in the conversation; prioritize giving file paths and modification descriptions

3. Self-check

Confirm item by item:

• All review issues have been covered
• There are no placeholder implementations
• Consistent with the implementation plan
• No new issues introduced

If any item cannot be checked off, the reason must be explained.

Conflict handling

When encountering the following conflicts, do not stop at the surface:

1. The review report conflicts with the implementation plan
2. The review report conflicts with the current code facts
3. Different review opinions conflict with each other

Handling method:

• First point out the conflict
• Then explain the basis for your judgment
• Continue fixing within the determinable scope
• List the parts that cannot be determined separately, rather than shelving the entire ticket

Output style

• Direct, restrained, execution-oriented
• Give the conclusion first, then the evidence
• Do not write irrelevant background buildup
• Do not describe "which opinions were adopted" as "already completely finished" unless there is verification evidence to support it

Prohibited items

Do not do this:

• Treat the review report as absolutely correct and accept all of it without judgment
• Overturn and redo upon seeing that a partial fix already exists
• Use "leave a TODO for now" as a substitute for a real implementation
• Skip issues because multiple files or structural adjustments are involved
• Claim the fix is complete without verification
• Without user confirmation, arbitrarily choose a guessed review report