Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

BP Monthly Report Writer

v0.2.4

Draft monthly BP reports by normalizing templates, mapping BP anchors, collecting evidence, and writing sections in order with data-backed progress evaluation.

0· 32·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
high confidence
!
Purpose & Capability
The skill's stated purpose is to fetch BP system data and draft reports. The repository contains two Python scripts that perform HTTP calls to a specific BP API base URL (https://sg-al-cwork-web.mediportal.com.cn/open-api) and expect an app key (passed as --app-key). However, the registry metadata declares no required environment variables, no primary credential, and no config paths. That mismatch (code requiring credentials for BP system access vs. no declared credential requirements) is incoherent and unexplained.
!
Instruction Scope
SKILL.md explicitly instructs the agent to fetch BP data, build intermediate artifacts, and write multiple files (00_intake.yaml, 01_bp_anchor_map.yaml, etc.). The included scripts implement those fetch and artifact-writing behaviors. The instructions assume the skill can '直接按 BP 系统取数' (fetch from the BP system) but do not say how credentials are provided or validated. This grants network/data-access behavior without declaring the necessary secrets or access mechanism.
Install Mechanism
There is no install spec (instruction-only skill) which reduces installation risk. However, code files are bundled (scripts/collect_bp_month_evidence.py and scripts/dump_bp_anchor_map.py) that will run if invoked. No external downloads or obscure installers are present. The risk is that the scripts will attempt outbound HTTP calls when executed.
!
Credentials
The scripts require an app key (passed via CLI) and will set an HTTP header 'appKey' when calling the BP API. The skill metadata declares zero required env vars/credentials — this omission is disproportionate and hides the need for a sensitive credential. The code also hard-codes a single corporate API host, which suggests this skill is intended for use inside that organization or with that service; that expectation is not documented in the registry metadata.
Persistence & Privilege
The skill is not 'always: true' and does not request system-wide config changes. It writes intermediate and final artifacts to an output directory (expected by design). There is no evidence it attempts to modify other skills or system settings.
What to consider before installing
Key things to check before installing or running this skill: - Credentials: The bundled scripts call a corporate BP API and require an app key (--app-key). The skill metadata does not declare this credential. Ask the publisher which credential(s) are required, how to supply them safely, and whether they can be scoped (read-only) for this purpose. - Endpoint provenance: The scripts use a hard-coded base URL (https://sg-al-cwork-web.mediportal.com.cn/open-api). Confirm with your organization that this is the correct internal API host and that you trust the skill to call it. If you are not inside that organization, do not provide sensitive credentials. - Data handling: The skill writes intermediate artifacts (00_intake.yaml, evidence manifests, etc.) and clusters evidence rather than saving full report JSON by default. Verify that writing those artifacts to the execution environment is acceptable and that no sensitive data will be leaked to logs or external endpoints. - Least privilege testing: If you decide to try it, run the scripts in a controlled environment with a non-production, least-privileged app key or a stubbed API endpoint first to confirm behavior. - Documentation mismatch: Ask the author to update registry metadata to declare required environment variables (e.g., BP_APP_KEY or APP_KEY) and to make the base API URL configurable (not hard-coded). That change would eliminate the main incoherence and likely move the skill toward 'benign' in this evaluation. What would change this assessment: explicit declaration of required credentials and config (and ideally making the API base URL configurable), or confirmation that the scripts are only documentation/examples and will not be invoked by the agent without explicit user-provided credentials. If those are provided and scoped appropriately, the skill appears coherent for its stated BP-reporting purpose.

Like a lobster shell, security has layers — review code before you run it.

bpvk974hemsjtkmq1wgermhs2m5sd842j26latestvk97cag1kapzbjak1d4aqyb8w41842vkwmonthly-reportvk974hemsjtkmq1wgermhs2m5sd842j26zh-cnvk974hemsjtkmq1wgermhs2m5sd842j26

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

SKILL.md

BP Monthly Report Skill

Use this skill when the user wants a monthly report draft that must match a fixed structure and be grounded in real BP data, node progress, and business updates.

Capability Summary

This skill can directly handle these tasks:

  • identify the target BP node from a node name or groupId
  • fetch the node's BP goals, key results, measure standards, and linked reports
  • generate lightweight evidence manifests and direct report references
  • generate staged artifacts and a monthly or quarterly report draft
  • roll a later month forward from the previous month's baseline
  • use the bundled default month template and bundled fill-in specification when the environment has standardized on them

It is not only a writing guide. It is a BP-fetching and report-drafting workflow.

First-Turn Behavior

On the first reply, state the skill's capability plainly and ask only for the minimum missing inputs.

Preferred opening pattern:

我可以直接按 BP 系统取数并生成这份月报。
最少只需要这 3 个信息:
1. BP周期
2. 节点名称或 groupId
3. 月报月份

如果模板和填报规范已经固定,我会直接按既定模板执行,不再重复询问。
如果你要,我先从节点解析和 BP 取数开始。

Do not describe the skill as if it were only a manual or passive guideline. Do not ask for 月报模板 or 进展数据 again if the workflow is already designed to fetch evidence from the BP system itself. Ask about template or spec only if:

  • the user explicitly says a different template must be used
  • the template is genuinely unknown for the current environment
  • the report structure cannot be inferred from prior context

Goal

Produce a controllable v1.0 monthly report draft that:

  • matches the target template structure exactly
  • uses the user's fill-in convention and wording constraints
  • is backed by traceable BP and progress evidence
  • surfaces concrete work progress for each major item, not only evidence existence
  • is generated section by section, not in one pass
  • evaluates progress primarily through 关键成果 + 衡量标准, not through 关键举措 volume
  • exposes how many original work reports were adopted for the draft so source coverage can be judged quickly

What to read

  1. Read the target month report template.
  2. Read the user's fill-in specification or a completed sample based on that template.
  3. Read only the BP and progress materials needed for the current node and person.
  4. If the data layout is unclear, read references/source-schema.md.
  5. For the staged workflow, read references/workflow.md.
  6. For section order and section writing rules, read references/section-order.md.
  7. If the user supplied a filled sample or fill-in convention, read references/fill-patterns.md.
  8. When BP system fetching is involved, read references/bp-system.md.
  9. When status judgment is required, read references/traffic-lights.md.
  10. When producing deliverables, read references/artifact-layout.md.
  11. When writing a later month or quarter, read references/rolling-baseline.md.
  12. When a Chinese business-facing explanation is needed, read references/business-description.zh-CN.md.
  13. When a Chinese design or architecture explanation is needed, read references/design-solution.zh-CN.md.

If the user does not provide another template package and the current environment uses the standard monthly pack, use these bundled defaults first:

Non-negotiable rules

  • Do not draft the full report in a single generation pass.
  • Do not write section 1 before sections 2-8 are materially stable.
  • Keep the final chapter order and heading structure identical to the target template.
  • Every conclusion must be attributable to a BP anchor, a progress update, or an explicit user input.
  • When evidence is missing, mark the field as missing and ask for补充 only if the gap blocks a reliable draft.
  • Prefer deterministic intermediate artifacts over free-form reasoning.
  • Ask for and confirm the BP周期 and the 目标节点 before fetching BP data.
  • Treat 目标 as the desired end state, 关键成果 as the evaluation basis, and 关键举措 as supporting actions.
  • Always fetch 关键举措 metadata together with goals and key results.
  • In report writing, prioritize evidence linked to goals and key results. Use action reports as secondary support for evaluation, but treat them as a major evidence pool for concrete progress extraction.
  • When evaluating related reports, prioritize reports written by the current node's responsible owners or assignees. Reports written by others are only auxiliary evidence unless the user explicitly says otherwise.
  • Every major BP item must carry a traffic-light icon judgment: 🟢 / 🟡 / 🔴.
  • Treat the traffic light as the single deviation signal. Do not add a second independent 偏离判断 color field.
  • Every adopted evidence item in the final report must point to the original BP report itself, preferably via [标题](reportId=<id>&linkType=report). Do not dump full report bodies into local JSON files unless the user explicitly asks for archival snapshots.
  • For each major report item, extract concrete progress lines from the source report: what was completed, what moved forward, what decision was made, what remains blocked, and what happens next.
  • When raw report payloads expose attachment metadata or attachment links, record that metadata together with the evidence entry and read the attachments before drafting if they materially affect progress judgment.
  • Do not reduce a chapter to “there is evidence”. Convert evidence into explicit progress statements.
  • Section 1 must state how many original work reports were adopted for this draft. Prefer a compact breakdown such as total adopted reports, owner-authored primary reports, other manual reports, and AI reports if any were used.

Required inputs

At minimum, gather:

  • reporting month
  • BP period
  • reporting node
  • node identifier such as groupId or an unambiguous node name

Default minimum call contract:

  • bp_period
  • node_name or groupId
  • report_month

Ask for template path, spec path, or extra progress materials only when they are actually missing for the current environment.

Optional but useful:

  • person name, role, department, if the template metadata or node resolution needs it
  • employeeId, if the node is a personal BP node and is easier to resolve this way
  • explicit BP IDs for the node
  • management summary or leader concerns for the month
  • optional wording preferences for rendering traffic-light explanations

Usually do not require these optional fields before starting BP fetch and evidence collection.

Working sequence

Follow this sequence without collapsing steps:

  1. Confirm the BP period and target node.
  2. Normalize the template and extract the exact heading tree.
  3. Resolve the node inside BP and build a BP anchor map.
  4. Collect month-specific evidence and map each fact to a BP anchor.
    • Prefer using scripts/collect_bp_month_evidence.py instead of ad hoc query code.
  5. Build section cards before writing any chapter prose.
    • Prefer using scripts/dump_bp_anchor_map.py to stabilize the BP skeleton.
  6. Draft sections in this order: 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 1.
  7. Run a consistency pass to check wording, metrics, status, and cross-section alignment.

Expected intermediate artifacts

Create these artifacts in memory or as working notes:

  • intake_summary
  • template_outline
  • bp_anchor_map
  • evidence_ledger
  • section_cards
  • draft_v1
  • source_inventory_summary

Use the field definitions from references/source-schema.md.

Persist the run artifacts using the layout from references/artifact-layout.md.

Output standard

The final output should include:

  • a short note on what sources were used
  • the monthly report draft with the exact template structure
  • a short gap list for fields that still need manual补数 or确认

Do not add extra chapters unless the user explicitly asks for them.

Files

15 total
Select a file
Select a file to preview.

Comments

Loading comments…