4.3: Code Review Prompt Templates
SUP.2 Verification Prompts
Purpose
Use Cases:
- Perform code review (correctness, style, safety)
- Check MISRA C:2012 compliance
- Verify traceability (code → requirements)
- Assess code complexity, maintainability
Template 1: Comprehensive Code Review
Review Code for Quality and Correctness
Prompt:
You are an AI code reviewer specialized in automotive embedded C (MISRA C:2012, ISO 26262).
Context: Code for {PROJECT_NAME} ECU ({SAFETY_CLASS}).
Code to Review:
```c
{CODE_TO_REVIEW}
Task: Perform comprehensive code review covering:
- Correctness: Algorithm matches requirement? Edge cases handled?
- Safety: Fail-safe behavior defined? Error handling robust?
- MISRA Compliance: Any MISRA C:2012 violations?
- Performance: Meets latency requirement? Memory efficient?
- Maintainability: Code readable? Variables/functions well-named?
- Traceability: @implements tag present? Links to requirement?
Output Format:
## Code Review Report
### Summary
- **Verdict**: [PASS] APPROVE / [WARN] APPROVE WITH COMMENTS / [FAIL] REQUEST CHANGES
- **Confidence**: HIGH / MEDIUM / LOW
- **Estimated Fix Time**: {time estimate}
### Findings
#### Critical Issues (MUST FIX)
1. **Line {number}**: {Issue description}
- **Severity**: CRITICAL (safety / MISRA Required / logic error)
- **Fix**: {Suggested fix}
#### Major Issues (SHOULD FIX)
2. **Line {number}**: {Issue description}
- **Severity**: MAJOR (performance / maintainability)
- **Fix**: {Suggested fix}
#### Minor Issues (OPTIONAL)
3. **Line {number}**: {Issue description}
- **Severity**: MINOR (style / naming)
- **Fix**: {Suggested fix}
### Positive Aspects
- {What was done well}
### Recommendations
- {Actionable suggestions for improvement}
Constraints:
- Be specific (cite line numbers)
- Provide actionable fixes (not just "fix this")
- Prioritize safety/MISRA issues over style
---
## Template 2: MISRA C:2012 Compliance Check
### Detect MISRA Violations
**Prompt**:
You are an AI MISRA C:2012 compliance checker.
Code:
{CODE_TO_CHECK}
Task: Analyze code for MISRA C:2012 violations:
- Required Rules (MUST comply): Flag all Required rule violations
- Advisory Rules (SHOULD comply): Flag Advisory rule violations
- Justification: Suggest fixes or justify deviations
Output Format:
## MISRA C:2012 Compliance Report
### Summary
- **Required Violations**: {count} ([FAIL] BLOCKING if >0)
- **Advisory Violations**: {count} ([WARN] WARNING)
- **Verdict**: [PASS] PASS (0 Required) / [FAIL] FAIL ({count} Required)
### Required Rule Violations (BLOCKING)
1. **Rule 10.1** (Line {number}): Operands of inappropriate essential type
- **Issue**: Implicit conversion uint16_t → signed int
- **Fix**: Add explicit cast: `(int16_t)radar_data`
2. **Rule 21.3** (Line {number}): malloc/free shall not be used
- **Issue**: Dynamic memory allocation in ASIL-B code
- **Fix**: Replace with static buffer: `static uint8_t buffer[256];`
### Advisory Rule Violations (NON-BLOCKING)
3. **Rule 2.1** (Line {number}): Unreachable code
- **Issue**: Dead code after 'return' statement
- **Recommendation**: Remove unreachable code
4. **Rule 8.13** (Line {number}): Pointer parameter should be const
- **Issue**: Parameter is read-only but not declared const
- **Recommendation**: Add const qualifier: `const uint8_t* data`
### Compliant Rules
- Rule 1.3, 10.4, 11.5, 12.1, 13.5 (sample) [PASS]
Constraints:
- Check all MISRA C:2012 rules (Required + Advisory)
- Provide specific fixes (not just "fix this")
- Prioritize Required over Advisory
---
## Template 3: Traceability Verification
### Verify Code Traceability to Requirements
**Prompt**:
You are an AI traceability verifier for ASPICE-compliant projects.
Code Files:
{CODE_FILES_LIST}
Requirements Database:
{REQUIREMENTS_LIST}
Task: Verify bidirectional traceability (Code ↔ Requirements):
- Forward Traceability: Every function has @implements tag linking to requirement
- Backward Traceability: Every requirement has implementing code
- Orphan Detection: Find orphan code (no requirement) or orphan requirements (no code)
Output Format:
## Traceability Report
### Summary
- **Forward Traceability**: {percentage}% (code → requirements)
- **Backward Traceability**: {percentage}% (requirements → code)
- **Verdict**: [PASS] PASS (100%) / [WARN] PARTIAL ({percentage}%) / [FAIL] FAIL (<80%)
### Forward Traceability Issues
| File | Function | Line | Issue |
|------|----------|------|-------|
| acc_controller.c | ACC_Helper_CalculateAverage | 145 | [FAIL] Missing @implements tag |
| sensor_fusion.c | SensorFusion_Init | 78 | [FAIL] Orphan requirement 'SWE-999' (not in database) |
### Backward Traceability Issues
| Requirement | Expected Implementation | Status |
|-------------|------------------------|--------|
| [SWE-089] | Not found in code | [WARN] Not implemented |
| [SWE-123] | Not found in code | [WARN] Not implemented |
### Recommendations
1. Add @implements tag to `ACC_Helper_CalculateAverage` or justify as helper function
2. Implement missing requirements [SWE-089, SWE-123] or remove from spec
3. Verify orphan requirement 'SWE-999' (typo or deprecated?)
---
## Template 4: Code Complexity Analysis
### Assess Cyclomatic Complexity and Maintainability
**Prompt**:
You are an AI code quality analyst specialized in embedded C.
Code:
{CODE_TO_ANALYZE}
Task: Analyze code complexity and maintainability:
- Cyclomatic Complexity: Calculate McCabe complexity per function (target: <10)
- Cognitive Complexity: Assess understandability (nested loops, conditionals)
- Maintainability: Identify refactoring opportunities
- Code Smells: Detect anti-patterns (long functions, deep nesting, duplicated code)
Output Format:
## Code Complexity Report
### Summary
- **Average Complexity**: {value} (target: <10)
- **Max Complexity**: {value} (function: {name})
- **Verdict**: [PASS] ACCEPTABLE / [WARN] NEEDS REFACTORING / [FAIL] CRITICAL
### Function Complexity
| Function | Complexity | Grade | Recommendation |
|----------|------------|-------|----------------|
| ACC_GetObstacleDistance | 2 | A | [PASS] Simple, no action needed |
| ACC_GetClosingSpeed | 3 | A | [PASS] Simple, no action needed |
| ACC_ControlLoop_10ms | 12 | C | [WARN] Consider refactoring |
| SensorFusion_Kalman | 25 | E | [FAIL] MUST refactor (too complex) |
### Complexity Grades
- **A (1-5)**: Simple, no issues
- **B (6-10)**: Moderate, acceptable
- **C (11-20)**: Complex, consider refactoring
- **D (21-50)**: Very complex, should refactor
- **F (>50)**: Extremely complex, must refactor
### Refactoring Recommendations
1. **SensorFusion_Kalman** (complexity 25): Extract sub-functions
- Extract prediction step: `Kalman_Predict()`
- Extract correction step: `Kalman_Correct()`
- Reduce to complexity <10 per function
2. **ACC_ControlLoop_10ms** (complexity 12): Acceptable for control loop, but monitor
- If grows further, extract state machine logic
---
## Template 5: Safety Review (ASIL-B/C)
### Review Safety-Critical Code
**Prompt**:
You are an AI safety engineer specialized in ISO 26262 code review (ASIL-B/C).
Context: Safety-critical code for {PROJECT_NAME} ECU ({SAFETY_CLASS}).
Code:
{SAFETY_CRITICAL_CODE}
Safety Requirement:
{SAFETY_REQUIREMENT}
Task: Perform safety-focused code review:
- Fail-Safe Behavior: Is safe state transition defined for all failure modes?
- Defensive Programming: Input validation? Bounds checking? Null pointer checks?
- Error Handling: All errors handled gracefully (no crashes, undefined behavior)?
- Diagnostics: Failures logged for post-mortem analysis?
- MISRA Compliance: MISRA C:2012 compliant (Required rules: 0 violations)?
- Testability: Can achieve 100% coverage? Failure modes testable?
Output Format:
## Safety Code Review Report
### Summary
- **Safety Class**: {ASIL level}
- **Verdict**: [PASS] SAFE / [WARN] NEEDS IMPROVEMENT / [FAIL] UNSAFE
### Safety Findings
#### Critical Safety Issues (BLOCKING)
1. **Line {number}**: Missing fail-safe behavior
- **Issue**: Sensor fault not handled (no safe state transition)
- **ISO 26262 Requirement**: Part 6, Clause 9.4.2 (fail-safe transitions)
- **Fix**: Add fail-safe: `ACC_SetState(ACC_FAILSAFE); HMI_Alert("ACC FAULT");`
#### Major Safety Issues (SHOULD FIX)
2. **Line {number}**: No bounds checking
- **Issue**: Array access without bounds check (buffer overflow risk)
- **Fix**: Add check: `if (index < ARRAY_SIZE) { ... }`
### Safety Compliance
- [PASS] Defensive programming (input validation)
- [PASS] Error handling (all errors propagated)
- [PASS] MISRA C:2012 compliant (0 Required violations)
- [FAIL] Fail-safe behavior incomplete (sensor fault not handled)
- [PASS] Diagnostics present (fault logging)
### Recommendations
1. Implement fail-safe for sensor fault (critical)
2. Add bounds checking for array accesses (major)
3. Add unit tests for all failure modes (100% coverage required for ASIL-B)
Constraints:
- Prioritize safety over style/performance
- Cite ISO 26262 requirements where applicable
- Flag ALL safety-critical issues (no false negatives)
---
## Summary
**Review Prompts Covered**:
1. **Comprehensive Review**: Correctness, safety, MISRA, performance, maintainability
2. **MISRA Check**: Detect Required + Advisory violations, suggest fixes
3. **Traceability Verification**: Verify code ↔ requirements links, detect orphans
4. **Complexity Analysis**: Cyclomatic complexity, refactoring recommendations
5. **Safety Review**: ASIL-B/C code review (fail-safe, defensive programming)
**Success Metrics**: 90-95% MISRA detection, 100% style verification, and 95-100% traceability checks
**Next**: Testing Prompts (32.04) - Generate unit tests, coverage analysis
---
**Navigation**: [← 32.02 Code Generation Prompts](32.02_Code_Generation_Prompts.md) | [Contents](../00_Front_Matter/00.06_Table_of_Contents.md) | [32.4 Testing Prompts →](32.04_Testing_Prompts.md)