One Pipeline, Three Shapes: Running Claude Design + big-task Across ÉLAN, Shichuan, and Panpanmao
One pipeline doesn't mean one shape
Previous post in this series covered the Claude Design + big-task pipeline as a linear thing: brief → six-direction exploration → pick → HANDOFF.md → ship. That linear version is what it looks like on paper. In practice, the same pipeline runs a different shape on each of my three products, because the starting state and the ship constraints are different.
This post is three case studies. Same tools, three different shapes.
Product 1: ÉLAN — greenfield, wide exploration
State at the start: No codebase. No existing visual language. A one-paragraph brief about a journal-like app for creators, and an intuition that it should feel slow and tactile.
Pipeline shape: Heavy on the exploration phase (step 2) and the direction study (step 5). Skip nothing upstream — you need the full spread because you have no constraints pulling you toward any particular direction.
This is the shape the previous post walked through. Six-direction exploration → converge to three → pick Film Stock → direction study → HANDOFF.md → big-task ui profile.
ÉLAN three finalist directions — Film Stock / Chiaroscuro / Field Notes — each complete with typography, palette, and sample screens
What was expensive: Step 4 (pick). Three directions were all plausible and I spent real time deciding. The decision took half a day; the exploration that enabled it took twenty minutes. That ratio is correct — exploration is cheap, judgment is the thing you pay for.
What big-task does differently here: When ÉLAN's repo exists and has HANDOFF.md + directions/*.jsx + Playwright set up, Phase 0.0 auto-detects ui-project. Every UI phase gets mandatory visual verification via Playwright screenshot + per-PNG parallel subagent dispatch. 24 PNGs checked by 24 subagents, main thread just aggregates the verdict matrix.
Product 2: Shichuan — live app, category-by-category migration
State at the start: Existing app shipped in production. Initial UI was serviceable but had drifted across seven product categories (different content types — meditation, divination, product photography, each with its own quirks). Brand DNA was partially formed but not locked.
Pipeline shape: Skip exploration. The brand direction was already known (Eastern-contemplative, serif-heavy, earth palettes). What wasn't known was how that direction should play out across seven categories. Heavy on step 5 (direction study) — but the study is per category, not per direction.
Shichuan direction study — three aesthetic variants for the category-level visual language, with phone mockups showing how each direction handles content photography, text, and navigation
Why the shape is different: A disruptive redesign shipped all at once would have broken existing users. The category system was the migration unit — one category at a time, each with Playwright-verified visual fidelity, each shipped as its own phase.
So the pipeline looked like:
- Design the visual DNA (one direction, not six) with Claude Design.
- HANDOFF.md captures brand-level tokens (typography, palette, motion).
- For each of seven categories: run the direction study within that category, generate category-specific
directions/category-X/*.jsx, open a phase inbig-task. big-taskPhase 0.0 detectsui-project, routes to Tier 3 GSD-lite, runs Playwright verify per category.- Ship the category. Monitor. Move to the next.
What was expensive: Not the design. The consistency across seven categories. Each category had its own legacy layout quirks, and maintaining brand coherence while respecting category-specific UX was genuinely harder than ÉLAN's greenfield case. The impeccable:normalize skill earned its keep — it audits for drift from the design system and flags where a category screen has wandered.
What big-task does differently here: Category-by-category migrations are the exact case big-task's Tier 3 GSD-lite was built for. 3+ tasks on disjoint files, mechanical work, known design pattern being applied N+1 times. Subagent policy: parallel-worktree. Each category gets its own worktree, parallel implementer subagents, no merge conflicts.
Product 3: Panpanmao — monorepo, three parallel expressions
State at the start: Monorepo with multiple surfaces — Telegram bot, web, admin dashboard, mobile. V1 shipped. V2 redesign planned to unify the visual language across all surfaces without killing the personality of any individual surface.
Pipeline shape: Exploration phase (step 2) runs, but not for direction — for expression. The brand DNA is locked (Eastern metaphysics / yin-yang / Chinese-typographic). What varies across surfaces is the expression of that DNA. So we run three parallel expressions of the same direction — 纸本 (paper / warm cream), 夜观 (nightwatch / indigo + ink-gold), 现代 (modern / off-white + jade). Not three competing directions; three themes of the same visual language.
Panpanmao v2 redesign — three parallel brand expressions: 纸本 (paper / warm cream), 夜观 (nightwatch / indigo + ink-gold), 现代 (modern / off-white + jade), each rendered on representative phone screens
Why the shape is different: Different surfaces have different audiences. The divination flow needs gravitas (夜观). The onboarding flow needs approachability (纸本). The analytics/dashboard needs clarity (现代). Forcing one expression on all of them would make two of the three surfaces wrong. But the surfaces also need to feel like the same product, which is what the shared brand DNA gives you.
This is closer to how Notion or Linear handle dark/light modes, except it's three modes chosen by surface role rather than by user preference.
Panpanmao landing page — yin-yang driven hero design, dark palette, Eastern-typographic language. Representative of the 夜观 expression
What big-task does differently here: Monorepo detection changes routing. Phase 0.0 sees multiple apps and a design-ref (HANDOFF.md in docs/redesign-v2/). But the presence of Supabase schema + payment dependencies bumps the tier higher than ÉLAN or Shichuan. For panpanmao, Phase 0 routes to Tier 4 (full GSD) via gsd-autonomous because the redesign crosses multiple apps in the monorepo and has cross-phase dependencies (design token package → component library → surface apps).
Phase 4 (8-track cleanup) also runs at the monorepo level — per package, parallel agents. The subagent dispatch policy for verification is critical here: four surfaces × three expressions × ~8 routes each = ~96 PNGs. Main thread aggregating 96 structured verdicts is fine; main thread reading 96 raw screenshots is not. Per-PNG parallel dispatch is non-negotiable.
Panpanmao redesign v2 full app screens overview — many flows (home / divination / dreams / bazi / hexagram / analytics) rendered consistently across the 纸本 expression
What changes vs. what doesn't
What stays the same across all three:
- Brief → HANDOFF.md → repo as the design handoff chain.
big-taskPhase 0.0 auto-detects profile (all three areui-projector close; panpanmao has enough heavy signals to tier up).- Playwright visual verify is mandatory for every UI phase.
- Per-PNG parallel subagent dispatch for verification. Scale varies (24 / 21 / 96 PNGs) but the pattern doesn't.
impeccable:*for polish passes.
What bends:
- Exploration width. Greenfield → six directions. Brand-locked → one direction, three expressions. Live app rebrand → one direction, per-category study.
- HANDOFF.md granularity. ÉLAN: one locked direction, ~15 screens. Shichuan: brand DNA + per-category specifics. Panpanmao: brand DNA + three expression variants + per-surface specifics.
- Ship cadence. ÉLAN: ship the whole redesign at once, greenfield. Shichuan: category-by-category, never more than one category in-flight. Panpanmao: package-first (tokens → components → surfaces), multi-phase, managed by
gsd-autonomous. - Tier. ÉLAN: Tier 3 ui. Shichuan: Tier 3 ui. Panpanmao: Tier 4 heavy (schema + payment + multi-app).
What I'd tell you
The pipeline is the same. The product is the shape. Don't force-fit the product into a pre-decided pipeline shape. Let the state of your product bend the pipeline:
- No codebase yet? Wide exploration. You're paying for search-space variance you otherwise couldn't afford.
- Live app rebranding? Skip exploration. Go direct to per-surface direction study. Migration discipline matters more than exploration width.
- Monorepo with multiple surfaces? Brand DNA plus parallel expressions. Don't pick one expression and force it on every surface.
The common piece is: big-task Phase 0.0 detects the product shape and routes accordingly. The reason Phase 0.0 takes auto-detection seriously — the bash heuristic for signals, the judgment-based task intent override — is that the profile it picks determines which shape of pipeline fires. Get profile detection wrong and you get the wrong shape; get it right and the whole downstream flow adapts correctly without me having to hand-hold.
References:
- Previous posts in this series:
- harness iteration — what
big-taskis and why it exists. - Claude Design pipeline — the pipeline in its linear form.
- harness iteration — what
- Product series: