Build a complete sales asset end-to-end via The Donahoe Method: diagnostic → primitives → fingerprint → page → integrity-gate → visual → audit → report. Composite orchestrator that calls 14-16 sub-skills via delegate_task in an 8-phase DAG (sequential where dependencies require it, parallel where they don't). Produces a client-ready full-asset bundle.
Use when the user has a product brief and wants the full agency-replacement deliverable in one run - not for single-primitive work.
Not for live-page audit (use /market landing) and not for partial Method runs (call individual /convert sub-skills).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Build a complete sales asset end-to-end via The Donahoe Method: diagnostic → primitives → fingerprint → page → integrity-gate → visual → audit → report. Composite orchestrator that calls 14-16 sub-skills via delegate_task in an 8-phase DAG (sequential where dependencies require it, parallel where they don't). Produces a client-ready full-asset bundle.
Use when the user has a product brief and wants the full agency-replacement deliverable in one run - not for single-primitive work.
Not for live-page audit (use /market landing) and not for partial Method runs (call individual /convert sub-skills).
triggers
["convert package","full sales asset","end to end sales page","end-to-end sales page","full method run","donahoe full build","build the full sales asset","build the page bundle","sales-asset bundle"]
negative_triggers
["just write the open","just the headline","audit my url","build my campaign","everything for the launch","launch my product","agency replacement"]
{"lineage":"Wayland-owned cross-skill orchestration over The Donahoe Method (Wayland-owned operating system)"}
Convert Package - Full Sales-Asset Composite (the agency replacement)
"That's the Donahoe Method. Write like a human. Sell like you mean it. Close like you know it works." - The Donahoe Method, summary
This skill is the suite-level orchestrator that takes a product brief and emits a complete, ship-ready sales asset built end-to-end through the Method. It calls 14-16 sub-skills across 8 phases, parallelizing where the DAG allows. The output is everything an agency would deliver - diagnostic, copy, page, integrity gate, visual specs, audit, client report - in one composite run.
Note on convert-transition: the transition library is consumed by convert-chute (which uses transitions as part of momentum engineering - open loops at section breaks, energy moves, etc.) rather than running as a standalone phase. When P3.5 invokes convert-chute, transitions are already integrated. There is no separate transition phase by design.
When to Use
Trigger phrases: "convert package", "full sales asset", "agency replacement", "end to end sales page", "full method run", "donahoe full build", "build the whole thing", "everything for the launch", /convert package <product>.
Use when:
The user has a product brief and wants the full deliverable, not just one primitive
The user is replacing an agency engagement and wants the complete artifact bundle
A net-new launch needs the asset stack assembled in one coordinated pass
A re-launch requires rebuilding the page from the Method foundations up
Do NOT use for:
A single primitive (use the specific sub-skill: /convert open, /convert close, etc.)
Live-URL audits - use /market landing <url>
Net-new offer construction - use /funnel offer first; package consumes the offer
Funnel-level architecture (multi-asset campaigns) - use /funnel build-campaign (which can call this skill as one component)
What This Composite Delivers
A complete asset bundle:
Diagnostic - The Four Questions answered + Market Temperature classification
Method primitives - The Open + The Three Locks + The Bullets + The Proof + The Cascade Close
Sales page - Full long-form direct-response page (copy + structure)
Why the integrity gate (P3.5) runs BEFORE the audit (P5): the audit is an inspection - but the chute + voice + bullshit-filter steps actually FIX the draft. Running them after P3 (page assembly) and before P5 (audit) means the audit scores the post-fix version, not the raw page output. This avoids the "AI grades its own homework while still failing" problem identified in the Pass 1 cross-audit.
The Bullshit Filter is a coaching pass, not a gate. P3.5's filter call quotes the 3 weakest lines and forces 3 rewrites of each. The composite output includes those quotes + rewrites for the user to choose from. There is no "PASSED ✓" stamp anywhere - the user inspects the coaching artifact and decides whether to ship.
Concurrency requirement: This composite requires delegation.max_concurrent_children >= 5 in the harness config. P2 fans out to 5 simultaneous children. P4 fans to 4 (within the same limit). If the harness is set lower than 5, P2 falls back to sequential - the asset still produces correctly, but slower (~3-5 minutes longer).
Configuration check at runtime:
# In settings.json or pack-level configdelegation:max_concurrent_children:5# required for parallel phases of /convert package
If the runtime cannot meet this, log a warning and serialize P2 + P4. Note the fallback in the report.
Inputs
Required:
Product brief - what we're selling. Minimum: product name, what it does, what it costs, who it's for. Better: full brief with target reader (one specific person), the nerve, founder credibility detail, real proof inventory, offer details.
Optional:
2. Stated audience temperature - overrides what convert-temperature would default; if provided, used as input rather than derived
3. Brand visual constraints - colors, typography, image style (informs P4 visual specs)
4. Existing assets - prior copy, prior page, prior audits - pulled in as comparison material in P5
5. out_path - caller-controlled output. Defaults to build_report_path("business-conversion", instruction)/<product-slug>/
If the product brief is too thin (e.g., just a product name), the orchestrator pauses at the start of P1 and asks the One Person Rule prompt:
"Before I can run the Method, describe the one person you're writing this for. Not a segment - one specific human. Name them, give me their city, their day, what's keeping them up at night. The whole asset is built around this person."
Don't proceed without the One Person.
Workflow
Pre-flight - config check + brief validation
Verify delegation.max_concurrent_children >= 5. If lower, log fallback warning.
Validate the product brief contains: product name, what it does, the One Person, the Nerve, the price/offer. If any missing, ask once for the missing fields.
Output: 12-proof-stack.md - visual proof patterns (1-7) mapped to real proof inventory + paste-ready HTML/CSS for each pattern.
Wait barrier: all 4 must complete before P5.
Phase 5 - Method Audit (sequential)
Step 5.1 - convert-audit <p3 output + p4 outputs>
Delegate. Inputs: 08-sales-page.md (the copy) + 09-12.md (the visual specs). Output: 13-audit.md containing:
0-100 normalized Donahoe Method score
Dimension-by-dimension findings (8 dimensions)
Prioritized rewrite recommendations
Method audit footer
If the audit score is < 70, the report flags this and recommends the user iterate (rerun specific primitives + re-audit). The composite does NOT auto-iterate by default - that's a user decision. If the user adds --auto-iterate to the package call, the orchestrator can rerun the lowest-scoring primitive once and re-audit, capping at one iteration.
Phase 6 - Client Report (sequential)
Step 6.1 - convert-report <all P1-P5 outputs>
Delegate. Inputs: every prior artifact. Output: 14-client-report.md containing:
Executive summary (the asset built, the Method score, the deliverable list)
The five Method primitives in P2 (open, three-locks, bullets, proof, close) are pairwise independent. Each reads the same P1 inputs (Four Questions + Temperature) and produces independent output. None depends on another's output to run. Parallelizing them cuts P2 wall time from ~5x to ~1x (limited by the slowest child).
Why Phase 3 must be sequential
convert-sales-page consumes ALL P2 outputs as inputs. It composes the Open into Section 1-2, the Three Locks across the zones, the Bullets into Section 8, the Proof into Sections 7+9, the Close into Sections 11-17. P3 cannot start until P2 is fully complete.
Why Phase 4 fans out
The four visual sub-skills are pairwise independent given P3's output. above-fold reads only the hero copy; scroll-rhythm reads the section list; mobile reads the page structure for compression rules; proof-stack reads the proof copy + section placement. None depends on another's output.
Why Phase 5 is sequential
The audit reads P3 (the page copy) and P4 (the visual specs) as input. It cannot start until both are complete.
Why Phase 6 is sequential
The report aggregates all prior artifacts. Last in the DAG.
Total wall-time estimate (with max_concurrent_children: 5)
P1: ~2 sub-skills × 30s each = 60s
P2: 5 parallel = ~max(child times) ≈ 60s (bottleneck = the slowest of 5)
P3: 1 sub-skill × 90s = 90s (token-heaviest)
P4: 4 parallel = ~max(child times) ≈ 45s
P5: 1 sub-skill × 45s = 45s
P6: 1 sub-skill × 30s = 30s
Total: ~5-6 minutes (vs ~12-15 min serialized)
If max_concurrent_children is lower:
=3: P2 takes 2 batches, P4 takes 2 batches; +90s
=1 (serialized): +5-6 minutes total
Failure handling
A child fails in P2: the other 4 still complete. The orchestrator surfaces the failure, asks user whether to retry the failed child or proceed with degraded inputs. P3 cannot proceed until all P2 succeed (or are explicitly waived).
A child fails in P4: P5 audits whatever visual specs completed. Missing visual specs are flagged in the audit's "Visual" section.
P3 fails: halt. P3 is the load-bearing core; without it, downstream is meaningless.
P5 fails: report still emits without an audit; flag prominently.
P6 fails: all primitive artifacts still exist; user can manually compile.
Pitfalls
Skipping the One Person Rule. If the user gives a vague brief ("agency owners"), the entire composite produces generic copy. Halt at pre-flight and force a specific One Person definition.
Concurrency mismatch. If the runtime can't meet max_concurrent_children: 5, P2 serializes. Surface this in the manifest so the user understands the time cost.
Composite ≠ pipeline. This is a DAG, not a strict pipeline - phases that can run in parallel do. A simple linear "run skill A then B then C" doesn't capture the actual structure.
Iterative re-runs. The composite produces v1. If the audit scores low (<70), iterating on the lowest-scoring primitive often lifts the score 10+ points. Treat v1 as a starting point, not a final.
Brief drift across children. Each delegated child receives the same brief. If the brief is ambiguous, children may interpret differently and produce inconsistent outputs. Force precision in the brief at pre-flight.
Visual specs without copy alignment. If P4's visual specs are produced from an early draft and P3's copy is regenerated, the visual specs become stale. The DAG enforces P4 reads from P3's final output - never from a partial.
Audit short-circuits. Don't let the audit produce "looks good" rubber-stamps. The audit follows its rubric strictly; if a dimension scored 6, it's a 6, not "close enough to 7."
Report bloat. The client report can grow to 50+ pages if every artifact is duplicated. The report SHOULD reference and excerpt; duplication is friction.
Auto-iteration loops.--auto-iterate runs ONE iteration max. Multi-iteration auto-loops produce diminishing returns and risk drift; cap at one.
Lineage
This composite is Wayland-owned cross-skill orchestration. The orchestration itself - the 8-phase DAG, the parallelization decisions, the wait barriers, the integrity-gate-before-audit ordering - is original Wayland design.
Every skill it calls is built on The Donahoe Method (Wayland-owned operating system). The Method is the substrate; this composite is the conductor.
No external lineage required for the orchestration design.
Notes
This skill is the suite's flagship "agency replacement" deliverable. The output bundle is what an agency would charge $5K-25K to produce; this composite produces it in 5-6 minutes.
The audit is run after the page is built, not during. This is intentional: the Method primitives are designed to produce method-aligned output by construction, so the audit is a verification gate, not a corrective process.
The visual specs (P4) produce paste-ready HTML/CSS. The user can take the bundle directly to Webflow / Framer / Wix / Carrd / static HTML. No framework dependencies.
The composite can be invoked recursively from larger composites (e.g., /funnel build-campaign calls this once per asset). When invoked from a parent, the parent passes the brief; the One Person check still runs but can be auto-satisfied if the parent supplied the One Person.
The 14-file output is deliberately granular. Each file is independently usable; the report aggregates them but doesn't replace them.
Iterative refinement is the expected workflow: run package → review audit → rerun specific primitives → re-package (or just re-audit). This skill is the entry point for iteration, not just first-time builds.
Composes upstream with /funnel offer (the offer is input to this skill) and downstream with /launch (suite-level meta-pack composite that calls this once per asset in a campaign).
