SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsarkweb-security-patch-review

arkweb-security-patch-review

Security & auditing

View repository

Updated 10-16 07:28

About this skill

ArkWeb Security Review

Used for arkweb-security-patch-reviewer and arkweb-security-patch-judge。

To review blocking boundaries, whether manual rewrites can be allowed through, and how non-active issues are handled, first read the references/patch-landing-review-contract.mdwithin this skill. Do not reference scripts or md from other skills.

Review focus

  1. Whether the given patch in the active batch has actually been merged into the current project target git sub-repository.
  2. Whether the final changes cover the target modified files and key diff semantics of the given patch.
  3. Whether there are unresolved conflicts, empty diffs, merging into the wrong repository/wrong files, out-of-scope changes, or obvious omissions of key hunks.
  4. Whether the manual rewrite is still within modified_files[] or the scope allowed by the merge report.

Blocking boundaries

The code review stage only adjudicates "whether the given patch in the active batch is merged". Only the following situations can be blocking issues:

  • The given patch was not applied, or the final diff is empty.
  • Key hunks, key files, or key semantics are missing.
  • Changes exceed modified_files[] or the scope allowed by the merge report.
  • Merged into the wrong repository, wrong files, or the target sub-repository does not match.
  • Unresolved conflicts exist.

The following situations are not issues at this stage and must not be used as blocking or fail reasons:

  • git apply After failing due to context drift, within modified_files[] complete the minimal manual rewrite within scope.
  • Concerns about semantic drift caused by manual rewrites, but without concrete evidence proving that the key semantics of the given patch are missing.
  • Missing compilation or runtime evidence because the compilation stage has not yet been entered.

If blocking is to be determined, it must directly point to evidence that "the given patch was not merged", such as missing hunks, missing key files, unresolved conflicts, or merging into the wrong repository.

In batch mode,terminal_failed and deferred_for_archive issues have already exited the active batch. Code review can only list them as archived/legacy items in the overview, cannot count them into blocked_issues, cannot output issues that need to return to "Conflict Resolution", and cannot fail the entire batch because of these issues. As long as pending_current_stage is empty and there are still ready_for_next issues, the review adjudication must allow the ready batch to proceed to "Compilation Verification".

Hard limits on review scope

  • Only review the files actually modified by this patch; the file list should come from the merge report, conflict resolution report, compilation fix report, or an explicit diff of this patch.
  • Before review, must read the 06_merge_result.mdoutput by the automatic merge stage; in batch mode, must also read issues/{issue_id}/06_merge_result.mdfor each issue one by one. After automatic merge pass , these files should already exist; if missing, must mark as artifact_missing:06_merge_result, and must not assume the patch has been merged.
  • In batch mode, must review each issue one by one, reading issues/{issue_id}/06_merge_result.md、issues/{issue_id}/07_conflict_resolution.md、issues/{issue_id}/10_build_fix.md and the git diff belonging to that issue in the current project target sub-repository.
  • In batch mode, using git worktree is prohibited; changes, risks, and conclusions of different issues must not be mixed together.
  • Other historical dirty changes, untracked files, SDK, toolchain, build artifacts,src/out、.ace-outputs and unrelated deletions in the workspace must be ignored.
  • Must not fail because of unrelated dirty changes, must not require cleaning up unrelated files, and must not include unrelated dirty changes in this fix suggestion.
  • If it cannot be confirmed whether a file belongs to this patch, it must be listed as "to be confirmed" and must not be included in the review scope by default.

Output

Single-issue mode review steps are written to .ace-outputs/{runId}/08_code_review.md。

In batch mode, each active issue is written to .ace-outputs/{runId}/issues/{issue_id}/08_code_review.md, and the overview is written to .ace-outputs/{runId}/08_code_review.md. The overview may only summarize and must not replace the independent review conclusion for each active issue. Non-active terminal_failed / deferred_for_archive issues are only included in the archive list.

Prefer stable scripts

Prefer using built-in scripts to generate code review artifacts; do not assemble temporary Python/Node/Shell scripts at runtime:

python3 skills/arkweb-security-patch-review/scripts/generate_code_review.py \
  --run-root <context.projectRoot>/.ace-outputs/<runId>

The script reads batch_status.json、06_merge_result.json and issues/{issue_id}/06_merge_result.json, writes issues/{issue_id}/08_code_review.mdfor each active issue, and writes the root-level 08_code_review.md and 08_code_review.json. The script only aggregates active/ready/pending issues;terminal_failed and deferred_for_archive only enter the archive list and do not participate in verdict。

After the script runs, the agent reply may only contain:

  • a one-sentence result summary;
  • artifact paths;
  • the last complete JSON code block.

Do not paste script source code, complete tool output, large blocks of 06_merge_result content, or the complete diff in the reply. Detailed evidence is only written to 08_code_review.md/json。

Both the review step and the adjudication step must output the last complete JSON code block at the end of the reply. Do not output truncated JSON containing only remaining_issues ;next_state and issues cannot be omitted.

{
  "verdict": "pass|fail",
  "next_state": "编译验证|冲突解决",
  "issues": [],
  "summary": "一句话总结"
}

JSON decision rules:

  • When the active batch has no blockers,pending_current_stage=[] and there are ready_for_next issues, output verdict=pass、next_state=编译验证、issues=[]。
  • Only when there is evidence in the active batch that a given patch was not actually merged and needs to return to minimal manual writing, output verdict=fail、next_state=冲突解决, and list the specific active issue blocking evidence in issues[] .
  • terminal_failed / deferred_for_archive issues may only be written to the archive list and must not be written to JSON issues[], and must not affect verdict。