skills/oh-add-memory-trace-tags/SKILL.md
Use when adding new resource tracking types to memory profiling in developtools_profiler and third_party_musl repositories. Triggered by requests to add trace tags, resource labels, or memory tracking types.
npx skillsauth add openharmonyinsight/openharmony-skills add-memory-trace-tagsInstall 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.
自动在 developtools_profiler 和 third_party_musl 仓库中添加新的资源跟踪类型标签。
此 skill 自动跨两个仓库的多个文件添加内存跟踪标签,确保定义一致、协议更新和测试覆盖。
适用于以下情况:
| 组件 | 修改文件数 | 主要变更 | |------|-----------|---------| | third_party_musl | 2 个文件 | TAG 和 MASK 定义 | | developtools_profiler | 9 个文件 | 协议、逻辑、测试 |
在对话中直接调用:
请添加一个新的资源跟踪标签 <标签名称>
或
使用 add-res-trace-tag 添加 <标签名>
此 skill 会提示输入:
标签名称(必填)
COMMON_<类型名> 或描述性名称COMMON_PIXELMAP、CREATE_NATIVE_WINDOW_FROM_SURFACE描述(可选)
是否绕过大小过滤(可选,默认:是)
src/hook/linux/memory_trace.h - TAG、MASK、位域布局porting/linux/user/src/hook/memory_trace.h - 重复定义协议:
protos/types/plugins/native_hook/native_hook_result.proto - TraceType、MemoryType 枚举常量:
device/plugins/native_daemon/include/hook_common.h - 索引常量业务逻辑:
device/plugins/native_hook/src/hook_guard.cpp - TagId 映射device/plugins/native_daemon/src/hook_manager.cpp - 掩码转换device/plugins/native_daemon/src/stack_preprocess.cpp - 统计映射device/plugins/native_daemon/src/hook_record.cpp - TraceType 设置device/plugins/native_hook/src/hook_client.cpp - 过滤条件(仅 COMMON_* 类型)测试:
device/plugins/native_daemon/test/unittest/common/native/hook_record_test.cppdevice/plugins/native_daemon/test/unittest/common/native/stack_preprocess_test.cpp每个资源类型必须定义两个宏:
// ✅ 正确:同时定义两个宏
#define RES_COMMON_WINDOW (1ULL << 33)
#define RES_COMMON_WINDOW_MASK (1ULL << 33)
// ❌ 错误:缺少 _MASK 后缀
#define RES_COMMON_WINDOW (1ULL << 33)
// 缺少 RES_COMMON_WINDOW_MASK!
为什么需要两个定义:
RES_<NAME> - 基础掩码值RES_<NAME>_MASK - 统一接口的别名常见错误场景:
错误 1:忘记添加 _MASK 后缀
#define RES_COMMON_SURFACE (1ULL << 34) // ✅ 有这个
// ❌ 缺少:#define RES_COMMON_SURFACE_MASK (1ULL << 34)
错误 2:只复制了第一行
#define RES_COMMON_TEXTURE (1ULL << 35) // ✅ 有这个
#define RES_COMMON_TEXTURE // ❌ 这行是错的!应该是 (1ULL << 35)
Skill 自动验证: 此 skill 会自动检查是否两个定义都存在,如果缺失会自动添加。
添加新标签后检查:
d:\Code\tools_develop\hook_client.cpp 的过滤条件| 错误 | 解决方案 | |------|----------| | 标签已存在 | 使用不同的标签名称 | | 文件未找到 | 验证仓库路径 | | 权限被拒绝 | 检查文件写入权限 | | 格式无效 | 标签名称必须是大写字母和下划线 | | 缺少 MASK | Skill 自动添加 RES_MASK 定义 | | 定义不匹配 | RES 和 RES_*_MASK 的值必须相同 |
development
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.
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