Suite workflow

Suite workflow

Turns "give me 10 X" into a pre-vetted, built, self-checked suite delivered for one batch review — instead of one-at-a-time back-and-forth. Four stages, in order. The orchestrator is whichever model runs the main session (never hardcode a model name into this process — models get retired, the process should outlive any one of them); the user is always the final authority above it.

Stage 1 — Ideate

• Generate overcapacity: default ~1.5x the requested count (asked for 10 → generate 15). More if the domain is new/untested for this user, less if their taste there is well-mapped.
• Pre-filter against a decision profile — a maintained document distilling how this specific user actually decides: their hard constraints (things that kill a candidate outright — e.g. new recurring costs, anything requiring their real-time presence, off-brand framing), their strong preferences, and their taste. Kill anything violating a hard constraint; score survivors against preferences and taste.
• Check the profile's own calibration score first (see "Calibrating the decision profile" below): if it's below the user's chosen confidence bar, don't silently cut candidates — present the FULL generated list with recommended cuts flagged and reasons shown, and say explicitly that the profile isn't calibrated enough yet for autonomous filtering. Autonomous pre-cutting is earned by a high enough calibration score, not assumed from day one.
• Ground candidates in platform research (what actually sells/ranks/performs on the target platform), not just creative generation.
• Present the full suite in ONE review: each candidate with its upside, its named tradeoff, and its cost line up front. Mark which ones the profile says the user would cut and why — they confirm or override.
• This stage stays single-threaded — it needs one coherent view of the user's taste and cross-candidate dedupe. Do not parallelize ideation.

Stage 2 — Build

• Once the user picks the final set, build each chosen item end-to-end to ready-to-ship against the target platform's checklist (image specs, file limits, licensing/compliance requirements — keep the checklist with that project, not in this skill).
• This is the stage that parallelizes — see Stage 4.
• Every built item lands as real files/artifacts in the project's working folder, not descriptions of what would be built.

Stage 3 — Self-check

• Apply a score-before-iterate discipline to each built item: a written critique (not a mental pass), scored with the best available objective proxy (a tool score, a platform-standard compliance check, or explicit stated criteria), weak/broken items regenerated by changing one identified variable, not re-rolled blindly.
• Per-item self-checks can run inside each parallel build agent; the suite-level QA cannot — someone has to see all items together to catch cross-item problems (three-too-similar, inconsistent branding, duplicate concepts). That final pass belongs to the orchestrator.

Stage 4 — Parallelise

• Scope: suite/batch work only — a defined set of independent items. Single-item and judgment-heavy work stays in the main session. Parallelism buys wall-clock speed, not tokens: N parallel agents burn the same total tokens as N sequential ones, faster. If you've hit usage/plan limits before, don't parallelize what doesn't need it.
• Each chosen item gets its own subagent running Build + per-item Self-check concurrently. Route by judgment required: cheap/fast models for research sweeps and mechanical work, mid-tier for real creative builds, the main session for synthesis and final QA.
• The orchestrator reviews raw artifacts, never agent self-reports. Open the actual files, check the actual dimensions, read the actual copy. An agent that fabricates output and reports success is a real, observed failure mode — the same rule applies to any subagent's "done."
• The orchestrator steps in on a worker only when its output fails QA, contradicts the system, or stalls — otherwise workers run uninterrupted.

Calibrating the decision profile

A decision profile is only as useful as it is accurate, and accuracy should be measured, not assumed:

• Periodically run a prediction interview: draft predicted answers to a mixed set of questions (business tradeoffs AND lower-stakes/personal ones, for a well-rounded model) and commit them to a timestamped file before the user answers, so there's no retrofitting. Reveal and score afterward — a simple rubric works (e.g. partial credit for matching the decision, partial credit for matching the reasoning).
• Set an explicit bar (e.g. ≥90/100) below which the workflow does NOT silently pre-filter — it shows full lists with flagged recommendations instead, and logs the score.
• Log every calibration round with what was learned, so the profile keeps improving rather than staying a one-time guess.
• Watch for the profile drifting to model a user's in-the-moment answer instead of their reflective standard — people sometimes answer one way live and, on reflection, want to be held to a different stated principle. When that happens, the profile should capture both and prefer the standard.

Ground rules

• ALWAYS present the Ideate suite as one batch review with tradeoffs and costs per candidate — never trickle candidates one at a time.
• ALWAYS verify parallel workers' outputs by opening their raw artifacts — never accept a subagent's self-report as completion.
• ALWAYS keep suite-level QA in the main session — per-item checks parallelize, cross-item checks don't.
• NEVER hardcode a model name into this workflow — "the orchestrator" is whatever model runs the main session; the user outranks it.
• NEVER parallelize single-item or judgment-heavy work just because parallelism exists.
• NEVER let a candidate that violates a hard constraint in the decision profile into the presented suite without flagging it as a deliberate exception worth the user's attention.