skills/log-coverage-analyzer/SKILL.md
Analyze code repository logging coverage to ensure all function branches have LOGE/LOGI logs and identify high-frequency log risks. Supports multiple programming languages (C++, Java, Python, JavaScript, etc.)
npx skillsauth add openharmonyinsight/openharmony-skills log-coverage-analyzerInstall 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.
This skill performs comprehensive log coverage analysis for code repositories. It identifies logging deficiencies in call chains and detects high-frequency log risks that may impact performance.
| Log Level | Behavior | Use Case | |-----------|----------|----------| | LOGE | Always prints, never lost | Critical - Must exist on all error return paths | | LOGI | Always prints, may be lost if high-frequency triggered at same location | Important - Success paths, key operations | | LOGD | Only prints when debug switch enabled | Optional - Debug information only | | LOGW | Only prints when debug switch enabled | Optional - Warning information only |
Description: Create detailed analysis plan before starting
Actions:
TodoWrite tool to create task listOutput: Analysis plan created via TodoWrite tool
Description: Find all relevant source files in the repository
Actions:
Glob tool to find source files based on language patterns:
**/*.cpp, **/*.cc, **/*.cxx, **/*.h, **/*.hpp**/*.java**/*.py**/*.js, **/*.ts**/*.go**/*.rs**/test/**, **/tests/**, **/*_test.*)**/build/**, **/out/**, **/target/**)Output: List of source files to analyze
Description: Scan all source files for logging macros/functions
Actions:
Grep tool to find log statements with pattern:
LOG[DEIW], HILOG[DEIW], ALOG[DEIW]\.log[deiw]\(, Log\.[deiw], LOG\.Output: Log statistics per file
Description: Parse source files to extract function definitions and call relationships
Actions:
Output: Function list with call relationships
Description: Check each branch in call chains for required logging
Actions:
Deficiency Classification:
Output: List of log deficiencies with locations
Description: Identify functions with LOGE/LOGI that may be called frequently
Actions:
OnDataReceived, OnPacketReceived, OnMessage)OnTimer, Tick, Update)HandleEvent, ProcessEvent, OnEvent)ProcessItem, HandlePacket, SendData)ProcessStream, HandleFrame, EncodeFrame)OnMessage, Dispatch)Risk Classification:
Output: List of high-frequency risks with locations
Description: Create comprehensive analysis report with all findings
Actions:
Write tool to save report to log-coverage-report-YYYYMMDD-HHmmss.mdOutput: Complete analysis report
Function Definition Patterns:
[return_type] [class::]function_name([parameters]) {
[\w\s:*,]*\{
Log Patterns:
LOG[DEIW]\(, HILOG[DEIW]\(, ALOG[DEIW]\(__android_log_printOHOS::HiviewDFX::HiLog::[Error|Warn|Info|Debug]Function Definition Patterns:
(public|private|protected)?(\s+static)?\s+\w+\s+\w+\s*\(.*\)\s*(throws\s+[\w\s,]+)?\s*\{
Log Patterns:
Log\.[deiw]\(Logger\.(error|warn|info|debug)\(Timber\.[deiw]\(Function Definition Patterns:
def\s+\w+\s*\(.*\)\s*->?\s*.*:
Log Patterns:
logger\.(error|warning|info|debug)\(logging\.(error|warning|info|debug)\(print\(Function Definition Patterns:
function\s+\w+\s*\(.*\)\s*\{
|\w+\s*\([^)]*\)\s*(=>|\{)
Log Patterns:
console\.(error|warn|info|log)\(logger\.(error|warn|info|debug)\(Error Return Path (Must Fix):
// BEFORE:
if (remote == nullptr) {
return ERR_NULL_OBJECT; // ❌ No LOGE
}
// AFTER:
if (remote == nullptr) {
HILOGE("FunctionName: remote is null, context=%{public}d", context);
return ERR_NULL_OBJECT;
}
Success Path (Should Fix):
// BEFORE:
int32_t CreateSession(...) {
// ... initialization code
return ERR_OK; // ❌ No LOGI on success
}
// AFTER:
int32_t CreateSession(...) {
// ... initialization code
HILOGI("CreateSession: success, sessionId=%{public}d, name=%{public}s", id, name);
return ERR_OK;
}
Remove High-Frequency LOGI:
// BEFORE:
void OnPacketReceived(int socketId, const void* data, uint32_t len) {
HILOGI("packet received: socket=%{public}d, len=%{public}u", socketId, len); // ⚠️ Per-packet
// ... process packet
}
// AFTER:
void OnPacketReceived(int socketId, const void* data, uint32_t len) {
// Removed per-packet LOGI
static std::atomic<uint64_t> packetCount{0};
if (++packetCount % 1000 == 1) {
HILOGI("Packet stats: count=%{public}llu, socket=%{public}d",
packetCount.load(), socketId);
}
// ... process packet
}
Use Throttled LOGE for Errors:
// BEFORE:
void ProcessPacket(const Packet* pkt) {
if (pkt == nullptr) {
HILOGE("packet is null"); // ⚠️ Per-packet error
return;
}
}
// AFTER:
void ProcessPacket(const Packet* pkt) {
if (pkt == nullptr) {
static std::atomic<uint32_t> errorCount{0};
if (++errorCount % 100 == 1) {
HILOGE("ProcessPacket: null packet, count=%{public}u", errorCount.load());
}
return;
}
}
================================================================================
Log Coverage Analysis Report
================================================================================
Repository: <repository_path>
Analysis Date: <timestamp>
Files Analyzed: <count>
## Summary Statistics
| Metric | Count |
|--------|-------|
| Total Source Files | <number> |
| Total Functions | <number> |
| Functions Analyzed | <number> |
| Log Deficiencies | <number> |
| High-Frequency Risks | <number> |
## Log Deficiencies
### [High/Medium/Low] Priority
**File**: `<file_path>`
**Function**: `<function_name>`
**Lines**: `<line_range>`
**Issue**: `<description>`
**Evidence**:
```cpp
<code snippet>
Impact: <explain impact on debugging/troubleshooting>
Fix:
<fixed code>
File: <file_path>
Function: <function_name>
Lines: <line_range>
Risk: <description>
Evidence:
<code snippet>
Analysis: <explain why this is high-frequency>
Fix:
<fixed code with throttling/statistics>
<function_1>()
↓ [✓/✗/⚠️] <log_status>
<function_2>()
↓ [✓/✗/⚠️] <log_status>
<function_3>()
├─ [✓/✗/⚠️] branch_1
├─ [✓/✗/⚠️] branch_2
└─ [✓/✗/⚠️] branch_3
Legend:
================================================================================
## Parameters
| Parameter | Required | Description |
|-----------|----------|-------------|
| `--path` | No | Repository path (default: current directory) |
| `--exclude-tests` | No | Exclude test files (default: true) |
| `--lang` | No | Language filter (cpp, java, python, js, all) |
| `--output` | No | Output report path |
## Usage Examples
/log-coverage-analyzer
/log-coverage-analyzer --path /path/to/repo
/log-coverage-analyzer --lang cpp --path /path/to/repo
/log-coverage-analyzer --exclude-tests false
/log-coverage-analyzer --output /path/to/report.md
## Tips
- Use `Grep` with `output_mode: content` and `-B/-C` flags for context
- Use `Read` tool with `offset` and `limit` for large files
- For large repositories, focus on critical directories first
- High-frequency risks should be prioritized over minor log deficiencies
- Always include context (IDs, states, parameters) in LOGE messages
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