Agent trace 诊断器:当用户提供 trace、日志 JSON、agent 执行记录、工具调用序列,或说“看下这个日志/trace,定位根因”“只说明问题不要改文件”时使用;用中文输出核心根因、可视化执行流程图、trace 证据链、可能文件/行和修复建议,默认只读。不用于没有日志证据的新功能设计、普通代码解释或直接修复代码。
日本語の概要は準備中です。原文の説明を表示しています。
Skill 生命周期治理 / 能力沉淀判断:当用户要新建、导入、合并、发布、更新、弃用、退役或删除一个 可复用 Skill,或要决定它应进入统一公开仓、项目、本地 Agent 或 Multica 时使用。
可用中文唤起:“帮我创建一个 Skill”“把这个流程固化成 Skill”“导入这个 GitHub Skill” “这个 Skill 应该放哪里”“把 Skill 发布到多个 Agent”。只评审现有 SKILL.md 时改用 skill-reviewer。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
team-skill-creatorskill-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 映射;必须有回滚方案 |
默认先弃用或退役,不直接删除。重命名按“新增稳定名称 + 弃用旧名称”处理,避免破坏引用。
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
references/assetization-gate.md,再按需读取 references/creation-rubric.md,在 Prompt、Context Pack、Loop、Workflow、Tool、Plugin、App 和 Skill 之间选择最小可靠形态。
skillshare target list --json 动态确认本地目标,不把 Agent 名称硬编码成固定清单。Multica 需求单独记录 workspace 和项目/Agent/小队范围。Lifecycle Decision,包含来源、目标、验证、发布、回滚和所需批准。skill-reviewer CR。修复 P0/P1;P2 可记录为 backlog,但要说明风险。skillshare sync --json 并验证实际目标。Multica 按独立流程处理。从对话、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:
new、merge-into-existing、replace-with-source 或 do-not-import。references/provenance.md 或等价 metadata。更新与统一公开仓实际 schema 一致的 README.md、SKILL_REGISTRY.md、SKILL_ROUTING.md、catalog/skills.yaml 和必要的安装文档。本地受限能力不进入公开 catalog,也不得通过自造状态值伪装为已发布 Skill。
扫描器无法解析 catalog、remote 不符或默认分支状态未知时,决策必须标记为 blocked,不得把空结果解释为“没有重复 Skill”。
git add .。git diff --cached --check。main。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 是独立 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>
multica_id: null,执行 --allow-create 计划并获取人工批准;创建后写回稳定 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/绑定证据、未完成项和回滚点。
满足以下条件才算完成:
references/creation-rubric.mdreferences/assetization-gate.mdreferences/skill-template-standards.mdscripts/inspect_existing_skills.pyscripts/create_team_skill.pyまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Agent trace 诊断器:当用户提供 trace、日志 JSON、agent 执行记录、工具调用序列,或说“看下这个日志/trace,定位根因”“只说明问题不要改文件”时使用;用中文输出核心根因、可视化执行流程图、trace 证据链、可能文件/行和修复建议,默认只读。不用于没有日志证据的新功能设计、普通代码解释或直接修复代码。
日本語の概要は準備中です。原文の説明を表示しています。
协作校准 / 认知校准 / 问题脑暴:当用户有模糊感受说不清问题、方案越补越复杂、想挑战假设、 想重新定义问题、想知道成熟领域里怎么叫这个问题时使用。 可用中文唤起:"帮我想想""先聊一下""一起脑暴""我感觉有问题但不清楚是什么" "先别执行,帮我看清问题""挑战我的假设""这个方案是不是想错了""帮我做认知校准" "双向钢人""钢人论证一下""正反最强论证,给我明确判断"。 也适用于:用户直接说"帮我做 X 功能""接入 Y 平台"但背景复杂、或对话早期感觉方向可能跑偏时, AI 主动识别并建议进入脑暴模式。 这里的“挑战假设”主要指问题定义、目标、约束和领域定位层面的假设;如果问题已确认且用户已有具体方案、 计划、架构或决策要压力测试,应转用 grill-me。不用于翻译、摘要、格式整理、单文件小改等简单执行任务。
日本語の概要は準備中です。原文の説明を表示しています。
AI 工作资产化诊断器 / Assetization Router:当用户提供 AI 协作会话、重复任务、prompt、工作流描述、 团队 AI 使用场景或一次成功交付过程,并要求判断应该沉淀成 Prompt、Context Pack、Workflow、Skill、 Loop、System,或根本不值得沉淀时使用。它只做诊断、分层和下一步资产建议,不替代具体 Skill 创建、 PRD 起草、调研、实现或自动化执行。不用于普通事实查询、一次性文案、trace 根因分析或高责任专业判断。
日本語の概要は準備中です。原文の説明を表示しています。
设计脑暴 / 实现前方案校准:当用户想把已基本成立的想法、功能方向或产品问题,在写 PRD、画 mockup 或进入开发计划前,先比较方案、确认取舍、对齐 UI/视觉约束,并收敛成可执行设计 spec 时使用。 可用中文唤起:“先脑暴一下方案”“先不要写 PRD,帮我设计几种路径”“参考 brainstorming 把这个需求变成设计 spec” “实现前先讨论设计”。问题还没定义清楚时先用 ai-collaboration-calibration;已有方案要压力测试时用 grill-me; 直接写 PRD 时用 prd-architect;grill-me 返回精确设计 gap 时,本 Skill 只输出 Design Delta。
日本語の概要は準備中です。原文の説明を表示しています。
竞品决策分析 / Competitive Decision Brief:当用户要调研竞品、替代方案、新产品、SaaS/AI 产品或市场信号, 并希望把官网、定价、评论、文档、更新日志、登录态走查、截图或浏览器取证转成产品定位、路线图、定价、 功能优先级、差异化、Go/No-Go 或 PRD 输入时使用。核心行为是先锚定产品决策,再选择证据渠道, 最后输出可行动的 Product Decision Brief;不要把它降级成泛泛功能清单、纯 UX 走查或“点完所有按钮”报告。
日本語の概要は準備中です。原文の説明を表示しています。
复杂探索资产化 / Complex Exploration:当用户面对复杂、不确定、多轮迭代的产品策略、Roadmap、商业化定价、竞品定位、复杂 PRD 前置探索、项目复盘或方法论沉淀任务时使用。它先判断任务类型,暴露隐含假设,重构真正问题,规划探索路径和中间产物,并在结束后沉淀认知、结构、方法论、工具和影响力资产。不用于简单润色、翻译、摘要、明确执行任务;问题只需早期认知校准时优先用 ai-collaboration-calibration,已有方案要压力测试时用 grill-me,系统专题研究用 research-topic-compiler。
日本語の概要は準備中です。原文の説明を表示しています。