Full Multica MVP setup
Give this to Claude Code to run the full discovery and setup flow end-to-end.
Give to Claude MD →Playbooks & skills
Copy our playbooks. Use the operating layer.
These are the copyable files behind the system: agent role cards, skill instructions, workflow recipes, briefs, review checklists, and approval gates. Take the useful bits, adapt them, and avoid building a fragile pile of one-off prompts from scratch.
Give-to-Claude setup files
Use these when you want Claude to perform the setup step.
These are executable setup prompts/files for Claude Code. They are different from the Instruction MD files: instructions explain the step; these tell Claude exactly what to do.
Create the four MVP agents
Give this to Claude to create Chief of Staff, Researcher, SEO Consultant, and Blog Writer in Multica.
Give to Claude MD →Add agent instructions
Give this to Claude to fetch and apply the role files to the matching agents.
Give to Claude MD →Create and attach skills
Give this to Claude to create core skills and attach them to the right agents.
Give to Claude MD →Run the first request
Give this to Claude to create the first parent request and check that the routing loop starts.
Give to Claude MD →Review the MVP loop
Give this to Claude to inspect the parent issue, child tickets, artifacts, and final handback.
Give to Claude MD →Actual skill files
These are the behaviours that make the agents more reliable.
Skills are reusable instructions attached to agents. They are system habits: how work gets reviewed, evidenced, formatted, and safely handed back. Specialist routing should mostly come from the role files: SEO work goes to the SEO Consultant because that is their lane.
Chief of Staff final review
The review gate that checks whether specialist work answered the brief, preserved evidence, and names approvals.
Open skill MD →Evidence labels
The evidence layer: confirmed, inferred, assumption, and gap labels for every meaningful claim.
Open skill MD →HTML styled report preview
Makes substantial reports readable HTML instead of Markdown walls, styled like the analysed site where relevant.
Open skill MD →HTML blog approval preview
Makes blog drafts come back as approval-ready HTML previews, clearly labelled draft/not published.
Open skill MD →Optional workflow recipes
Recipes are examples, not plumbing.
A Chief of Staff with clear role files should route SEO work to the SEO Consultant automatically. Recipes exist when you want a repeatable demo pattern or checklist for a common workflow — not because the system needs a special permission slip to use the obvious agent.
SEO audit to site growth work
Optional demo recipe for turning one broad SEO/ranking ask into specialist tickets. Not required for basic SEO routing.
Open recipe MD →Agent role files
The four MVP agents also have copyable role files.
The role files define lanes. The skills define repeatable behaviours. Together they stop the system becoming a fragile pile of one-off prompts.
Chief of Staff
Coordinator instructions for routing, briefing, reviewing, and final handback.
Open agent MD →Researcher
Evidence-gathering instructions for source material, competitors, and buyer language.
Open agent MD →SEO Consultant
Search/site visibility instructions for audits, ranking actions, and draft review.
Open agent MD →Blog Writer
General-purpose blog writing instructions, not just the sample SEO workflow.
Open agent MD →Human playbooks
Plain-English patterns for people reviewing the work.
These are the human-readable versions of the operating habits above: briefs, handbacks, approval gates, shipped-work summaries, and evidence discipline. Use them when you need to explain the system without dumping raw agent files on someone.
Coordinator brief
Use this when founder intent needs to become actual work instead of chat residue.
- Outcome: What commercial or operational result are we trying to create?
- Owner: Which specialist owns the first artifact?
- Inputs: What sources, pages, docs, customers, or constraints must be read first?
- Success signal: What must be true for this to be accepted?
- Approval gate: What cannot happen without human approval?
- Deadline: When should the first useful handback exist?
- Definition of done: What artifact gets attached back to the issue?
Agent role card
Create lanes before you create agents. Otherwise they all become the same eager intern in different hats.
- Name and role: What does this agent own?
- Reports to: Which coordinator reviews and closes the work?
- Owns: 3–5 responsibilities, written as verbs and outputs.
- Works with: Which agents provide inputs or receive outputs?
- Style: What should artifacts sound and look like?
- Not this: What must this agent not do?
- Tools: Which systems can it read, draft in, or mutate? Which actions are gated?
Issue handoff
The fastest way to make agent work reviewable is to force clean handbacks.
- Delivered: Link or attach the artifact.
- What changed: 3–5 bullets, no vague triumph noises.
- Evidence: Sources, screenshots, logs, checks, or data used.
- Gaps: Missing access, weak evidence, or unverified assumptions.
- Recommended next action: Accept, revise, route, approve, hold, or kill.
- Approval needed: Name the exact decision if a human is required.
Coordinator review checklist
Specialists do the work. Coordinators protect quality and context.
- Does the artifact answer the brief?
- Did the agent read the required inputs?
- Are claims labelled and defensible?
- Are public, paid, financial, customer-facing, or irreversible actions gated?
- Is the output useful to the next owner?
- Is there a clear accept/revise/route/hold/kill decision?
- Could a smart buyer/operator respect this if they saw it?
Approval gate
Humans should approve decisions, not decode messy agent rambling at speed.
- Decision needed: One sentence.
- Recommended move: Go / hold / revise, with reason.
- Risk: What could go wrong if approved?
- Rollback or escape hatch: How do we undo it?
- What will happen after approval: Specific next action.
- What will not happen: Any important limits or non-actions.
Shipped-work summary
Activity is not strategy, but visible work stops the system becoming imaginary.
- What closed: Issue/title/artifact.
- Who owned it: Agent or human owner.
- What landed: One clear sentence.
- What was deliberately held: Spend, send, public action, production change, etc.
- What remains: Next issue, decision, or known gap.
Evidence labels
This is the evidence layer. Missing data is a gap, not a permission slip to hallucinate.
- Confirmed: Directly observed in source data, logs, screenshots, docs, customer words, or platform output.
- Inferred: Reasonable conclusion from evidence, but not directly observed.
- Assumption: Useful working belief that must not be reported as fact.
- Gap: Missing access, missing data, failed read, blocked source, or unresolved uncertainty.
Use one template today.
Start with the coordinator brief. If the first issue is clean, the rest of the system has a fighting chance.