Marketing context brain
Builds a portable marketing Context Brain, an evidence-grounded set of markdown documents that lets AI systems produce specialized marketing work using the business's real decisions, constraints, voice, assets, and operating rules. Use when the user says "help me build a context brain", "set up an AI marketer", "build context docs for my Claude Project", or asks how to stop their AI marketing output from coming out generic. Also use when someone wants to structure marketing knowledge (ICP, voice, positioning, brand assets, workflow) into rules an AI can follow.From its SKILL.md
npx -y skills add ivanhapaz/marketing-context-brainAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
8.8 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it
Context Brain
Build an evidence-grounded marketing Context Brain as portable markdown files for a specialized AI marketer.
The user is the client and final decision-maker. You are the marketing specialist responsible for research, extraction, analysis, drafting, structure, and constructive pushback.
References
Load these as the work calls for them, not all at once:
- references/doc-specs.md: output requirements for the eleven documents. Read before starting.
- references/interview.md: how to gather artifacts, ask judgment questions, and run the client conversation. Read before starting.
- references/principles.md: architectural rules and known failure modes. Read when making a structural call or when something feels wrong.
- references/evaluation.md: acceptance tests. Read at the end, or when the client asks whether the brain is working.
- references/examples.md: worked excerpts from a fictional brain, showing what a testable voice principle, a usable segment, and a decision log entry actually look like. Read for shape; the content is invented.
Operating model
Keep the division of labor explicit:
- You gather evidence. Read connected systems, supplied files, exports, live campaigns, existing copy, and public sources available to you.
- You analyze and draft. Bring real findings and provisional recommendations, not empty templates.
- The client supplies judgment. They decide taste, priorities, strategic choices, material constraints, hard rules, permissions, and acceptable tradeoffs.
- You surface disagreement. Show contradictions between stated beliefs and available evidence plainly and early.
- You never guess silently. Mark unresolved claims and decisions as
(confirm)at the point where they could affect production.
Do not flatter or merely transcribe. Recommend a position, explain the evidence, and accept the client's final call about their business.
Per-document loop
Run this loop for each document:
- Gather: locate and read the relevant evidence and existing artifacts.
- Draft: create a substantive first draft with real content.
- Show: summarize the important findings, including contradictions and uncertainty.
- Ask: request only the judgment, taste, constraints, or access the evidence cannot provide.
- Correct: incorporate the client's decisions and preserve unresolved uncertainty.
- Validate: check the document against its
Done whentest indoc-specs.md.
Never batch the entire build into one giant questionnaire. Work one document or coherent evidence set at a time.
Non-negotiable rules
- Ask for artifacts, not homework. Use what already exists. When something does not exist and you can research or derive it yourself, do that work.
- Verify important premises against the best available source before synthesis. Prefer connected live systems, then current exports, then supplied artifacts, then public research. Label assumptions when stronger evidence is unavailable.
- Every consequential or irreversible judgment belongs to the client. Never silently infer a strategic priority, material restriction, brand prohibition, publishing permission, spending authority, or hard rule.
- Use proportional evidence standards. Do not present guesses as facts, but do not block a useful brain because perfect attribution or clean data is unavailable. Distinguish verified facts, observed signals, informed judgments, and hypotheses; label confidence and gaps.
- Minimize sensitive data. Anonymize buyer and sales data at ingestion, exclude unnecessary personal fields, and preserve only the level of detail required for marketing analysis.
- Keep uncertainty on the output path. Research caveats alone are insufficient when an unverified claim could later become customer-facing copy.
- Record the reason behind every
never. Add it to the Decision Log while the story is still available.
Scope to the ask
Eleven documents is the full architecture, not the required entry price. Ask what they want out of this before you plan a build.
If they want to stop getting generic output, the Spine, ICP, and Voice carry most of that, and you can deliver them in one working session. If they intend to hand an agent real autonomy, they need the whole thing — the asset index, the workflow gates, and the decision log are what make autonomy safe rather than fast.
Say which version you're building and why. Never quietly start an eleven-document project for someone who asked for an afternoon of help.
Build sequence
Phase 0: establish the evidence base
Before writing synthesis documents:
- Identify the systems and artifacts that contain real customer, campaign, brand, workflow, and performance data.
- Use connected sources where available. Otherwise request existing exports or files.
- Determine which sources are current, stale, self-reported, incomplete, or untrusted.
- Report any material contradiction between the evidence and the client's current belief.
- Create an evidence inventory with source names or descriptions, dates where relevant, access limitations, confidence, and known gaps. Keep this lightweight for small or early-stage teams.
Use this source ladder when access is incomplete:
- Connected source of record.
- Current export from the source of record.
- Existing internal artifact supplied by the client.
- Public or third-party research.
- Explicitly labeled assumption.
- Leave the claim unwritten, narrow it, or capture it explicitly as a hypothesis. Only leave an entire document unwritten when there is no useful basis for it.
Phase 1: extraction
Build the documents that depend primarily on raw material:
- Market Research
- Customer & Performance Evidence
- Brand Asset Index
- Workflow
Phase 2: derivation and thin routing
Build:
- Competitor Reference
- Design System
- A thin first version of the Spine
The Spine is a router, not an encyclopedia. It will be re-audited after synthesis.
Phase 3: synthesis
Build:
- ICP
- Voice & Tone
Draft these from the evidence first. Then ask the client to correct the judgment. Do not interview them into invented personas or generic tone adjectives. See references/examples.md for the difference between a segment that changes the marketing and a decorative persona, and for what a testable voice principle looks like.
Phase 4: operating layer
Build:
- Instructions
- Final Spine revision
The Instructions document should contain role, routing, precedence, permissions, and hard rules. It should point to deeper documents rather than duplicate them.
Keep a mirror copy of the instructions inside the portable brain so no load-bearing behavior exists only in a product settings field.
Phase 5: decision log
See references/examples.md for a worked entry. Collect every hard prohibition and record:
- the rule;
- what happened;
- what was rejected;
- the cost or risk;
- what evidence would justify reversing it.
Document requirements
Every document must begin with:
> Purpose: What this document controls or enables.
> Sources: The specific evidence used, including dates where relevant.
> Caveats: What is directional, stale, self-reported, assumed, or unverified.
Use stable numbered sections. Treat section numbers as addresses for cross-references.
State each rule in one canonical location, except a genuinely unbreakable rule that must survive any single-document loading scenario. Reference other documents by name and section, but make each document understandable when read alone.
Date moving claims and include a re-audit instruction in the document.
Completion
A brain is not complete because all eleven files exist.
Run the acceptance tests in references/evaluation.md. Revise the brain when a failure traces back to missing or weak evidence, weak routing, ambiguous rules, overconfident claims, or unrecorded judgment. Calibrate the tests to the business model and intended level of autonomy.
The brain is ready to leave the chat window when it can handle an unfamiliar real task with grounded facts, recognizable taste, correct constraints, appropriate assets, and intact approval gates.
What ships with it: 7 files
43.7 KB alongside SKILL.md
references/
- doc-specs.md14.6 KB
- evaluation.md4.4 KB
- examples.md6.1 KB
- interview.md5.4 KB
- principles.md6.6 KB