skills/cpp-core-guidelines-review/SKILL.md
Parallel C++ Core Guidelines code review using multiple specialized sub-agents. Use when reviewing C++ code, modules, or files against C++ Core Guidelines to identify violations. Each sub-agent reviews against a specific guideline section (Functions, Classes, Resource Management, etc.) and outputs findings to separate markdown files in the review/ directory, followed by a consolidated summary.
npx skillsauth add openharmonyinsight/openharmony-skills cpp-core-guidelines-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Review C++ code against the C++ Core Guidelines by launching parallel sub-agents, each analyzing code against a specific guideline section. This skill ensures comprehensive coverage while maintaining high confidence in violation identification.
Before launching any sub-agents, clarify the review scope with the user:
.cpp, .h, .hpp)Important: Do not proceed until the scope is clearly defined and unambiguous.
CRITICAL REQUIREMENTS:
references/Content/. Do not skip any files. Each guideline section requires its own dedicated sub-agent.agents/guideline-section-reviewer.md from this plugin for each sub-agent.Parallel launch strategy: To maximize performance, launch all sub-agents in parallel by sending multiple Task tool calls in a single response message. The Task tool documentation explicitly states: "When the user specifies that they want you to run agents 'in parallel', you MUST send a single message with multiple Task tool use content blocks."
Launch one sub-agent per guideline section. Each sub-agent:
<current-working-directory>/review/<SectionName>.mdAgent invocation process:
agents/guideline-section-reviewer.md{{SECTION_NAME}}: The display name of the section (e.g., "Functions"){{SECTION_FILE}}: The filename of the section in references/Content/ (e.g., "Functions.md"){{TARGET_FILES_PATTERN}}: The files/directories to review (e.g., "src/**/*.cpp" or specific file paths){{OUTPUT_DIR}}: The output directory (typically <current-working-directory>/review){{DATE}}: Current date in YYYY-MM-DD format{{FILES_COUNT}}: Number of files being reviewed{{VIOLATION_COUNT}}: Placeholder, will be filled by agentsubagent_type=general and the substituted prompt as the agent's instructionExample invocation:
For section "Functions":
- Read agent template from agents/guideline-section-reviewer.md
- Substitute: SECTION_NAME="Functions", SECTION_FILE="Functions.md", etc.
- Launch guideline-section-reviewer agent with substituted prompt
The agent will:
references/Content/ directory<OUTPUT_DIR>/<SECTION_NAME>.mdAfter launching all sub-agents, collect their task IDs and wait for completion:
Waiting process:
TaskOutput with:
task_id: The task ID from the sub-agent launchblock=true: Wait until the sub-agent completestimeout=600000 (10 minutes): Maximum wait time per agent<current-working-directory>/review/<SectionName>.mdError handling:
Verification checklist:
After all sub-agents complete, create <current-working-directory>/review/Summary.md with a comprehensive analysis of all findings.
Process:
<current-working-directory>/review/*.md (excluding Summary.md itself)Summary.md template:
# C++ Core Guidelines Review Summary
## Overview
**Date**: YYYY-MM-DD
**Review Scope**: <Files/directories reviewed>
**Total Sections Reviewed**: <Number of sections completed>
**Total Violations Found**: <Total count across all sections>
## Summary by Section
| Section | Violations | Most Violated Rule |
|---------|------------|-------------------|
| Functions | N | F.15, ... |
| Classes and Class Hierarchies | N | C.7, ... |
| Resource Management | N | R.1, ... |
| [Continue for all sections] | | |
## Summary by File
| File | Total Violations | Top Violation Categories |
|------|------------------|--------------------------|
| path/to/file1.cpp | N | Resource Management, Error Handling |
| path/to/file2.h | M | Const Correctness, Interfaces |
| [Continue for affected files] | | |
## Top Violations by Frequency
| Rank | Rule ID | Rule Summary | Count |
|------|---------|--------------|-------|
| 1 | F.15 | Prefer simple and default constructs | N |
| 2 | R.3 | Raw pointers should not be used | M |
| [Continue] | | | |
## Critical Findings
### High-Priority Issues
<List violations with high impact or security implications>
### Most Common Patterns
<Identify recurring violation patterns across the codebase>
## Detailed Section Breakdown
### Functions (N violations)
<Brief summary of key violations in this section>
See: [Functions.md](Functions.md)
### Classes and Class Hierarchies (N violations)
<Brief summary of key violations in this section>
See: [Classes and Class Hierarchies.md](Classes%20and%20Class%20Hierarchies.md)
### [Continue for all sections with violations]
## Recommendations
1. **Immediate Actions**: <Critical violations that should be addressed soon>
2. **Process Improvements**: <Suggestions to avoid common violations>
3. **Training Topics**: <Areas where team education may help>
## Review Metadata
- **Sections Completed**: <List of sections that completed>
- **Sections Skipped/Failed**: <List of sections that had issues>
- **Total Files Reviewed**: <Count>
- **Lines of Code Reviewed**: <If available>
Key requirements for summary:
<current-working-directory>/review/ directory.The C++ Core Guidelines reference files are bundled in this skill's references/ directory:
Introduction.md - Overview and glossaryContent/ - Individual guideline sectionsEach section contains multiple rules with:
Example 1: Review specific files
User: "Review src/transaction.cpp and src/account.h against C++ Core Guidelines"
→ Clarify scope, then launch sub-agents for those files.
Example 2: Review directory
User: "Review all C++ files in the services/ directory"
→ Clarify file patterns and exclusions, then launch sub-agents.
Example 3: Review against specific sections
User: "Review using only Resource Management and Error Handling guidelines"
→ Launch only those two sub-agents.
testing
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
development
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common