/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:

1. An explicit .yaml or .json path argument.
2. 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.
3. 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)").

1. 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
   

2. 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`*
   

3. 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`*
   

4. 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.