ascendc-operator-code-review

Ascend C Code Review Skill

Core Principles

1. Compliance First - All review actions are mapped to specific clauses of the coding standards, with 100% coverage and no omissions
2. Auditable and Reusable - The entire review action process is logged
3. Concise and Efficient - The review report is structured, clear, and concise

Invocation Interface

Required Parameters

When invoking this skill, the following parameters must be explicitly provided:

Parameter 1: Code Snippet

• The code content to be reviewed
• It can be a function, code block, file content, etc.

Parameter 2: Review Rule Description

• Explicitly specify the type of issue to be reviewed
• For example:检查整数溢出、检查内存泄漏、检查空指针解引用, etc.
• Or specify a specific specification file path

Parameter 3: Specification File Path(optional)

• Specify a specific coding specification file path
• If not specified, the corresponding specification file will be found based on the review rule description

Parameter Validation

If any required parameter is missing, you should:

1. Clearly notify the user which parameters are missing
2. Abandon the review execution
3. Prompt the user to provide complete parameters

Specification File Reference

When the user specifies a review rule description, match the specification file according to the following rules:

• 数值运算、溢出、除零 → references/01_numeric_operations.md
• 内存、指针、越界 → references/02_memory_pointer_safety.md
• 资源、泄漏 → references/03_resource_management.md
• 输入、验证 → references/04_input_validation.md
• 并发、线程 → references/05_concurrency_safety.md
• 算子接口、Runtime、Tiling、动态Shape → references/06_operator_interface.md
• 接口兼容性、ABI → references/07_interface_compatibility.md
• The user directly specifies a path → use the specified path

Review Process (Hypothesis Testing Driven)

Phase One: Preparation

1. Verify whether the required parameters are complete
2. Read the coding specification file according to the review rule description or the specified path
3. Confirm the code snippet to be reviewed

Phase Two: Hypothesis Testing (Core)

Step 1: Code Segment Identification

Divide the target code into independent code segments (functions, statement blocks, logical units)

Step 2: Hypothesis Establishment

Establish a hypothesis for each code segment:

• Null Hypothesis H0: This code segment is safe
• Alternative Hypothesis H1: This code segment has risks
• Confidence Value Initialization：0%

Step 3: Evidence Collection and Evaluation

Systematically seek evidence according to dimensions:

Evidence Type	Analysis Action	Score Rule
Red-line specification violation	Identify serious violation points against red-line specification clauses	Valid evidence +40%
General specification violation	Identify violation points against general specification clauses	Valid evidence +20%
Missing contextual defense	Check whether there is defensive code within the scope	No defense +30%
Function call chain risk	Use LSP/Grep to analyze the internal logic of the called function	Risk found +25%
Data flow tracking risk	Analyze variable sources and computation processes	Risk discovery +25%

• When providing evidence of numerical operation types, clear risk operation cases must be provided (such as overflow, out-of-bounds, wraparound, etc.)

Analysis requirements：

• Use LSP to obtain symbol definitions in the code, and use Grep to find dependencies
• Risk code must be checked for whether defense is performed elsewhere within the current file scope
• When encountering a function call, the internal logic of the function must be examined and judged comprehensively
• When encountering a risky struct or member variable, the definition and computation process must be examined

Step 4: Evidence validity verification

Rule out false positives:

• Effective defense has already been performed elsewhere in the scope → Exclude
• The context proves that the risk cannot be triggered → Exclude

Step 5: Decision-making

Calculate the confidence value and make a decision:

• Confidence value = Σ valid evidence scores
• Decision rule: When the confidence value exceeds 60%, determine that the code segment has a risk and proceed to report generation; otherwise continue checking the next code segment

Phase 3: Report generation

1. Generate the report according to the code review report template format
2. Before each issue detail, display the hypothesis testing process (evidence chain and confidence value calculation process)

Notes

1. Please first read the corresponding coding specification file completely, and conduct the code review according to these specifications; nothing else is counted
2. During the review process, if there is function call behavior in a questionable code block, LSP tools or search tools must be used to achieve in-depth analysis
3. For uncertain coding specification issues, list them in the output report as doubts for users to judge independently
4. The problematic code listed in the review report should not be too long; clearly describing the problematic code is sufficient
5. When returning the review results, the correctness of the line numbers of the risky code lines in the results must be carefully checked
6. When returning the review results, all risky code blocks should be referenced; do not display only one line number

Output specification

The review report must include

1. Review category
2. Risk point list (including line numbers and code snippets)
3. Evidence chain (displaying the hypothesis testing process)
4. Suggested fix

Output format

See: agents/ascendc-ops-reviewer/style/code_review_summary_style.txt