--- name: os-message-architecture description: Writes outreach for one account from its Account Context using the path its evidence allows (confirmed pain, signal-only question, or research task), mapped to three decision roles, with every proof point drawn from the proof register. Use when the user says "write the outreach", "what do I say to this account", "draft the email for X", "message architecture", or as the ACT step after scoring. --- # os-message-architecture Produce `artifacts/os-message-.md`. The evidence decides the path. The path decides what the message is allowed to claim. ## 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`, `context/fence.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. Before any connector write or external send, check `context/fence.md` for the account's bucket and the action. Auto = proceed. Approve = ask. Never = decline and name the row. 5. On finish, update the artifact row in `INDEX.md` (with `[[wikilinks]]` to the files this run read) and append one line to `signals/log.md`: ` | | | | | `. ## Prerequisites - A full Account Context record for the account, scored by `os-account-scorer`. - `context/messaging.md` with a thesis, tone rules, and a proof register. Cold-start: "Give me the account, one thing they've said or done recently with where you saw it and when, and your one-sentence value thesis." Build a minimal record, score it, mark fast path, continue. ## Step 1: Pick the path from readiness.md Read the account's PAIN, MOMENT, CONFIDENCE and the message eligibility table in `os-decide/skills/os-account-scorer/references/readiness.md`. - **Confirmed pain (PAIN 4 or 5):** state the problem in their words. At 5, name the consequence they named and make the case. At 4, ask about the consequence. - **Signal only (PAIN 3, MOMENT ≥ 3, CONFIDENCE ≥ 3):** ask whether the suspected problem exists. Example: a new CRO and a CRM rollout support "Does your rollout include call-to-CRM handoffs?" They do not support "You're struggling with CRM hygiene." Never assert. - **Insufficient (PAIN ≤ 2, or any supporting fact expired or synthetic):** write no message. Produce a research task: what to find, where, by when. Route to `os-account-context`. Write the path and the reason at the top of the file. ## Step 2: The six beats Signal (verified change, where seen, when) → Pain (their words, or the question on the signal-only path) → Consequence (theirs, never yours; omitted on signal-only) → Value (thesis applied) → Proof (one entry from the proof register) → Action (one small ask). ## Step 3: Persona map Fill three roles from the record; find contacts in whatever CRM, email, or enrichment source is connected, or ask. Account facts stay constant across roles. The question and the next step change: - Workflow owner: workload, process quality, adoption. Ask about the day-to-day. - Economic buyer: business consequence, investment, success measures. Ask about the number. - Technical owner: permissions, integration, maintenance. Ask about the stack. Target three contacts by day 14. ## Step 4: Proof from the register only Every proof point must exist in `context/messaging.md` under the proof register with: source, measurement period, scope, permission for external use. If the register lacks an entry, say "no approved proof for this claim" and leave the beat as a question. Never turn a workflow improvement into a revenue claim. ## Step 5: Formats One email under 120 words, one LinkedIn note under 60, one call opener of three sentences, per role. Match tone rules. ## Step 6: Hand to the evaluator Set `draft status: pending`. Do not mark approved. Say: "Run `os-message-evaluator` before anything leaves." If the user is running `os-act-loop`, it does this automatically. ## Quality gate No message on the insufficient path. No consequence beat on the signal-only path. No proof outside the register.