lls-skill-lifecycle-manager · git:20260727.ddb9af2 · 2026-07-27 · sha256 fd2e1d197405807d

lls-skill-lifecycle-manager git:20260727.ddb9af2A

Immutable. This exact content is served forever at /api/v1/blob/fd2e1d197405807d.

---
name: lls-skill-lifecycle-manager
description: 管理完整 AI Skill 生态与仓库生产线。用于新建、升级、查重、合并、审计、打包、公开发布或恢复 Skill,以及维护私有生产母库、GitHub 公开镜像、Release 安装包、飞书 Skill 专区、WorkBuddy 运行副本和 SkillHub 状态。用户提到 Skill 仓库治理、来源版权、LLS Original/Adapted/Community Pick、版本发布、自动打包、飞书联动、WorkBuddy 对账或“后面持续更新”时使用。
---

# 罗老师 Skill 全生命周期与仓库治理管家

## 核心使命

把 Skill 当作持续迭代的产品,而不是散落的 ZIP、提示词和平台副本。

始终维护一条清楚的生产链:

```text
生产母库
  → 校验与版本
  → 安装包
  → GitHub 公开镜像与 Release
  → 飞书中文说明和下载入口
  → WorkBuddy / SkillHub 安装与运行
  → 使用反馈回到生产母库
```

只允许一个生产真源。公开仓库、飞书、WorkBuddy 和 SkillHub 都是下游渠道。

## 开始前

先声明:

```text
使用 skill:lls-skill-lifecycle-manager,原因:本任务涉及 Skill 的仓库治理、版本、发布或跨平台同步。
```

然后执行只读盘点,不要先改文件:

1. 确认生产母库、公开仓库和目标 Skill。
2. 读取项目级 `AGENTS.md`、`CLAUDE.md` 和现有台账。
3. 检查 Git 状态、远程地址、当前版本和工作区修改。
4. 查找重复 Skill、历史包、平台副本和来源信息。
5. 明确本轮模式、范围、验收标准和高风险边界。

可以运行:

```bash
python3 scripts/audit-repository.py \
  --factory <factory-repo> \
  --public <public-repo> \
  --workbuddy <runtime-skills-dir>
```

## 选择工作模式

| 模式 | 典型请求 | 核心结果 |
|---|---|---|
| 新建 | “把这个流程做成 Skill” | 新母版、台账、包、公开说明 |
| 升级 | “把现有 Skill 提升一下” | 更新同一 Skill、升级版本、保留历史 |
| 发布 | “同步 GitHub 和飞书” | 镜像、Release、下载链接、页面读回 |
| 对账 | “WorkBuddy 里这些要不要导回” | 来源分类、版本差异、回收建议 |
| 审计 | “看看体系有没有乱” | 真源、重复、漂移、隐私和未闭环项 |
| 恢复 | “平台版本比母库新” | 隔离回收、差异审查、确认后合并 |

如果已有 Skill 覆盖主要职责,优先升级、合并或补参考资料。只有边界和用户群明显不同才新建。

## 真源优先级

发生冲突时按这个顺序判断:

1. 私有生产母库的 `skills/<slug>/`
2. 母库台账、版本记录和发布证据
3. GitHub 公开镜像源码
4. GitHub Release 安装包
5. 飞书说明页
6. WorkBuddy、Codex、SkillHub 等运行副本

运行副本出现独有修改时,先进入恢复区并做差异审查,不直接覆盖母版。

详细角色和目录约定见 [references/repository-architecture.md](references/repository-architecture.md)。

## 来源与版权决策

每个公开条目必须选定且展示一种来源:

| 标识 | 类型 | 处理 |
|---|---|---|
| 🔵 `LLS Original` | 罗老师原创 | 完整源码和安装包 |
| 🟡 `LLS Adapted` | 获得许可的改编 | 原作者、原仓库、许可证、版权和修改记录 |
| 🟢 `Community Pick` | 社区实测推荐 | 默认只做中文目录和原仓库链接 |

来源或许可状态不清时,保持链接推荐,不复制源码和安装包。

社区项目优先引导用户支持原作者;罗老师仓库的价值是筛选、测试、中文说明和持续维护目录。

详细规则见 [references/provenance-and-trust.md](references/provenance-and-trust.md)。

## 标准执行流程

### 1. 定义本轮交付

写清楚:

- 目标结果
- 修改范围与明确不做项
- 版本变化
- 2 到 5 条可测试的验收标准
- 测试方式
- 删除、迁移、凭证、付费、最终提交等确认门禁

确认规则:

| 动作 | 执行条件 |
|---|---|
| 只读审计、本地编辑、校验、临时打包 | 明确执行目标后可以推进 |
| GitHub push / Release | 用户本轮明确要求“发布、上线、同步 GitHub”时覆盖本次发布;否则先确认 |
| 飞书写入 | 用户明确要求联动或更新飞书时覆盖本次写入;否则先确认 |
| WorkBuddy 覆盖、批量迁移 | 每次单独确认,并先准备回滚副本 |
| SkillHub 最终提交 | 每次单独确认 |
| 删除旧包、附件、Release、页面 | 每次单独确认 |

### 2. 只改生产母版

- 在 `skills/<slug>/` 新建或更新源文件。
- 不把 WorkBuddy、飞书附件或公开镜像当编辑源。
- 核心流程、判定优先级、失败路径和高风险边界写入 Skill。
- 详细资料放 `references/`,确定性重复操作放 `scripts/`。
- 保持 `SKILL.md` 简洁,避免把完整项目历史塞入上下文。

### 3. 选择版本

- 文案修正、触发优化:patch
- 新增流程、平台或检查项:minor
- 改变核心定位、目录职责或兼容关系:major

生产母库 `publish-info.md` 的“当前版本”是本次发布版本的唯一人工维护入口。总台账、ZIP 文件名、公开 `registry.json`、Release tag、飞书和运行副本都从它同步并做一致性检查,不在多个地方分别决定版本。

更新:

- `publish-info.md`
- Skill 总台账
- 发布队列或发布记录
- 产品功能与交互台账

### 4. 校验与隐私检查

至少检查:

- frontmatter、名称和目录一致
- 必填章节、输出和质量门禁完整
- 无本机绝对路径、密钥、Cookie、账号和客户资料
- 来源类型、许可证和上游链接清楚
- 脚本实际执行通过
- 真实用户请求能够触发并产生交付结果
- 外部命令、Python/Node 包、MCP、账号权限和平台登录要求已在正文或 references 中声明并验证可用

用 [references/test-scenarios.md](references/test-scenarios.md) 的夹具做最小触发测试;根据 Skill 类型补充真实场景。

### 5. 生成可安装包

安装包只包含运行所需文件:

- `SKILL.md`
- `agents/`
- `references/`
- `scripts/`
- `assets/`

生成后必须:

1. 列出 ZIP 内容;
2. 确认包结构为 `<slug>/SKILL.md`,同级放 `agents/`、`references/`、`scripts/`、`assets/`;
3. 在临时目录解压,并确认恰有预期的 `SKILL.md`;
4. 执行随包脚本的代表性测试;
5. 计算 SHA256;
6. 记录版本和证据。

### 6. 生成公开镜像

- 只同步明确批准公开的 Skill。
- 排除 `publish-info.md`、内部台账、上传队列、私有素材和凭证。
- 保留公开仓库独立维护的 README。
- 同步脚本只刷新 `SKILL.md`、`agents/`、`references/`、`scripts/`、`assets/`,不删除公开 README。
- 更新公开 `registry.json` 和来源类型。
- 运行公开仓库的 Skill 与来源校验。

### 7. GitHub 发布

按顺序执行并读回:

1. 提交并推送公开源码;
2. 等待 GitHub Actions 校验成功;
3. 为单个 Skill 生成版本化 Release;
4. 上传 ZIP 和 SHA256;
5. 用公网地址实际下载;
6. 再次解压并检查 `SKILL.md`;
7. 记录源码、Release 和下载地址。

幂等规则:

- 目标 tag 或 Release 不存在:创建。
- 已存在且资产哈希、源码 commit 和版本一致:读回并复用。
- 已存在但内容不同:停止并标记 REWORK,升级版本后重新发布;不覆盖同名历史 Release。
- Actions 默认每 3 到 10 秒读一次,等待 5 分钟;失败先读日志并修复,最多重跑一次。只有同一外部阻塞连续出现至少三轮才标记 BLOCKED。

Star、Watch 和 Download 分开说明:

- ⭐ Star:收藏与支持
- 🔔 Watch Releases:版本通知
- 📦 Download:安装包

### 8. 飞书联动

每个说明页至少包含:

- 一句话用途
- 适用场景
- 来源标识
- 当前版本
- GitHub 源码
- ZIP 下载链接
- 启动语
- 隐私或依赖提醒
- Star / Watch / Download 说明

飞书只负责中文解释和入口,不作为源文件仓库。写入后必须读回标题、版本、源码、下载和来源字段。

使用稳定的 wiki node token 或文档 token 定位现有页面;总索引以 Skill slug 作为唯一键。找不到旧节点时先搜索和查重,再创建新页,避免同名重复。

### 9. WorkBuddy 与 SkillHub 对账

按来源分类:

- 母库已有的运行副本
- 社区或市场安装项
- 本地实验项
- 来源未知项

只在运行副本包含母库没有的新修改时进入恢复流程:

1. 以“上次正式 Release”为基准,对母库、当前 Release、WorkBuddy 做三方比较;
2. 复制 WorkBuddy 当前副本到带时间和版本的隔离恢复区;
3. 比较文件、版本和哈希;
4. 判断新旧方向;
5. 人工确认后合并;
6. 重新走完整发布链。

如果 WorkBuddy 明确比母库旧且没有独有修改:

1. 记录旧文件清单和哈希;
2. 生成可恢复副本;
3. 获得覆盖确认;
4. 用已验证的 Release 包更新;
5. 重载或重新打开运行工具;
6. 执行最小触发测试;
7. 失败时恢复旧副本。

不要批量把平台安装目录倒回母库。

SkillHub 的最终提交、删除旧附件和批量迁移保留用户确认。

### 10. 收口与留下证据

最终报告使用:

| 状态 | 含义 |
|---|---|
| PASS | 已执行并有读回证据 |
| REWORK | 已执行但未达到验收标准 |
| UNCOVERED | 本轮范围内尚未执行 |
| BLOCKED | 连续验证后仍依赖外部变化 |

报告必须包含:

- 改了什么
- 哪些测试通过
- 源码、安装包、GitHub 和飞书入口
- 工作区与远程是否一致
- 未验证项和残余风险
- 下一次最小升级动作

详细检查表见 [references/operating-checklists.md](references/operating-checklists.md)。

## 持续升级机制

每次真实使用后,把反馈分成:

- 触发问题
- 流程缺口
- 平台变化
- 质量门禁不足
- 用户理解成本
- 自动化机会

遵循同一循环:

```text
真实任务
→ 记录证据
→ 找到最小改动
→ 更新母版和版本
→ 重跑发布闭环
→ 读回验证
```

不要为一次偶发现象无限扩张 Skill。重复出现两次以上,或会影响发布正确性、来源可信度和隐私安全时,再沉淀为正式规则。

## 最终质量门禁

- 生产母库是否仍是唯一真源?
- 本轮是否更新了原有 Skill,而不是制造重复 Skill?
- 版本号和变更范围是否匹配?
- 来源、作者和许可证是否清楚?
- ZIP 是否实际解压测试?
- GitHub Actions、Release 和下载是否读回?
- 飞书页面是否写后读回?
- WorkBuddy 副本是否保持下游身份?
- 高风险动作是否保留用户控制权?
- 台账和下一次升级入口是否更新?