本文へ移動
cccskills
無料GitHub で公開

team-skill-creator

Skill 生命周期治理 / 能力沉淀判断:当用户要新建、导入、合并、发布、更新、弃用、退役或删除一个 可复用 Skill,或要决定它应进入统一公开仓、项目、本地 Agent 或 Multica 时使用。

可用中文唤起:“帮我创建一个 Skill”“把这个流程固化成 Skill”“导入这个 GitHub Skill” “这个 Skill 应该放哪里”“把 Skill 发布到多个 Agent”。只评审现有 SKILL.md 时改用 skill-reviewer。

インストール方法を見る

含まれるファイル(9)

  • SKILL.md14.4 KB
  • agents/openai.yaml258 B
  • evals/evals.json3.1 KB
  • references/assetization-gate.md2.9 KB
  • references/creation-rubric.md7.7 KB
  • references/skill-template-standards.md5.8 KB
  • scripts/create_team_skill.py7.5 KB
  • scripts/inspect_existing_skills.py23.5 KB
  • tests/test_governance_contract.py8.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Skill 生命周期治理(team-skill-creator)

中文速查

  • 中文名:Skill 生命周期治理 / 能力沉淀判断
  • 英文稳定名:team-skill-creator
  • 适合:新建、导入、合并、发布、更新、弃用、退役、删除 Skill,并治理来源与分发目标
  • 不适合:只评审已有 Skill,改用 skill-reviewer;一次性任务不要强行沉淀为 Skill

核心原则

这个 Skill 是治理编排层,不是新的复制工具。先确定能力是否值得沉淀,再确定唯一权威来源、生命周期和目标,最后调用已有工具完成发布与分发。

层级唯一职责不负责
team-skill-creator能力判断、查重、仓库选择、生命周期、验证和发布计划自己实现所有 Agent 的复制协议
GitHub 仓库版本事实源、评审、回滚和公开披露边界直接让每个 Agent 立即可用
Skillshare从聚合目录同步到 Codex、Claude、OpenCode、Qoder、WorkBuddy 等本地目标选择权威仓库或发布 Multica
Multica publisher通过白名单和稳定 ID 发布 Multica Skill 内容管理本地 Agent,或自动决定项目/Agent/小队绑定

禁止对 $SKILLSHARE_SKILLS_ROOT 聚合目录运行 skillshare push。 该目录可能汇集多个来源,不能被当作单一 GitHub 仓库整体发布。GitHub 发布必须在选定的权威 checkout 中精确暂存目标 Skill。

不要替换系统 .system/skill-creator;把它作为结构和脚手架基线。

权威来源决策

先选来源,再写文件:

来源适用条件标准仓库
统一公开仓通用、可复用、来源和许可证允许公开,且通过披露检查PANGKAIFENG/ai-product-manager-skills
项目级只服务单个仓库,依赖其架构、命令或领域约束项目仓库内 .skillshare/skills 或约定目录
本地受限包含客户数据、内部 URL、凭据、个人绝对路径或不可公开来源受控本地目录;先去敏或拆分,不进入公开 catalog
本地草稿尚未通过验证或用户明确要求不发布独立草稿目录,不进入正式分发

通用能力默认以统一公开仓为候选权威源,但公开性不确定时必须停在项目级或本地受限状态。公开发布前检查 secrets、内部 URL、客户数据、许可证和 provenance。不要从 Skillshare 聚合目录反推权威仓库;以 catalog、Git remote 和 Skill provenance 为准。

生命周期

动作处理方式
新增查重后选择来源,创建、验证、评审、合并,再分发
导入记录来源和许可证,决定 new / merge / replace / reject
更新在权威仓库分支修改;skill-creator 负责行为优化,skill-reviewer 负责发布门禁
弃用标记替代项和迁移说明,停止新绑定,保留旧引用
退役停止维护和自动发布,保留墓碑记录与稳定 ID
删除先查引用和影响面,经明确批准后依次处理仓库、catalog、Skillshare 目标和 Multica 映射;必须有回滚方案

默认先弃用或退役,不直接删除。重命名按“新增稳定名称 + 弃用旧名称”处理,避免破坏引用。

Workflow

  1. 用一句话复述要沉淀的能力,并识别本次动作:新增、导入、合并、更新、弃用、退役或删除。
  2. 检查统一公开仓、用户指定项目和本地候选来源的 remote、默认分支、ahead/behind 和 dirty 状态。存在用户改动时使用独立 worktree,不清理或覆盖。
  3. 扫描相似 Skill。至少包含统一公开仓、Skillshare 聚合源、系统 Skills、当前项目和导入来源:
python3 <this-skill>/scripts/inspect_existing_skills.py \
  --name "<candidate-name>" \
  --description "<request summary>" \
  --catalog-root /path/to/ai-product-manager-skills \
  --root /path/to/current-project \
  --import-root /path/to/imported/skills \
  --fetch-catalog --json
  1. 对非平凡或模糊请求先读取 references/assetization-gate.md,再按需读取 references/creation-rubric.md,在 Prompt、Context Pack、Loop、Workflow、Tool、Plugin、App 和 Skill 之间选择最小可靠形态。
    • 先判断是不是一次性工作;重复 AI 协作优先选择 Workflow/Loop,只有稳定原子职责才进入 Skill。
    • 资产化判断和失败归因作为本 Skill 的前置治理阶段,不再提供同触发的独立入口。
  2. 认知类 Skill 在决策前调研经过验证的方法、常见失败模式和 AI 场景可操作性;技术操作类可跳过,但要记录原因。
  3. 选择统一公开仓、项目级、本地受限或本地草稿来源;再确定 category、status、稳定英文名和 provenance。
  4. 读取 skillshare target list --json 动态确认本地目标,不把 Agent 名称硬编码成固定清单。Multica 需求单独记录 workspace 和项目/Agent/小队范围。
  5. 缺少会改变方案的信息时最多问 5 个问题;能从文件、Git 或工具发现的信息不要再问用户。
  6. 写文件前输出 Lifecycle Decision,包含来源、目标、验证、发布、回滚和所需批准。
  7. 获得明确确认后,在选定 Git checkout 的 feature branch 或 worktree 中创建或修改;禁止先写 runtime 副本。
  8. 完成结构校验、行为 eval、前向测试和 skill-reviewer CR。修复 P0/P1;P2 可记录为 backlog,但要说明风险。
  9. 推送 feature branch,通过 PR 或等价评审合并默认分支,并从远端默认分支回读验证。
  10. 只把已合并版本同步到 Skillshare 聚合源,再运行 skillshare sync --json 并验证实际目标。Multica 按独立流程处理。

Context Intake

从对话、catalog、Git 和工具结果中收集:目标用户与复用频率、期望产物、触发与非触发示例、失败成本、公开性、provenance、目标 Agent/项目/Multica workspace、外部写入和回滚要求。只有缺失信息会改变来源、结构、权限或删除决策时才提问;其余内容用明确假设继续。

创建与更新

创建脚手架时必须显式传入选定 Git checkout,避免误写 Codex runtime:

python3 <this-skill>/scripts/create_team_skill.py \
  --name "<skill-name>" \
  --description "<trigger description>" \
  --resources scripts,references \
  --path /path/to/selected-github-checkout \
  --expected-remote git@github.com:<owner>/<repo>.git

更新现有 Skill 时,先保存旧版本和失败证据,按 skill-creator 的 old/new eval 做最小通用改动。最终用 skill-reviewer 审查,不让 Reviewer 代替 Creator 决定产品范围。

导入与合并

对 Git 仓库、市场下载、插件或另一个 Agent 目录中的候选 Skill:

  1. 记录 repo、commit/version、原路径、license 和 import date。
  2. 比较 trigger、workflow、resources、eval、context budget 和维护成本。
  3. 选择 new、merge-into-existing、replace-with-source 或 do-not-import。
  4. 有重叠时优先合并,不制造同触发空间的重复 Skill。
  5. 将 provenance 写入 references/provenance.md 或等价 metadata。

Catalog 与状态

更新与统一公开仓实际 schema 一致的 README.md、SKILL_REGISTRY.md、SKILL_ROUTING.md、catalog/skills.yaml 和必要的安装文档。本地受限能力不进入公开 catalog,也不得通过自造状态值伪装为已发布 Skill。

扫描器无法解析 catalog、remote 不符或默认分支状态未知时,决策必须标记为 blocked,不得把空结果解释为“没有重复 Skill”。

发布门禁

  1. 在 feature branch 上精确暂存目标 Skill、测试和必要 catalog 文件,禁止 git add .。
  2. 运行结构校验、团队 checker、行为测试和 git diff --cached --check。
  3. 推送 feature branch,完成 CR 后合并默认分支;不要绕过审查直接把工作分支推成 main。
  4. fetch 远端并验证默认分支中的 Skill 内容、catalog 和 routing。
  5. 记录 merge commit 和回滚 commit。外部副作用已发生时,回滚代码不等于恢复下游数据,必须单独验证分发回滚。

本地 Agent 分发

GitHub 合并后,先确认本地权威 checkout 已 fast-forward 到远端默认分支,再通过 Skillshare 的安装元数据把已合并 Skill 引入 $SKILLSHARE_SKILLS_ROOT/<skill-name>。不要裸复制:首次安装要登记来源,后续更新要验证登记来源仍指向同一权威 checkout。保留聚合目录中的其他用户改动,不做仓库级 reset、pull 或整体 push。

git -C /path/to/selected-github-checkout fetch origin main
git -C /path/to/selected-github-checkout merge --ff-only origin/main

# 首次进入聚合源:写入 .metadata.json 的 source 与 file_hashes
skillshare install /path/to/selected-github-checkout/<skill-name> --json

# 后续更新:先核对 .metadata.json 中的 source,再预演和更新
jq -e '.entries["<skill-name>"].source == "/path/to/selected-github-checkout/<skill-name>"' \
  "$SKILLSHARE_SKILLS_ROOT/.metadata.json"
skillshare update <skill-name> --dry-run --json
skillshare update <skill-name> --json

# 内容一致后才向 Agent 目标分发
diff -qr /path/to/selected-github-checkout/<skill-name> \
  "$SKILLSHARE_SKILLS_ROOT/<skill-name>"
skillshare target list --json
skillshare sync --dry-run
skillshare sync --json
skillshare status --json

正式同步前必须检查非 JSON dry-run 明细,逐项核对所有 create / update / prune 项列出的 Skill 名称均等于本次目标 Skill。不要用只返回 target 级数量的 JSON 汇总代替名称检查。若出现目标 Skill 之外的变更,或预览无法列出具体 Skill 名称,立即停止,不得执行全量 skillshare sync。先确认当前 CLI 是否支持单 Skill sync;若不支持单 Skill sync,明确报告工具限制,不得通过临时隐藏、覆盖其他 Skill 或扩大同步范围来绕过。

多 Skill 仓库不能把 --skill 与 --track 混用。对单个 Skill 使用上面的 metadata-backed install/update;只有整个仓库本身就是一个允许整体跟踪和分发的专用来源时,才使用 skillshare install <repo> --track。来源不匹配、更新发生冲突或 hash/diff 不一致时停止,不得继续 sync。

以命令返回的真实 targets 为准。当前或未来新增 Agent 通过 Skillshare target 配置接入,不修改 Creator 的业务逻辑。

skillshare sync 会同步全部已配置目标。若用户只允许部分目标,在目标 Skill frontmatter 中声明 metadata.targets: [codex, claude, qoder] 等明确策略,先用 dry-run 验证只有声明目标会变化,再正式同步。若当前 Skillshare 版本或目标适配器不支持该策略,停止并说明限制,不得静默扩大到未授权 Agent。

删除时先 dry-run/影响检查,再使用 Skillshare 的 uninstall/disable/trash 能力并同步;不要直接 rm -rf runtime symlink。

Multica 分发

Multica 是独立 registry;skillshare sync --json 不会更新它。只有存在经过审计的独立 tools/multica-skill-publisher 时才进入该流程:

python3 tools/multica-skill-publisher/publisher.py validate
python3 tools/multica-skill-publisher/publisher.py plan --only <skill-name>
python3 tools/multica-skill-publisher/publisher.py sync --only <skill-name>
  • 新 Skill:先新增 manifest 条目,multica_id: null,执行 --allow-create 计划并获取人工批准;创建后写回稳定 ID。
  • 更新:原位更新同一 ID并回读验证。
  • 引用文件删除:计划中明确 stale files;只有显式批准后才启用 prune,避免静默残留或误删。
  • 弃用/退役:更新 lifecycle,不自动删除远端对象。
  • 项目/Agent/小队绑定:publisher 当前只管理 Skill 内容和 ID。另行输出 workspace -> Skill -> project/agent/squad 部署映射,通过 Multica 支持的 UI/API 执行并回读;没有绑定证据时不得声称部署完成。

输出格式

**Lifecycle Decision**
- Action: <create / import / merge / update / deprecate / retire / delete>
- Recommended shape: <Prompt / Context Pack / Workflow / Tool / Plugin / App / Skill>
- Candidate and overlap: <name, similar Skills, merge decision>
- Authoritative source: <public/private/project/local, repo, branch, clean/ahead/behind>
- Visibility and provenance: <public checks or private reason, source/license>
- Lifecycle/status: <current -> target>
- Catalog plan: <README, registry, routing>
- Local targets: <from skillshare target list>
- Multica scope: <none or workspace/project/agent/squad + manifest action>
- Eval and CR: <baseline, regression, transfer, negative, holdout, reviewer>
- Publish and rollback: <branch, PR/merge, remote verification, rollback>
- Confirmation needed: <exact write/create/delete approval>

完成后输出 Lifecycle Result,逐项报告 GitHub merge commit、验证命令、Skillshare 各 target、Multica ID/绑定证据、未完成项和回滚点。

Definition of Done

满足以下条件才算完成:

  • 能力形态、重叠处理、公开/私有/项目来源和生命周期已明确。
  • 修改发生在选定权威仓库,结构、eval、前向测试和 CR 有新鲜证据。
  • feature branch 已合并,远端默认分支回读一致。
  • 需要本地使用时,已从合并版本更新 Skillshare 聚合源并验证所有声明目标。
  • 需要 Multica 时,manifest、稳定 ID、内容回读和项目/Agent/小队绑定分别有证据。
  • 弃用、退役或删除已完成引用检查、用户批准、迁移说明和回滚验证。

Resource Guide

  • 形态、查重和来源决策:references/creation-rubric.md
  • 是否资产化以及 Skill/Loop/Workflow/Tool 分层:references/assetization-gate.md
  • Skill 内容结构和质量门槛:references/skill-template-standards.md
  • 相似度与 catalog 扫描:scripts/inspect_existing_skills.py
  • 已确认后的脚手架:scripts/create_team_skill.py

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Agent trace 诊断器:当用户提供 trace、日志 JSON、agent 执行记录、工具调用序列,或说“看下这个日志/trace,定位根因”“只说明问题不要改文件”时使用;用中文输出核心根因、可视化执行流程图、trace 证据链、可能文件/行和修复建议,默认只读。不用于没有日志证据的新功能设计、普通代码解释或直接修复代码。

日本語の概要は準備中です。原文の説明を表示しています。

PANGKAIFENG/ai-product-manager-skills162026年8月31日 更新

协作校准 / 认知校准 / 问题脑暴:当用户有模糊感受说不清问题、方案越补越复杂、想挑战假设、 想重新定义问题、想知道成熟领域里怎么叫这个问题时使用。 可用中文唤起:"帮我想想""先聊一下""一起脑暴""我感觉有问题但不清楚是什么" "先别执行,帮我看清问题""挑战我的假设""这个方案是不是想错了""帮我做认知校准" "双向钢人""钢人论证一下""正反最强论证,给我明确判断"。 也适用于:用户直接说"帮我做 X 功能""接入 Y 平台"但背景复杂、或对话早期感觉方向可能跑偏时, AI 主动识别并建议进入脑暴模式。 这里的“挑战假设”主要指问题定义、目标、约束和领域定位层面的假设;如果问题已确认且用户已有具体方案、 计划、架构或决策要压力测试,应转用 grill-me。不用于翻译、摘要、格式整理、单文件小改等简单执行任务。

日本語の概要は準備中です。原文の説明を表示しています。

PANGKAIFENG/ai-product-manager-skills162026年8月31日 更新

AI 工作资产化诊断器 / Assetization Router:当用户提供 AI 协作会话、重复任务、prompt、工作流描述、 团队 AI 使用场景或一次成功交付过程,并要求判断应该沉淀成 Prompt、Context Pack、Workflow、Skill、 Loop、System,或根本不值得沉淀时使用。它只做诊断、分层和下一步资产建议,不替代具体 Skill 创建、 PRD 起草、调研、实现或自动化执行。不用于普通事实查询、一次性文案、trace 根因分析或高责任专业判断。

日本語の概要は準備中です。原文の説明を表示しています。

PANGKAIFENG/ai-product-manager-skills162026年8月31日 更新

设计脑暴 / 实现前方案校准:当用户想把已基本成立的想法、功能方向或产品问题,在写 PRD、画 mockup 或进入开发计划前,先比较方案、确认取舍、对齐 UI/视觉约束,并收敛成可执行设计 spec 时使用。 可用中文唤起:“先脑暴一下方案”“先不要写 PRD,帮我设计几种路径”“参考 brainstorming 把这个需求变成设计 spec” “实现前先讨论设计”。问题还没定义清楚时先用 ai-collaboration-calibration;已有方案要压力测试时用 grill-me; 直接写 PRD 时用 prd-architect;grill-me 返回精确设计 gap 时,本 Skill 只输出 Design Delta。

日本語の概要は準備中です。原文の説明を表示しています。

PANGKAIFENG/ai-product-manager-skills162026年8月31日 更新

竞品决策分析 / Competitive Decision Brief:当用户要调研竞品、替代方案、新产品、SaaS/AI 产品或市场信号, 并希望把官网、定价、评论、文档、更新日志、登录态走查、截图或浏览器取证转成产品定位、路线图、定价、 功能优先级、差异化、Go/No-Go 或 PRD 输入时使用。核心行为是先锚定产品决策,再选择证据渠道, 最后输出可行动的 Product Decision Brief;不要把它降级成泛泛功能清单、纯 UX 走查或“点完所有按钮”报告。

日本語の概要は準備中です。原文の説明を表示しています。

PANGKAIFENG/ai-product-manager-skills162026年8月31日 更新

复杂探索资产化 / Complex Exploration:当用户面对复杂、不确定、多轮迭代的产品策略、Roadmap、商业化定价、竞品定位、复杂 PRD 前置探索、项目复盘或方法论沉淀任务时使用。它先判断任务类型,暴露隐含假设,重构真正问题,规划探索路径和中间产物,并在结束后沉淀认知、结构、方法论、工具和影响力资产。不用于简单润色、翻译、摘要、明确执行任务;问题只需早期认知校准时优先用 ai-collaboration-calibration,已有方案要压力测试时用 grill-me,系统专题研究用 research-topic-compiler。

日本語の概要は準備中です。原文の説明を表示しています。

PANGKAIFENG/ai-product-manager-skills162026年8月31日 更新

PANGKAIFENG のスキルをすべて見る

このスキルの問題を報告する