/marketing-os-research

name: marketing-os-research
description: "Answer an open question the Marketing OS already wrote down, then promote it to a finding. Takes its queue from the OS itself: files with status open-question in Intelligence/research/, open questions and untested beliefs in Analytics/what-works.md, and ideas with no established pain. Fans out one agent per stream in a single batch across papers, forums, the web and creators, with an effort floor, distinct sources and full-text reads, fact-checks every hard claim with a verifier prompted to refute rather than confirm, then writes Intelligence/research/topic-slug.md and updates the question file in place with a dated status change. Routes findings about our own performance to Analytics, and graduates recurring customer language to the segment files. Always closes by rendering the report. Use when the user says 'research this', 'deep dive on', or runs /marketing-os-research.\\\"\ndisable-model-invocation: true\nargument-hint: \\\"[a topic, or an open-question file to close, or nothing to be shown the queue]"
disable-model-invocation: true

Marketing OS Research

Research one question properly, then put the answer where the rest of the OS will read it.

**The queue is already written.** A well-kept OS records what it does not know: files marked as open questions, beliefs flagged as untested, ideas with no established pain, findings that name the exact measurement that would settle them. That backlog is this skill's input, and working it is more valuable than researching whatever comes to mind, because somebody already decided those questions mattered and wrote down what would answer them.

**The output is not a report.** It is a file the writers, the strategy and the next research run all read. The rendered page is a convenience for a human. The markdown is the artifact.

Run from the OS root. **Stay inside that root.** **Start from zero on identity:** who this is for and what they believe comes from the OS or from the user, never from your context.

First, check what you have

| State | Do | | --- | --- | | No `Context/config.md` | Not a Marketing OS. Point at `marketing-os-setup` and stop | | A topic was named | Run on it. Still check the queue for an existing question it answers, because closing one is worth more than opening another | | No topic named | **Show the queue.** Present the open questions with what each would settle, and let the operator pick | | The queue is empty | Say so. It is a real and good state. Ask for a topic |

Step 1: build the queue

Read these and assemble one list. This is the step that makes the skill OS-native, and skipping it turns it back into a generic research tool.

| Source | What qualifies | | --- | --- | | `Intelligence/research/*.md` with `status: open-question` | A question the OS wrote down deliberately, often with the blocker named. **Highest priority**, because the file usually already states what would answer it | | `Analytics/what-works.md`, its open questions | Claims with some evidence that do not yet support a rule. Each names the specific measurement that would settle it | | `Analytics/what-works.md`, its untested table | Beliefs carried from conviction with no evidence at all, each with the measurement it needs | | `Channels/{primary}/ideas/*.md` with `pain: not yet established` | An idea nobody has grounded yet | | `Intelligence/market/` briefs, their translation-gap sections | Something one audience understands and ours does not, which is a research question shaped like a content opportunity | | `Intelligence/decisions/` | **Read for exclusions.** A question a decision already settled is not open, and re-answering it wastes the run |

Present the queue with, for each item: the question, where it lives, what the file says would answer it, and whether this skill can actually answer it. Say plainly which ones external research cannot settle, because some need an internal measurement instead and no amount of reading will produce it.

**A question whose blocker is a missing connector or an unpulled metric is not a research question.** Name it, say what would unblock it, and do not pretend a literature review substitutes for the measurement.

Step 2: targeted intake

Two things, before any research runs.

**A. Scope it.** Ask conversationally, one thing at a time, and pull half the answers from the OS rather than from the operator.

| Ask | Read instead, where you can | | --- | --- | | The question, and what they already believe or suspect | The question file usually states the belief already. Read it back and ask only what it leaves open | | The purpose: to write something, to decide something, to brief the team | If it came from an idea file or a what-works entry, the purpose is written there | | The angle to pressure-test, or claims they are suspicious of | `Context/brand/positioning.md` names the strategic position, which is usually the thing worth stress-testing | | Who the answer is for | `Context/icp/*.md`. Do not ask which audience, read the segment files and confirm | | Depth: quick, standard, or deep | Ask. It is the one thing the OS cannot tell you |

**Reflect the angle honestly.** Support it where the evidence does and push back where it does not. A research run that only confirms the position it started from has produced nothing.

**B. Probe the connectors.** Read `Context/config.md` for what exists, then verify. Say which streams you can run, offer to connect the high-value missing ones, and name the fallback each stream will use. Never hard-fail for a missing connector: degrade and label it. Detail in `references/streams.md`.

Step 3: fan out. This is not optional

**Launch every stream agent in one batch, before you read any result.** Do not run a stream, look at what came back, and then decide about the next. Sequential collection produces a file built on whatever the first search happened to return, and it is the failure this step exists to prevent.

**Read `ref