oh-interfaces-ipc-to-service_skill

Overview

This skill adds a passthrough RSInterface endpoint in the OpenHarmony graphic_2d repository when the user requests a new interface tagged ToService. It guides the developer through declaring the C++ interface, choosing the required authorization (System or Foundation), and generating the client/service/IPC plumbing while leaving hardware-specific hooks for implementation. The output focuses on practical file edits, IPC code patterns, and verification steps to integrate the new interface cleanly.

How this skill works

I inspect the requested interface signature for valid C++ syntax and ask for corrections if needed. I then generate the required client-side, service-side, and IPC changes following the existing SetDualScreenState/GetPanelPowerStatus call chains, including new enum codes, proxy/stub parcel handling, descriptor checks, and access verification stubs. Hardware calls are left as clear TODO hooks in rs_screen.cpp for developers to implement.

When to use it

• You want to expose a new RSInterface in graphic_2d marked ToService.
• You need a passthrough path from client to service without adding business logic in graphic_2d.
• You must add IPC transport code (proxy, stub, parcel read/write) for a new interface.
• You require controlled authorization (System or Foundation) for a new interface.
• You want consistent style and C++17-compliant integration with existing rs_* files.

Best practices

• Provide a valid, compilable C++ function signature when asked; I will validate syntax before generating code.
• Specify the authorization type (System or Foundation) up front so access verifier code is generated correctly.
• Follow existing patterns in rs_interfaces.cpp/.h and rs_screen.cpp/.h; mirror SetDualScreenState/GetPanelPowerStatus chains for consistent behavior.
• Add minimal, well-documented TODO hooks in rs_screen.cpp for vendor or hardware-specific calls instead of embedding platform logic in generated code.
• Run a C++17 build and static analysis after changes to catch style or ABI mismatches early.

Example use cases

• Expose a brightness or HDR control API from client UI to the screen service as ToService.
• Add a hardware-specific calibration command that must be routed from client through IPC to the screen manager.
• Create a diagnostic trigger interface that client tools call, with Foundation or System authorization as required.
• Add a power-management hint that requires a direct passthrough to the service and vendor implementation.