BP Monthly Report Writer
v0.2.4Draft monthly BP reports by normalizing templates, mapping BP anchors, collecting evidence, and writing sections in order with data-backed progress evaluation.
Like a lobster shell, security has layers — review code before you run it.
License
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
- Read the target month report template.
- Read the user's fill-in specification or a completed sample based on that template.
- Read only the BP and progress materials needed for the current node and person.
- If the data layout is unclear, read references/source-schema.md.
- For the staged workflow, read references/workflow.md.
- For section order and section writing rules, read references/section-order.md.
- If the user supplied a filled sample or fill-in convention, read references/fill-patterns.md.
- When BP system fetching is involved, read references/bp-system.md.
- When status judgment is required, read references/traffic-lights.md.
- When producing deliverables, read references/artifact-layout.md.
- When writing a later month or quarter, read references/rolling-baseline.md.
- When a Chinese business-facing explanation is needed, read references/business-description.zh-CN.md.
- 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
groupIdor an unambiguous node name
Default minimum call contract:
bp_periodnode_nameorgroupIdreport_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:
- Confirm the BP period and target node.
- Normalize the template and extract the exact heading tree.
- Resolve the node inside BP and build a BP anchor map.
- Collect month-specific evidence and map each fact to a BP anchor.
- Prefer using
scripts/collect_bp_month_evidence.pyinstead of ad hoc query code.
- Prefer using
- Build section cards before writing any chapter prose.
- Prefer using
scripts/dump_bp_anchor_map.pyto stabilize the BP skeleton.
- Prefer using
- Draft sections in this order:
2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 1. - 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_summarytemplate_outlinebp_anchor_mapevidence_ledgersection_cardsdraft_v1source_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 totalComments
Loading comments…
