---
name: trend-workflow
description: 把 GitHub 趋势变成自己仓库的改进。每天出趋势日报、对照你的仓库提改进建议，你采纳后自动写 PRD、拆任务建 issue、写 T1 设计草稿、落 PR（只开不合并）。当用户说"跑日报"、"看趋势"、"trend"、"把这个流行项目的思路用在我的仓库上"时使用。
version: 1.0.0
---

# GitHub 趋势工作流（trend-workflow）

## 30 秒速览

1. **准备**：一个中央仓库（放 PRD / issue / 日报 / 看板）+ 你的仓库清单 + GitHub 写权限（`gh` CLI 已登录）。
2. **跑**：说"跑今天的日报" → 得到建议清单 → 你说"都做"或"要第几条"。
3. **收**：每个采纳项自动变成 PRD + 5 个任务 issue + T1 设计草稿 → 落到目标仓库开 PR（只开不合并）→ 你评审、拍板。

## 前置条件

- `gh` CLI 已登录（`gh auth status` 能过），或等效的 GitHub API 写权限。
- 一个中央仓库（建议私有）。首次运行时若不存在，按下面的"中央仓库结构"建好。
- 一份"自有仓库清单"：仓库名 + 一句话说明（存在中央仓库 `repos.yaml`，或每次直接告诉我）。

## 工作流

### Step 1：出日报（每天一次，或按需）

1. 抓 GitHub 趋势：读 `https://github.com/trending?since=daily`（可用浏览器或抓取），取 Top 10~20，记录名称、star 数、许可证、解决什么问题。
2. 先读中央仓库的 `adopted/ADOPTED.md`（已采纳/已拒绝清单）——**已采纳过的方向不再推荐**。
3. 对照"自有仓库清单"，为每个相关仓库提 1~3 条改进建议。每条建议写清：借鉴哪个趋势项目（附许可证）、解决你仓库的什么问题、建议做什么。
4. 日报存中央仓库 `digests/YYYY-MM-DD.md`，把"最值得做的 3~5 条"摘要推给用户。

### Step 2：人采纳

等用户拍板（"都做" / "要第×条" / "不要"）。**不要跳过这步。** 用户说"不要"的，记入 `ADOPTED.md` 拒绝区并写一句话原因。

### Step 3：写 PRD（每个采纳项一个）

PRD 存 `adopted/PRD-<编号>-<slug>.md`，编号全局递增。结构：

```
# PRD-0XX：标题
- 背景（借鉴哪个趋势项目，许可证是什么）
- 目标 / 非目标
- 借鉴对象与许可证声明
- 方案概述
- 任务拆分（T1~T5，对应 issue 号）
- 验收标准
- 风险（含许可证风险）
```

### Step 4：拆任务建 issue（每个 PRD 固定 5 个）

- 在中央仓库建 5 个 issue：T1 设计草稿、T2/T3/T4 实现、T5 文档/验收。
- **先建 issue，拿到真实 issue 号，再写 PRD**（PRD 里引用真实号）。
- issue 标题格式：`[PRD-0XX/T1] 一句话任务`。

### Step 5：T1 设计草稿（只写设计，不写代码）

- 在中央仓库 `adopted/drafts/` 写具体设计文档（字段级、步骤级，不是提纲）。
- 在对应 T1 issue 下留言：要点 + 下一步。
- **T1 永远是设计文档**，不许直接写实现代码。

### Step 6：落 PR（只开不合并）

用户确认 T1 后才落：

1. **查重**：查目标仓库 open 和 closed PR，确认无同分支/同任务的 PR（防重复）。
2. 从目标仓库 main 拉分支 `trend/prd-0XX-t1-<slug>`，把设计文档放 `docs/plans/YYYY-MM-DD-<slug>.md`（纯加法，不碰现有代码）。
3. 开 PR，body 注明：趋势项目 PRD-0XX/T1、中央仓库 PRD 链接、issue 号、**"只开 PR 不合并，等 review"**。
4. **绝不合并**，等用户逐个评审。

多条建议并行时：分仓库并行跑，注意推送冲突（409 重试）。

### Step 7：跟进评审

- PR 评审意见默认修完推送（除非用户要求逐条确认），修完汇报。
- 用户批准合并后才合，合并后验证关键文件在 main 上。
- 用户说"继续 T2"时，按 PRD 任务拆分往下走。

## 铁律（违反任何一条就停下问人）

1. **只开 PR，不合并**——合并权永远在人手里。
2. **T1 永远是设计文档**，不写实现代码。
3. **推荐前先读 ADOPTED.md**，不重复推荐已采纳方向。
4. **许可证红线**（见下表）：高风险许可证只借鉴思路，绝不复用代码，PRD 里明确声明。
5. **落 PR 前查重** open + closed，防重复劳动。

## 中央仓库结构

```
<中央仓库>/
  digests/YYYY-MM-DD.md      # 每日日报原文
  adopted/PRD-0XX-*.md       # PRD 成稿
  adopted/drafts/*.md        # T1 设计草稿
  adopted/ADOPTED.md         # 已采纳/已拒绝清单（防重复）
  STATUS.md                  # 看板：PRD → issue → 目标 PR → 状态
  PLAYBOOK.md                # 沉淀下来的可复用模式
  STATS.md                   # 建议数/采纳数/落地数
  repos.yaml                 # 自有仓库清单（可选）
```

## 许可证红线速查

| 许可证 | 能否复用代码 | 做法 |
|---|---|---|
| MIT / Apache-2.0 / BSD | ✅ | 可复用，注明来源 |
| MPL-2.0（弱 copyleft）| ⚠️ | 当工具/进程调用无传染；不要当 MIT 用 |
| Elastic License 2.0 | ❌ | 只借鉴思路，独立实现 |
| AGPL-3.0 | ❌ | 只借鉴思路，绝不引入代码 |

> 经验：不要信项目文档里写的许可证，用 GitHub License API 实测（曾遇到自称 MIT 实为 MPL-2.0 的项目）。

## PLAYBOOK（8 条可复用模式摘要）

完整版见中央仓库 `PLAYBOOK.md`。摘要：

1. **标准 SKILL.md**：description 放用户口语触发词，顶部 30 秒速览。
2. **只读 MCP**：先做只读 scope，不做写入。
3. **官方插件市场发布**：对齐官方 schema，大包拆小，实份拷贝。
4. **自维护 Wiki**：经验层独立，草稿人工确认才入库。
5. **摘要模式**：三段式摘要 + 开关可回退全量。
6. **独立验收测试**：每个 skill 三层测试，CI 集成。
7. **Harness 生成器**：`capability.yaml` 生成 CLI + SKILL.md 草稿。
8. **Skill 链拆分**：大 skill 按阶段拆，段间 JSON Schema 定契约。

## 给首次使用者的建议

- 先拿 1 个仓库跑通一次完整闭环（日报 → 采纳 → PRD → PR），再扩大到多个仓库。
- 日报建议贵精不贵多：每天 3~5 条最值得做的，比 15 条泛泛的更有用。
- 明确记录"为什么不做"，跟"做了"一样重要。