--- name: os-account-context description: Builds the Account Context record for one account: expected value, verified pain with source, recent changes, confidence-tagged signals, hypothesis, why-we-might-be-wrong, owner, and next action. Use when the user says "build the account context", "research this account", "what do we know about X", "account record", "prep me on this company", or after os-win-loss-extract. --- # os-account-context Produce `artifacts/accounts/.md`. This record is the single most important artifact in the OS. Modules 3 and 4 read it directly. ## 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 - `context/icp.md` at draft or better. - `context/signal-library.md` with at least three signals. Cold-start: "Describe your ideal customer in two sentences, and name two things that usually happen right before someone buys from you." Write both as fast path entries and continue. ## Step 1: Pick the account Ask for one account, ideally the best open opportunity. Create `artifacts/accounts/.md` from `references/account-template.md`. ## Step 2: FIT Check the account against `icp.md`. Score FIT 1 to 5 with the reasons. ## Step 3: Gather evidence Every fact row carries: source · source date · event date · expiry · contradicts hypothesis? · real or synthetic (see `readiness.md` in os-decide). Several reports of one announcement are one event. A provider's first-seen date is an observation, not adoption. In this order, and tag every fact: 1. Internal: `~~crm` notes, `~~calls` transcripts, `~~email` threads with this account → Verified when quoted with source. 2. Enrichment: `~~enrichment` or web search for leadership changes, funding, hiring, tool switches, public statements of pain → Verified if a URL or record is cited, otherwise Inferred. 3. Pattern: signals from the library that fit the segment → Inferred. Anything else is Unknown. Write Unknown explicitly; don't fill gaps with guesses. ## Step 4: Score the rest PAIN 1 to 5 (severity of verified pain), MOMENT 1 to 5 (recency and strength of change signals), CONFIDENCE 1 to 5 (share of facts that are Verified). Record expected value. ## Step 5: Hypothesis and doubt List any evidence that contradicts the hypothesis before writing it. If contradicting evidence exists and the doubt section doesn't mention it, the record isn't done. Write one hypothesis: "We believe will because and ." Then write "Why we might be wrong" with at least two real reasons. If you can't write the doubt, the record isn't done. ## Step 6: Owner and next action Name the owner and a single next action with a date. ## Step 7: Write and feed back Save the record. Any new signal you found that isn't in `signal-library.md` gets proposed at the bottom of the record for the human to add. Update `INDEX.md`. ## Quality gate Refuse to mark the record complete if PAIN rests only on Inferred facts, or if "Why we might be wrong" is empty. ## Hand off Say: "This record feeds `os-account-scorer` (DECIDE). If you're running SCALE, it's also what you take into every vendor demo in `scale-align`."