Improve skill quality guardrails and examples

.github/workflows/validate.yml

@@ -0,0 +1,13 @@
+name: Validate Skills
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Validate skill packages
+        run: bash scripts/validate-skills.sh

CONTRIBUTING.md

@@ -0,0 +1,50 @@
+# Contributing to ManageUp
+
+ManageUp is opinionated on purpose. Contributions should make workplace writing more concrete, more decision-ready, and less fluffy.
+
+## Skill package contract
+
+Each skill lives in `skills/<skill-name>/` and must include:
+
+- `SKILL.md`
+- `examples.md`
+
+Most `SKILL.md` files must contain these sections:
+
+- Frontmatter with `name` and `description`
+- `## 触发场景`
+- `## 必填输入`
+- `## 报告模板`
+- `## 反空话规则`
+- `## 质量检查`
+
+Exception:
+
+- `manage-up-core` is the methodology layer, so it may replace `## 报告模板` with methodology-specific sections such as workflow or framework guidance.
+
+`examples.md` must include:
+
+- At least one realistic user input
+- At least one ManageUp output
+- No invented facts beyond the provided input
+
+## Non-negotiable quality rules
+
+- Do not fabricate numbers, dates, names, business impact, or deadlines that the user did not provide.
+- If information is missing, leave it blank, mark it as `[待确认]`, or explain the uncertainty explicitly.
+- Prefer concrete evidence over polished wording.
+- Keep Chinese and English guidance aligned in structure and intent.
+
+## Before opening a PR
+
+1. Run `./scripts/validate-skills.sh`.
+2. Read your examples line by line and remove any unsupported claims.
+3. Check that your skill clearly inherits the ManageUp core principles.
+4. Make sure a new user can understand the skill without extra repo context.
+
+## What good contributions look like
+
+- A new report type with a clear business use case
+- Better examples that demonstrate anti-fluff writing without hallucination
+- Better validation, docs, or installation guidance
+- Smaller wording improvements that make prompts more precise and easier for agents to follow

README.md

@@ -124,6 +124,30 @@ ManageUp 不只是给工程师用的。所有需要写报告给老板的人都
 3. 必须包含反空话规则和质量检查清单
 4. 示例必须包含"空话版 vs ManageUp 版"的对比
 
+开始贡献前，建议先阅读 [CONTRIBUTING.md](CONTRIBUTING.md) 和 [docs/quality-roadmap.md](docs/quality-roadmap.md)，并运行：
+
+```bash
+./scripts/validate-skills.sh
+```
+
+详细规范见 [CONTRIBUTING.md](CONTRIBUTING.md)。
+
+## 质量保障
+
+仓库现在包含一套基础质量门禁：
+
+- `bash scripts/validate-skills.sh` 会检查每个 skill 是否包含必需文件和关键章节
+- GitHub Actions 会在 push / pull request 时自动运行校验
+- `manage-up-core` 现在也包含示例，便于理解方法论本身如何落地
+
+如果你准备新增 skill，建议先跑一次：
+
+```bash
+bash scripts/validate-skills.sh
+```
+
+如果你想先快速感受效果，再决定是否安装，先看 [docs/showcase.md](docs/showcase.md)。
+
 ## License
 
 MIT

docs/quality-roadmap.md

@@ -0,0 +1,57 @@
+# ManageUp Quality Roadmap
+
+## Why this exists
+
+ManageUp already has a clear point of view, but the repository still feels more like a prompt dump than a polished product. This roadmap defines the next quality bar:
+
+- The repo must be trustworthy: examples cannot invent facts the user did not provide.
+- The repo must be maintainable: every skill should follow the same package shape and section contract.
+- The repo must be usable: a new contributor should know how to add or improve a skill without guessing.
+- The repo must be demoable: the value of "anti-fluff" should be obvious within 2 minutes of landing on the repo.
+
+## Current gaps
+
+### P0: Trust
+
+- Some examples add metrics, dates, or business impact that were not present in the user's input.
+- `README.md` says every skill contains `examples.md`, but `manage-up-core` currently does not.
+
+### P1: Maintainability
+
+- There is no automated validation for skill completeness or required sections.
+- There is no contributor guide beyond four short bullets in the README.
+- There is no CI to stop incomplete or inconsistent skill packages from landing.
+
+### P2: Productization
+
+- The repo has good content, but little "show me" packaging: no quick showcase page, no quality rubric, no visible roadmap.
+- Installation and verification guidance exists, but there is no single "how to evaluate output quality" reference.
+
+## Execution plan
+
+### Phase 1: Fix trust and repo hygiene
+
+- Remove invented facts from examples.
+- Add `skills/manage-up-core/examples.md`.
+- Add a validator for required files and section headings.
+- Add CI to run the validator on every change.
+
+### Phase 2: Raise contributor quality
+
+- Add a proper `CONTRIBUTING.md`.
+- Define a standard skill package contract.
+- Require examples to clearly separate user input from generated output.
+
+### Phase 3: Make the repo feel exciting
+
+- Add a showcase doc with strong before/after transformations across roles.
+- Add a "quality rubric" doc that people can use even without installing the skills.
+- Add one or two new high-value skills that extend beyond classic status reports, such as upward email drafts or 1:1 prep.
+
+## Definition of done for a high-quality skill
+
+- `SKILL.md` exists and includes triggers, required inputs, templates, anti-fluff rules, and a quality checklist.
+- `examples.md` exists and does not invent facts outside the user input.
+- The skill works for both Chinese and English requests.
+- The examples show measurable improvement over vague baseline output.
+- The skill passes repository validation.

scripts/validate-skills.sh

@@ -0,0 +1,60 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+repo_root="$(cd "$(dirname "$0")/.." && pwd)"
+skills_dir="$repo_root/skills"
+
+fail() {
+  echo "ERROR: $*" >&2
+  exit 1
+}
+
+[[ -d "$skills_dir" ]] || fail "missing skills directory"
+
+default_required_sections=(
+  "## 触发场景"
+  "## 必填输入"
+  "## 报告模板"
+  "## 反空话规则"
+  "## 质量检查"
+)
+
+core_required_sections=(
+  "## 五大原则"
+  "## 输入优先工作流"
+  "## 质量检查清单"
+)
+
+skill_count=0
+
+for skill_dir in "$skills_dir"/*; do
+  [[ -d "$skill_dir" ]] || continue
+  skill_count=$((skill_count + 1))
+
+  skill_md="$skill_dir/SKILL.md"
+  examples_md="$skill_dir/examples.md"
+
+  [[ -f "$skill_md" ]] || fail "$(basename "$skill_dir"): missing SKILL.md"
+  [[ -f "$examples_md" ]] || fail "$(basename "$skill_dir"): missing examples.md"
+
+  grep -q '^---$' "$skill_md" || fail "$(basename "$skill_dir"): missing frontmatter delimiter"
+  grep -q '^name:' "$skill_md" || fail "$(basename "$skill_dir"): missing frontmatter name"
+  grep -q '^description:' "$skill_md" || fail "$(basename "$skill_dir"): missing frontmatter description"
+
+  required_sections=("${default_required_sections[@]}")
+  if [[ "$(basename "$skill_dir")" == "manage-up-core" ]]; then
+    required_sections=("${core_required_sections[@]}")
+  fi
+
+  for section in "${required_sections[@]}"; do
+    grep -q "$section" "$skill_md" || fail "$(basename "$skill_dir"): missing section '$section'"
+  done
+
+  grep -q '### 用户输入\|### User Input' "$examples_md" || fail "$(basename "$skill_dir"): examples missing user input section"
+  grep -q '### ManageUp 输出\|### ManageUp Output\|### ManageUp 行为' "$examples_md" || fail "$(basename "$skill_dir"): examples missing ManageUp output section"
+done
+
+[[ "$skill_count" -gt 0 ]] || fail "no skills found"
+
+echo "Validated $skill_count skills successfully."

skills/manage-up-core/SKILL.md

@@ -9,6 +9,14 @@ description: "ManageUp 核心方法论：将大模型的空洞报告改造为数
 
 ---
 
+## 触发场景
+
+- 用户要求写任何向上汇报类内容，例如周报、月报、项目汇报、绩效自评、提案、会议纪要、复盘
+- 用户只给了一个模糊请求，例如“帮我写个报告”“整理成老板能看的版本”
+- 其他 ManageUp 技能被触发时，本技能的五大原则默认一并生效
+
+---
+
 ## 五大原则
 
 所有 ManageUp 技能共享以下原则。生成任何报告前，逐条检查是否违反。
@@ -85,6 +93,24 @@ description: "ManageUp 核心方法论：将大模型的空洞报告改造为数
 
 ---
 
+## 必填输入 (Required Inputs)
+
+在通用场景下，如果用户没有提供足够事实，先一次性收集以下输入：
+
+```text
+为了写出一份数据驱动、可汇报的内容，请尽量提供：
+
+1. 你完成了什么：具体交付物、决策、里程碑
+2. 关键数据：数量、日期、比例、金额、时长、前后对比
+3. 风险或阻塞：卡在哪里、影响多大、需要谁帮助
+4. 下一步：接下来最重要的 2-3 件事和目标时间
+5. 是否需要老板决策：如果需要，请写明截止时间和不决策的后果
+
+没有的信息可以留空，我不会编造数据。
+```
+
+---
+
 ## 输入优先工作流 (Input-First Workflow)
 
 这是 ManageUp 最关键的设计：**先问，再写**。
@@ -161,6 +187,15 @@ ManageUp 同时支持中文和英文输出。
 
 ---
 
+## 反空话规则 (Anti-Fluff Rules)
+
+- 没有数据支撑的判断不要写
+- 优先把“进展顺利”“积极推进”“表现出色”改成数字、日期、交付物和影响
+- 如果一句话不能回答“所以呢”或“老板需要做什么”，就删掉或重写
+- 具体替换方式遵循上文“禁用词 → 替换表”和“校准语言”规则
+
+---
+
 ## 质量检查清单 (Quality Checklist)
 
 每份报告生成后，逐项验证：

skills/manage-up-core/examples.md

@@ -0,0 +1,61 @@
+# ManageUp Core Examples
+
+## 示例一：信息不足时先补输入
+
+### 用户输入
+
+```text
+帮我写周报
+```
+
+### ManageUp 行为
+
+```text
+为了写出一份数据驱动的周报，请提供以下信息（可以用口语化的方式，我来帮你整理）：
+
+1. 本周完成的事：例如完成了哪些任务、交付了什么结果
+2. 关键数据/指标：例如 DAU、转化率、工单数、收入、完成率
+3. 风险或阻塞：例如被什么卡住、可能影响什么、需要谁帮助
+4. 下周计划：例如最重要的 2-3 件事和预计日期
+5. 需要老板关注的事（可选）：例如需要审批、协调、拍板
+
+没有的信息可以跳过，我不会编造数据。
+```
+
+### 为什么这符合 ManageUp
+
+- 没有拿着空输入硬写空话报告
+- 一次性收集关键事实，减少来回
+- 明确承诺不会编造数据
+
+---
+
+## Example 2: Same facts, different quality bar
+
+### User Input
+
+```text
+This week I finished the login refactor, fixed 8 bugs, and DAU went from 12,000 to 14,500.
+We are blocked on payment API docs from a third party.
+Next week I need to start push notifications.
+```
+
+### Weak Output
+
+```text
+This week the team made strong progress across multiple areas and continued to improve product quality.
+We also maintained close collaboration with external partners and will keep pushing key initiatives next week.
+```
+
+### ManageUp Output
+
+```text
+Bottom line: login refactor is complete, 8 bugs were fixed, and DAU increased from 12,000 to 14,500 (+20.8%). Main blocker: payment API docs are still missing from the third party, which may delay integration work next week.
+```
+
+### Why it is better
+
+- Starts with the conclusion
+- Uses only facts present in the input
+- Turns a vague blocker into an explicit risk
+- Gives the reader enough context to act

skills/meeting-summary/examples.md

@@ -23,9 +23,9 @@
 ```markdown
 # 会议纪要：v2.0 需求评审会
 
-**日期**：2026.03.19 | **时间**：14:00 - 15:00 | **方式**：线下
+**日期**：[待确认] | **时间**：[待确认] | **方式**：[待确认]
 
-**参会人**：老张（产品总监）、陈工（研发负责人）、小李（前端）、小王（设计）、Alice（QA）
+**参会人**：老张（产品总监）、我（研发负责人）、小李（前端）、小王（设计）、Alice（QA）
 
 ---
 
@@ -44,11 +44,11 @@ v2.0 首页改版确定采用方案 2（低风险迭代 + A/B Test），下周
 
 | # | 事项 | 负责人 | 截止日 | 状态 |
 |---|------|--------|--------|------|
-| 1 | 首页方案 2 设计稿终稿 | 小王 | 3/24（周一） | ⏳ 待完成 |
-| 2 | 反馈模块设计稿 | 小王 | 3/26（周三） | ⏳ 待完成 |
-| 3 | 首页性能排查——前端部分 | 小李 | 3/26 | ⏳ 待完成 |
-| 4 | 首页性能排查——后端部分 | 陈工 | 3/26 | ⏳ 待完成 |
-| 5 | 反馈模块前端开发（设计稿就绪后启动） | 小李 | 4/9（预计 1.5 周） | ⏳ 待设计稿 |
+| 1 | 首页方案 2 设计稿终稿 | 小王 | [待确认] | ⏳ 待完成 |
+| 2 | 反馈模块设计稿 | 小王 | 下周三前 | ⏳ 待完成 |
+| 3 | 首页性能排查——前端部分 | 小李 | [待确认] | ⏳ 待完成 |
+| 4 | 首页性能排查——后端部分 | 我 | [待确认] | ⏳ 待完成 |
+| 5 | 反馈模块前端开发（设计稿就绪后启动） | 小李 | 设计稿完成后约 1.5 周 | ⏳ 待设计稿 |
 
 ## 关键讨论点
 
@@ -64,7 +64,7 @@ v2.0 首页改版确定采用方案 2（低风险迭代 + A/B Test），下周
 
 - 需求：在应用内增加反馈入口（替代当前的邮件反馈）
 - 小李评估：技术可行，前端开发约 1.5 周
-- 阻塞：设计稿预计 3/26 才能完成，开发需等设计
+- 阻塞：设计稿要到下周三才能完成，开发需等设计
 
 ### 首页性能
 
@@ -74,11 +74,11 @@ v2.0 首页改版确定采用方案 2（低风险迭代 + A/B Test），下周
 
 ## 遗留问题
 
-- **暗色模式**：老张提出探索意向，但团队一致认为优先级低于当前需求。暂缓，视 v2.0 完成情况决定是否纳入 v2.1
+- **暗色模式**：老张提出探索意向，但团队一致认为优先级低于当前需求，先暂缓
 
 ## 下次会议
 
-**时间**：3/26（周三）14:00 | **议题**：性能排查结果汇总 + 反馈模块设计评审
+**时间**：[待确认] | **议题**：性能排查结果汇总 + 反馈模块设计评审
 ```
 
 ---