skills/oh-precommit-codecheck/SKILL.md
Run local code quality checks covering a subset of OpenHarmony gate CI (copyright, CodeArts C/C++) plus additional local checks (pylint/flake8, shellcheck/bashate, gn format). Use before committing to reduce gate failures. Triggers on: /oh-precommit-codecheck, "门禁检查", "门禁预检", "检查代码", "run codecheck", "check code quality", "lint my code", "代码检查", or after completing code implementation. WHEN to use: before git commit, before creating PR, after modifying C/C++/Python/Shell/GN files, when gate CI fails with codecheck defects, or when you want to preview what gate will flag.
npx skillsauth add openharmonyinsight/openharmony-skills oh-precommit-codecheckInstall 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.
Run local code quality checks. Includes gate CI checks and additional local-only checks.
Gate CI checks (same as OpenHarmony gate):
/** for C/C++)Additional local checks (NOT part of gate CI, for extra quality):
gn format --dry-run~/.codecheck-tools/pylint, flake8, shellcheck, bashate-mod-ds)compile_commands.json may miss some context-dependent issuesgn in PATHThis skill covers a subset of the full OpenHarmony gate CI checks:
-CPP suffix.| Invocation | Mode | Behavior |
|-----------|------|----------|
| /oh-precommit-codecheck (standalone) | Mode 1 | Check specified files, report results, ask before fixing |
| /oh-precommit-codecheck --fix | Mode 1 | Check and auto-fix up to 3 rounds |
| Auto-triggered by oh-pr-workflow | Mode 2 | Silent check + auto-fix, report only if defects remain |
| Pre-commit hook | Mode 2 | Same as auto-trigger |
Check whether $ARGUMENTS is set.
$ARGUMENTS present or /oh-precommit-codecheck called)Parse $ARGUMENTS to determine file scope and fix mode:
/oh-precommit-codecheck → files from: git diff --cached --name-only
/oh-precommit-codecheck <commit> → files from: git diff-tree --no-commit-id -r <commit> --name-only
/oh-precommit-codecheck <file ...> → the listed files directly
/oh-precommit-codecheck --fix → same file resolution + auto-fix mode
Argument parsing rules:
--fix flag can appear anywhere in argumentsgit rev-parse --verify <arg>), treat it as a commitSteps:
bash ~/.claude/skills/oh-precommit-codecheck/scripts/check.sh <file1> <file2> ...
--fix was NOT specified:
/oh-precommit-codecheck --fix to auto-fix these issues."--fix WAS specified and defects were found:
gn format <file> to auto-format.$ARGUMENTS, after completing code changes)When you have just finished writing or modifying code files, automatically check them.
Steps:
bash ~/.claude/skills/oh-precommit-codecheck/scripts/check.sh <modified_files...>
gn format <file>.
b. Re-run checks to verify fixes.
c. Repeat up to 3 rounds total.
d. If defects remain after 3 rounds, report the unfixable ones to the user.Mode 2 and CLAUDE.md interaction: When triggered as pre-commit hook or by
oh-pr-workflow, Mode 2 auto-fixes to streamline the commit flow. This overrides
the CLAUDE.md "show report first" convention because the user has already expressed
intent to commit. If invoked standalone (/oh-precommit-codecheck without commit
context), default to report-only and ask before fixing.
Below: Reference sections — consult when fixing specific defect types. Skip to "Common Mistakes" if you just need guardrails.
When auto-fixing defects, match the rule to the fix below. If the rule is not listed, read the defect message and apply best judgment.
2025 → 2025-2026).cpp/.c/.h/.hpp files, change first line to /** (block comment style){} around single-line if/for/while/else bodiesNULL / 0 (pointer context) with nullptrconstexpr constant|| exit after cd commands#!/usr/bin/env bash at topgn format <file> — fully automatic, no manual intervention neededgn format on files that fail gn parse — it corrupts the file. Run gn parse first; if it fails, fix syntax manually before formatting.defects.json is non-empty AND engine exited normally.java -version, clang-tidy --version, pylint --version.java -version (requires 11+). Check download integrity: md5sum codecheck-ide-engine.jar. Re-run setup: bash scripts/setup_codecheck.sh --force.gn gen out/default --export-compile-commands or proceed with reduced accuracy.pylint --version and compare with gate CI logs.Typical Mode 1 result:
Codecheck Results (12 defects):
| Rule | Count | File | Auto-fixable |
|------|-------|------|-------------|
| G.FMT.11-CPP | 5 | token_test.cpp | Yes |
| G.NAM.03-CPP | 3 | token_test.cpp | Yes (with context) |
| G.EXP.35-CPP | 2 | token_test.cpp | Yes |
| G.FUN.01-CPP | 1 | token_test.cpp | No — report to user |
| G.FMT.05-CPP | 1 | token_test.cpp | Yes |
发现 12 个告警,其中 11 个可自动修复。是否修复?
development
OpenHarmony PR full lifecycle workflow. Five modes: - Commit: standardized commit with DCO sign-off and Issue linking - Create PR: commit + push to fork + create Issue + create PR on upstream - Fix Codecheck: fetch gate CI codecheck defects from a PR and auto-fix them - Review PR: fetch a PR's changes to local for code review - Fix Review: fetch unresolved review comments from a PR and auto-fix them Triggers on: /oh-pr-workflow, "提交代码", "创建PR", "提个PR", "commit", "修复告警", "修复门禁", "修复codecheck", "fix codecheck", "review pr", "review这个pr", "看下这个pr", "检视pr", "修复review", "修复检视意见", "fix review", or a GitCode PR URL with fix/review intent.
testing
分析 HM Desktop PRD 文档,提取需求信息、验证完整性、检查章节顺序(需求来源→需求背景→需求价值分析→竞品分析→需求描述)、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求:(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词:PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
development
基于 PRD 文档自动生成鸿蒙系统设计文档,包括架构设计文档和功能设计文档。生成前会分析 OpenHarmony 存量代码结构,确保与现有架构兼容。架构设计文档第2章必须为竞品方案分析,位于需求背景之后。适用于用户请求:(1) 生成架构设计文档, (2) 生成功能设计文档, (3) 从 PRD 生成设计文档, (4) 创建系统架构设计, (5) 编写功能规格说明, (6) 分析 OH 代码结构。关键词:architecture design, functional design, design doc, 竞品方案分析, OpenHarmony code analysis, 架构设计, 功能设计, 设计文档生成, OH代码分析, analyze codebase, competitor analysis
development
基于设计文档自动生成鸿蒙系统代码框架,包括 IDL 接口定义、目录结构、头文件、源文件模板、构建配置等。生成前会分析 OpenHarmony 存量代码,学习现有代码风格和架构规范。适用于用户请求:(1) 生成代码框架, (2) 创建 IDL 接口, (3) 生成 BUILD.gn 配置, (4) 创建服务代码, (5) 初始化项目结构, (6) 参考现有代码风格。关键词:code generation, IDL, BUILD.gn, bundle.json, SA profile, OpenHarmony code style, 代码生成, 接口定义, 构建配置, OH代码风格