ideate

name	ideate
description	Generate and critically evaluate grounded Infiquetra product, architecture, or workflow ideas. Multi-agent divergent→convergent engine — generate many, critique all, explain survivors only. Triggers on "ideate on X", "give me ideas", "what should I improve", "surprise me", "what would you change".

Ideate

Generate and critically evaluate grounded Infiquetra ideas. The engine generates many candidates across parallel frames, critiques all of them, and explains only the survivors — with their rejection reasons preserved and revivable.

/ideate sits in the Think phase, before /brainstorm and /plan:

• /office-hours answers: "What is even the right frame here?"
• /ideate answers: "What are the strongest ideas worth exploring?"
• /brainstorm answers: "What exactly should one chosen idea mean?"
• /plan answers: "How should it be built?"

This skill produces a ranked ideation artifact under docs/ideation/. It does not produce requirements, plans, or code.

Core principles

1. Ground before ideating. Scan the actual repo, journal, and relevant context-libraries first. Do not generate abstract advice detached from the infiquetra world.
2. Generate many → critique all → explain survivors only. The quality mechanism is explicit rejection with reasons, not optimistic ranking. Extra process must not obscure this.
3. Two-way partnership. AI-generated and user-supplied ideas enter the same pool and face the same critique. User seeds are fed into the frame agents to build on / challenge / combine — never just judged at the end, never rubber-stamped, never silently dropped.
4. Rejection is first-class and revivable. Cut ideas keep stable IDs and can be revived — but only by re-entering the filter with new evidence (see the convergence reference).

Interaction method

Use the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded). Fall back to numbered options in chat only when no blocking tool exists or the call errors. In a channel session, inline the choices in the reply text. Never silently skip a gate question. Ask one question at a time.

Operator-absence contract (#371). Every known-set gate above declares what happens on silence, and the declaration above this line is the contract. HALT here: stop and wait. A timeout, a widget error, or a dropped session is never consent — do not proceed on a default and do not invent an answer. Ask one question at a time and read the decision from the operator's actual answer, never from a widget's raw return value.

Engine Offer

Before offering an external-engine lane for ideation, run python3 plugins/saga/scripts/engine_offer.py offer --stage ideate --repo-root . --attended. If the helper reports prompt_required, this skill owns the AskUserQuestion or channel-inline prompt and then persists the selected preference with engine_offer.py remember. The offer is advisory only; it never dispatches, scores, or gates ideas.

The offer prompt rides the durable gate-record contract declared in Interaction method (gate id ideate-engine-offer-<run-id>): open before prompting, satisfy on answer, resolve-absent on silence (HALT).

Focus hint

<focus_hint> #$ARGUMENTS </focus_hint>

Treat any argument as optional context: a concept (DX improvements), a path (plugins/unifi/), a constraint (low-complexity quick wins), a backlog phrasing (themes in our open issues), or a volume hint (top 3, 100 ideas, raise the bar). With no argument, proceed open-ended.

---

Phase 0: Scope, grounding-fit gate, and seed capture

0.1 Resume check

Look in docs/ideation/ for ideation docs from the last 30 days. Treat one as relevant when the topic matches, the path/subsystem overlaps, or the request is open-ended with one obvious recent open doc. Keep issue-grounded and non-issue ideation as distinct topics — do not offer to resume across that boundary. If a relevant doc exists, ask whether to continue (read it, summarize what was explored, preserve prior idea statuses, update the file in place) or start fresh.

0.2 Grounding-fit gate — ASK when unsure, never silently auto-route

Every downstream agent needs an identifiable subject and enough grounding to say something specific. Weigh the idea's breadth against the available grounding — the current repo, relevant *-context-library repos, and any named infiquetra repos. There are four outcomes. When the call is not obvious, ask rather than auto-deciding; a vibe-check that routes silently is the failure this gate exists to prevent.

Outcome 1 — Clearly groundable → proceed. The idea is bound to grounding you can actually reach:

• Repo-bound — the idea lives inside the current repo. Example: sitting in infiquetra-claude-plugins, /ideate quick wins in the unifi plugin — the plugin source is right here.
• Multi-repo with named repos — the idea spans repos and names them. Example: /ideate how campps-auth and campps-identity-access should share session state — both repos exist and are named, so grounding is bounded. Record the named repos; Phase 1 grounds against each of them through the named-repo reader (Source 3).
• Inside a *-context-library with an idea that library grounds. Example: sitting in mimir-context-library, /ideate gaps in our mimir routing taxonomy — the library is exactly the substance the idea needs. Record that the current repo is itself a *-context-library; Phase 1 threads this flag so the library is read locally in place as the primary grounding (Source 4), not re-fetched over gh as if it were a remote. When it is borderline whether the library actually grounds the idea (vs. the idea being broader than the library's domain), lean to the Case B ask below rather than silently proceeding.

State the inferred framing in one plain sentence ("Treating this as a topic inside the unifi plugin — about X") and proceed. Never print internal routing labels. Carry forward two facts the gate establishes for Phase 1: the named repos (when the multi-repo branch fired) and whether the current repo is itself a *-context-library (when the in-library branch fired).

Outcome 2 — Out of the engineering domain → politely decline / redirect. The subject has no software surface in the infiquetra world — coffee, branding independent of a product, personal decisions, non-digital business strategy. Example: /ideate names for my side coffee roastery → decline: "That's outside what /ideate grounds against — I'd be generating ungrounded slop. Want to take it to a general chat instead?" Redirect kindly; do not run the engine. When a subject sits on the engineering / non-engineering line — "the infiquetra brand voice in our docs", "our developer-onboarding experience" — do not hard-decline; ask which side it is on (ground it as an engineering topic, or take it to general chat), per ASK-when-unsure.

Outcome 3 (Case A) — Unframed / cannot settle a scope → recommend /office-hours. The prompt refers only to a quality or placeholder, not a subject — improvements, ideas, what to build, things to fix, an empty prompt — and no repo footprint settles it. Being inside a repo does not settle this: improvements in infiquetra-claude-plugins still scatters across DX, reliability, new plugins, docs, and tests. Example: /ideate ideas with nothing else → "There's no settled subject here for the agents to work on. /office-hours is built for finding the frame first — want to start there?" Recommend /office-hours; proceed only if the operator declines, and only after asking them to name a subject or pick "surprise me."

Cheap disambiguation before asking: if a short phrase might name something (browser sniff, dark mode), Glob filenames or Grep the README/docs for it. Any footprint → treat as identifiable and proceed. No footprint and still reads as a bare quality → Case A.

Outcome 4 (Case B) — Broad relative to grounding but still infiquetra → surface the mismatch and ASK, leaning /office-hours. The idea is legitimately infiquetra but far broader than the grounding you are sitting in. Example: sitting in mimir-context-library, /ideate the whole infiquetra plugin marketplace strategy — real infiquetra topic, but the library grounds mimir, not the marketplace. Surface it plainly: "You're in mimir-context-library, but this idea spans the whole marketplace — the grounding here won't carry it. /office-hours fits a question this broad better. Or name the repos it should span and I'll ground against each of them. Proceed broad in place anyway?" Lean office-hours; proceed broad in-place only if the operator declines the redirect. If the operator takes the "name the repos" offer, record those repos and ground against them via the named-repo reader (Source 3) — do not promise grounding the engine cannot reach. If they decline and proceed broad in-place without naming repos, note that grounding will be thin (only the library you are sitting in), and weight survivors accordingly.

0.3 Capture user seed ideas

Ask whether the operator already has ideas they want in the run. Capture each verbatim as a user-seed candidate. These are partnership inputs: they will be passed into the Phase 2 frame agents to build on / challenge / combine, AND enter the merged pool, AND face the identical Phase 3 critique. They are never rubber-stamped and never silently dropped. If the operator has none, note "no user seeds" and proceed — generation does not depend on them.

0.4 Focus, volume, and adaptive frame count

Infer two things from the focus hint and intake:

• Focus context — concept, path, constraint, backlog phrasing, or open-ended.
• Volume override — honor clear hints: top 3, 100 ideas, go deep, raise the bar.

Tactical-scope detection. Scan the focus for tactical signals: polish, typo, typos, quick wins, small improvements, cleanup, small fixes, or a single narrow file/line. When present, lower the Phase 2 ambition floor (the meeting-test is waived) — the operator has opted into tactical scope.

Adaptive frame count (1–6) by scope. Frame agents run on the inherited model — no tier-down (creative ideation needs full reasoning). Scale the count to scope:

• Tactical / single narrow file or fix → 1 frame (or a single orchestrator pass for a true one-liner).
• Narrow — one flow, one stage, one plugin → 2–3 frames.
• Standard subsystem or component → 4 frames.
• Broad — whole repo, multi-repo, or a sweeping product/architecture question → all 6 frames.

Default per-frame target is ~6–8 raw candidates; volume overrides adjust it.

0.5 Cost notice

Before dispatching, state the agent count in one line so multi-agent cost is not invisible. Count = grounding agents (current-repo scan + journal-learnings, always; named-repo reader, one per repo the gate recorded for a multi-repo or "name the repos" ask; context-library reader when a relevant library exists; issue read+cluster only on backlog intent; web only for the cross-domain frame or on request) + N frame agents. When backlog intent fires (Source 5), the frame count is the theme-frame count (≤4 — see Phase 2's backlog override), not the adaptive N above; state that count. The line is informational; the operator need not ack it.

Example: "Will dispatch ~7 agents: current-repo scan + journal-learnings + context-library reader + 4 frame agents. Skip phrases: 'no web research'." Example (multi-repo): "Will dispatch ~8 agents: current-repo scan + journal-learnings + named-repo reader x2 (campps-auth, campps-identity-access) + 4 frame agents." Example (tactical): "Will dispatch ~3 agents: current-repo scan + journal-learnings + 1 frame agent."

---

Phase 1: Grounding

Generate a <run-id> once (8 hex chars). Create the scratch directory and capture its absolute path for every checkpoint write this run:

SCRATCH_DIR=".claude/saga/ideate/<run-id>"
mkdir -p "$SCRATCH_DIR"
echo "$SCRATCH_DIR"

Use the echoed path as <scratch-dir>. Scratch lives under .claude/saga/ — it is ignored local state, never /tmp and never a durable doc.

Dispatch the grounding agents in parallel, in the foreground (results are needed before Phase 2). Each agent below carries its verbatim tuned prompt — dispatch it with that prompt body, not a generic "scan the repo" instruction. The prompt body is the repeatability guarantee.

Source 1 — Current-repo scan (always)

Dispatch an Explore (or general-purpose) sub-agent on the cheapest capable model with this prompt verbatim, substituting {focus_hint}:

Read the project's AGENTS.md (or CLAUDE.md as a compatibility fallback, then README.md if neither exists). Read STRATEGY.md if present — it captures the repo's target problem, wedge, persona, non-goals, and success criteria. Discover the top-level directory layout with the native glob tool (Glob pattern * then */*). Read docs/engineering-journal/ if present for the project's own record of how it thinks.

For other root-level *.md files: if the focus hint names one specifically (e.g. "ideate based on FEEDBACK.md"), fully read it and include its substantive content under a heading User-named references — Phase 2 treats these as constraint, so quote real content, not a gist. For any other root-level *.md files, read briefly and give a one-line gist under Additional context — Phase 2 treats these as background.

Return a concise summary (under 40 lines, longer only if user-named references carry substantive content) covering:

• project shape (language, framework, top-level layout)
• notable patterns or conventions
• obvious pain points or gaps
• likely leverage points for improvement
• product/technical strategy summary if STRATEGY.md was present — include the wedge and active direction verbatim so ideation can weight toward strategy-aligned moves
• User-named references section (when the focus named root-level *.md files)
• Additional context section (when other root-level *.md files exist)

Keep the scan shallow otherwise — top-level docs and directory structure only. Do not analyze GitHub issues, templates, or contribution guidelines. Do not do deep code search.

Focus hint: {focus_hint}

Source 2 — Journal-learnings (always)

Read the current repo's own engineering journal directly (no separate agent needed if the current-repo scan already loaded it; otherwise dispatch a sub-agent with this prompt verbatim):

Read docs/engineering-journal/LEARNINGS.md and docs/engineering-journal/DECISIONS.md in this repo. Return only the entries relevant to this ideation focus: prior empirical findings, the mechanisms behind them, and any architecture/convention/tooling decisions (with their "revisit when" conditions) that bear on the focus. For each, give the one-line generalizable rule and a file:line or entry-date reference. Skip everything unrelated to the focus. If either file is absent, say so and return nothing for it.

Focus hint: {focus_hint}

Surfaced learnings/decisions become direct: basis material for Phase 2 — an idea that contradicts a recorded decision must engage that decision's "revisit when" condition or be cut.

Source 3 — Named-repo reader (when the gate recorded named repos)

Trigger when Phase 0's gate recorded named repos — a multi-repo ask (how campps-auth and campps-identity-access should share session state) or the Case B "name the repos it should span" offer. This is the source that makes the gate's multi-repo promise real: it reads each named repo the operator actually named, not just the current repo. Dispatch one reader sub-agent per named repo in parallel, each with this prompt verbatim, substituting the repo name and focus:

You are reading the {repo_name} infiquetra repo for material relevant to this ideation focus — this repo is in scope because the operator named it. Prefer the local clone at ~/workspace/infiquetra/{repo_name} when it exists (faster and matches the working tree); otherwise read via gh api / gh repo view. Read the repo's AGENTS.md (or CLAUDE.md as a compatibility fallback, then README.md), STRATEGY.md if present, and the top-level directory layout relevant to the focus. Keep the scan shallow — top-level docs and the layout that bears on the focus only; do not do deep code search. Return: (1) the repo's shape, conventions, and the part of it the focus touches; (2) any constraint or contract this repo imposes that a cross-repo idea would have to honor (e.g., the session-token shape it already emits); (3) file:line or doc-name references so Phase 2 can cite direct: basis. If the repo cannot be reached (no clone and gh fails), say so plainly and return nothing for it.

Repo: {repo_name} Focus hint: {focus_hint}

The returned repo shapes and cross-repo constraints become direct: basis material for Phase 2 — a cross-repo idea that violates a contract a named repo already imposes must engage it or be cut. On a per-repo read failure, follow warn and proceed ("Could not ground against {repo}: {reason}. Proceeding with the repos that read.") — never block on one unreachable repo.

Source 4 — Context-library reader (when a relevant library exists)

Current-repo short-circuit. When Phase 0's gate flagged that the current repo is itself a *-context-library (the in-library branch of Outcome 1), that library is the primary grounding and is already in the working tree. Do not re-fetch it over gh — read it locally in place: point a reader sub-agent at the current working directory using the verbatim prompt below with {library_name} set to the current repo and the local-clone path being . (the current repo), and treat its output as the primary context-library context. Reserve gh-based discovery and remote reads for OTHER topic-relevant libraries. This keeps the explicit library framing the gate said was "exactly the substance the idea needs" and avoids a slower, staler remote double-read of the repo you are standing in.

Then discover any OTHER libraries by pattern (skip the current repo in the results when it is itself a context-library — it is already covered by the short-circuit above):

gh repo list infiquetra --limit 300 --json name --jq '.[].name' | grep -i context-library

Pick the topic-relevant ones (e.g. mimir-context-library for mimir/routing topics, campps-context-library for campps topics, infiquetra-context-library for org-wide conventions). For each relevant library, dispatch a reader sub-agent with this prompt verbatim, substituting the library name and focus:

You are reading the {library_name} context-library repo for material relevant to this ideation focus. Prefer the local clone at ~/workspace/infiquetra/{library_name} when it exists (faster); otherwise read via gh api / gh repo view. Read the library's README.md and top-level layout first to understand what domain it grounds, then read only the documents relevant to the focus. Return: (1) the context this library establishes that bears on the focus — conventions, taxonomies, prior analyses, constraints; (2) any explicit guidance the library gives that an idea would have to honor; (3) file:line or doc-name references so Phase 2 can cite direct: basis. Skip everything unrelated. If nothing in the library bears on the focus, say so plainly and return nothing.

Library: {library_name} Focus hint: {focus_hint}

If no *-context-library is topic-relevant, skip this source and note it in the cost notice.

Source 5 — Issue read + cluster (ONLY on backlog intent)

Trigger only when the topic is explicitly about the backlog — phrasings like open issues, issue themes, issue patterns, what users are reporting, bug reports. Do not trigger on a focus that merely mentions a bug (bug in auth, the signup bug). There is no mission-control dependency — this is a read-only gh read plus local clustering. Dispatch a sub-agent with this prompt verbatim, substituting the repo and focus:

Run this read-only command and cluster the results — do not mutate any issue, do not call mission-control:

gh issue list --repo {repo} --state open --json number,title,body,labels --limit 200

Group the open issues into 3–6 coherent themes by what they are actually about (not by label alone). For each theme return: a short theme name, the issue numbers in it, a one-line description of the shared problem, and a rough sense of how many issues and how recent. If fewer than 5 open issues exist, say "insufficient issue signal for theme analysis" and return the raw list. Each theme becomes candidate Phase 2 material, so make the shared problem concrete enough to ideate against.

Repo: {repo} Focus hint: {focus_hint}

When usable themes return, they seed the Phase 2 frames (see Phase 2). On error (gh missing, no remote, auth failure) warn "Issue analysis unavailable: {reason}. Proceeding with standard ideation." and continue.

Source 6 — Web (smart-auto)

Off by default for internal topics. Engage only for the cross-domain-analogy frame (Frame 5) or on explicit request. Never pass repo contents, journal entries, or context-library material out. When engaged, dispatch a web-research sub-agent with this prompt verbatim:

Research external prior art and cross-domain analogies for this ideation focus. Do not assume any private repository context — operate purely from the focus description below. Return: named prior art and adjacent solutions (with sources), and 2–3 structurally analogous problems from unrelated fields (other industries, biology, games, infrastructure, history) with a one-line note on how each solved it. Cite every source so Phase 2 can use it as external: basis. Push past the obvious first analogy.

Focus hint (no private context): {focus_hint}

Honor skip phrases ("no web research"); note the skip in the grounding summary.

Consolidate

Merge all results into one grounding summary with these sections (omit any that produced nothing): Repo context (project shape, patterns, pain points, leverage points, strategy); User-named references (constraint); Additional context (background); Journal learnings; Named-repo context (per named repo, with its cross-repo constraints — when the gate recorded named repos); Context-library context (per library); Issue themes (when backlog intent fired); External context (when web ran). Grounding failures follow warn and proceed — never block on a grounding miss. Phase 1.5 appends a Topic axes section to this same summary.

---

Phase 1.5: Topic-surface decomposition

Decompose the subject into 3–5 orthogonal axes naming what aspects to think about. Frames (Phase 2) determine how to think; axes determine what to think on. Without an explicit axis list, parallel frames converge on whichever interpretation is most salient at first read and the rest of the surface goes unexamined — lens diversity alone does not produce surface coverage.

This is a single orchestrator-side analysis against the grounding summary already in context. No sub-agent, no extra grounding read, no user-facing question.

Axis criteria: 3–5 axes; orthogonal (one idea falls on one axis — merge heavy overlaps); derived from the actual grounding, not a generic template; at the same level (don't mix "the whole plugin" with "one frontmatter field"); named in the topic's language a reader would recognize.

Worked examples (illustrative — derive yours from real grounding):

Topic	Axes
Improve the unifi plugin	Endpoint coverage; dry-run ergonomics; error handling; output formatting; auth/session robustness
mimir routing taxonomy	Route definitions; classification signals; fallback behavior; observability of routing decisions
campps session-state sharing across services	Token shape; storage/replication; invalidation triggers; cross-service contract

Skip condition (atomic subjects). Some subjects resist meaningful decomposition: a single string output (a name, a tagline), a narrow tactical fix ("the typo on line 47"), or a topic where the candidate axes are the deliverable. When 3+ orthogonal axes passing the criteria cannot be generated, skip decomposition and note Decomposition skipped — atomic subject in the grounding summary so the artifact records the choice.

Append the axis list (or skip-reason) under a Topic axes section. Phase 2 threads axes into frame prompts; Phase 3 uses them for axis-spread scoring; Phase 5's artifact records them.

---

Phase 2: Divergent ideation

Generate the full candidate list before critiquing anything.

Dispatch the N frame agents chosen in Phase 0.4 in parallel, on the inherited model (no tier-down). Omit any mode parameter so the operator's permission settings apply. Each agent targets ~6–8 raw candidates (adjust for volume overrides). Each frame is a starting bias, not a cage — begin from the assigned lens but follow any promising thread; cross-cutting ideas that span frames are valuable.

The six frames (select the adaptive subset; for partial counts take them in this order):

1. Pain & friction — what is consistently slow, broken, or annoying for the user, operator, or maintainer.
2. Inversion / removal / automation — invert a painful step, remove it entirely, or automate it away.
3. Assumption-breaking & reframing — what is treated as fixed that is actually a choice; reframe one level up or sideways.
4. Leverage & compounding — choices that make many future moves cheaper or stronger; second-order effects.
5. Cross-domain analogy — how a structurally analogous problem is solved in an unrelated field (other industries, biology, games, infrastructure, history). This is the frame that may engage web (Source 6). Push past the obvious analogy.
6. Constraint-flipping — invert the obvious constraint to its opposite or extreme (budget 10x or 0; team of 100 or 1; 0 users or 1M). Use the resulting design as a candidate even if the flip itself is unrealistic.

Backlog-intent override. When Source 5 returned usable issue themes, turn each high-signal theme into a frame; pad from the six-frame pool (in the order above) if fewer than 3 theme-frames exist; cap at 4 frames total.

Frame-agent prompt (verbatim — dispatch each frame agent with this, substituting its frame, the grounding summary, the axis list, the per-agent target, the captured user seeds, and whether the run is tactical scope):

You are generating raw ideation candidates for this Infiquetra topic through ONE assigned lens. Generate candidates only — do not critique, rank, or filter. Your first few ideas will be the obvious ones; push past them to the non-obvious. Target ~{per_agent_target} candidates.

Your frame (starting bias, not a cage): {frame_name} — {frame_description}. Begin from this lens but follow any promising thread; a strong idea that spans frames is welcome.

Grounding summary (your substance — every idea must be grounded in it): {grounding_summary}

Focus: {focus_hint}

Topic axes (the surface map — distribute your ideas across them; tag each idea with the one axis it most centrally targets; reach a plausible axis at least once before doubling up): {axis_list} ← omit this whole block when decomposition was skipped; do not invent axes

User seed ideas — engage these directly, do not just restate them. For each seed, do at least one of: build on it (extend or strengthen it through your lens), challenge it (surface a flaw or a better alternative your lens reveals), or combine it (merge it with another seed or one of your own into something stronger). Treat seeds as peers to generate against, not as fixed requirements and not as answers: {user_seeds} ← when there are no seeds, state "No user seeds — generate freely."

Constraint vs background: the focus hint, the operator's prompt, and any User-named references are CONSTRAINTS — an idea that violates them is out regardless of basis. The rest of the grounding (repo context, additional context, journal learnings, context-library context, external context) is BACKGROUND — it can support a basis and inform direction but must not pull ideation toward whatever was loudest in the corpus.

Per-idea contract — every idea returns exactly this, and an idea with no articulated basis does NOT surface:

• title
• summary (2–4 sentences)
• axis — required when an axis list was given above; pick the single axis this idea most centrally targets; do not span. Omit only when decomposition was skipped.
• basis (required, tagged — one of):
  • direct: a quoted line / specific file / named issue / explicit user-supplied context or seed it builds on
  • external: named prior art / domain research / adjacent pattern, with its source
  • reasoned: an explicit, written-out first-principles argument for why this move applies — not a hand-wave; the argument is spelled out
• why_it_matters — connects the basis to why the move is significant
• meeting_test — one line confirming this would warrant team discussion. Tactical scope: {tactical_scope} — when this is "yes", waive the meeting-test and state "tactical — meeting-test waived" for each idea. The orchestrator sets this flag from Phase 0.4; do not try to infer tactical scope yourself.

Bias toward the basis type your frame naturally produces (pain/inversion/leverage → direct:; analogy/constraint-flipping → reasoned: or external:; assumption-breaking → mixed) but do not exclude other types. Stay within the subject's identity: expansions, new surfaces, and pivots are fair game when the basis supports them, but moves that abandon or replace the subject are out regardless of basis. When the focus names a slice (one flow, one plugin, one stage), ideate at full ambition within that slice — do not widen the surface to the whole product.

External-engine generator lane (additive, blind, best-effort). In addition to the N Claude frame agents, attempt one chaperoned external-engine generator lane. Use the existing chaperone-dispatch posture offload with sonnet/medium; do not route this generator lane through the stage-offer second-opinion default. Assign the lane an ordinary Phase 2 frame value: use the next unused frame from the ordered frame pool when one exists, otherwise reuse the frame whose lens best fits the focus.

Give the lane the same substituted frame-agent prompt above — frame, grounding summary, focus, topic axes, per-agent target, captured user seeds, constraint/background split, and tactical-scope flag. Do not add an external-engine-only prompt variant, do not relax the per-idea basis contract, and do not include any raw candidates or merged candidate pool in the prompt. The lane is blind by construction: its output first meets the Claude frame-agent output at the merge boundary below.

If the external-engine dispatch is unavailable, lacks credentials, times out, or returns an adapter error, record a non-blocking note and continue with the Claude-only frame-agent set. Do not halt /ideate, do not create a partial-failure state, and do not ask Phase 3 to compensate for the missing lane.

After all available generator lanes return:

1. Merge and dedupe every frame agent's candidates into one master candidate list, keeping sub-agent (frame) attribution. For candidates produced by the external-engine generator lane, also tag the candidate provenance engine-generated. Do not apply engine-generated to Claude frame-agent, user-seed, interview, or combined candidates.
2. Add the user seeds to the pool as user-seed candidates (if not already absorbed by a frame agent that built on them). A seed a frame only challenged or rejected — rather than building into a promoted idea — still enters the pool as its own peer candidate; never drop a seed because a frame rejected a variant of it. Seeds face the identical Phase 3 critique — they are peers in the pool, never auto-promoted.
3. Synthesize cross-cutting combinations — scan for ideas from different frames that combine into something stronger; expect roughly 3–5 additions. Tag combined ideas with their source frames.
4. Axis-coverage check (when Phase 1.5 produced axes; skip otherwise) — count ideas per axis after dedupe. For any axis with zero ideas, dispatch one recovery frame agent (an unused frame, or the frame whose lens best fits the missing axis) targeting that axis with the same per-idea contract and ~3–5 ideas. Cap recovery at 2 axes — beyond that, accept thin coverage and note empty axes as axis: <name> — recovery skipped (cap reached) for the rejection summary. Merge recovery output and dedupe again.
5. If a focus was given, weight the merged list toward it without excluding stronger adjacent ideas. Spread across dimensions when justified: workflow/DX, reliability, extensibility, missing capabilities, docs/knowledge compounding, quality/maintenance, leverage on future work.

Checkpoint — raw candidates. Immediately after cross-cutting synthesis, write <scratch-dir>/raw-candidates.md with the full candidate list and frame attribution (and the captured user seeds). This protects the most expensive output (N parallel frame dispatches + dedupe) before Phase 3 critique compacts context. Best-effort — if the write fails, warn and proceed; the checkpoint is not load-bearing. Do not delete the run directory at the end of the run.

---

End of Phase 2. Load saga/skills/ideate/references/convergence-and-partnership.md and follow Phases 3–6 (adversarial filter → present survivors + revivable cut → persist → refine / co-ideate / revive / interview / hand off), then the quality-bar self-check. This load is non-optional — the critique rubric, revival state machine, persistence template, the Phase 6 menu, and the quality bar live there, not in this file. Do not improvise them from memory.

Reference files

• saga/skills/ideate/references/convergence-and-partnership.md — Phases 3–6 (critique, present, persist, refine/revive/hand off) and the quality bar.
• saga/skills/ideate/references/ideation-artifact.md — the persisted artifact template.
• saga/references/formatting-style.md — the canonical formatting contract that governs how the presented survivors and the persisted artifact look (lead-in summaries, short prose, compact fields as a table).