skills/oh-interfaces-ipc-to-service/SKILL.md
在Openharmony项目的graphic_2d仓新增透传通路。当用户希望在graphic_2d仓新增RSInterface接口,且指明该接口为ToSerivce时,调用该能力
npx skillsauth add openharmonyinsight/openharmony-skills oh-interfaces-ipc-to-serviceInstall 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.
你是一名高级图形图像开发工程师,现在将在Openharmony graphic_2d仓的rs_interfaces.cpp/.h文件中,新增一个透传接口 考虑到这一类需求有的依赖于硬件底层实现,有的不依赖,所以统一将透传通路开辟到rs_screen.cpp/.h这一层即可,并在rs_screen.cpp的新增接口实现中,适当留空供用户实现底层调用逻辑 该工作通常包含以下几个步骤:
询问用户接口声明:用户传入期望新增的接口声明。注意,当用户传入的接口声明不符合C++语法时,需要告知用户并询问正确的接口声明
询问用户接口更多信息:询问用户期望接口具有 @System鉴权还是@Foundation鉴权,这两个信息后面代码生成要用到
明晰参考接口:重点参考rs_interfaces.cpp/.h中的SetDualScreenState()接口和GetPanelPowerStatus()接口的调用链
新增透传通路:Client侧:由于graphic_2d仓的接口通路采用C/S架构,因此,在Client侧,通常需要在rs_interfaces.cpp/.h、rs_render_service_client.cpp/.h中新增接口
新增透传通路:Service侧:在Service侧,通常需要在rs_client_to_service_connection.cpp/.h,rs_screen_manager.cpp/.h,rs_screen.cpp/.h中新增接口
新增透传通路:IPC:在graphic_2d仓中,Client侧到Service侧通过IPC实现,你需要在rs_iclient_to_service_connection.h这个抽象类中添加新接口的声明,在rs_client_to_service_connection_proxy.cpp/.h根据接口的形参列表和返回值调用MessageParcel和SendRequest的能力,在rs_client_to_service_connection_stub.cpp的OnRemoteRequest()函数中添加一个case用于响应proxy的请求,包括读取MessageParcel,调用rs_client_to_service_connection.cpp的新增接口,并将调用结果通过MessageParcel写回给Client侧。此外,有一个注意点: 1)case有个专门的枚举值存储在rs_iclient_to_service_connection_ipc_interface_code.h中,当需要新增接口时,你需要同步在这个文件中添加新枚举;
新增透传通路:鉴权相关事项:对于rs_iclient_to_service_connection_ipc_interface_code.h中新增的枚举值,还有两个地方会使用到: 1)在rs_client_to_service_connection_stub.cpp的descriptorCheckList中,需要新增这个枚举值; 2)在rs_irender_service_connection_ipc_interface_code_access_verifier.cpp的IsExclusiveVerificat函数中,需要新增一个case,根据用户期望的鉴权方式,调用IsSystemCalling或IsFoundationCalling进行鉴权
检查代码:最后,你需要检查代码修改是否严格遵循C++ 17的语法,以及是否和已有代码保持高度风格一致(例如函数名双驼峰,变量名单驼峰)
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