Ideate Fleet

Ideate Fleet

Strategy-grounded ideation fan-out at the head of the -fleet spine — compose STRATEGY.md tracks and supplied opportunity areas into a queue of disjoint themes, confirm the batch with the human in one up-front round, fan out worktree-isolated subagents that each run the real harness-ideate pipeline for one theme to its ranked artifact, collect every artifact back out of its worktree, independently re-derive every ranking instead of trusting a subagent's report, and hand back one curated ranked shortlist for a human to pick from. The fleet files nothing and commits nothing.

The -fleet conveyor starts at intake: issue-fleet sorts a backlog that already exists, and nothing upstream produces it. Ideation is still a per-topic, human-driven act — harness-ideate converges one topic into one ranked artifact, so a team that wants candidates across five strategy tracks runs it five times by hand and then reconciles five separately-ranked lists into one decision itself. That reconciliation — deduping across topics, checking each candidate against what is already filed or already shipped, and cutting the union down to something a human can actually read — is exactly the attention tax this family exists to remove. ideate-fleet fills that gap and becomes the head of the spine: ideate → issue → adr → roadmap → pr.

Its defining property is a caution rather than a capability. Ideation is the lowest-precision stage in the lifecycle. harness-ideate is asked for 5–25 candidates per topic whether or not that many good ones exist; its only defense is a stated preference for fewer-but-distinct over padded near-duplicates, and nothing stops a merely-plausible idea from filling a slot. Across six themes that is a hundred-plus ideas, most of which should never become work. A fleet that auto-filed them would convert one afternoon of machine thinking into a hundred tracking issues that issue-fleet then has to triage — the backlog-spam failure mode, transposed one stage upstream and multiplied by the fan-out. So this fleet files nothing. Its product is a curated, deduped, bounded shortlist; only the ideas a human explicitly picks become issues or roadmap rows, and those enter the conveyor at intake like anything else. This is bug-fleet's no-reproduction-no-filing discipline applied at the stage where precision is lowest and the temptation to over-produce is highest.

This skill builds on the shared -fleet spine documented in docs/reference/fleet-family.md — the five-phase SELECT → CONFIRM → DISPATCH → VERIFY → terminal skeleton, the concurrency governor, the artifact-based verification discipline, the worktree fan-out with its nested-path push caveat, the front-load / park-unforeseen interaction model, and the never-ship-unreviewed-work invariant. The family ADRs cited there — Subagent worktree fan-out (vs the Workflow primitive) for -fleet execution and The front-load / park-unforeseen interaction model for the -fleet family — state that contract once for the family. This SKILL.md defines only what is ideate-fleet's own: its theme queue, its curation taxonomy, its artifact-collection step, its re-derived-ranking verification, its shortlist terminal act, and its domain-specific rationalizations.

When to Use

• Generating fresh candidate work across several strategy tracks at once, when nothing has been selected yet and the backlog holds no strategy-grounded candidates
• Making STRATEGY.md the queue itself rather than one more optional grounding input, so every theme traces to a committed track or to an opportunity area the human named
• Batch-scale ideation, where running harness-ideate per topic by hand and then reconciling the separately-ranked lists is the bottleneck
• When the themes are genuinely independent — each is one coherent ideation topic, run in its own worktree, and one theme's candidates do not depend on another's
• When the output has to be short enough to read in one sitting and trustworthy enough to pick from: every row carries a re-derived score, a standing objection, and a novelty citation
• NOT for a single topic — converging one topic into one ranked artifact is harness-ideate; a fleet's overhead only pays off across a batch
• NOT for ranking work that already exists — prioritizing existing roadmap entries is harness-roadmap-pilot; this member generates fresh candidates
• NOT for triaging, deduping, or routing an existing issue backlog — that is issue-fleet, immediately downstream on the conveyor
• NOT for producing specs, plans, ADRs, or code — a picked idea goes to harness-brainstorming by hand, after this run has already ended
• NOT for writing or repairing STRATEGY.md — that is harness-strategy; this member only reads it, exactly as harness-ideate does

Flags

Every flag has a default and is restated in the CONFIRM round, so a bare invocation is a complete invocation. There is deliberately no --report-only: a member that files nothing has no destructive mode to suppress, so the flag would do nothing. The objection policy is likewise settled at CONFIRM rather than exposed as a flag.

Process

Iron Law

NOTHING IS FILED — the fleet never creates an issue, never adds or mutates a roadmap row, never writes a spec, plan, or ADR, and never opens a PR. It commits nothing, stages nothing, and pushes nothing. Ideas leave this run promoted in exactly one form: a curated shortlist a human picks from — the collected per-theme artifacts are left beside it as un-promoted evidence. The pick is the human's act, and it happens after the run has ended.

Ideation is the lowest-precision stage in the lifecycle. harness-ideate fills its requested count with whatever is plausible, and the fan-out multiplies that by the theme count — so the fleet's raw output is, by construction, mostly ideas that should never become work. Auto-filing them would hand issue-fleet a backlog the fleet itself manufactured, making the intake stage's job harder rather than easier, and would launder machine speculation into tracked work that then looks like a commitment somebody made. bug-fleet refuses to file a defect without a reproduction because confident prose is not evidence; the same reasoning applies here with more force, because an idea has no equivalent of a failing test. The human pick is the only gate that converts an idea into work, and this fleet does not stand on that side of it.

The corollary matters as much as the law. A thin theme is a valid, valuable result. The pressure to return something — anything — so a batch does not look wasted is precisely what produces the shortlist nobody trusts. A theme reported thin tells the human that track is already well-covered, which is information. Padding it destroys the property that makes the shortlist worth reading at all.

Phase 1: SELECT --> Phase 2: CONFIRM --> Phase 3: DISPATCH
                                                    |
                                                    v
          Phase 5: CURATE-AND-REPORT <-- Phase 4: VERIFY

Phase 1: SELECT — Compose the Strategy into Disjoint, Strategically-Ranked Themes

1. Ground in STRATEGY.md — read it, never write it. Call read_strategy on the harness MCP server and handle its three cases exactly as harness-ideate does:

   • Absent — no strategy grounding; supplied --themes proceed ungrounded and the batch's assumptions note records it.
   • Present and valid — capture the Tracks bullets plus Target problem, Our approach, and Who it's for; these are the queue and the scoring basis.
   • Present but invalid — surface the validation error verbatim, degrade to the supplied themes, and continue. Repairing STRATEGY.md is harness-strategy's job and never this fleet's.

   When read_strategy itself is unreachable (no harness MCP server), use harness-ideate's documented @harness-engineering/core fallback. If that is unavailable too, treat the run as having no strategy source.

2. Stop when there is no theme source at all. If STRATEGY.md is absent or unusable and no --themes were supplied, stop and report. There is nothing to fan out over, and deriving themes from the codebase instead would invent strategy the human never committed to.

3. Fold the sources into themes. A theme is one coherent ideation topic — the unit that becomes one harness-ideate run, in one worktree. Two constraints are hard:

   • Disjoint. Two themes whose focus lines overlap produce the same idea twice in two worktrees, which is how a fleet becomes a duplicate factory. Disjointness is not merely asserted: compare every pair of candidate focus lines and, where two overlap, merge them into one theme with a combined focus line — or split them along a stated boundary if the human prefers that at CONFIRM. Every merge is carried into the CONFIRM round showing both source lines, so the human sees what was folded together before anything fans out.
   • Bounded. Default 6 themes per batch. The bound is what keeps the shortlist readable and the fan-out inside the governor's reach.

4. Score and order by strategic weight. Do not rank ad-hoc. Reuse harness-roadmap-pilot-style impact scoring over a composite of track membership, whether the theme touches Target problem or Our approach, and how thinly the theme is already covered by existing roadmap rows, so the order is principled and reproducible rather than a matter of which theme looked interesting first. Highest strategic weight first; this order is also the first tiebreaker in the CURATE cut.

5. Build the Theme record for each survivor:

   Theme {
     sources,      // "strategy-track" | "supplied" (may be both after a merge)
     id,           // theme slug
     focus,        // the one-line focus the harness-ideate run receives verbatim
     mergedFrom,   // the source focus lines folded in for disjointness (may be empty)
     basis,        // track membership, target-problem/approach touch, existing coverage
     score,        // composite strategic weight
     forks,        // detected decision forks to surface at CONFIRM (may be empty)
   }
   

Phase 2: CONFIRM — The Single Up-Front Human Gate [checkpoint:human-verify]

1. Present the whole batch in one round. This is the only human touchpoint until the shortlist is presented — everything between runs autonomously. Present, together, in a single surface:

   • The ranked themes, highest strategic weight first, each with its basis, and every disjointness merge with both source focus lines.
   • The per-theme candidate count (default 10, clamped to harness-ideate's [5, 25]).
   • The objection policy (default none — every strongest objection stands as an accepted downside).
   • The per-theme shortlist cut (default 3) and the global shortlist cap (default 10).
   • The novelty lookback window for recently-merged PRs (default 90 days).
   • The pinned UTC batch date, fixed here and reused for the whole batch.
   • The proposed concurrency (default 2, capped at ~3).
   • An explicit restatement that nothing will be filed and nothing committed — no issue, no roadmap row, no spec, no plan, no ADR, no PR, no commit, no push.

2. The human approves or trims once. A theme the human drops is dropped; a bound the human tightens applies to the whole batch; a merge the human would rather split is split here, before dispatch. Front-loading the genuinely-ambiguous calls is what keeps the autonomous stretch from producing a shortlist the human would have declined.

3. Pin the batch date in UTC here. One date for the shortlist filename and for artifact resolution, so a run that spans UTC midnight does not scatter its artifacts across two dates — the same reason bug-fleet pins one base SHA per batch.

4. From here it is autonomous. The fleet does not pause per theme. The only thing that re-surfaces before CURATE-AND-REPORT is a theme that hits a genuinely-unforeseen fork mid-flight, which parks that one theme without blocking the batch. Under --dry-run the skill stops at the end of this phase.

Phase 3: DISPATCH — Worktree Fan-Out With a Concurrency Governor

One worktree-isolated subagent per confirmed theme, each running the real harness-ideate pipeline for its one theme. It does not hand-generate ideas, it does not hand-edit the artifact, and it does not short-cut the pipeline — the ranked artifact the pipeline necessarily leaves behind is what VERIFY checks for, exactly as a plan directory is for the build-stage member.

1. GROUND → GENERATE → CRITIQUE → RANK → WRITE — the real harness-ideate, run to its ranked artifact. The subagent invokes the actual skill with the confirmed focus line and candidate count. It never writes an ideation artifact itself; producing one by hand leaves a file that looks right and proves nothing.

2. Answer harness-ideate's two interactive stops from CONFIRM policy — never skip them. The pipeline pauses twice: once to confirm its inputs, and once after critique to ask which objections to answer. A fan-out cannot pause per theme, so both are answered from policy settled at CONFIRM:

   • Inputs — the confirmed theme focus line and the confirmed candidate count.
   • Objections — the confirmed policy, default none: every strongest objection stands as an accepted downside. An unanswered objection lowers an idea's standing, which is the honest default for a machine-generated rebuttal to a machine-generated critique. A fleet that answered its own objections would inflate its own rankings, and the human who picks from the shortlist reads the standing objection as part of the pick.

3. PRESELECT the theme's top-K. Take the top --cut candidates by the artifact's own order as this theme's shortlist proposal — provisionally. Phase 3 reads that order for convenience; Phase 4 re-derives it before anything is promoted, so trusting it here costs nothing. Everything below the cut stays in the artifact — un-promoted, never deleted.

4. CROSS-CHECK each preselected candidate for novelty. Check it against open issues (via gh), existing roadmap rows (read directly from docs/roadmap.md / docs/roadmap.d/ — never by invoking a roadmap skill), and recently-shipped features — PRs merged within the confirmed lookback window (default 90 days, via gh) plus roadmap rows in a done state.

   • An already-tracked or already-shipped idea is annotated already-known and dropped citing the issue, roadmap row, or PR that covers it — never re-surfaced as new.
   • Each drop backfills from the next-highest below-cut candidate in that theme until the cut refills or the theme's candidates are exhausted. Every backfill is recorded.
   • If a cross-check source is unavailable (gh unauthenticated, no tracker, no roadmap), the candidate is annotated novelty-unknown — not novel. It stays eligible, its shortlist row says the check could not run and names the missing source, and the batch's assumptions note records it. Never launder an unrun check into a novelty claim.

5. COLLECT the artifact verbatim before the worktree is released. Each harness-ideate run writes its artifact inside that theme's worktree, and this fleet pushes nothing — so without collection the artifacts die with the worktrees and every shortlist link dangles. Copy each theme's artifact byte-identical into the invoking working tree's docs/ideation/. Copying is not editing, and writing a local file is not filing.

   • The collision rule is applied at collection, not in the worktree. Each worktree starts with its own empty docs/ideation/, so a subagent never observes a collision and never applies harness-ideate's hex-suffix rule. Two themes whose focus lines truncate to the same 30-character slug — and a retry re-running the same focus on the pinned date — would otherwise arrive as the same filename and one would silently overwrite the other. The collector therefore applies that same rule on arrival, deriving the 6-character lowercase hex suffix from the SHA-1 of the focus line plus the run's ISO timestamp — which the artifact records as generated_at — so both files coexist and each stays resolvable by its frontmatter.
   • Release the worktree only after its artifact has landed in the invoking tree. Removing it first destroys the only copy.
   • A theme whose artifact cannot be collected (destination unwritable, worktree unreadable) is parked with the filesystem error surfaced verbatim — not rejected, and its worktree is left in place so the artifact is still recoverable by hand. A collection failure is the orchestrator's plumbing problem, and calling it a failed pipeline run would blame the subagent for the fleet's own wiring.

6. Never edit a per-theme artifact. The fleet reads it, re-derives from it, and links it. Cross-check results, backfills, and verdicts live in the returned record, never in the artifact — an edited artifact can no longer serve as evidence that the pipeline produced it.

7. Cap concurrency at the governor (default 2, max ~3). This is the machine-storm limit: beyond roughly three concurrent subagents the compound load produces failures indistinguishable from real ones. Never raise the cap to "go faster." The confirmed candidate count is a separate bound — it caps what each subagent asks harness-ideate for, not how many subagents run.

8. Record an "assumptions made" note per theme — the derivation basis the theme came from and any merge folded into it, the pinned batch date, the objection policy applied, the cut and cap in force, and every novelty call including the sources that were unavailable. A shortlist is only trustworthy when the reader can see what was assumed and what was deliberately dropped.

9. Park the unforeseen. A theme that hits a genuinely-unforeseen fork — the focus line turns out to span two themes, the strategy source contradicts a supplied area, harness-ideate cannot proceed — parks that one theme and reports it. The other themes continue uninterrupted.

10. Push-path caveat. This member pushes nothing, so the pre-push documentation gate never fires for it — but worktrees are still created outside a nested agent-config path, so a subagent that needs to run any repository gate is not operating in a self-excluding tree. Never --no-verify under any circumstance.

Each preselected candidate carries this record forward:

Candidate {
  theme,           // the theme it was generated in
  premise,         // the idea, in one declarative sentence
  persona,         // the target persona segment
  complexity,      // low | medium | high
  impact,          // low | medium | high
  confidence,      // low | medium | high
  effort,          // low | medium | high
  recordedScore,   // the base score the artifact records
  rederivedScore,  // the base score the orchestrator recomputes in VERIFY
  finalScore,      // rederivedScore + the artifact's recorded bonus (the bonus is read, never recomputed)
  alignment,       // "applied" | "recorded-not-applied" + reason
  objection,       // the standing strongest-objection paragraph
  novelty,         // "novel" | "already-known" + citation | "novelty-unknown" + missing source
  verdict,         // "shortlisted" | "backfilled-shortlisted" | "below-cut" | "deduped-into" + target | "already-known"
}

And the batch itself carries the record every shortlist row and every assumptions note is written against:

Batch {
  label,           // the human's invocation topic, or the highest-weighted theme's focus when none was given
  slug,            // batch-slug: kebab-cased label, truncated to 30 chars (+ hex suffix on collision)
  pinnedDate,      // the UTC date fixed at CONFIRM, used for the shortlist filename and artifact resolution
  themes,          // the confirmed Theme[] with their SELECT order
  bounds,          // count, cut, cap (and any reserved-slot raise), lookback, governor
  objectionPolicy, // the policy answered into every harness-ideate run (default "none")
  verdicts,        // per-theme: verified | thin | parked | rejected
  artifacts,       // the collected artifact path per theme
}

Worker handoff — return the canonical FleetHandoffRecord. When a worker finishes its theme it hands the orchestrator exactly one FleetHandoffRecord (from @harness-engineering/types) — the ONE bounded envelope every -fleet member emits, so fleet-command parses any fleet's worker output uniformly instead of special-casing an ad hoc per-worker report shape. The record carries status (done | parked | blocked | failed), fleet, item, a one-line summary, an evidence[] of verifiable pointers (branch, PR, artifact path, CI check — exactly the references VERIFY re-checks), next_steps[], and, for any non-done status, a blocker. The orchestrator validates it with validateFleetHandoffRecord; a malformed or unknown-keyed record is rejected, never silently misread. See the canonical handoff record in docs/reference/fleet-family.md.

Phase 4: VERIFY — Provenance Plus a Re-Derived Ranking, Never Self-Report

1. Why two checks, and why CI is not one of them. The family invariant requires proof the real per-item pipeline ran and forbids accepting a subagent's word for it. This member produces no code and no PR, so the family's all-OS-CI half has no subject — it is recorded as not applicable for every theme rather than quietly dropped, and its evidentiary weight is carried by a second check instead. The spine's base-freshness clause (docs/reference/fleet-family.md § Base freshness) is not-applicable here for the same reason and recorded as such: this member derives no verdict from a CI conclusion, so there is no stale-green to guard against — a not-applicable check is recorded, never confused with a passed one. Provenance proves the pipeline ran; it says nothing about whether the order it produced follows from its own inputs. Re-derivation proves the ranking was computed rather than asserted; it says nothing about whether a real run produced it. Neither does the other's job, so both run, independently, for every theme. Never accept a subagent's self-report — "generated ten, ranked them, top three attached" is a claim to be checked, not a result.

2. Provenance — the pipeline actually ran. The collected artifact must exist directly under docs/ideation/ with frontmatter topic matching the theme's confirmed focus line. The scan excludes docs/ideation/shortlists/ — that subdirectory holds this fleet's own terminal artifacts, and a prior batch's shortlist must never be readable as a per-theme artifact.

   • Resolve the artifact by that frontmatter, not by an exact filename. harness-ideate truncates slugs to 30 characters, and the collector applies its hex-suffix collision rule on arrival — which a retry and two themes sharing a truncated slug both trigger. An exact-path check would reject its own pipeline's legitimate output.
   • It must carry the frontmatter harness-ideate mandates: topic, generated_at, strategy_grounded, strategy_path, count_requested, count_generated, and ranking_formula. count_requested must equal the confirmed candidate count, and count_generated must equal the number of candidates actually present.
   • Each candidate must carry the six persisted fields — premise, persona, complexity, impact, confidence, effort — plus its strongest-objection paragraph. (key_risk is the seed the artifact renders as that paragraph, not a separate persisted field.)
   • Absent or malformed ⇒ the pipeline did not run ⇒ rejected, however good the ideas look.
   • A count_generated below count_requested is not a rejection — it is reported as thin. harness-ideate asks for exactly N and prefers fewer-but-distinct over padded near-duplicates, so the two readings of a shortfall are "the run under-delivered" and "the run refused to pad", and the artifact does not say which. Rejecting on that ambiguity would discard real candidates to punish an unproven contract breach, so the fleet takes the conservative side and reports it. Only a count that exceeds the confirmed request, or candidates missing their fields, is unambiguous enough to reject on.

3. Re-derived ranking — the order follows from the recorded inputs. Recompute (impact × confidence) ÷ effort for every candidate from that candidate's own recorded impact/confidence/effort using the published 1|2|3 mapping, then confirm three properties:

   • Score equality — each candidate's recorded base score equals the recomputed one.

   • Non-increasing base-score order — the artifact's order is monotonically non-increasing in base score. Order is checked as a monotonicity property, not as one permitted permutation, and on the base score, not the final score. Two reasons, both structural:

     • The base score is the only quantity fully re-derivable from the artifact's persisted inputs. The alignment bonus is read, never recomputed, so a final-score check would be half-borrowed from the very artifact it is auditing.
     • The 1|2|3 mapping yields twelve distinct base-score values, whose smallest gap is 1/6 ≈ 0.167 — larger than the 0.05 tie window, so the window is only ever entered by exact ties. But the bonus can reach +0.75, which exceeds seven of the eleven inter-value gaps. So a tied candidate that earns the full bonus can carry a higher final score than a candidate legitimately ranked above it on base, and the artifact's final-score sequence is then not non-increasing while the artifact is perfectly conforming. Checking final-score monotonicity would reject that artifact and discard the whole theme.

     Exact base-score ties in any order are accepted — the generation order that breaks them is not persisted, so demanding one exact permutation would reject legitimate artifacts for an unknowable reason.

   • Bounded bonus — any strategy-alignment bonus is checked as a standalone bounded property, not as an ordering claim: it is within 0 ≤ bonus ≤ 0.75, and it is non-zero only for a candidate in an exact base-score tie (the only case the 0.05 window admits). How harness-ideate resolves order between a bonused candidate and a higher-base one is its call, and this fleet accepts either resolution rather than forcing one.

   A recomputed-score mismatch, a non-monotonic base-score order, or an out-of-bounds bonus is rejected, not corrected. An order that does not follow from the recorded inputs means the ranking was asserted rather than computed — and re-deriving is the one check an eloquent subagent cannot talk its way past. Silently re-sorting would repair the symptom and destroy the signal.

4. Assign exactly one verdict per theme:

   • verified — artifact resolved, frontmatter and fields complete, every score re-derived, order non-increasing, tiebreaker in bounds.
   • thin — verified, but count_generated fell below the confirmed request (or no candidate survived curation downstream). A reported outcome, not a failure.
   • parked — the theme forked unforeseeably, or its artifact could not be collected. Reported with the error verbatim.
   • rejected — any check missing or wrong-shaped. Retried once; still failing, it is reported as rejected with the reason and the batch continues. Where a retry leaves two collected artifacts for one focus, the one with the later generated_at is the one verified.

5. Record all-OS CI as not applicable in every theme's verdict line. Recording it is what keeps the family invariant honest: a reader can see the check was considered and why it has no subject here, rather than wondering whether it was skipped.

Phase 5: CURATE-AND-REPORT — One Shortlist, Presented and Then Stop

1. Run the cross-theme dedup backstop. Themes are disjoint by construction, so this is a backstop rather than the primary defense. Two candidates with the same premise collapse into one entry citing both themes, and the collapse is recorded. A premise that differs only by a parameter is one idea, per harness-ideate's own near-duplicate rule.

2. Apply the bounded cut, resolving cap collisions by the reserved-slot rule. The per-theme cut and the global cap routinely collide (6 themes × 3 = 18 against a cap of 10), so the collision is resolved by a stated rule rather than by whichever theme finished first:

   • One slot is reserved for the highest-scoring survivor of every non-thin theme, so no theme is silently erased from the shortlist.
   • The remaining slots are filled by re-derived final score descending across all themes, ties broken by the theme's SELECT order and then by artifact order.
   • If the reserved slots alone exceed the cap, raise the cap to the theme count and report the raise.
   • Everything below the cut stays in its per-theme artifact, which the shortlist links. Nothing is destroyed — only un-promoted.

3. Write exactly one shortlist, to docs/ideation/shortlists/ as <batch-slug>-<pinned-UTC-date>.md. That is a distinct namespace from the per-theme artifacts, so nothing the fleet writes can be mistaken for a harness-ideate run's own output or violate its one-artifact-per-run law.

   • batch-slug is derived the same way harness-ideate derives a topic slug: kebab-case the batch label (the human's invocation topic, or the highest-weighted theme's focus line when none was given), lowercase, collapse everything outside [a-z0-9-] to -, trim, truncate to 30 characters.
   • The shortlist carries the same collision rule as the artifacts. Two batches on the same pinned UTC date would otherwise resolve to one filename and the second would silently overwrite the first — the exact loss the artifact collision rule exists to prevent. On collision, append a 6-character lowercase hex suffix derived from the batch label and the pinned timestamp, so both shortlists coexist. Nothing the fleet writes is ever overwritten.

   Each row carries:

   Premise	Theme	Re-derived score	Standing objection	Novelty	Artifact

   The novelty cell is the citation, or the novelty-unknown note naming the missing source. The artifact cell links the collected copy, so the link resolves in the invoking tree. The document also carries the batch's assumptions-made note: theme derivation basis and every merge, the pinned batch date, the objection policy, the cut and cap applied (and any reserved-slot raise), and every novelty call including unavailable sources.

4. Present the shortlist and stop. Presentation is the end of the run. No fleet action is defined for what follows — the human routes a pick by hand to harness-brainstorming (to spec one) or to the roadmap (to enqueue several). The fleet performs neither and does not wait for either, because the routing act is the filing act and the Iron Law puts it on the human's side of the line.

5. Report every non-shortlisted outcome with its reason and count: already-known drops each citing the covering issue, roadmap row, or PR; novelty-unknown annotations naming the missing source; backfills applied; cross-theme dedup collapses; below-the-cut counts per theme; thin themes; parked themes with their errors; and rejected themes with their failed check. Thin themes are reported as thin — a valid outcome, not a failure.

6. State plainly what was not done: nothing was filed, and nothing was committed, staged, or pushed. The shortlist and the collected artifacts are ordinary working-tree changes the human keeps or discards.

7. Degrade gracefully. An unavailable theme source, an unavailable novelty source, a failed collection, a parked theme, or one rejected theme is reported while the rest of the batch proceeds. One bad theme never sinks the batch, and one thin theme is not a bad theme.

Harness Integration

• harness skill run ideate-fleet — Run the full five-phase batch pipeline.
• read_strategy — The SELECT grounding oracle. Returns presence, validity, and the parsed document; its Tracks bullets are the queue and its Target problem / Our approach / Who it's for sections are the scoring basis.
• @harness-engineering/core — harness-ideate's documented fallback for read_strategy when the harness MCP server is unavailable; if it is also unresolvable the run has no strategy source.
• harness-strategy — The read-only boundary: strategy writes STRATEGY.md, this fleet only reads it. An invalid document is surfaced verbatim and routed to that skill, never repaired here.
• harness-ideate — The real per-theme pipeline each DISPATCH subagent runs to its ranked artifact. Its artifact, its frontmatter contract, its (impact × confidence) ÷ effort scoring, its bounded strategy-alignment tiebreaker, and its slug/collision rules are consumed as-is — never reimplemented, never forked.
• harness-roadmap-pilot — Its impact-scoring approach is reused in SELECT to order themes by strategic weight. It is a reference for how to score, never a skill this fleet invokes: it opens its own human confirmation round and terminates by transitioning into spec or build work, both of which this fleet's Iron Law forbids. The roadmap rows the novelty cross-check reads come from docs/roadmap.md / docs/roadmap.d/ directly.
• harness-brainstorming — The documented downstream a human routes a pick to. This fleet never invokes it — doing so would be filing by another name.
• gh — Novelty cross-check only: open issues and PRs merged within the confirmed lookback window. It is never used to create an issue, comment, or PR.
• harness skill validate ideate-fleet — The authoring-time gate for this skill's own structure and schema.
• docs/reference/fleet-family.md — The shared -fleet spine this skill builds on (the five-phase skeleton, the concurrency governor, the artifact-based verification discipline, the worktree fan-out and its push caveat, and the never-ship-unreviewed-work invariant), stated once for the family.

Success Criteria

• Given a confirmed batch of N themes, the fleet produces exactly one curated ranked shortlist under docs/ideation/shortlists/, and no issue, roadmap row, spec, plan, ADR, or PR is created.
• The fleet commits, stages, and pushes nothing: the shortlist and the collected per-theme artifacts are left as working-tree changes.
• Every shortlisted candidate traces to a verified per-theme artifact collected into docs/ideation/, resolved by its frontmatter topic rather than by an exact filename, so slug truncation and the hex-suffix collision rule cause no false rejections. A theme with no artifact, or a malformed one, is rejected as not having run the real pipeline.
• Every shortlisted candidate's score is independently re-derived from the artifact's own impact/confidence/effort values. A recorded score that differs from the recomputed one, or an order that is not non-increasing in base score, is rejected rather than silently re-sorted; exact base-score ties in any order are accepted, because the generation order that breaks them is not persisted.
• The strategy-alignment bonus is checked as a standalone bounded property (0 ≤ bonus ≤ 0.75, non-zero only on an exact base-score tie), never as an ordering claim — a bonused tie may legitimately carry a higher final score than a higher-base candidate, and rejecting that would discard a conforming artifact. An out-of-bounds bonus is a rejection.
• A verified artifact whose count_generated is below the confirmed request is reported thin, not rejected; only a count exceeding the request, or candidates missing their persisted fields, is a rejection.
• The shortlist is bounded by the confirmed per-theme cut and global cap, and when the two collide the reserved-slot rule resolves it so no non-thin theme is silently erased. Every below-the-cut candidate stays reachable through its linked, collected artifact.
• Already-tracked or already-shipped ideas are dropped citing the covering issue, roadmap row, or PR, never re-surfaced as new, and each drop backfills from the next below-cut candidate until the cut refills or the theme is exhausted.
• When a novelty source is unavailable, affected candidates are annotated novelty-unknown naming the missing source — never reported as novel.
• Themes are disjoint on dispatch: every overlapping pair found in SELECT is merged (or split), and every merge is shown to the human with both source focus lines.
• Cross-theme duplicates are collapsed into one entry citing both themes, with the collapse recorded.
• Every shortlist entry carries its standing strongest objection, and the batch carries an "assumptions made" note (derivation basis and merges, pinned batch date, objection policy, cut and cap applied, novelty calls including unava

…(truncated)