/ouroboros:publish
Convert a Seed into a GitHub Epic issue plus Task issues. Works entirely through the gh CLI (no MCP), creates new issues only, and never modifies existing ones.
ooo publish [seed_path]
/ouroboros:publish [seed_path]
Instructions
Run commands with the active runtime's run_shell capability and ask every question with the active runtime's ask_user capability.
Step 1: Prerequisites
Run command -v gh. If missing, tell the user to install it from https://cli.github.com/ and stop. Run gh auth status; if not authenticated, tell the user to run gh auth login and stop.
Step 2: Locate the Seed
Seeds live in ~/.ouroboros/seeds/: interview Seeds as {seed_id}.yaml, PM Seeds as pm_seed_{id}.json. In priority order:
- An explicit
.yaml or .json path argument.
- The most recent files from
ls -t ~/.ouroboros/seeds/*.yaml ~/.ouroboros/seeds/*.json 2>/dev/null | head -5; if several exist, ask the user to choose.
- A Seed path reported by
ooo seed or ooo pm earlier in this conversation.
If none is found, tell the user to run ooo seed or ooo pm first, and stop.
Step 3: Parse the Seed
Detect the format by extension. Omit any section whose field is missing or empty rather than failing.
YAML Seed (ooo interview + ooo seed):
| Field | Use |
|---|
goal | Epic title and Goal section |
constraints | Constraints section |
acceptance_criteria | Epic checklist, distributed to Task issues |
ontology_schema | Ontology table (field, type, description) |
evaluation_principles | Evaluation Principles table (name, weight, description) |
exit_conditions | Exit Conditions (Definition of Done) |
metadata.ambiguity_score | Confidence indicator |
metadata.seed_id | Duplicate detection |
JSON PM Seed (ooo pm, PMSeed schema):
| Field | Use |
|---|
pm_id | Duplicate detection |
product_name | Epic title prefix |
goal | Goal section |
constraints | Constraints section |
success_criteria | Acceptance Criteria checklist |
user_stories | User Stories, each as "As a {persona}, I want to {action}, so that {benefit}." |
deferred_items | Deferred Items section |
decide_later_items | Open Questions section |
assumptions | Assumptions section |
Step 4: Target repository
Run gh repo view --json nameWithOwner -q '.nameWithOwner' 2>/dev/null. If it returns a repo, ask whether to publish there or to another owner/repo; otherwise ask for owner/repo. Store the answer as TARGET_REPO. Every later gh command MUST include -R <TARGET_REPO>.
Step 5: Duplicate check
gh issue list -R <TARGET_REPO> --label "ouroboros" --state all --search "<seed_id or pm_id>" --limit 5 --json number,title,state
This finds earlier publishes because the Epic body records the Seed ID (Step 7). If matches exist, list them and ask whether to create anyway or cancel; on cancel, stop.
Step 6: Plan the issues
Group the acceptance criteria into logical implementation units (by feature area, layer, or dependency order); each unit becomes one Task. Show the plan (Epic goal summary, then each Task title and brief scope) and ask whether to create the issues or modify the plan. On modify, ask what to change, adjust, and show it again.
Step 7: Create the issues
gh issue create prints the issue URL; take the number from its trailing digits (grep -o '[0-9]*$'). Pass bodies through a quoted heredoc (--body "$(cat <<'BODY' ... BODY)").
- Create labels, ignoring "already exists":
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
- Epic: title
[Epic] <goal summary>, labels ouroboros,epic. Body: the Step 3 sections in order (Goal, Constraints, Acceptance Criteria as - [ ] items, Ontology, Evaluation Principles, Exit Conditions, plus the PM-only sections), then this footer:
---
**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`*
- Each Task: title
[Task] <task title>, labels ouroboros,task. Body: Parent: #<epic>, then Scope, Acceptance Criteria (- [ ] items for this unit), Test Checklist, Pass Criteria (measurable done conditions), then this footer:
---
*Part of [Epic] #<epic> | Generated by [Ouroboros](https://github.com/Q00/ouroboros) via `ooo publish`*
- Comment on the Epic (
gh issue comment <epic> -R <TARGET_REPO>) with an "Implementation Tasks" checklist of - [ ] #<task>: <title> lines, noting progress is tracked by checking off tasks as their issues close.
Step 8: Summary
Show Published to <TARGET_REPO>: with the Epic and its Tasks as a tree (#<n> [Epic|Task] <title>) and the link https://github.com/<TARGET_REPO>/issues/<epic>. Suggest next steps: assign tasks, track on a GitHub Projects board, run ooo run for AI-assisted implementation of individual tasks.
RFC #1392 State Breadcrumb Footer
End the final response with exactly one line ◆ <current state> → next: <recommended action>. Derive the state from live session state via ouroboros_session_status when available, otherwise from this skill's actual outcome. Never use a linear Step N of M footer; when the next step is a real choice, list 2-3 options.