external-gitcode-ascend-ascendc-operator-code-review

Ascend C Code Review Skill

Core Principles

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

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
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:

Clearly notify the user which parameters are missing
Abandon execution of the review
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
User directly specifies a path → use the specified path

Review Process (Hypothesis Testing Driven)

Phase 1: Preparation

Validate whether the required parameters are complete
Read the coding specification file according to the review rule description or specified path
Confirm the code snippet to be reviewed

Phase 2: 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 search for evidence by dimension:

Evidence Type	Analysis Action	Scoring 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 context defense	Check whether there is defensive code within the scope	No defense +30%
Function call chain risk	LSP/Grep analyzes the internal logic of the called function	Risk found +25%
Data flow tracing risk	Analyze variable sources and computation process	Risk found +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, use Grep to find dependency relationships
Risky code must be checked for defensive measures elsewhere within the current file scope
When encountering a function call, the function's internal logic must be examined and judged comprehensively
When encountering a risky struct or member variable, its definition and computation process must be examined

Step 4: Evidence validity verification

Eliminate false positives:

Effective defense already exists elsewhere in the scope → exclude
The context proves the risk cannot be triggered → exclude

Step 5: Decision making

Calculate 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

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

Notes

Please first read the corresponding coding standard files in full, and conduct the code review according to these standards; nothing else is counted
During the review process, if a questionable code block contains function call behavior, LSP tools or search tools must be used to achieve in-depth analysis
For uncertain coding standard issues, list them in the output report as questionable items for the user to judge independently
The problematic code listed in the review report should not be too long; clearly describing the problematic code is sufficient
When returning the review results, the line numbers of the risky code lines in the results must be carefully checked for correctness
When returning the review results, all risky code blocks should be cited; do not show only a single line number

About this skill