BP Monthly Report Writer

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

Security Scan

The skill claims to fetch internal BP system data and auto-generate traceable monthly reports, but its declared requirements omit any credentials or network-access details needed to do that—this mismatch is suspicious and needs clarification before use.

Purpose & Capability

The skill explicitly says it will fetch BP data (APIs such as /bp/period/getAllPeriod, /bp/task/v2/getGoalAndKeyResult, POST /bp/task/relation/pageAllReports) and produce artifacts, yet the registry metadata lists no required environment variables, no primary credential, and no network/access configuration. Fetching internal BP APIs normally requires network access and auth credentials (API key, bearer token, service account, or platform-provided identity). The absence of declared credentials or explanation for how the skill will legitimately access the BP system is an incoherence between stated capability and declared requirements.

Instruction Scope

SKILL.md contains detailed runtime instructions to (1) resolve periods/nodes, (2) call specific BP endpoints, (3) collect and adopt evidence, and (4) write multiple intermediate artifacts to disk. That scope is coherent with the description, but it presumes the agent can call the BP system and store local artifacts. The instructions do not list any safeguards (e.g., explicit confirmation before calling external/internal APIs) and implicitly assume privileged access. Because no credentials or explicit authorization steps are declared, the instruction scope may allow unexpected network access or data reads if the runtime provides credentials — this should be made explicit.

Install Mechanism

There is no install spec (instruction-only), which reduces supply-chain risk. However, the package includes two Python scripts (scripts/collect_bp_month_evidence.py and scripts/dump_bp_anchor_map.py) that implement fetch-and-collect logic. Although not auto-installed, these scripts can be executed by the agent and will access network and local filesystem. The presence of executable scripts increases runtime capability compared with pure-text skills and should be reviewed for hardcoded endpoints, credentials, or unexpected external hosts.

Credentials

The skill requests no environment variables or credentials, yet its behavior requires access to BP APIs and possibly other internal services; that normally requires secrets (API tokens, session credentials, or platform-scoped service accounts). The lack of declared env vars is disproportionate to the described functionality. Also, no config paths or I/O constraints are declared even though the skill writes intermediate artifacts (00_intake.yaml, 01_bp_anchor_map.yaml, etc.).

Persistence & Privilege

always is false (normal). Autonomous invocation (disable-model-invocation false) is allowed by default; combined with the skill's ability to fetch and write data this increases potential impact if the agent has network credentials. The skill writes its own intermediate artifacts per references/artifact-layout.md — that is normal for its purpose, but you should confirm where those files are written and whether they persist beyond the agent run.

What to consider before installing

Key things to check before installing or enabling this skill: 1) Credentials and network access: Confirm how the skill will reach your BP system. The skill claims to call internal endpoints but declares no required credentials. Ask the publisher whether it expects platform-provided credentials, user-supplied API tokens, or none. Do not enable autonomous runs until you understand the auth model. 2) Inspect the included scripts: Review scripts/collect_bp_month_evidence.py and scripts/dump_bp_anchor_map.py for hardcoded hosts, IPs, tokens, or unexpected outbound destinations. If you are not comfortable reading Python, ask for a code review from a trusted developer/security contact. 3) Restrict runtime scope: If you allow this skill, prefer requiring explicit user confirmation before any network fetch or before writing artifacts. Consider limiting it to user-invoked runs (no autonomous invocation) until you validate behavior. 4) Artifact storage and privacy: The skill writes intermediate files (00_intake.yaml, evidence ledgers, section cards). Confirm where these are stored, how long they persist, and who can access them; ensure sensitive payroll/personnel data is handled per policy. 5) Ask the publisher for missing metadata: Request a clear statement of required environment variables, OAuth/client credential flows, and a network endpoint allowlist. If the skill cannot provide these, treat its declared capability (automatic BP fetch) as unsupported and consider using the skill in 'user-supplied material' mode only. 6) If you cannot validate the above, sandbox the skill (no network access, limited file write) or decline installation. If you choose to proceed, monitor the agent's first runs for outbound connections and unexpected file writes.

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` 或 BP组织节点ID
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:

• assets/P001-T001-MONTH-TPL-01_月报模板_v1.md
• assets/人力资源中心_月报填写规范_组织示例_v1.md

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. If the user already provides groupId or a BP组织节点ID, use it directly and skip redundant node-name lookup.
• Treat 目标 as the desired end state, 关键成果 as the evaluation basis, and 关键举措 as supporting actions.
• Always fetch 关键举措 metadata together with goals and key results.
• In chapter 2, the traffic-light judgment target is each 关键成果. Do not judge only at the goal heading level. If one subsection contains multiple key results, render separate result blocks and judge each one independently.
• 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.
• If no valid progress report or no credible evidence can support progress judgment for the current month, default to ⚫ rather than 🟡 or 🔴.
• AI may judge an item as ⚫, but AI must not decide the black-light subtype on its own.
• After a ⚫ judgment, the report must explicitly tell the user that black-light subtype requires manual review, and ask the user to choose one of: 未开展/未执行, 已开展但未关联, or 体外开展但体系内无留痕.
• If the user confirms 未开展/未执行, the report must explicitly ask and record what will be done in the next month / next cycle.
• If the user confirms 已开展但未关联, the report must explicitly require BP re-association of the existing work report/material and keep that item as a reminder until the next cycle confirms completion.
• If the user confirms 体外开展但体系内无留痕, the report must explicitly require补充留痕 and improvement of the working method so the same level can be judged in future cycles.
• Every traffic-light judgment in the final report must be followed by an explicit 判断理由.
• In user-facing report markdown, render the whole traffic-light review block in a color that matches the judgment itself: 🟢 uses green text, 🟡 uses yellow text, 🔴 uses red text, and ⚫ uses black or deep gray text.
• Every traffic-light judgment in the final report must also include a short human-review block asking whether the user agrees with the judgment.
• The human-review block must support: 同意 / 不同意.
• If the reviewer disagrees, the block must ask for a reason category and free-text reason.
• Reason categories should at least support: BP不清晰 / 举证材料不足 / AI判断错误 / 其他.
• If the judgment is 🟡 or 🔴 or ⚫, the final report must require a corrective-action block: 整改方案 / 承诺完成时间 / 下周期具体举措.
• 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, BP组织节点ID, or an unambiguous node name

Default minimum call contract:

• bp_period
• node_name or groupId or node_id
• 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.