--- name: Seed slug: seed-2 category: AI Engineering description: Seed generates validated Seed specifications from interview results. Use it to crystallize interview sessions into a YAML seed with ambiguity scoring and QA. github: "https://github.com/Q00/ouroboros/tree/main/skills/seed" language: Python stars: 5431 forks: 550 install: "npx degit https://github.com/Q00/ouroboros/tree/main/skills/seed ~/.claude/skills/seed" installs_to: ~/.claude/skills/seed source_path: skills/seed/SKILL.md collection_size: 25 category_size: 2451 collection_url: "https://dirskills.com/collections/Q00/ouroboros" added: 2026-08-16T07:00:03.442Z last_synced: 2026-08-16T07:00:03.442Z canonical_url: "https://dirskills.com/skills/seed-2" --- # Seed Seed generates validated Seed specifications from interview results. Use it to crystallize interview sessions into a YAML seed with ambiguity scoring and QA. **Install:** ```bash npx degit https://github.com/Q00/ouroboros/tree/main/skills/seed ~/.claude/skills/seed ``` ## README # /ouroboros:seed Generate validated Seed specifications from interview results. ## Required Skill Capabilities - `ask_user` — ask human-judgment questions through the active runtime's user-question surface. - `inspect_code` — read repo-local agent roles and recover exact context from local files before guessing. - `call_mcp` — use available Ouroboros MCP tools directly, including runtime tool discovery when a deferred MCP surface must be loaded. - `run_shell` — run bounded local commands for audit-trail writes and setup steps. - `refine_answer` — confirm free-form user decisions before treating them as accepted seed revisions. - `maintain_ledger` — keep QA scores, candidate decisions, rejected proposals, and audit trail keys visible. ## Usage ``` ooo seed [session_id] /ouroboros:seed [session_id] ``` **Trigger keywords:** "crystallize", "generate seed" ## Instructions When the user invokes this skill: ### Python Runtime (Required) Before running any shell snippet below, define this resolver in the same shell. It accepts only Python 3.12 or newer, prefers `python3` and then `python`, and uses uv as the final fallback. Call `ouroboros_python` directly and quote every argument passed to it; the function preserves arguments and heredoc/stdin input. Only the probe and child interpreter discard inherited CPython path-selection overrides; the caller shell keeps its environment unchanged. ```bash ouroboros_python() { if command -v python3 >/dev/null 2>&1 && (unset PYTHONHOME PYTHONPATH PYTHONPLATLIBDIR PYTHONEXECUTABLE __PYVENV_LAUNCHER__; command python3 -c 'import sys; raise SystemExit(sys.version_info < (3, 12))') >/dev/null 2>&1 then (unset PYTHONHOME PYTHONPATH PYTHONPLATLIBDIR PYTHONEXECUTABLE __PYVENV_LAUNCHER__; command python3 "$@") return fi if command -v python >/dev/null 2>&1 && (unset PYTHONHOME PYTHONPATH PYTHONPLATLIBDIR PYTHONEXECUTABLE __PYVENV_LAUNCHER__; command python -c 'import sys; raise SystemExit(sys.version_info < (3, 12))') >/dev/null 2>&1 then (unset PYTHONHOME PYTHONPATH PYTHONPLATLIBDIR PYTHONEXECUTABLE __PYVENV_LAUNCHER__; command python "$@") return fi if command -v uv >/dev/null 2>&1; then (unset PYTHONHOME PYTHONPATH PYTHONPLATLIBDIR PYTHONEXECUTABLE __PYVENV_LAUNCHER__; command uv run --no-project --quiet --python '>=3.12' python "$@") return fi printf '%s\n' 'Ouroboros skills require Python >= 3.12 or uv on PATH.' >&2 return 127 } ``` ### Load MCP Tools (Required before Path A/B decision) The Ouroboros MCP tools are often registered as **deferred tools** that must be explicitly loaded before use. **You MUST perform this step before deciding between Path A and Path B.** 1. Use the active runtime's `call_mcp` capability to find and load the seed generation MCP tool through runtime tool discovery when needed: ``` tool discovery query: "+ouroboros seed" ``` 2. The tool will typically be named `mcp__plugin_ouroboros_ouroboros__ouroboros_generate_seed` (with a plugin prefix). After runtime tool discovery returns, the tool becomes callable through the active runtime's `call_mcp` capability. 3. If the tool is callable — already exposed, or loaded by discovery — proceed to **Path A**. An empty discovery result for an already-exposed tool is expected, not a failure. Proceed to **Path B** only if the tool is genuinely absent (no Ouroboros MCP server). **IMPORTANT**: Do NOT skip this step. Do NOT assume MCP tools are unavailable just because they don't appear in your immediate tool list. They are almost always available as deferred tools that need to be loaded first. **CRITICAL — deferred-schema guard (prevents "Invalid tool parameters"):** This skill makes `ouroboros_*` MCP calls across multiple turns, and each turn runs in a fresh tool context. A deferred tool's schema loaded on one turn is NOT guaranteed to still be loaded on the next. If you call any `ouroboros_*` MCP tool while its schema is not loaded in the **current** turn, the runtime rejects the call with **"Invalid tool parameters"** before it ever reaches the server. Therefore: **immediately before EVERY `ouroboros_*` MCP call in this skill, re-run the tool-discovery load query for the specific MCP tool you are about to call** (idempotent — a no-op when the schema is already loaded) so the correct schema is guaranteed present for that call. Use `"+ouroboros seed"` before `ouroboros_generate_seed`, `"+ouroboros qa"` before `ouroboros_qa`, and `"+ouroboros lateral"` before `ouroboros_lateral_think`. If a load ever returns no matching tool (and the tool is not already callable — an empty load for an already-exposed tool is an expected no-op, not absence), switch to the documented fallback / Path B instead of retrying the failing call. ### Path A: MCP Mode (Preferred) If the `ouroboros_generate_seed` MCP tool is available (loaded via runtime tool discovery above): 1. Determine the interview session: - If `session_id` provided: Use it directly - If no session_id: Check conversation for a recent `ouroboros_interview` session ID - If none found: Ask the user 2. Call the MCP tool through the active runtime's `call_mcp` capability: ``` Tool: ouroboros_generate_seed Arguments: session_id: ``` 3. The tool extracts requirements from persisted interview state, calculates ambiguity score, and generates the Seed YAML. **Seed generation response shapes**: Branch only after an actual Seed YAML artifact is available. - If the response has `status: "delegated_to_subagent"` and `dispatch_mode: "plugin"`, keep the returned `session_id`, wait for the plugin-managed subagent result, then extract the Seed YAML from that result. Do not enter the QA loop using the delegation envelope as the artifact. - If the response directly contains Seed YAML, extract that YAML directly. - If neither shape yields Seed YAML, stop and ask the user to resume generation or provide the missing artifact; do not fabricate a seed just to satisfy the QA loop. 4. Continue immediately into the required QA Refinement Loop. Do not present the seed as final, ask for acceptance, or proceed to "After Seed Generation" until QA exits with PASS or the user explicitly accepts a below-threshold best attempt at the loop boundary. **Advantages of MCP mode**: Automated ambiguity scoring (must be <= 0.2), structured extraction from persisted interview state, reproducible. ### Path B: Plugin Fallback (No MCP Server) If the MCP tool is NOT available, fall back to agent-based generation: 1. Read `src/ouroboros/agents/seed-architect.md` and adopt that role. 2. Recover the interview requirements before drafting; do not invent missing context: - If `session_id` was provided, first identify context for that same session: use current-thread interview Q&A only when it clearly belongs to that `session_id`, and use current-thread corrections only when they explicitly amend that same interview or seed request. - If same-session conversation context is incomplete, use the active runtime's `inspect_code` / `run_shell` capabilities to look for persisted interview artifacts under the Ouroboros data directory (for example `~/.ouroboros/data/`), exported session artifacts, or other exact local records for that ID. - If both same-session conversation context and a persisted artifact are available, merge them conservatively: keep the persisted transcript as evidence, but let explicit same-thread user corrections or clarifications supersede older persisted wording. - If no `session_id` was provided, use current-thread interview Q&A only when it is complete enough to identify one coherent interview; otherwise ask which interview or requirements summary should be seeded. - If no matching artifact is found, or if local artifacts plus matching conversation history still do not provide enough requirements, ask the user for the missing interview transcript / concise requirement summary, or ask them to run or resume `ooo interview`. Do not generate a seed from an absent or mismatched transcript. 3. Generate a Seed YAML specification from the recovered requirements. 4. Continue immediately into the required QA Refinement Loop. Do not present the seed as final, ask for acceptance, or proceed to "After Seed Generation" until QA exits with PASS or the user explicitly accepts a below-threshold best attempt at the loop boundary. ### QA Refinement Loop (Required after generation) After Path A or Path B produces a seed, **do not present it as final yet**. Run a QA loop until the seed passes a high quality bar. The first generation (Path A `ouroboros_generate_seed` or Path B agent role) runs **exactly once** and establishes the seed's ontology. From there on, **all revisions are direct YAML edits by you (main session)** — do not call `ouroboros_generate_seed` again. It does not accept revision hints, and re-running it would discard the established ontology. **Threshold for seed**: `pass_threshold: 0.90` (stricter than default 0.80 — seeds are structural specs and must be precise). **Max iterations**: 5. Track the highest-scoring seed across all iterations (the "best attempt"). If still not PASS after 5, present that best attempt with its QA verdict and ask the user: accept it as-is, make one final manual edit and accept it below threshold, or escalate to `ooo interview` / `ooo unstuck`. If the user chooses one final manual edit, apply exactly that user-specified edit, present the complete edited Seed YAML in a fenced `yaml` block, and ask for explicit below-threshold acceptance; do not start a sixth QA iteration, rerun QA, or claim the result passed unless the user explicitly asks to rerun QA despite the max-iteration cap. If the user accepts any below-threshold attempt, present the complete accepted Seed YAML in a fenced `yaml` block before proceeding to "After Seed Generation". The seed sits inside the **Define** diamond of Double Diamond — where expansion (Wonder) and convergence (Reflect/Refine/Restate) both happen in service of a single sharp specification. Expansion is not the enemy; **unchecked expansion that bypasses the user gate is.** The four-phase cycle plus User Adoption Gate is the workflow's primary safeguard. **Loop**: 1. Establish the QA evaluator for this run: - **MCP QA mode**: Load the QA tool via the active runtime's `call_mcp` capability using runtime tool discovery query `"+ouroboros qa"` if not already loaded. - **Fallback QA mode**: If MCP is unavailable, read `src/ouroboros/agents/qa-judge.md`, adopt that evaluator role, and return its exact JSON schema: lowercase `verdict` (`pass`/`revise`/`fail`), numeric `score`, `dimensions`, `differences`, `suggestions`, and `reasoning`. In this mode there is no MCP-owned `qa_session_id`; track iteration history in the audit block and local loop ledger instead. 2. Obtain a QA verdict using the available mode: **MCP QA mode** — call QA on the generated seed through the active runtime's `call_mcp` capability: ``` Tool: ouroboros_qa Arguments: artifact: quality_bar: "Seed must be internally consistent, acceptance_criteria must be measurable and testable, constraints must be concrete (no vague terms), ontology_schema must cover all entities referenced in goal/criteria, and there must be no contradictions between fields. acceptance_criteria must also be parsimonious in the ontological sense: a criterion names a state of the finished work a user can see is true, while an implementation step names a means of reaching it, and only the first belongs in the list. Read each criterion beside its siblings — one intelligible only as a move toward a sibling is that sibling's means and belongs merged into the outcome it serves, and flagging that is as important as flagging a missing piece, since it commits the seed to an unverified path. How many criteria a goal has follows from that judgment, so weigh each criterion against its siblings." artifact_type: "document" pass_threshold: 0.90 seed_content: qa_session_id: iteration_history: ``` **Fallback QA mode** — skip the tool call and evaluate the current seed text under the QA Judge role from step 1, using the same quality bar and threshold. Treat the locally produced verdict exactly like the MCP verdict for the PASS/REVISE/FAIL branch below. **QA response shapes**: Branch only after a usable verdict is available. - In MCP QA mode, if the response has `status: "delegated_to_subagent"` and no verdict payload, keep the returned `qa_session_id`, wait for the plugin-managed subagent result, then parse that result as the QA verdict. Do not treat the delegation envelope itself as PASS/REVISE/FAIL. - In MCP QA mode, if the response already includes a scored verdict, parse that inline verdict directly. - In fallback QA mode, parse the exact QA Judge JSON. Normalize `verdict` to uppercase only for the branch labels below (`pass`→PASS, `revise`→REVISE, `fail`→FAIL). Treat `differences` as blocking/revision issues and `suggestions` as proposed fixes; do not add non-schema fields such as `loop_action`. - In all modes, append the parsed verdict plus applied/rejected revision decisions to `iteration_history` before the next QA pass. 3. Branch on verdict: - **PASS (>= 0.90)**: Exit loop. Present the final validated Seed YAML to the user, then proceed to "After Seed Generation" below. - **REVISE (0.40–0.89)**: Run the **Wonder → Reflect → Refine → Restate** cycle below, then loop back to step 2. - **FAIL (< 0.40)**: Stop the loop. The seed has fundamental issues that regeneration likely won't fix. Show the full verdict and recommend `ooo interview` to revisit requirements, or `ooo unstuck` to challenge assumptions. Do not proceed to celebration. 4. On iteration N >= 3, briefly tell the user "Refining seed (iteration N/5)..." so they know progress is being made — but do not dump full verdicts each round; only deltas. 5. After PASS, show a one-line summary of the journey: `Seed passed QA at iteration N/5 with score X.XX.` 6. Immediately after that PASS summary, present the complete final validated Seed YAML in a fenced `yaml` block. This must happen before any "After Seed Generation" celebration, star prompt, setup prompt, or next-step text. #### Wonder → Reflect → Refine → Restate (REVISE branch) This revision loop mirrors the Double Diamond Define cycle: **diverge via multiple perspectives first, then converge through debate, user decision, and structural application.** Revisions must NEVER be auto-applied by the main session alone — *"No candidate is accepted by default."* (Symposium User Adoption Gate) Four explicit phases per iteration: - **Wonder** — diverge: collect raw proposals from independent sources - **Reflect** — debate: surface where sources agree and where they conflict - **Refine** — user gate: human picks which proposals enter the next seed - **Restate** — apply: edit YAML in place with accepted items only **Phase 1 — Wonder (diverge): collect raw proposals from available sources** **Source 1 — QA Judge** (structural, external) The `suggestions` from the QA verdict. These are gaps, contradictions, and quality issues in the YAML itself. QA cannot see the interview. **Source 2 — Socrates** (dialectical, user-intent evidence) You are Socrates — the Socratic facilitator lens from `skills/interview/SKILL.md` and `src/ouroboros/agents/socratic-interviewer.md`. Review the current seed YAML against verifiable interview evidence, in this order: 1. If a `session_id` exists, first use available persisted interview/session state for that session. Path A may run from `ooo seed ` in a fresh conversation, so persisted state can be the only reliable dialectic record. 2. Use conversation memory when it is available in the current thread. 3. If no persisted state or conversation evidence is available for a point, mark Socrates output as `no Socrates-only proposal: dialectic context unavailable` for that point. Do not invent user preferences, rejected scope, or interview nuance. From the available evidence, surface 2–4 items neither QA nor lateral personas can see: - Did the user emphasize a constraint that got softened or dropped? - Did something the user explicitly rejected sneak back in? - Did the seed flatten nuance the user spent multiple turns clarifying? - Are there silent assumptions the user never agreed to? - Does wording contradict stated priorities (e.g., "MVP in a week" but 8 acceptance criteria)? If QA and Socrates conflict, do not resolve the conflict silently in Wonder. Carry both candidates into Reflect as a divergent signal, cite the available evidence for each side, and let the Refine user gate choose the resolution. Do not assume the Socratic lens is automatically authoritative; QA can be correct when no user-intent evidence contradicts it. **Source 3 — `ouroboros_lateral_think` (independent perspectives, MCP-only when available)** Attempt to load the MCP tool with the active runtime's `call_mcp` capability using runtime tool discovery query `"+ouroboros lateral"` if needed. If the tool loads, call it through the active runtime's `call_mcp` capability to collect 5 independent MCP personas or isolated perspectives: ``` Tool: ouroboros_lateral_think Arguments: problem_context: | Seed is in REVISE state (QA score X.XX, threshold 0.90). Current seed YAML: QA suggestions: - - Original user goal from interview: current_approach: "The seed as currently drafted (above)." persona: "all" failed_attempts: - - ... ``` The 5 personas return distinct revision angles: - **hacker**: unconventional workarounds (e.g., reframe a constraint instead of adding criteria) - **researcher**: knowledge the seed assumes but doesn't pin down - **simplifier**: criteria/constraints to *remove* for sharper convergence - **architect**: structural reorganization without expansion - **contrarian**: challenges to assumptions the seed treats as settled **Parsing persona outputs when lateral MCP is available**: Each persona returns free-form prose, not a structured list. After the parallel call returns, read each persona's text and extract its concrete proposals into discrete candidates (one revision per candidate, not bundled). If a persona's output is purely abstract advice with no actionable revision, drop it from the candidate list rather than inventing one. Aim for 1–2 candidates per persona — if a persona produced 5, pick the 2 most concrete and discard the rest. **Lateral response shapes**: `ouroboros_lateral_think` does not have one universal synchronous shape. After calling it with all personas, branch on the returned shape before extracting candidates: - **Plugin delegation**: If the response has `status: "delegated_to_subagent"`, `dispatch_mode: "plugin"`, and an `_subagents` array, wait for every plugin-managed subagent result. Extract concrete revision candidates from those returned persona texts. Do not attempt to parse candidates from the envelope prompts themselves. - **Inline fallback with dispatch block**: If the response returns markdown `content` plus the hidden sentinel ``, keep the visible markdown as the lateral scaffold. If the active runtime can dispatch isolated subagents, decode the sentinel JSON (`dispatch_mode`, `persona_count`, `payloads`) and send each `payload.prompt` + `payload.context` through that isolated subagent surface, then extract candidates from the returned persona texts. If the runtime cannot dispatch subagents, synthesize candidates directly from the visible inline persona sections. - **Inline fallba