publish

/ouroboros:publish

将 Seed 转换为一个 GitHub Epic issue 和多个 Task issue。全程通过 gh CLI 操作（不使用 MCP），只创建新 issue，绝不修改已有 issue。

ooo publish [seed_path]
/ouroboros:publish [seed_path]

说明

使用当前运行时的 run_shell 能力运行命令，并使用当前运行时的 ask_user 能力询问每个问题。

步骤 1：前置条件

运行 command -v gh。如果未找到，告知用户从 https://cli.github.com/ 安装，然后停止。运行 gh auth status；如果尚未通过身份验证，告知用户运行 gh auth login，然后停止。

步骤 2：定位 Seed

Seed 位于 ~/.ouroboros/seeds/：访谈 Seed 的文件名为 {seed_id}.yaml，PM Seed 的文件名为 pm_seed_{id}.json。按以下优先级查找：

1. 明确指定的 .yaml 或 .json 路径参数。
2. 通过 ls -t ~/.ouroboros/seeds/*.yaml ~/.ouroboros/seeds/*.json 2>/dev/null | head -5 查找最新文件；如果有多个文件，请用户选择。
3. 本次对话中之前由 ooo seed 或 ooo pm 报告的 Seed 路径。

如果未找到 Seed，告知用户先运行 ooo seed 或 ooo pm，然后停止。

步骤 3：解析 Seed

根据扩展名检测格式。如果某个字段缺失或为空，则省略对应部分，而不是报错。

YAML Seed（ooo interview + ooo seed）：

字段	用途
goal	Epic 标题和 Goal 部分
constraints	Constraints 部分
acceptance_criteria	Epic 检查清单，分配到各 Task issue
ontology_schema	本体表（字段、类型、描述）
evaluation_principles	Evaluation Principles 表（名称、权重、描述）
exit_conditions	Exit Conditions（Definition of Done）
metadata.ambiguity_score	置信度指标
metadata.seed_id	重复检测

JSON PM Seed（ooo pm，PMSeed schema）：

字段	用途
pm_id	重复检测
product_name	Epic 标题前缀
goal	Goal 部分
constraints	Constraints 部分
success_criteria	Acceptance Criteria 检查清单
user_stories	User Stories，每项格式为“As a {persona}, I want to {action}, so that {benefit}。”
deferred_items	Deferred Items 部分
decide_later_items	Open Questions 部分
assumptions	Assumptions 部分

步骤 4：目标仓库

运行 gh repo view --json nameWithOwner -q '.nameWithOwner' 2>/dev/null。如果返回一个仓库，询问用户要发布到该仓库还是另一个 owner/repo；否则询问 owner/repo。将答案保存为 TARGET_REPO。之后的每条 gh 命令都必须包含 -R <TARGET_REPO>。

步骤 5：重复检查

gh issue list -R <TARGET_REPO> --label "ouroboros" --state all --search "<seed_id or pm_id>" --limit 5 --json number,title,state

此步骤会查找之前发布的内容，因为 Epic 正文会记录 Seed ID（步骤 7）。如果找到匹配项，列出这些条目，并询问用户是仍要创建还是取消；如果取消，则停止。

步骤 6：规划 issue

将验收标准划分为逻辑实现单元（按功能领域、层级或依赖顺序）；每个单元对应一个 Task。展示计划（Epic 目标摘要，然后是每个 Task 的标题和简要范围），并询问用户是要创建 issue 还是修改计划。如果选择修改，询问要修改什么，调整计划后再次展示。

步骤 7：创建议题

gh issue create 会打印议题 URL；从末尾的数字中提取编号（grep -o '[0-9]*$'）。通过带引号的 heredoc 传递正文（--body "$(cat <<'BODY' ... BODY)"）。

1. 创建标签，忽略“已存在”错误：

   gh label create "ouroboros" -R <TARGET_REPO> --description "Created by Ouroboros publish" --color "6f42c1" 2>/dev/null || true
   gh label create "epic" -R <TARGET_REPO> --description "Epic / parent issue" --color "0075ca" 2>/dev/null || true
   gh label create "task" -R <TARGET_REPO> --description "Implementation task" --color "008672" 2>/dev/null || true
   

2. Epic：标题为 [Epic] <goal summary>，标签为 ouroboros,epic。正文按顺序包含步骤 3 的各个部分（Goal、Constraints、Acceptance Criteria，条目格式为 - [ ]、Ontology、Evaluation Principles、Exit Conditions，以及仅供 PM 使用的部分），然后添加以下页脚：

   ---
   
   **Seed ID**: `<seed_id or pm_id>` | **Ambiguity Score**: <score> | **Seed**: `<seed_file_path>`
   *Generated by [Ouroboros](https://github.com/Q00/ouroboros) via `ooo publish`*
   

3. 每个 Task：标题为 [Task] <task title>，标签为 ouroboros,task。正文依次包含 Parent: #<epic>、Scope、Acceptance Criteria（此单元的条目格式为 - [ ]）、Test Checklist、Pass Criteria（可衡量的完成条件），然后添加以下页脚：

   ---
   
   *Part of [Epic] #<epic> | Generated by [Ouroboros](https://github.com/Q00/ouroboros) via `ooo publish`*
   

4. 在 Epic 下发表评论（gh issue comment <epic> -R <TARGET_REPO>），添加“Implementation Tasks”检查清单，内容为 - [ ] #<task>: <title> 格式的行，并注明通过勾选已关闭的议题来跟踪进度。

步骤 8：总结

显示 Published to <TARGET_REPO>:，并以树形结构列出 Epic 及其 Task（#<n> [Epic|Task] <title>），以及链接 https://github.com/<TARGET_REPO>/issues/<epic>。建议后续步骤：分配任务、在 GitHub Projects 看板上跟踪进度、运行 ooo run 以 AI 辅助实现各个任务。

RFC #1392 状态提示页脚

最终回复必须以且仅以一行 ◆ <current state> → next: <recommended action> 结尾。有 ouroboros_session_status 可用时，从实时会话状态推导状态；否则根据此技能的实际结果推导。不得使用线性的 Step N of M 页脚；如果下一步需要实际选择，请列出 2–3 个选项。