23 Agents, 11 PRDs, 1 Goal File: A Real Vertical From a Single Prompt

The constraint

The existing platform handles fixed-slot tour-ops — start times of nine, ten, twelve, two. The new vertical needs flexible-duration: a six-hour booking starting at 2:30, with tiered pricing across guest bands and an additional-hour rate. The catch is that the new model has to live in the same database schema, behind the same booking flow, without breaking a single existing customer. Two real assets will be the live UAT — once it works for them, the platform supports the entire new product category.

Phase one — eleven PRDs from one prompt

I started with a custom skill called goalgeneratorfreebo that takes a casual idea and produces a ready-to-run /goal condition string. The first thing it did was fan out PRD authoring. Twenty-three distinct subagents wrote, cross-referenced each other’s outputs, revised, and produced eleven product requirement docs plus a phased rollout plan with explicit acceptance gates between every phase.

Phase two — one goal file, six sequential phases

With the PRDs settled, I wrote a single goal file: docs/prds/v1.goal.md. The mission:

# /goal — Vertical v1: Two-Asset UAT

## Mission

Build the new vertical end-to-end per `docs/prds/`, then prove
it works by autonomously configuring the client's two real assets
with their actual products, schedules, pricing, and rules, then
completing the full reservation lifecycle (book → availability
reacts → admin modifies → ledger updates).

The agent does this with zero manual intervention. The only
humans involved are me reading the final PR.

## Execution model

Use the `feature-orchestrator` agent for each phase. It reads the
phase's PRD and auto-picks `/upgrade-feature-team` (PRDs that
extend existing services) or `/implement-feature-team` (PRDs
that are pure migrations) per its decision tree.

Run phases sequentially. Do NOT start the next phase until the
current phase's gate is green and merged to main.

Phases run sequentially. The next phase doesn’t start until the current phase’s gate is green and merged to main:

Phase three — the honest postmortem

When the run finished, I generated a postmortem from ccusage data and my own walk through the resulting UI. It’s unflattering on purpose.

What worked. Database schema landed correctly. Fixed-slot regression tests passed bit-for-bit. The flexible-duration engine returned correct prices on the PRD’s worked examples. The phased gate model held — nothing merged that broke the regression baseline.

That last one is the real lesson. The orchestrator has a strong gradient toward “make it work” — and when “make it work” can be solved either by changing the API or by changing the UI, it picked whichever was closer. The right answer was the one further away.

The fix that came out of it

I wrote up the findings, then used them to author a new prd-review skill that audits a PRD’s frontmatter for required blocks (auth_preconditions, ui_surfaces, api_to_ui_wiring, no_shortcut_rules, docs_deliverables) before /plan-feature ever runs. Same mistakes won’t catch me twice.

The postmortem is what produced the next skill. That’s the actual deliverable of a multi-hour orchestrator session — not the code, but the next set of guardrails.

The pricing formula (real, public-safe)

# Standard pricing (fixed-slot products — unchanged by this work)

subtotal              = base_price + add_ons + custom_charges - custom_discounts
subtotal_after_promo  = subtotal - promo_discount
platform_fee          = subtotal_after_promo × platform_fee_rate
taxable               = subtotal_after_promo + platform_fee
tax                   = taxable × tax_rate
grand_total           = subtotal_after_promo + platform_fee + booking_fees + tax

# Tiered-Hourly Pricing (the flex-duration model the new vertical adds)

total = base_price_cents
      + max(0, duration_hours - base_duration_hours) × additional_hour_rate_cents
      + max(0, guests - per_guest_threshold)        × per_guest_rate_cents
      + max(0, extra_crew - included_crew)          × per_extra_crew_rate_cents

Worked example, real from the PRD: a 3-hour booking, 25 guests, base tier 19–41 guests at $4000 with per_guest_threshold = 18 and per_guest_rate = $100.

total = $4000 + (25 − 18) × $100 = $4,700

Add a fourth hour: + $500 additional hour rate → $5,200.

That formula correctly survived the orchestrator. The UI rendering it did not. Both will be true in your runs too.

Related work

• 100 Agents, 88 Million Tokens, $313 — the content-side companion to this orchestrator pattern. Same agent-team idea, different blast radius.
• 21 Agents to Untangle a Year of Frontend Drift — the surgical-refactor pattern that powered Phase B of this build.

References & further reading

• ccusage — local Claude Code usage reporter, the basis for the postmortem cost numbers.
• Anthropic — Claude Code subagents — official docs on the subagent system this orchestrator builds on.
• Anthropic — prompt caching — explains why the cache-read column was the smallest line item in a multi-hour orchestrator run.
• Astro content collections — how this post itself is structured and rendered.