| name | manage-up-core |
| description | ManageUp 核心方法论：将大模型的空洞报告改造为数据驱动、结论先行的高质量职场报告。Use when writing any workplace report, status update, or professional document for a boss/manager. Triggers on: '写报告', '汇报', 'report', 'write a report', 'status update', '周报', '月报', '项目汇报', '绩效', '提案', '会议纪要', '复盘'. Applies to ALL report types across industries. |
ManageUp 核心方法论
大模型写的报告为什么不好？因为它没有你的数据，只能用空话填充。ManageUp 的核心思路：先收集事实，再组织表达。让 AI 成为你的写作助手，而不是空话制造机。
触发场景
- 用户要求写任何向上汇报类内容，例如周报、月报、项目汇报、绩效自评、提案、会议纪要、复盘
- 用户只给了一个模糊请求，例如“帮我写个报告”“整理成老板能看的版本”
- 其他 ManageUp 技能被触发时，本技能的五大原则默认一并生效
五大原则
所有 ManageUp 技能共享以下原则。生成任何报告前，逐条检查是否违反。
原则一：BLUF — 结论先行 (Bottom Line Up Front)
老板的时间比你贵。第一段就要回答"所以呢？"。
- 报告的第一句话必须是结论、状态或核心请求
- 背景信息放在结论之后，不是之前
- 如果老板只读第一段就关掉，他应该已经知道最重要的事
反面示例：
本周团队在多个方面开展了工作，包括前端优化、后端重构、以及与产品团队的需求对齐……
正面示例：
核心结论：项目整体进度提前 2 天，但支付模块存在一个高风险阻塞项，需要本周五前决策是否增加 1 名后端人力。
原则二：数据锚定 (Data-Anchored)
每一个判断都必须挂钩到用户提供的具体数据。AI 不编造数据，不用模糊词代替数字。
- "进展顺利" → 必须替换为具体完成率、日期、数量
- 没有数据支撑的断言，宁可不写
- 引用用户原始输入中的数字、日期、事实
禁用词 → 替换表：
| 禁用表达 | 替换为 |
|---|
| 取得了一定进展 | 完成率从 X% 提升至 Y% |
| 进展顺利 | 按计划完成 N 项里程碑中的 M 项 |
| 显著提升 | 提升了 X%（从 A 到 B） |
| 有所改善 | 指标从 X 变为 Y |
| 大量工作 | 完成了 N 个任务/处理了 N 个工单 |
| 各方面表现良好 | 在 X、Y、Z 三个维度达标 |
| made good progress | completed N of M milestones |
| significant improvement | improved from X to Y (Z% increase) |
| worked on various tasks | delivered A, B, and C |
| positive feedback | NPS increased from X to Y |
原则三：So-What 测试 (So-What Test)
写完每一段，问自己：老板看完会说"所以呢？"吗？ 如果会，这段话没有价值。
- 每一段必须能回答"这对团队/项目/业务意味着什么？"
- 不是罗列做了什么，而是说明做了之后产生了什么影响
- 如果一件事没有影响，考虑是否值得写进报告
原则四：行动导向 (Decision-Ready)
报告不是日记，是决策工具。每份报告必须明确：
- 需要老板做什么？ → 审批 / 决策 / 知悉 / 协调资源
- 截止时间是什么？ → 何时需要回复或行动
- 不行动的后果是什么？ → 不决策会导致什么延误或损失
如果报告不需要老板做任何事，在开头标注 [仅供知悉 / FYI]。
原则五：校准语言 (Calibrated Language)
消灭模糊词。用精确表达替代笼统描述。
| 模糊 | 精确 |
|---|
| 尽快 | 3月25日前 |
| 部分用户 | 影响了 12% 的付费用户（约 3,400 人） |
| 风险较高 | P1 风险：如不处理将导致上线延迟 5 天 |
| 资源紧张 | 差 1 名后端工程师，当前 3 人承担 4 人工作量 |
| soon | by March 25 |
| some users | 12% of paid users (~3,400) |
| high risk | P1: 5-day launch delay if unresolved |
| resource constrained | need 1 more backend engineer; 3 people covering 4-person workload |
必填输入 (Required Inputs)
在通用场景下，如果用户没有提供足够事实，先一次性收集以下输入：
为了写出一份数据驱动、可汇报的内容，请尽量提供：
1. 你完成了什么：具体交付物、决策、里程碑
2. 关键数据：数量、日期、比例、金额、时长、前后对比
3. 风险或阻塞：卡在哪里、影响多大、需要谁帮助
4. 下一步：接下来最重要的 2-3 件事和目标时间
5. 是否需要老板决策：如果需要，请写明截止时间和不决策的后果
没有的信息可以留空，我不会编造数据。
输入优先工作流 (Input-First Workflow)
这是 ManageUp 最关键的设计：先问，再写。
为什么要先收集输入？
大模型的空话来源于信息不足。当用户只说"帮我写个周报"，AI 没有任何事实可用，只能编造"本周团队积极推进各项工作"这类废话。
ManageUp 的每个技能都包含一个 Required Inputs（必填输入） 清单。在生成报告前，必须先通过提问收集这些信息。
收集输入的原则
- 一次性列出所有需要的输入项，不要一个一个问（减少来回）
- 给出示例，让用户知道该提供什么格式和粒度
- 接受不完美的输入，用户可以用口语化、碎片化的方式提供信息
- 用户没有的数据就留空，不要 AI 编造
- 允许用户用中文或英文提供输入，输出语言跟随用户偏好
输入收集模板
当用户请求写报告但没有提供足够信息时，使用以下格式请求输入：
为了写出一份数据驱动的 [报告类型]，请提供以下信息（可以用口语化的方式，我来帮你整理）：
1. [输入项 1]：例如 [示例]
2. [输入项 2]：例如 [示例]
3. [输入项 3]：例如 [示例]
...
没有的信息可以跳过，我不会编造数据。
受众分析框架
不同受众需要不同的报告风格。在生成报告前，确认受众类型：
| 受众 | 关注点 | 风格 |
|---|
| 直属上级 (Direct Manager) | 细节、执行、风险 | 详细、有数据支撑 |
| 隔级上级 (Skip-level) | 大局、趋势、战略对齐 | 精炼、聚焦结果和影响 |
| 跨部门 (Cross-functional) | 协作点、依赖、时间线 | 去掉专业术语、聚焦接口 |
| 客户/外部 (External) | 价值、进展、信心 | 专业、正面但诚实 |
默认假设受众是直属上级。如果用户指定了不同受众，调整详略程度和用词。
双语策略 (Bilingual Strategy)
ManageUp 同时支持中文和英文输出。
语言检测规则
- 跟随用户输入语言：用户用中文提供输入 → 输出中文报告；用户用英文 → 输出英文
- 混合输入：如果用户混用中英文，默认按占比多的语言输出，或直接询问用户偏好
- 模板双语：技能内部的模板和示例同时提供中英文版本
中文报告风格
- 简洁、有力、不啰嗦
- 使用短句，避免长从句
- 关键数字加粗或独立成行
- 用
· 或 - 做列表，不要大段落
英文报告风格
- Professional, concise, action-oriented
- Use bullet points over paragraphs
- Bold key metrics and decisions
- Avoid passive voice where possible
反空话规则 (Anti-Fluff Rules)
- 没有数据支撑的判断不要写
- 优先把“进展顺利”“积极推进”“表现出色”改成数字、日期、交付物和影响
- 如果一句话不能回答“所以呢”或“老板需要做什么”，就删掉或重写
- 具体替换方式遵循上文“禁用词 → 替换表”和“校准语言”规则
质量检查清单 (Quality Checklist)
每份报告生成后，逐项验证：
与其他 ManageUp 技能的关系
本技能是基础层。以下技能继承本技能的五大原则，并添加各自的报告模板和规则：
| 技能 | 用途 |
|---|
weekly-report | 周报 / 月报 |
project-update | 项目进展汇报 |
performance-review | 绩效自评 |
proposal | 提案 / 资源申请 |
meeting-summary | 会议纪要 |
quarterly-review | 季度复盘 / QBR |
使用任何报告技能时，五大原则和禁用词表自动生效。
