/publish

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

/ouroboros:publish

Convert a Seed specification into structured GitHub Issues for team workflows.

Usage

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

**Trigger keywords:** "publish to github", "create issues from seed", "seed to issues"

Instructions

When the user invokes this skill:

Step 1: Prerequisite Check

**1a. Verify `gh` CLI is installed:**

command -v gh >/dev/null 2>&1 && echo "OK" || echo "MISSING"

If missing, tell the user:

GitHub CLI (gh) is not installed.
Install it: https://cli.github.com/

Stop.

**1b. Verify `gh` is authenticated:**

gh auth status

If not authenticated, tell the user:

GitHub CLI is not authenticated. Run: gh auth login

Stop.

Step 2: Locate the Seed

Ouroboros stores seeds in `~/.ouroboros/seeds/`:

• **Interview seeds**: `~/.ouroboros/seeds/{seed_id}.yaml` (YAML)
• **PM seeds**: `~/.ouroboros/seeds/pm_seed_{id}.json` (JSON)

Determine the Seed source in this priority order:

1. **Explicit path argument**: If the user provided a file path (`.yaml` or `.json`), read it directly 2. **Most recent seed file**: Search for the most recent seed in the standard location:

   ls -t ~/.ouroboros/seeds/*.yaml ~/.ouroboros/seeds/*.json 2>/dev/null | head -5

If multiple seeds exist, present the top candidates via AskUserQuestion and let the user choose. 3. **Conversation context**: If `ooo seed` or `ooo pm` was just run in this conversation and the seed path was reported, use that path.

If no seed is found:

No Seed found. Run `ooo seed` or `ooo pm` first to generate a specification.

Stop.

Step 3: Parse the Seed

Detect the file format by extension and parse accordingly:

**For YAML seeds** (from `ooo interview` + `ooo seed`): Read the YAML file and extract:

• `goal` → Epic title and description
• `constraints` → Listed in Epic body
• `acceptance_criteria` → Checklist items in Epic + distributed to Task issues
• `ontology_schema` → Documentation section in Epic
• `evaluation_principles` → Quality criteria reference
• `exit_conditions` → Definition of Done
• `metadata.ambiguity_score` → Confidence indicator
• `metadata.seed_id` → Used for duplicate detection

**For JSON seeds** (from `ooo pm`): Read the JSON file and extract fields using the actual `PMSeed` schema:

| PMSeed field | Maps to | |-------------|---------| | `pm_id` | Seed identifier (for duplicate detection) | | `product_name` | Epic title prefix | | `goal` | Epic Goal section | | `constraints` | Epic Constraints section (array of strings) | | `success_criteria` | Acceptance Criteria checklist (array of strings) | | `user_stories` | User Stories section (array of `{persona, action, benefit}`) | | `deferred_items` | Deferred Items section (array of strings) | | `decide_later_items` | Open Questions section (array of strings) | | `assumptions` | Assumptions section (array of strings) |

Format user stories as: "As a **{persona}**, I want to **{action}**, so that **{benefit}**."

If any field is missing or empty, omit that section from the Epic body rather than failing.

Step 4: Detect Repository

**4a. Attempt auto-detection from current directory:**

gh repo view --json nameWithOwner -q '.nameWithOwner' 2>/dev/null

**4b. Present the target repo choice via AskUserQuestion:**

If auto-detection succeeded:

{
  "questions": [{
    "question": "Publish Seed as GitHub Issues to this repository?",
    "header": "Target Repository",
    "options": [
      {"label": "<detected_repo>", "description": "Use current repository"},
      {"label": "Other", "description": "I'll specify a different owner/repo"}
    ],
    "multiSelect": false
  }]
}

If auto-detection failed (not in a git repo):

{
  "questions": [{
    "question": "Which GitHub repository should the issues be created in? (format: owner/repo)",
    "header": "Target Repository"
  }]
}

If the user chose "Other", ask:

{
  "questions": [{
    "question": "Enter the target repository (format: owner/repo):",
    "header": "Target Repository"
  }]
}

Store the resolved repository as `TARGET_REPO`. **All subsequent `gh` commands MUST include `-R <TARGET_REPO>`** to ensure they target the correct repository.

Step 5: Duplicate Check

Before creating issues, check if this seed was already published:

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

The search uses the seed's unique identifier (`metadata.seed_id` for YAML seeds, `pm_id` for JSON seeds). This works because Step 7 persists the identifier in the Epic body (see the `Seed ID` field in the Epic template).

If matching issues are found, warn the user via AskUserQuestion:

{
  "questions": [{
    "question": "Found existing Ouroboros issues that may be from the same seed:\n\n<list of matching issues>\n\nCreate new issues anyway?",
    "header": "Duplicate Warning",
    "options": [
      {"label": "Create anyway", "description": "Proceed with new issues"},
      {"label": "Cancel", "description": "Do not create duplicate issues"}
    ],
    "multiSelect": false
  }]
}

If "Cancel": Stop.

Step 6: Plan Issue Structure

Before creating issues, present the planned structure to the user for review.

**6a. Break down acceptance criteria into Task groups:**

Analyze the acceptance criteria and group them into logical implementation units. Each unit becomes a Task issue. Use your understanding of the domain to create meaningful groupings (e.g., group by feature area, layer, or dependency order).

**6b. Present the plan via AskUserQuestion:**

{
  "questions": [{
    "question": "Here's the planned issue structure:\n\n**Epic**: <goal summary>\n\n**Tasks**:\n1. <task_1_title> — <brief scope>\n2. <task_2_title> — <brief sco