# MBAC Skill: SOP Builder

| | |
|---|---|
| **Version** | v2.1 (2026-08-25) |
| **Workflow** | Meta (wraps SOPs around every working skill) |
| **Lead indicator it moves** | Skills with a finished SOP (goal: every deployed skill has one) |
| **Process owner** | Deborah Davis (each SOP's owner = that skill's owner) |
| **Built from** | Disruption Now's EOS process-architect method, rebuilt for MBAC |

## What this is

A skill file tells the AI how to do the work. An **SOP tells a person why and when**, and names the skill that does the how. This builder turns "how Danielle actually does it" into a one-page SOP anyone at MBAC could follow on her day off. Build order: skill first, SOP second, always. A finished workflow = the skill (for the AI) + the SOP (for the human).

The AI drafts, you edit, and nothing ships without your yes. Claude acts as a coach here, never a generator: it must not skip a step below, and it must not move past a gate without you literally typing "yes."

## Before you start (the hard stop)

All three must be true, or stop and fix that first:

1. **The skill exists** in the MBAC Skills Library (one of the 11, or a new one that went through the customization moves).
2. **It has run for real at least once, and worked.** An SOP cannot wrap a skill nobody has used.
3. **You have the Loom.** The process owner records their screen ONCE while doing the task and narrating out loud, like explaining it to a new teammate. 5 to 15 minutes. Include the judgment calls ("I always check X before I send"). The transcript is the raw material; nobody writes from a blank page. **PII rule:** blur or close client records before recording, or mark the video internal-only.

## Steps

1. Paste into Claude: the MBAC Context Document, this file, the skill file being wrapped, and the Loom transcript.
2. Claude first summarizes what it saw on the Loom as a numbered list of actions. Confirm the list before anything else.
3. Claude asks six things, two or three at a time, never all at once:
   - **Outcome:** which of the 11 lead indicators this moves, and the near-term target (2x to 3x). **Write down the BEFORE number now**; the before/after is what we bring to the state.
   - **Trigger:** when it runs, in calendar terms.
   - **Owner:** name plus a backup. If the owner's role is not yet confirmed, the SOP says so ("owner: unconfirmed") until the Director confirms it. Rob approves; Rob never owns an MBAC process.
   - **Stack:** the tools used today.
   - **Exceptions:** the If/Then edge cases, plus every judgment call heard on the Loom.
   - **Category:** Workflow A (intake, counseling, follow-up), Workflow B (outreach, re-engagement, workshops), or Meta.
4. Claude drafts the SOP in this exact shape, one page:
   - **Purpose:** why this process exists, in one sentence a new hire understands
   - **When it runs:** the trigger, in calendar terms
   - **Who owns it:** name and backup (plus "unconfirmed" flag if it applies)
   - **The steps:** 5 to 10 numbered steps. Each step says who does it (person or AI), and any step run by AI names the skill file: "Run *MBAC Initial Outreach, 4-Touch Sequence*"
   - **Zone tags:** each step tagged Zone 1 (AI runs it) / Zone 2 (human checks before it ships) / Zone 3 (human only). Anything a client sees is at most Zone 2.
   - **The checkpoint:** exactly what the human reviews, and the test ("is it true, is it kind, would I send it?")
   - **If it goes wrong:** the fail-safe (who to tell, what to stop)
   - **Compliance:** how this process satisfies all six rules (IT-17 posture, PII double-verified, public-record-only in general chats, AI disclosure at the client relationship start, AI drafts humans send, archive never delete)
   - **For other centers:** what changes if another ODOD site adopts this (site name, host org, team names stay fill-ins)
   - **The proof line:** the BEFORE number, the target, and where the weekly number gets typed (the Lead Indicator Scoreboard)
   - **Version + last audited date** (starts at v0.9-draft)
5. **GATE 1.** Claude asks, word for word: *"Does this match how [owner] actually does it, including the judgment calls from the Loom? Reply 'yes' to continue."* The owner reads the draft against reality and fixes what Claude got wrong. The Loom shows what you do; the owner knows why. An SOP nobody recognizes is worse than no SOP.
6. Publish to Monday: the SOP doc lives in the **MBAC SOP Library** (see Monday Setup Checklist), one page per SOP, cross-linked to its skill file in the **Skills Library Index** board and to its lead indicator. Claude shows you the full page and the destination first and asks "Create this Monday doc? (yes/no)". Publishing bumps the version to v1.0.
7. **GATE 2.** Book the audit: exactly 2 weeks after v1.0 ships, the owner answers five questions (did it hold, what broke, what edge case was missed, what step was unnecessary, what was missing) and ships v1.1. Audits update the SAME Monday doc in place. One living playbook at one link.

## Human checkpoint (Zone 2)

The process owner approves every SOP before it is published, at both gates. Claude must require a literal "yes"; "looks good" does not count.

## Safety & disclosure

Loom recordings of real work may show client data on screen. Blur or close client records before recording, or mark the video internal-only. Transcripts follow the same PII rules as everything else. Every SOP carries the six compliance rules; none are optional.

## Output & where it lands

A versioned, one-page SOP in the Monday SOP library, cross-linked to its skill file and its lead indicator, with the BEFORE number recorded and an audit date on the calendar.

## What changed in v2.1

Project home moved from ClickUp to Monday (MBAC's project management tool): the SOP Library, Skills Library Index, and audit-in-place step now all point at Monday. The SMS Nudge skill was retired, so the library is 11 skills / 11 lead indicators, not 12.

## What changed in v2.0

Added the hard stop (skill must exist and have run once), the two literal yes gates, the owner "unconfirmed" flag, the compliance section in every SOP, the other-centers fill-ins, and the BEFORE-number proof line for the state. v1.0's shape is unchanged; v2.0 makes the discipline explicit.