05 — OUTPUT SKILL: Advisory Onboarding Kit

Scope

Produces: Three artifacts per practice:

1. The roadmap — HTML, client-facing, visual
2. Action plan template — Markdown, advisor populates per client engagement
3. Mutual-responsibility template — Markdown, advisor populates per client engagement

Audience: Practice owner (advisor) runs the kit; advisory client receives the output.

Filename pattern:

• [practice-slug]-advisory-roadmap.html
• [practice-slug]-action-plan-template.md
• [practice-slug]-mutual-responsibility-template.md

Lifecycle: One kit run per practice. After delivery, the artifacts become the advisor's living documents — the kit doesn't keep updating them.

Required Inputs

Restated from file 01 for standalone readability:

1. Interview output — structural capture from running file 06 (06-advisory-onboarding-interview-protocol.md) with the practice owner. Live interview, not solo recording.
2. Practice reference data — per-practice file (e.g., members/rob/rob-foncannon-reference-data.md) plus cohort-level reference data (tpc-reference-data.md).
3. The patterns + decisions — from file 01 of this kit.
4. The terminology lock — from file 02 of this kit.

Content Rules

1. Universal spine, member variants. Every roadmap addresses the five patterns + package-design layer (file 01). The spine wording is universal; the practice's specific implementations are noted as variants with attribution.
2. Trigger is named at the top of the roadmap. Signed agreement + payment received (default). If the practice has a different trigger condition, name it explicitly.
3. Pre-scheduled cadence appears as specific months/dates. Not "seasonal" or "quarterly" — actual months that the advisor will book at onboarding. Specific to the practice's rhythm.
4. First win is dollar-measurable and 30-day-bounded. The roadmap names the win type (tax savings, cash-leak recovery, etc.) but does not pre-populate the dollar amount — that gets filled in per client at kickoff. The 30-day window is fixed.
5. Mutual-responsibility doc is referenced, not embedded. The roadmap points to the mutual-responsibility doc; the doc itself is a separate template that gets populated per client.
6. Welcome experience is concrete. Not "send a welcome video" — name the specific format the practice uses (e.g., "3-min welcome video covering [topics] + a one-page printed letter mailed within 48 hours of payment").
7. Completion gate is criteria-based. Not "after 30 days" — a checklist of conditions the advisor and client can both verify.
8. No client-facing AI patterns or consultant jargon. Per file 02 (forbidden terms) and business-aos/reference/core/voice.md.
9. Living document, not static PDF. The roadmap is HTML, shareable, updateable. A PDF export can supplement; it cannot be the primary artifact.
10. Proper nouns from reference data, always. Cross-check every name, tool, and term against the cohort + practice reference data. Override transcript renderings.

Production Phases

Phase 1 — Pre-build validation

Before producing any output, run the pre-build validation gate from file 01:

• Live interview output exists (not solo recording)
• Practice reference data is current (last updated within 30 days)
• Trigger is named and locked
• Package-design layer specified (or waived for lean bundled practices)
• Completion gate named
• Special-sauce protection applied to captured content
• Audience boundary reviewed

If any check fails, stop. Resolve before continuing.

Phase 2 — Synthesize the structural capture

Take the interview output and organize into the kit's working structure:

Phase 3 — Apply special-sauce protection

For each captured element, classify:

• Spine — universal pattern that every practice needs. Goes into the kit's structural elements.
• Variant — practice-specific implementation. Goes into the roadmap as the practice's named approach, attributed if used elsewhere.
• Excluded — advisor-internal content. Stays out of client-facing output.

Test for spine vs. variant: does this element apply to every practice in the cohort? If yes, spine. If specific to this practice's competitive edge, variant.

Phase 4 — Build the roadmap (HTML)

Use the component templates below. Apply the brand visual style (business-aos/reference/brand/visual-style-cyp.md for CYP-flavored output, visual-style.md for AOS-flavored).

Required sections, in order:

1. Header — practice name, client name (placeholder for population per engagement), date the engagement begins
2. The trigger — what's now true that wasn't true before. Name it clearly.
3. The welcome experience — what the client receives in the first 7 days
4. The first win — what the client will see by day 30, with placeholder for the dollar amount the advisor fills at kickoff
5. The roadmap — visual timeline of the year's meetings, what each meeting covers, what the client gets at each
6. What the firm does / What the client does — pointer to the mutual-responsibility doc (the doc itself is a separate artifact)
7. The package boundary (institutional practices only) — what's in, what's a separate project, the table-of-services pattern adapted for this practice
8. The completion gate — criteria-based, when onboarding is done
9. Footer — advisor contact, version date, link to the living-document home

Phase 5 — Build the action plan template (Markdown)

Per-client artifact the advisor populates at kickoff. Structure:

# Action Plan — [Client Name]
**Engagement start:** [date]
**Trigger event:** [Signed agreement on X / Payment received on Y]
**First seasonal meeting:** [date]

---

## What I'm working on
- [Item with target date]
- [Item with target date]

## What I need you to work on
- [Item with target date and named dependency]
- [Item with target date and named dependency]

## Our first win
**Target:** [dollar-measurable outcome]
**By when:** [30 days from trigger]
**The client's role:** [specific action]
**The firm's role:** [specific action]
**How we'll know it's done:** [verification step]

## The next meeting
**When:** [pre-booked date]
**What we'll cover:** [agenda]
**What you'll bring:** [if anything]
**What I'll bring:** [the visual or update]

Phase 6 — Build the mutual-responsibility template (Markdown)

Per-client artifact, signed by both sides. Structure:

# Mutual Responsibility — [Client Name] + [Practice Name]
**Engagement period:** [start] through [annual review date]
**Signed:** [date]

---

## What [Practice Name] commits to
- [Specific commitment]
- [Specific commitment]
- [Cadence — pre-scheduled meetings, the months booked]

## What [Client Name] commits to
- [Specific commitment]
- [Specific commitment]
- [Response time, attendance, etc.]

## Out of scope (separate project)
- [Item the practice does but is not included in this engagement]
- [Item the practice does but is priced separately]

## When onboarding is complete
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

## How we handle the unexpected
- If the client misses a meeting: [process]
- If life intervenes: [process — see Diane's "what would you like me to do" framing]
- If scope changes: [process — re-open this doc, mutual sign-off]

---

**Practice signature:** _______________  Date: _______
**Client signature:** _______________  Date: _______

Phase 7 — Validation

Run the file 04 quality checklist. Address all blocking failures before delivery.

Component Templates

HTML — roadmap section block

<section class="roadmap-stage">
  <div class="stage-header">
    <h2>[Stage name — e.g., "Welcome"]</h2>
    <span class="stage-timing">Days 0–7</span>
  </div>
  <div class="stage-content">
    <p class="stage-purpose">[One-sentence purpose]</p>
    <ul class="stage-items">
      <li><strong>What you'll receive:</strong> [item]</li>
      <li><strong>What we'll do:</strong> [action]</li>
      <li><strong>What you'll do:</strong> [action]</li>
    </ul>
  </div>
</section>

HTML — cadence calendar block

<section class="cadence-calendar">
  <h2>The year on the calendar</h2>
  <p class="cadence-intro">Your advisory meetings are booked before the work begins. These dates are flexible if life intervenes, but they're on the calendar from day one.</p>
  <ul class="cadence-list">
    <li class="cadence-item">
      <span class="month">[Month]</span>
      <span class="purpose">[Meeting purpose]</span>
      <span class="duration">[Length]</span>
    </li>
    <!-- repeat per scheduled meeting -->
  </ul>
</section>

HTML — first-win callout

<aside class="first-win">
  <h3>Your first win</h3>
  <p class="win-type">[Win category — e.g., "Reduced quarterly estimated tax"]</p>
  <p class="win-target">By day 30: <strong>[Placeholder — advisor fills at kickoff]</strong></p>
  <p class="win-mechanic">[How we'll get there — universal language, not member-specific tactic]</p>
</aside>

Mode 2 — Improve Existing Kit

After running this kit:

1. Did the operator change anything in the output by hand? → Update file 03 (golden) once a real golden exists, OR update file 05 (this file) if the process needs adjustment.
2. Did QC miss something? → Update file 04 (quality) — add the check + add to common failure modes.
3. Did a new term need locking? → Update file 02 (terminology).
4. Did inputs change? → Update file 01 (context).
5. Did the interview protocol need adjusting? → Update file 06.

For each change:

• State what changed and why
• Check propagation — does this require updates to other files?
• Add a change log entry to the affected file

Delivery Checklist

Before presenting the output to the practice owner:

1. [ ] Pre-build validation gate (file 01) passed before production started
2. [ ] All three artifacts produced (roadmap HTML + action plan template + mutual-responsibility template)
3. [ ] File 04 blocking failures all cleared
4. [ ] File 04 warnings reviewed (addressed or documented)
5. [ ] Client perspective test passes for every roadmap section
6. [ ] Proper nouns cross-checked against reference data files
7. [ ] Special-sauce protection applied — no proprietary content from other practices in this practice's spine
8. [ ] Audience boundary applied — no advisor-internal content in client-facing output
9. [ ] The trio cross-references coherently (same trigger, cadence, first-win, completion gate)
10. [ ] Filenames match the pattern ([practice-slug]-advisory-roadmap.html, etc.)
11. [ ] Output saved to the practice's per-member workspace, NOT to the kit directory
12. [ ] Mode 2 candidates noted for queued kit-file updates
13. [ ] Practice owner has confirmed understanding before the run finished (file 00 — Confirm Understanding Before Executing)

Don't Interrupt the First Run

When testing a new or updated kit, let the kit produce its full output before making corrections. Mid-process corrections mask real gaps in the kit's instructions.

If you fix a problem while the kit is running, the kit doesn't learn — the same problem will recur next time. Let it finish. Compare to spec. Document every gap. Fix the kit files (not just the output). Re-run and verify.

This is especially important for the first run, where the golden example is a placeholder. The first run defines what the golden becomes.