← Marketing CompassCONTENT HISTORY

Update to Marketing Compass

Snapshot Sep 30, 2026 · 23:14 UTC · version 1.1.1

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Turn scattered marketing or business symptoms, metrics, stakeholder statements, disagreements, and vague concerns into an evidence-bounded, testable problem definition before structural diagnosis or solution design. Use when a user says the issue is unclear, teams describe different problems, observations exist only as disconnected points, a request already jumps to ads/CRM/MA/reorganization, metrics conflict, definitions may have changed, or source data and interviews must be gathered to create an analysis-ready brief. Separate facts, measurements, interpretations, emotions, hypotheses, requests, and proposed solutions; connect points without inventing causality; identify competing explanations; and specify or perform the minimum evidence acquisition that can change the decision.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 447
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 720
    },
    {
      "relative_path": "references/evidence-acquisition.md",
      "size_in_bytes": 4726
    },
    {
      "relative_path": "references/output-contract.md",
      "size_in_bytes": 3098
    },
    {
      "relative_path": "references/problem-formation.md",
      "size_in_bytes": 5102
    }
  ],
  "name": "articulate-marketing-problem",
  "skill_md_contents": "---\nname: articulate-marketing-problem\ndescription: \"Turn scattered marketing or business symptoms, metrics, stakeholder statements, disagreements, and vague concerns into an evidence-bounded, testable problem definition before structural diagnosis or solution design. Use when a user says the issue is unclear, teams describe different problems, observations exist only as disconnected points, a request already jumps to ads/CRM/MA/reorganization, metrics conflict, definitions may have changed, or source data and interviews must be gathered to create an analysis-ready brief. Separate facts, measurements, interpretations, emotions, hypotheses, requests, and proposed solutions; connect points without inventing causality; identify competing explanations; and specify or perform the minimum evidence acquisition that can change the decision.\"\n---\n\n# Articulate Marketing Problem\n\nCreate the problem before solving it. Convert fragmented reality into an analysis-ready brief without polishing assumptions into facts or declaring a single root cause prematurely.\n\nRead [references/problem-formation.md](references/problem-formation.md) for every substantive problem-definition task. Read [references/evidence-acquisition.md](references/evidence-acquisition.md) when files, systems, interviews, definitions, or additional data must be inspected or requested. Read [references/output-contract.md](references/output-contract.md) before returning a full brief.\n\n## Establish the decision context\n\nIdentify:\n\n- Who must decide what, and by when\n- What triggered the concern\n- What outcome, customer state, or operating condition is at risk\n- What action is already being proposed, by whom, and on what premise\n- What evidence is available now and what access is actually authorized\n\nAsk at most three initial questions that materially change the scope or evidence plan. If answers are unavailable, continue with a provisional problem statement and label its limits.\n\nDo not accept the requested solution as the problem. Translate “increase advertising,” “replace CRM,” “sales must follow up,” or “we need more people” into the condition those actions are intended to change.\n\n## Phase A — Collect and classify the points\n\nExtract atomic statements from conversation, documents, dashboards, spreadsheets, meeting notes, interviews, and system exports. Preserve source and wording when material.\n\nClassify every consequential point as one of:\n\n- Confirmed event or directly observed fact\n- Measurement, including definition, denominator, population, period, and source\n- Stakeholder report or lived observation\n- Interpretation or causal story\n- Emotion, concern, incentive, or desired outcome\n- Hypothesis\n- Unknown\n- Proposed action or solution\n\nDo not collapse stakeholder reports into system facts. Do not treat a logged value as self-explanatory truth; the value can be real while its definition, population, or comparison is unsuitable.\n\n## Phase B — Connect points into candidate structures\n\nConnect points only through an explicit relationship:\n\n- Same population or cohort\n- Temporal sequence\n- Stage or process dependency\n- Shared constraint or common cause\n- Feedback loop or delay\n- Contradiction or definition mismatch\n- Stakeholder perspectives on the same event\n\nMark each connection as `confirmed`, `supported`, `plausible`, or `unknown`. Never join different cohorts, periods, definitions, or attribution systems silently.\n\nGenerate at least two competing explanations when the decision is consequential. State what observation would distinguish them. If the points cannot yet support a structure, say so and produce an evidence-acquisition plan instead of a polished narrative.\n\n## Phase C — Form the problem statement\n\nWrite the narrowest useful problem definition that states:\n\n1. Scope: population, process, market, cohort, and period\n2. Observed condition or change\n3. Why it matters to the pending decision\n4. Candidate mechanism, explicitly labeled by evidence status\n5. Material competing explanation\n6. Missing evidence that could reverse the definition\n\nPrefer formulations such as:\n\n> In scope S and period T, observations O show condition C. This prevents or threatens decision outcome R. Evidence is consistent with mechanism H1, while H2 remains plausible because evidence E is missing. The next useful step is V.\n\nDo not claim to have found the “true problem” when the evidence supports only a provisional issue or decision uncertainty.\n\n## Phase D — Acquire the minimum decisive evidence\n\nWhen authorized files, systems, or connectors are available, inspect them rather than merely listing unknowns. Follow [references/evidence-acquisition.md](references/evidence-acquisition.md): verify definitions and lineage first, then retrieve only information that distinguishes competing problem definitions.\n\nWhen direct access is unavailable, specify:\n\n- Exact field, extract, document, or interview evidence needed\n- Source system or responsible person\n- Population, period, cohort, and granularity\n- Why the evidence changes the decision\n- What result supports, weakens, or refutes each explanation\n- Owner and practical timing when known\n\nDo not ask for exhaustive discovery. Stop when the remaining uncertainty no longer changes the immediate reversible decision, or when the acquisition cost exceeds the decision value.\n\n## Route without overreaching\n\nReturn an analysis-ready problem brief, not a full marketing strategy.\n\n- Route to `diagnose-marketing-structure` after the issue and evidence base are sufficiently defined to compare bottlenecks.\n- Route to `audit-marketing-reasoning` when an existing report or proposal itself is the audit object.\n- Route to `design-marketing-measurement` when metric architecture, experiments, causal identification, or thresholds must be designed.\n- Route to the relevant advertising, B2B, MA/CRM/LTV, or communications skill only after stating the defined problem that justifies it.\n\nIf an immediate danger, legal deadline, material customer harm, or irreversible loss exists, separate containment from deeper problem formation and prioritize the safe immediate action.\n\n## Return a usable brief\n\nAdapt depth to the material. For ambiguous but small requests, return a compact articulation. For cross-functional or consequential cases, use the full format in [references/output-contract.md](references/output-contract.md).\n\nAlways distinguish:\n\n- What is happening\n- What people think it means\n- What may connect the points\n- What is still missing\n- What the problem can defensibly be called now\n- What should be checked or collected next\n\n## Guardrails\n\n- Do not turn a complaint, metric, or proposed solution into the problem by paraphrasing it.\n- Do not invent a link merely because multiple symptoms form an elegant story.\n- Do not merge different cohorts, periods, definitions, or sources without qualification.\n- Do not interpret stakeholder disagreement as evidence that one party is incompetent or acting in bad faith.\n- Do not gather data because it is available; gather it because it can distinguish decisions or hypotheses.\n- Do not let missing information become a reason for endless discovery or no decision.\n- Do not expose credentials, private customer data, or unnecessary personal information while gathering evidence.\n- Do not diagnose the maximum bottleneck before the problem is sufficiently formed; hand off to structural diagnosis.\n- Do not present Marketing Compass terminology as universal industry terminology.\n"
}

SHA-256 of public snapshot: 549ccaabdb18213019d547cbb8487ae5c4ffb599d097533cc4b89cb3dfabd79d