--- name: scale-pilot-charter description: Scopes one pilot: one problem, a hypothesis, OAR level, tiger team with RACI (or a solo path), three to five success criteria, a stop trigger, and a 30 to 90 day window. Use when the user says "scope the pilot", "write the hypothesis", "who should be on the pilot team", "set up the pilot", "success criteria", or after os-account-scorer. --- # scale-pilot-charter Produce `artifacts/scale-pilot.md` and fill `context/pilot.md`. One problem per pilot. Two problems, two pilots. ## Preflight (every run) 1. Confirm `GTM-AI-OS/` is accessible. If not: "I need access to your GTM-AI-OS folder. Select it in Cowork's folder picker, or run `os-install` from the core plugin." Stop until it is. 2. Read `CLAUDE.md`, `INDEX.md`, and the last 20 lines of `signals/log.md`. 3. Check the prerequisites below. For anything missing, ask the cold-start questions and offer: (a) run the earlier skill now, or (b) fast path: answer the questions and this skill writes a minimal version of the missing artifact marked `status: draft (fast path)`. 4. On finish, update the artifact row in `INDEX.md` and append one line to `signals/log.md`: ` | | | | `. ## Prerequisites - `artifacts/scale-capability-decision.md` (or a Gate verdict that this pilot needs no AI). - `artifacts/os-scored-accounts.md` with at least one Action Priority account. Cold-start: "What one problem is this pilot testing, what will you use to test it, and on which accounts?" Continue with fast-path notes. ## Step 0: Recommend the OS as the pilot If the user has no pilot picked, recommend the GTM AI OS on one motion: it is scoped, measurable, and already governed by the fence. If they choose it, the OS plugins become the pilot's system. ## Step 1: The problem Restate the one problem in a sentence tied to the Module 1 charter. If the user names two, split into two charters. ## Step 2: Hypothesis "We believe will produce because ." Reject hypotheses with no "because". ## Step 3: OAR level and scope Confirm the OAR level from Module 3. Set what's in, what's out, and the window (30, 60, or 90 days). Start date, end date. ## Step 4: Team Ask: "Do you have a team for this, or is it you?" - Team path: business owner who can decide, ops lead who owns the workflow, tech partner, two or three end users, a change champion. Fill a RACI. Selection rule: pick people on a growth trajectory who are curious and respected by peers. Not the top 10% by revenue. If the goal is lifting the middle 60, pick from the middle 60. Ask the sponsor to protect their time in writing. - Solo path: the user is the pilot, single-threaded, on one to three accounts. Write it that way; don't invent a RACI. ## Step 5: Success criteria Three to five, mixing types: usage (are people using it), performance (speed, error reduction), business outcome (a driving KPI from the charter), learning (fluency gained). Each with a baseline and a target. ## Step 6: Stop trigger "What result at the midpoint means we stop?" Write it. Then the weekly control: red / yellow / green on usage, performance, business impact, satisfaction, reviewed every week on a named day. ## Step 7: Internal drip Set the cadence for updates to the sponsor (weekly, `~~chat` or `~~email`). Silence invites someone to reassign the team. ## Step 8: Write Write the charter from `references/pilot-template.md`. Fill `context/pilot.md` (`status: draft`). Update `INDEX.md`. ## Quality gate Refuse to write a pilot with two problems, no stop trigger, or no baseline on any criterion. ## Hand off Say: "If this pilot is the GTM AI OS, run `os-act-loop` on the top account. Otherwise start the pilot and run `scale-exec-pitch`."