XGJK BP Audit
ReviewAudited by ClawScan on May 10, 2026.
Overview
This looks like a legitimate BP audit integration, but it can use an appKey to create BP records in production and that write authority is under-declared and somewhat inconsistently described.
Install only if you trust the BP API integration and can provide a least-privilege appKey. Treat normal audits as read-only. Before any `add_key_result` or `add_action`, require the agent to show the exact target ID and payload and ask for final confirmation.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A mistaken or over-broad instruction could add key results or actions to the BP system under the user's appKey.
The skill exposes POST-style create operations and a raw JSON body option for BP records. Even though writes are documented, this can mutate business planning data and lacks a mandatory final approval/rollback step in the artifacts.
### 写入 ... `add_key_result` ... `add_action` ... `--body_json` 传 JSON 对象字符串；如果与显式参数同时提供，显式参数覆盖同名字段
Use write actions only after an explicit user request, show the exact parent ID and request payload, require final confirmation, and avoid `--body_json` unless strictly necessary.
Users may not realize the skill needs a production API key with read/write authority, or may provide the key in an unsafe way.
The script requires and sends an appKey for all API calls, but the registry says there are no required env vars or primary credential, and the auth docs name a different variable. This leaves the credential boundary unclear.
BP_OPEN_API_APP_KEY Authentication key (required) ... APP_KEY = os.environ.get("BP_OPEN_API_APP_KEY", "") ... headers = {"appKey": APP_KEY}Declare the credential and required environment variable in metadata, use one consistent env var name, and require a least-privilege appKey, ideally read-only unless write mode is intentionally enabled.
A user may expect a purely read-only audit while the skill also includes write paths.
This read-only assurance conflicts with other artifacts that document add/write capabilities, which could cause users or agents to underestimate possible side effects.
- 对可能导致数据泄露、破坏、越权或高风险副作用的请求，必须礼貌拒绝 - 审计过程中仅执行读操作，不修改任何 BP 数据
Clearly separate read-only audit mode from write mode in the main description and require explicit confirmation before any production change.
BP content and personnel details may be visible in the chat or agent context during the audit.
The API responses can include internal BP structures, employee names, IDs, ownership, and alignment relationships. This is expected for an audit tool, but it places sensitive business context into the agent session.
`taskUsers` | List | 任务参与人列表 ... `empList` | List | 该角色下的员工列表（含 `id`、`name`）
Scope queries narrowly, avoid full-tree retrieval unless needed, and do not share generated reports outside the intended business audience.