← Vault Index
frameworks / kit-scope-discipline / 05-kit-scope-discipline-output-skill.md
Source: frameworks/kit-scope-discipline/05-kit-scope-discipline-output-skill.md

05 — OUTPUT SKILL: Scope Discipline Kit

Scope

Produces:

Audience: Advisor-internal. Not client-facing.

Filename pattern:

Lifecycle: Primary output is a living document. Regenerated only via targeted Mode 3 updates after initial Mode 1 creation. Secondary output is one-shot per engagement or renewal.

Required Inputs (Restated for Standalone Use)

This file is standalone-readable. Inputs are restated from file 01 so the kit operator doesn't need to jump across files mid-production.

Mode 1 (Create a Scope-Check Document)

  1. Client name (required)
  2. Engagement type (required)
  3. Signed SOW or SOW draft (required — blocks build if absent)
  4. Client reference data (recommended)
  5. Session recap history / master plan C3 evidence trail (strongly recommended)
  6. Advisor's trigger-pattern input — either free-form text, notes, or a 10-min interview capture (required — blocks build if triggers can't be made concrete)
  7. Active bleed amount (optional but strongly recommended when it exists)
  8. Forbidden topics for this client (optional)
  9. Advisor's voice samples (recommended when file 06 is not tuned for this advisor yet)

Mode 3 (Update a Client's Scope-Check)

  1. Client name (required)
  2. Event type — one of: CREATED / HELD / MISSED / EXPANDED / CAP HIT / REVIEWED (required)
  3. Event detail — what happened, what was said, what was done (required)
  4. Date (required)
  5. Actual language used — if event = HELD, the advisor's real response text (recommended)
  6. Updated SOW or change order — required if event = EXPANDED

If any required input is missing, consult file 01 Gap Protocol. Do not fill gaps with assumptions.

Content Rules

Non-negotiable rules that govern every generated scope-check doc and scripted response.

  1. Use the locked terminology from file 02. Every term appearing in the doc matches file 02 definitions. No synonyms, no looser variants.
  2. Scan for forbidden terms before shipping. The forbidden-term list in file 02 is blocking, not advisory. Any hit on checks 21-24 of file 04 = automatic revise.
  3. Scripted responses in the advisor's voice. If the kit operator is not the advisor, the operator must pass scripted responses through the advisor for review before the doc ships. Mine existing emails or session transcripts for phrasing patterns before drafting from scratch.
  4. Triggers must be concrete. Each trigger names a person, a topic, or a specific circumstance. "When [the primary stakeholder] emails about [the recurring problem topic]" passes. "When the client is stressed" fails. Run the 10-min trigger interview before generating if concrete triggers aren't available.
  5. Only document what has happened. The Historical section lists real incidents with dates. Out-of-scope items list work explicitly excluded by SOW or demonstrated to be out-of-scope by prior actual pattern. No speculation, no pre-emptive cataloging of hypothetical asks.
  6. Dollar amounts and hour counts are factual. If a specific dollar amount is cited, it is drawn from actual logged time. If the figure isn't known, the Current Status section says "unknown — to be reconciled" rather than an estimate.
  7. One doc per client, in place. No dated versions. No per-session archives. Updates overwrite. The Review Log tracks change history.
  8. No client-facing diplomacy. The doc is advisor-internal. Write what's true to notice, not what's polite to say out loud.
  9. Status flags are mandatory for ACTIVE BLEED. Optional for STABLE engagements. See file 02 for the five states and their visual treatments.
  10. Section order is locked. See Full Template below. Do not rearrange.
  11. Review Log event types are locked. Use only CREATED / HELD / MISSED / EXPANDED / CAP HIT / REVIEWED. See file 02.
  12. Confirm understanding before executing Mode 1. Present the Mode 1 confirmation statement (below) to the advisor. Wait for confirmation. Do not start production on assumption.

Phase-by-Phase Production Workflow — Mode 1

Phase 1 — Pre-Engagement Setup

Trigger: SOW signed (or SOW draft provided with advisor's explicit intent to generate based on the draft).

  1. Verify SOW exists and is scoped. No doc generation without the SOW. If only a draft exists, confirm with the advisor that generating from the draft is acceptable (the doc will be updated via Mode 3 after final SOW is signed).
  2. Confirm clients/[client-name]/ folder exists in the advisor's client repo. If not, create it (or coordinate with the New-Client Kit if that's the upstream scaffolding).
  3. Read file 02 terminology before proceeding. Every output uses locked vocabulary.
  4. Read file 06 consultant methodology before drafting scripted responses. The voice and advisory-layer awareness have to be in the operator's working context.

Phase 2 — Input Gathering

  1. Read the signed SOW. Extract in-scope items — verb-led, specific, pointed-to. Not umbrella phrases.
  2. Read client reference data (reference-data/[client]-reference-data.md if present). Capture stakeholder names, vendor names, tool names, industry terms.
  3. Read session recap history. Every recap with a C3 mention, a scope-related incident, or a documented out-of-scope ask goes into a working list.
  4. Read master plan C3 evidence trail for this client. Cross-reference against session recaps.
  5. Gather advisor's trigger-pattern input. If the advisor hasn't provided notes, schedule the 10-min trigger interview.
  6. Gather active bleed amount if applicable — factual only, drawn from logged hours.
  7. Ask about forbidden topics. Some clients have incidents the advisor doesn't want documented in writing; honor those requests.

Phase 3 — Gap Protocol Check

  1. Run the pre-build validation gate from file 01:
  1. If any gate fails, block the build. Return to the advisor with the specific gap. Do not proceed.

Phase 4 — Confirm Understanding with Advisor

  1. Present the Mode 1 confirmation statement:

"Here's the client I'm about to generate for: [client name]. Here's what I'm reading: [SOW summary, key historical incidents from session recaps, known triggers, active bleed if any]. Here's what I'll produce: clients/[client-name]/scope-check.md + a proposal scope-section draft in drafts/. Here's what I'll NOT include: [anything the advisor wants held back]. Does this match your intent, or am I missing something?"

  1. Wait for advisor confirmation. Do not start production until confirmation is received.

Phase 5 — Draft the Scope-Check Doc

  1. Start with the header. Populate client name, engagement type, SOW reference, today's date. Set status flag per bleed evidence.
  2. Populate "What's In Scope (Explicit)" from SOW. Verb-led items, minimum 4.
  3. Populate "Lane violations" — at least 3 concrete items specific to this client's industry.
  4. Populate "Lever violations" — at least 2 items naming who has the lever for each.
  5. Populate "Historical out-of-scope asks" — cited past incidents with dates. If session history is absent, mark the section with "populates after first Mode 3 update."
  6. Populate "Scope Triggers" — 3-7 concrete triggers, each naming signal + likely-ask, dated when evidence exists.
  7. Populate "Scripted Responses" — use Template Skeletons A-E below. Tune per advisor voice using voice samples.
  8. Populate "Current Status" — factual state of bleed, open items, pending conversations.
  9. Populate "Cap Tracking" — active favors with caps, or single-row empty-state.
  10. Create initial Review Log entry: today's date, CREATED event, summary of initial state.

Phase 6 — Draft the Proposal Scope-Section

  1. Using the proposal scope-section template below, draft a drop-in scope section for the SOW, change order, or renewal.
  2. Save to drafts/[client-name]-proposal-scope-section-[YYYY-MM-DD].md.

Phase 7 — Self-QC

  1. Run file 04 quality checks. Score.
  2. Run forbidden-term scan (checks 21-24). Fix any hits.
  3. Check required-revise triggers. Fix any hits.
  4. If below 90, identify the lowest-scoring category, fix, re-run.
  5. If below 90 after two revision attempts, escalate to advisor with specific gaps.

Phase 8 — Advisor Voice Review

  1. If the kit operator is not the advisor: present scripted responses to the advisor for voice accuracy review. Mandatory gate before delivery.
  2. Advisor provides edits. Apply edits. Confirm final voice matches.

Phase 9 — Delivery

  1. Commit clients/[client-name]/scope-check.md to the client repo.
  2. Commit proposal scope-section draft to drafts/.
  3. Report to advisor: file paths, QC score, decisions made, open questions (if any).
  4. Add to advisor's monthly calendar: "Review scope-check.md before next [client-name] session." Cadence discipline matters; docs that don't get reviewed go stale.

Phase-by-Phase Production Workflow — Mode 3

Phase 1 — Identify the Event

  1. Client name: known.
  2. Event type: one of CREATED / HELD / MISSED / EXPANDED / CAP HIT / REVIEWED.
  3. Event detail: what happened.
  4. Date: today.

Phase 2 — Load and Audit

  1. Open the existing scope-check.md for this client.
  2. Identify which section(s) the event affects:

Phase 3 — Apply the Update

  1. Make targeted edits. No full regeneration.
  2. If event = HELD: capture the advisor's actual language used. Compare against current scripted response template. If the advisor's real language is tighter or warmer, replace the template.
  3. If event = MISSED: add new trigger if the signal wasn't previously captured. Add scripted response variant if the 5 existing templates don't cover this pattern.
  4. If event = EXPANDED: update "What's In Scope" with new items. Audit triggers — triggers that fire on newly in-scope work may need retuning or removal.
  5. If event = CAP HIT: update Cap Tracking row. Specify the next action taken (wind-down, re-scope, hand-off, stop).
  6. Always add a Review Log entry with the date, event type, and concise summary.
  7. Update Status Flag if bleed state changed.

Phase 4 — Mini QC

  1. Scan for forbidden terms in any new text.
  2. Verify Review Log entry uses a locked event type.
  3. Confirm the doc still reads as skimmable — if the Historical section has grown beyond ~8 entries, consolidate older ones.

Phase 5 — Commit

  1. Commit updated scope-check.md in place.
  2. No new file. No dated version. Updates overwrite.

Template Skeletons

Templates below are voice-shaped by patterns observed in real advisor language when scope was successfully held. Key observed voice markers that work: first-person naming of stance ("I know you want X, but"), specific timeframes and caps, direct acknowledgment without apology, "I would not recommend" framings. Key markers that fail: softening preludes ("I just wanted to"), apologetic openings ("sorry to bother"), vague commitments ("let me see what I can do").

Scripted Response Template A — Small favor, warm relationship

Hi [Stakeholder] — happy to take a look. I can give you [X minutes] on this, then I'll need to step back. If there's more to untangle, let's set up a scoped conversation.

Use when: The ask is clearly under a defined time cap, the relationship warrants a warm yes, and the work won't cascade into more. The time cap is explicit and in the message. Do not use if there's any pattern of the same issue recurring — that's bleed, not a favor.

Voice shaped from: Observed advisor phrasing that accepts warmly while bounding explicitly. The cap goes in the FIRST sentence, not as an afterthought. "Happy to" is the warmth; "I'll need to step back" is the structure. Both matter; neither can be removed.

Tuning notes:

Scripted Response Template B — Out of lane

Hi [Stakeholder] — this one isn't something I'm the right person for. You need [specialist type] on this. I can stay with you on [the part that IS in the advisor's lane] — but [the specialist work] belongs with [specialist].

Use when: The ask is operational execution, tax filing, vendor accountability, or specialist work the firm doesn't carry. Recommend the correct party; stay in the advisory role on the people-and-process side.

Voice shaped from: "Isn't something I'm the right person for" lands better than "I don't do that" in observed holds. The first framing is about fit; the second reads as refusal. Fit is relational; refusal is transactional. Also observed: preserving the in-lane portion ("I can stay with you on...") holds the relationship open even while redirecting the specialist work. This is the "both/and" move — not either-or.

Tuning notes:

Scripted Response Template C — In lane but no lever

Hi [Stakeholder] — I can tell you how I'd approach this, but I want to be direct: the outcome depends on [third party] acting. I'll be most useful giving you the framework and letting you drive the follow-up, rather than me chasing [them] for results I can't produce. Here's how I'd think about it...

Use when: The ask is strategic (in lane) but execution requires a third party the advisor can't compel. Provide framework, not chase.

Voice shaped from: "I want to be direct" is the observed opening that signals a reframe is coming — used by advisors who have a reputation for candor. "I would not recommend" / "I'll be most useful" / "I'll be honest" are interchangeable openers; pick the one that matches the advisor's natural voice. Naming the third party explicitly ("the outcome depends on [board / vendor / CEO]") is observed to matter — generic "someone else" or "circumstances" don't land the same way.

Tuning notes:

Scripted Response Template D — Scope expansion

Hi [Stakeholder] — this is bigger than what we scoped for [current engagement]. I want to do it right, which means a separate scope of work. Let me put together a short proposal — likely [X hours / $Y] — and send it over this week.

Use when: The ask is real, billable, within the firm's lane, and has a closable outcome. Formalize before starting.

Voice shaped from: "I want to do it right" frames the scope expansion as care, not resistance — observed to land well even with clients who push back on formalization. Rough sizing in the message ("likely [X hours / $Y]") moves the conversation from "will we do it" to "what's the scope" — a shift that changes negotiation posture. "This week" is the timing signal; observed patterns show delays of more than a week cause the momentum to die.

Tuning notes:

Scripted Response Template E — Active bleed wind-down

Hi [Stakeholder] — I need to be direct about something. Since [date] I've logged roughly [$X] of work on the [specific issue]. That's outside our [engagement scope], and I haven't invoiced because the situation kept evolving. Before we go any further, I need us to agree on how we close this out — either as a scoped project with pricing, or as a wind-down where I step back after [X specific items]. Can we get 15 minutes on the calendar this week to align?

Use when: There's already significant unpaid work, a pattern of continued bleed, and the relationship can absorb a direct conversation. This is the hardest conversation; consult file 06's "Wind-Down Conversation" advisory play before sending.

Voice shaped from: "The situation kept evolving" is the factual frame observed to work — it names the drift as mutual without blaming. Observed failures: apologetic openings ("I'm so sorry this got complicated") center the advisor's discomfort rather than the structural reset; vague commitments ("let's figure out how to handle this going forward") produce more drift, not less. "I need us to agree" signals the conversation needs both parties; "15 minutes live" prevents email drift; "this week" blocks the conversation from sliding.

Tuning notes:

Full Template — scope-check.md

# {{CLIENT_NAME}} — Scope Check

**Client:** {{CLIENT_NAME}}
**Engagement:** {{ENGAGEMENT_TYPE}}
**Signed SOW:** {{SOW_REFERENCE}}
**Last scope review:** {{YYYY-MM-DD}}
**Status flag:** {{STATUS_FLAG_OR_OMIT}}

---

## What's In Scope (Explicit)

- {{IN_SCOPE_ITEM_1}}
- {{IN_SCOPE_ITEM_2}}
- {{IN_SCOPE_ITEM_3}}
- {{IN_SCOPE_ITEM_4}}
- {{ADDITIONAL_ITEMS_AS_NEEDED}}

## What's Explicitly Out of Scope

### Lane violations ({{FIRM_NAME}} doesn't do these)

- **{{LANE_VIOLATION_1_HEADER}}** {{LANE_VIOLATION_1_EXPLANATION}}
- **{{LANE_VIOLATION_2_HEADER}}** {{LANE_VIOLATION_2_EXPLANATION}}
- **{{LANE_VIOLATION_3_HEADER}}** {{LANE_VIOLATION_3_EXPLANATION}}
- {{ADDITIONAL_LANE_VIOLATIONS}}

### Lever violations ({{ADVISOR_NAME}} can't close these)

- **{{LEVER_VIOLATION_1_HEADER}}** {{LEVER_VIOLATION_1_EXPLANATION_INCLUDING_WHO_HAS_LEVER}}
- **{{LEVER_VIOLATION_2_HEADER}}** {{LEVER_VIOLATION_2_EXPLANATION_INCLUDING_WHO_HAS_LEVER}}
- {{ADDITIONAL_LEVER_VIOLATIONS}}

### This client's historical out-of-scope asks (pattern recognition)

- **{{INCIDENT_1_SUMMARY}} ({{DATE_RANGE}}):** {{INCIDENT_1_DETAIL}}
- **{{INCIDENT_2_SUMMARY}} ({{DATE_RANGE}}):** {{INCIDENT_2_DETAIL}}
- {{ADDITIONAL_INCIDENTS}}

---

## Scope Triggers (Watch For)

These are the specific signals from {{CLIENT_NAME}}'s side that a new out-of-scope ask is incoming:

- **{{TRIGGER_1_SIGNAL}}.** {{TRIGGER_1_LIKELY_ASK}} *({{DATED_PATTERN_OBSERVATION}})*
- **{{TRIGGER_2_SIGNAL}}.** {{TRIGGER_2_LIKELY_ASK}} *({{DATED_PATTERN_OBSERVATION}})*
- **{{TRIGGER_3_SIGNAL}}.** {{TRIGGER_3_LIKELY_ASK}} *({{DATED_PATTERN_OBSERVATION}})*
- {{ADDITIONAL_TRIGGERS}}

---

## Scripted Responses (The Consultant Layer)

### When the ask is a small favor and the relationship warrants it

> {{SCRIPTED_RESPONSE_A}}

**Use when:** {{USE_CONDITION_A}}

### When the ask is outside {{FIRM_NAME}}'s lane

> {{SCRIPTED_RESPONSE_B}}

**Use when:** {{USE_CONDITION_B}}

### When the ask is inside the lane but {{ADVISOR_NAME}} has no lever

> {{SCRIPTED_RESPONSE_C}}

**Use when:** {{USE_CONDITION_C}}

### When the ask is a genuine scope expansion worth doing

> {{SCRIPTED_RESPONSE_D}}

**Use when:** {{USE_CONDITION_D}}

### When the bleed is already active

> {{SCRIPTED_RESPONSE_E}}

**Use when:** {{USE_CONDITION_E}}

---

## Current Status

{{CURRENT_STATUS_SUMMARY_INCLUDING_ACTIVE_UNBILLED_OPEN_ITEMS_PENDING_CONVERSATIONS_EXPECTED_TRIGGER}}

## Cap Tracking

| Favor / Extra Work | Cap | Logged | Trigger at Cap |
|---|---|---|---|
| {{CAP_TRACKING_ROWS_OR_EMPTY_STATE_ROW}} |

---

## Review Log

| Date | Event | Summary |
|------|-------|---------|
| {{YYYY-MM-DD}} | {{EVENT_TYPE}} | {{SUMMARY}} |
| {{PRIOR_ENTRIES_REVERSE_CHRONOLOGICAL}} |

---

*This document gets reviewed at every {{REVIEW_CADENCE}} advisory session with {{CLIENT_NAME}} and updated whenever a new out-of-scope ask surfaces or scope gets held. Mode 3 of the kit handles these updates.*

Proposal Scope-Section Template (Secondary Output)

Drop-in scope language for SOWs, change orders, or renewals. Saved to drafts/[client-name]-proposal-scope-section-[YYYY-MM-DD].md.

## Scope

### What This Engagement Includes

{{IN_SCOPE_ITEMS_VERB_LED_SPECIFIC_BOUNDED}}
- {{ITEM_1_WITH_VERB_AND_BOUNDARY}}
- {{ITEM_2_WITH_VERB_AND_BOUNDARY}}
- {{ITEM_3_WITH_VERB_AND_BOUNDARY}}

### What This Engagement Does Not Include

{{OUT_OF_SCOPE_ITEMS_SPECIFIC_TO_CLIENT_INDUSTRY}}
- {{DAY_TO_DAY_OR_OPERATIONAL_EXCLUSION_1}}
- {{DAY_TO_DAY_OR_OPERATIONAL_EXCLUSION_2}}
- {{REACTIVE_CRISIS_EXCLUSION}}
- {{SPECIALIST_WORK_EXCLUSION_WITH_RECOMMENDATION_FOR_CORRECT_PROVIDER_TYPE}}

### How Scope Changes Happen

New work identified during the engagement requires a written scope expansion before work begins. Expansion proposals include specific deliverables, additional time, and pricing. Unscoped work is not performed informally, even in response to urgent requests.

### Time Caps and Overages

{{IF_TIMED_SESSIONS}}Sessions are scheduled {{DURATION}}. Work beyond scheduled session time requires written approval in advance.{{/IF}}

{{IF_RETAINER_STRUCTURE}}The monthly retainer covers {{HOURS_OR_DELIVERABLES}}. Work beyond the retainer either rolls into the next month (capped at {{ROLLOVER_CAP}}) or triggers a scope-expansion conversation.{{/IF}}

External QC Dependencies

The scope-check doc contains prose in the advisor's voice. External vault QC files that may apply:

QC FileWhen to RunWhat to Fix
copy-qc.md (if present in vault)After draft, before shipP1 and P2 copy violations
sentence-editor.md (if present in vault)For scripted responses specificallyTightness, voice, directness
Advisor-specific brand QC (per firm)If the firm has brand voice guidelinesAlignment to firm voice

If these files exist in the vault, reference them and run them as part of Phase 7 self-QC. If they don't exist yet, document the gap and flag for a future Mode 2 update.

Delivery Checklist

Before handing the scope-check doc to the advisor:

  1. [ ] SOW was read and cited in "What's In Scope" — verb-led items
  2. [ ] Session history (if available) was read; at least 2 historical incidents cited with dates
  3. [ ] At least 3 concrete triggers listed with specific person/topic/circumstance AND likely-ask prediction
  4. [ ] All 5 scripted response templates present (A-E), each with "Use when" note
  5. [ ] All scripted responses pass voice requirements from file 02
  6. [ ] Forbidden-term scan ran — zero hits on checks 21-24 from file 04
  7. [ ] Cap Tracking table present (populated or empty-state row)
  8. [ ] Review Log entry added with today's date and locked event type
  9. [ ] Status flag set correctly (ACTIVE BLEED if applicable)
  10. [ ] QC scored 90+ against file 04
  11. [ ] Advisor reviewed scripted responses for voice accuracy
  12. [ ] File path verified: clients/[client-name]/scope-check.md (exact filename, no version suffix)
  13. [ ] If Mode 1 also produced proposal scope section, that file is in drafts/ with today's date
  14. [ ] File 06 consultant methodology was read by operator before drafting scripted responses
  15. [ ] Required-revise triggers all cleared

Don't Interrupt the First Run (Testing Discipline)

When running Mode 1 for the first time on a new client:

  1. Let the kit produce the full scope-check doc before making corrections.
  2. Compare output to the golden example (file 03).
  3. Document every gap between actual and expected in a Mode 2 improvement note.
  4. Fix the kit files — not just the output for this client.
  5. Re-run on a second client to verify the gaps are closed.

Mid-process corrections mask real gaps in the kit's instructions. Let it finish; then fix the kit.

Post-Production Mode 2 Discipline

After every Mode 1 run, before moving on:

  1. Did the advisor change anything in the generated scope-check doc by hand? → Update file 03 (golden example) to reflect the better version. Update relevant content rules in this file (05) so the kit produces it that way next time.
  2. Did QC miss something the advisor caught? → Update file 04 (quality) to add the missing check. Add an entry to Common Failure Modes.
  3. Did a new scripted response pattern emerge? → Update the Template Skeletons above with the new variant. Cross-check file 02 voice requirements.
  4. Did a new forbidden term surface from production? → Update file 02 terminology.
  5. Did an advisory play get invoked that file 06 doesn't document? → Update file 06.

Every manual fix becomes a kit fix. If you fixed it by hand, fix the kit so you never fix it by hand again.

Summary for Operators

If you're the kit operator and you've read this far, the shortest version of what to do:

  1. Read file 02 (terminology) and file 06 (consultant methodology) before production.
  2. Get the SOW, session history, reference data, and trigger-pattern input from the advisor.
  3. Run the pre-build validation gate. Block the build if gates fail.
  4. Present the Mode 1 confirmation statement. Wait for advisor confirmation.
  5. Draft the doc following the phase-by-phase workflow above.
  6. Run file 04 QC. Fix issues. Re-run.
  7. Get advisor voice review. Apply edits.
  8. Commit. Report.

That's it. The depth lives in files 02, 04, and 06. This file is the recipe.