/publish

name: publish
description: "Publish Seed specification as GitHub Issues for team-based project management"

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