sarojkjha Campaign Orchestrator
Route a marketing goal to the right work, in the right order. This is the skill to reach for when the problem is real but the diagnosis isn't — "our funnel is broken", "growth stalled", "we're launching in six weeks" — and the honest first answer is that nobody yet knows which part is at fault.
Every engagement runs the same three phases:
Diagnose — establish what's actually wrong, with evidence. Design — build the system that addresses it. Execute — ship it, measure it, iterate.
The single most valuable thing this skill does is refuse to start in Execute. Almost every request arrives as an Execute-phase task — write the ads, fix the landing page, build the sequence — because that's the visible surface. If the underlying problem is positioning or activation, better ads make it worse: more traffic reaching a page that doesn't convert costs more and teaches you nothing.
Nine times in ten the right response to "write me some ad copy" is two diagnostic questions first.
When to use
The user has a goal or a symptom rather than a defined task, or is asking for a campaign, marketing, or GTM plan. If they already know exactly which skill they need, use that skill directly — this exists for the case where they don't.
Before you start
- Read the brand/product context. If
.agents/product-marketing.mddoesn't exist, runbrand-product-contextfirst. Every downstream skill depends on it, and without it each one asks the same questions again. - Get the symptom in their words, not a category. "Nobody signs up" and "signups don't convert to paid" route to completely different Plays.
- Ask what's already been tried. It tells you what's been ruled out, and often reveals the real constraint.
- Get whatever numbers exist. Partial data beats none. If there are no numbers at all, that itself is the finding and instrumentation is the first Play.
Method
Route on the symptom, not the request. A user asking for ad copy whose real problem is a 4% activation rate should be told so. The routing table in resources/plays.md maps symptoms to Plays; the mapping is deliberately based on where the money leaks, not on which team asked.
Then respect the phase gates. Each phase has exit criteria — conditions that must hold before the next begins:
| Phase | Complete when |
|---|---|
| Diagnose | The problem is named with evidence, and you could defend the diagnosis to someone sceptical |
| Design | The intervention is specified concretely enough to build without further interpretation |
| Execute | It's shipped, instrumented, and a measurement date is set |
Skipping Diagnose is the expensive failure. Skipping Design produces activity without a system — work that can't be repeated or handed over. Skipping Execute's instrumentation means you'll never know whether any of it worked.
Start where the evidence says, not at the beginning. If a team genuinely has a well-evidenced diagnosis, start at Design. The gate is evidence, not ceremony.
See resources/plays.md for the seven Plays, the symptom routing table, the skill sequence for each, and worked routing examples.
The Plays
Seven named sequences. Each is a full Diagnose → Design → Execute cycle for one class of problem:
| Play | Reach for it when |
|---|---|
| Fix the funnel | Traffic arrives and doesn't convert |
| Stop the leak | Customers arrive and don't stay |
| Get found | Nobody arrives at all |
| Stand up outbound | You need pipeline and can't wait for inbound |
| Launch | A product, feature, or segment is going live |
| Prove the spend | You're spending and can't defend it |
| Reposition | The message is wrong, so everything downstream underperforms |
Reposition is the one people resist and most often need. When several Plays all seem to apply — weak conversion and weak retention and expensive acquisition — the common cause is usually positioning, and fixing it upstream is cheaper than compensating for it in four places.
Workflow
- Confirm the context file exists. If not, run
brand-product-contextbefore anything else. - Take the symptom in their words, then ask the two or three questions that separate the candidate Plays.
resources/plays.mdlists the discriminating questions per pair. - Name the Play and say why — including which Plays you ruled out and on what basis. This is where the user's own judgment engages; don't skip the reasoning.
- Determine the starting phase from the evidence available. Default to Diagnose. Only start later if the user can produce the evidence that phase would have generated.
- Run the phase, calling the skills in the Play's sequence. Load one at a time; don't bulk-load a category.
- Check the exit criteria before advancing. State plainly whether they're met.
- Hand back at each phase boundary with what was found, what it means, and what the next phase will do. Long autonomous runs across all three phases produce work nobody trusts.
- Name the measurement date at the end of Execute. Work that isn't scheduled for review isn't finished.
Present the result
Lead with the Play and the phase you're starting in, each with its one-line justification. Then the sequence, so the user can see the shape of the work before it begins. Then the first concrete step.
Where two Plays genuinely both apply, say so and name which you'd run first and why — usually the upstream one, since fixing it changes the diagnosis of the other.
Guardrails & common mistakes
- Don't start in Execute because that's what was asked for. The most common request is a task; the most common need is a diagnosis. Say so, briefly, and move.
- Don't run all three phases in one pass. Hand back at each boundary. A plan produced without the user's input at the Diagnose→Design gate gets ignored.
- Don't run two Plays at once. They compete for the same attention and budget, and you lose the ability to attribute any improvement.
- Evidence, not ceremony. If the diagnosis genuinely exists, skip to Design. Insisting on process theatre when the answer is known wastes the engagement's credibility.
- Load one skill at a time. Bulk-loading a category floods the context and degrades every output.
- If there are no numbers at all, that's the finding. Instrumentation becomes the first Play, and everything else waits.
- Naming a Play is not doing the work. The Play is a route, not a deliverable. The value is in the skills it calls.
- Watch for the upstream cause. When three Plays all apply, look for the one problem generating all three symptoms — usually positioning, occasionally targeting.
Related AAJ resources
- Interactive tool: https://aajconsult.com/tools/marketing-maturity-scorecard
- Method: https://aajconsult.com/methodology
Related skills
brand-product-context (the prerequisite for everything) · positioning-statement (where the Reposition Play begins) · marketing-report (the measurement Execute hands off to) · and every skill in the catalog, called in sequence by the Plays.
Credits
Original AAJ skill. Encodes AAJ's Diagnose → Design → Execute consulting methodology as an agent-callable router. The Agent Skills format and the marketing-skills catalog by Corey Haines (coreyhaines31/marketingskills, MIT) were references for structure; the routing model and the Plays are AAJ's own. See the repository README for the full reference list.