@antoneeo/mkt-agentic-sdlc-skill 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +18 -0
- package/README.md +45 -0
- package/gemini-extension.json +6 -0
- package/package.json +45 -0
- package/scripts/init.js +146 -0
- package/scripts/lib.js +170 -0
- package/scripts/postinstall.js +42 -0
- package/scripts/preuninstall.js +17 -0
- package/skills/mkt-agentic-sdlc/ENFORCEMENT.md +82 -0
- package/skills/mkt-agentic-sdlc/SKILL.md +201 -0
- package/skills/mkt-agentic-sdlc/elicitation.md +89 -0
- package/skills/mkt-agentic-sdlc/frameworks.md +105 -0
- package/skills/mkt-agentic-sdlc/research.md +104 -0
- package/skills/mkt-agentic-sdlc/review.md +73 -0
- package/skills/mkt-agentic-sdlc/scripts/mkt_check.py +567 -0
- package/skills/mkt-agentic-sdlc/templates.md +444 -0
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: mkt-agentic-sdlc
|
|
3
|
+
description: Evidence-First marketing planning protocol with engagement triage, SOSTAC workflow, evidence ledger, adversarial CMO review, a complete Standalone mode and optional symbiosis with devPNT. Use for marketing plans, go-to-market strategy, campaign planning and market research.
|
|
4
|
+
author: Antonio Pinto (https://github.com/Antoneeo)
|
|
5
|
+
copyright: (c) 2026 Antonio Pinto
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Marketing Agentic SDLC
|
|
9
|
+
|
|
10
|
+
This skill guides marketing strategy work with an Evidence-First process proportional to the engagement. It turns the agent into a disciplined marketing strategist: facts come from the user, analysis comes from real research, numbers come from a ledger, and the plan ships only after mechanical validation and adversarial review. It must work fully even without devPNT. When devPNT is available and configured for the current project, plans and strategy artifacts become governed, versioned documents with proposal/approval workflow.
|
|
11
|
+
|
|
12
|
+
Support files in the skill directory:
|
|
13
|
+
- `frameworks.md`: which professional framework to use in which phase (SOSTAC, STP, JTBD, positioning, KPI tree) — and when NOT to use one.
|
|
14
|
+
- `elicitation.md`: the question waves and the only-facts-you-own rule.
|
|
15
|
+
- `research.md`: the research playbook and the evidence ledger discipline.
|
|
16
|
+
- `templates.md`: templates for every artifact and deliverable.
|
|
17
|
+
- `review.md`: the CMO review discipline and the marketing red-flag battery.
|
|
18
|
+
- `scripts/mkt_check.py`: mechanical validator (`check`, `validate`, `ledger`, `budget`, `funnel`, `trace`, `index`).
|
|
19
|
+
- `ENFORCEMENT.md`: optional setup for CI and hooks.
|
|
20
|
+
|
|
21
|
+
Read these files only when needed. `SKILL.md` is the operating contract; the support files are progressive resources.
|
|
22
|
+
|
|
23
|
+
## Honesty Contract
|
|
24
|
+
|
|
25
|
+
No process guarantees market success, and this skill never claims one. What it guarantees is **process rigor**: zero invented numbers, internal mathematical consistency, conformance to frameworks professionals recognize, measurability of every commitment, and a built-in control loop. State this plainly if the user asks for a "guaranteed" outcome — the guarantee is the rigor, not the market.
|
|
26
|
+
|
|
27
|
+
## Marketing Values
|
|
28
|
+
|
|
29
|
+
- **Evidence before claims:** no market number, benchmark or persona trait enters an artifact without an evidence ledger entry. An unsourced number is a defect, not a placeholder.
|
|
30
|
+
- **Ask only what the user owns:** facts (product, price, budget, capacity, constraints) come from the user; analysis (market size, competitors, channels) comes from research. Never ask the user to do the analysis, and never use jargon in questions to the user.
|
|
31
|
+
- **Framework conformance:** deliverables follow structures professionals recognize (SOSTAC, STP, SMART, KPI tree) — but a framework is a lens, not a form to fill. An empty section is declared, never padded.
|
|
32
|
+
- **Internal consistency:** budget allocations sum, funnel math closes, every tactic serves an objective, every objective has a KPI. Checked mechanically, not rhetorically.
|
|
33
|
+
- **Positioning must exclude:** a positioning statement that could describe any competitor is a defect. The swap test (replace our name with the top competitor's) must fail.
|
|
34
|
+
- **Honesty about uncertainty:** assumptions are declared with ranges and confidence, never laundered into facts. A plan built on assumptions says so on page one.
|
|
35
|
+
- **Measurability:** every tactic has a KPI, every objective a success signal, every plan explicit kill/scale criteria and a review cadence.
|
|
36
|
+
- **Protect the Marketing Vision:** every downstream choice must serve a stated expected benefit or success signal; unauthorized scope is a vision divergence, not initiative.
|
|
37
|
+
|
|
38
|
+
If a strategic choice looks obvious but you cannot trace it to evidence, research first.
|
|
39
|
+
|
|
40
|
+
## Rule Zero: Triage
|
|
41
|
+
|
|
42
|
+
Always classify the request before choosing the process. Declare the chosen level to the user when you start operational work.
|
|
43
|
+
|
|
44
|
+
| Level | Criteria | Required process |
|
|
45
|
+
|---|---|---|
|
|
46
|
+
| **E1 - Quick** | Single question or asset feedback: a positioning opinion, copy critique, one channel question | Answer directly. Numbers still need a source or an explicit "assumption" label. No new documents. |
|
|
47
|
+
| **E2 - Campaign** | One campaign or one channel plan, bounded budget, existing strategy context | Mini-brief in the message (objective, audience, budget, KPI), targeted research, `mkt_docs/tactics/CAMPAIGN_[name].md`. Evidence ledger discipline applies. |
|
|
48
|
+
| **E3 - Full Plan** | Complete marketing plan, go-to-market for a launch, entering a new market, or no prior strategy exists | Full workflow: all nine phases, all gates, full deliverable pack. |
|
|
49
|
+
| **Research Spike** | Time-boxed market question that reduces uncertainty ("is there demand for X in market Y?") | Outcome in `mkt_docs/spikes/RESEARCH_[topic].md`. Ledger discipline applies. For strategy decisions, feed into E2/E3. |
|
|
50
|
+
|
|
51
|
+
Cross-cutting rules:
|
|
52
|
+
- Anything touching pricing strategy, brand repositioning, or a new market entry is never E1: those decisions cascade.
|
|
53
|
+
- If a bigger scope emerges during E1/E2 work (e.g. the campaign reveals there is no positioning), stop, reclassify and declare it.
|
|
54
|
+
- When in doubt, pick the higher level.
|
|
55
|
+
- An E2 whose strategy context does not exist (no approved MKT-VISION or STRATEGY) escalates to E3: tactics without strategy is the failure mode this skill exists to prevent.
|
|
56
|
+
|
|
57
|
+
## Operating Modes
|
|
58
|
+
|
|
59
|
+
### Full Standalone
|
|
60
|
+
|
|
61
|
+
Use this mode when devPNT is unavailable, not configured for the current project, or the user explicitly asks for a filesystem-only workflow.
|
|
62
|
+
|
|
63
|
+
Source of truth:
|
|
64
|
+
- Vision: `mkt_docs/vision/MKT_VISION.md`, `principles.md`.
|
|
65
|
+
- Evidence: `mkt_docs/research/evidence_ledger.md` + research documents in `mkt_docs/research/`.
|
|
66
|
+
- Strategy artifacts: `mkt_docs/strategy/` (ICP_PERSONAS, THREAT_MAP, OBJECTIVES, STRATEGY).
|
|
67
|
+
- Tactical artifacts: `mkt_docs/tactics/` (TACTICAL_PLAN, ACTION_90D, MEASUREMENT_PLAN).
|
|
68
|
+
- Deliverables: `mkt_docs/deliverables/` (MARKETING_PLAN, ONE_PAGER, exports).
|
|
69
|
+
- Spikes and handoff: `mkt_docs/spikes/`, `mkt_docs/audit/handoff.md`.
|
|
70
|
+
|
|
71
|
+
Standalone mode is not reduced: it must handle full plans, campaigns, research spikes, reviews and closure without devPNT.
|
|
72
|
+
|
|
73
|
+
### Hybrid in symbiosis with devPNT
|
|
74
|
+
|
|
75
|
+
Use this mode when the `devpnt_*` tools are available and point at the current project.
|
|
76
|
+
|
|
77
|
+
Authoritative hierarchy:
|
|
78
|
+
1. **devPNT M-VISION**: strategic beacon of the plan cycle. Before strategy or tactics, read it and verify benefits, success signals, scope-in and non-goals.
|
|
79
|
+
2. **devPNT Master Plan**: the marketing roadmap; milestones are plan cycles (a quarter, a launch, a market entry).
|
|
80
|
+
3. **devPNT Action Plan**: the nine phases of the active engagement as tactical nodes.
|
|
81
|
+
4. **devPNT governed artifacts**: the marketing artifact set (table below).
|
|
82
|
+
5. **Local `mkt_docs/`**: readable context, Standalone fallback, evidence ledger home, shadow/mirror when useful.
|
|
83
|
+
|
|
84
|
+
### Ownership matrix (the Hybrid seam)
|
|
85
|
+
|
|
86
|
+
The skill owns the **process** (triage, phases, gates, lifecycle); devPNT owns the **machinery** (governed storage, versioned proposals, review wiring). The marketing artifacts occupy the same governance slots the software artifacts occupy in the sibling skill:
|
|
87
|
+
|
|
88
|
+
| Artifact | Standalone master | Hybrid master (devPNT slot) | Mirror rule |
|
|
89
|
+
|---|---|---|---|
|
|
90
|
+
| Marketing vision | `vision/MKT_VISION.md` | M-VISION (`milestone_vision_<slug>`) | filesystem copy is a shadow; DB wins |
|
|
91
|
+
| ICP & Personas | `strategy/ICP_PERSONAS.md` | `mkt_icp_personas` (D-UC slot) | shadow `SHADOW_[doc_key]_vX.Y.md` |
|
|
92
|
+
| Threat map | `strategy/THREAT_MAP.md` | `mkt_threat_map` (P-TM slot) | shadow |
|
|
93
|
+
| Objectives | `strategy/OBJECTIVES.md` | `mkt_objectives` | shadow |
|
|
94
|
+
| Strategy | `strategy/STRATEGY.md` | `mkt_strategy` (E-ISP slot) | shadow, exported BEFORE tactics work |
|
|
95
|
+
| Tactical plan | `tactics/TACTICAL_PLAN.md` | `mkt_tactical_plan` (E-TDD slot) | shadow, exported BEFORE action phase |
|
|
96
|
+
| Measurement plan | `tactics/MEASUREMENT_PLAN.md` | `mkt_measurement_plan` (E-TP slot) | shadow |
|
|
97
|
+
| Evidence ledger | `research/evidence_ledger.md` | `research/evidence_ledger.md` — **filesystem-first even in Hybrid** | validator needs it on disk; devPNT may reference, never copies |
|
|
98
|
+
| Final plan + one-pager | `deliverables/` | assembled from ACCEPTED artifact versions | PDF via `devpnt_generate_document_pdf` when available |
|
|
99
|
+
| Handoff | `audit/handoff.md` | `audit/handoff.md` | always filesystem |
|
|
100
|
+
|
|
101
|
+
Hybrid rules:
|
|
102
|
+
- devPNT is the governed source for plans and strategy artifacts; do not create a second truth in `mkt_docs/`.
|
|
103
|
+
- The skill stays autonomous: if devPNT is not there, switch to Standalone without losing capability.
|
|
104
|
+
- If the user request, the local vision and the M-VISION diverge, stop and make the conflict explicit.
|
|
105
|
+
- Never auto-accept devPNT proposals: present the preview and wait for explicit confirmation.
|
|
106
|
+
- Where the local devPNT protocol imposes stricter gates (vision creation/amendment gates, independent review gates), follow them: they are the same discipline this skill encodes.
|
|
107
|
+
|
|
108
|
+
## The Three Engineered Guarantees
|
|
109
|
+
|
|
110
|
+
Every E3 (and every E2 with numbers) is bound by these. They are the product; the phases below exist to feed them.
|
|
111
|
+
|
|
112
|
+
1. **Evidence ledger** (`research.md`): every number is classified — `FACT` (user input or primary data), `BENCHMARK` (external source, URL + date mandatory), `ASSUMPTION` (declared, range + confidence mandatory) — and referenced as `[EV-nn]` wherever used. `mkt_check.py ledger` fails on unresolved references and unsourced benchmarks.
|
|
113
|
+
2. **Mechanical validation** (`mkt_check.py`): `budget` (allocations sum to the declared total), `funnel` (spend → clicks → leads → customers chain recomputed, ±5% tolerance, compared to the objective target), `trace` (every tactic names an objective; every objective has a KPI in the measurement plan). A plan that fails validation is not presented to the user as finished.
|
|
114
|
+
3. **Adversarial CMO review** (`review.md`): before the strategy gate and before final packaging, an independent fresh-context reviewer attacks the artifact — swap test on positioning, untraced numbers, orphan tactics, missing kill criteria. Findings are answered one by one; cap 3 rounds, then surface open findings to the user.
|
|
115
|
+
|
|
116
|
+
## E3 Workflow (nine phases on the SOSTAC spine)
|
|
117
|
+
|
|
118
|
+
Deliverable language: ask for (or infer) the target market's language in Discovery; artifacts and deliverables are written in it. The skill's internal doctrine stays English.
|
|
119
|
+
|
|
120
|
+
### 1. Intake & Triage
|
|
121
|
+
- Declare the level. Read `mkt_docs/audit/handoff.md` and `mkt_docs/README.md`/`INDEX.md` if they exist; if handoff dates are inconsistent, treat it as history.
|
|
122
|
+
- Hybrid: bootstrap devPNT, restore Master/Action Plan and any existing marketing artifacts before asking the user anything they already answered.
|
|
123
|
+
|
|
124
|
+
### 2. Discovery (Situation — internal)
|
|
125
|
+
- Run elicitation **Wave 1** (`elicitation.md`): business facts only, plain language, max 4 questions per round, options where a real choice exists.
|
|
126
|
+
- Every fact captured becomes a `FACT` ledger entry. Draft `MKT_VISION.md` (Status: DRAFT) from the answers.
|
|
127
|
+
- **Vision Gate:** the user approves the MKT-VISION (expected benefit, success signals, non-goals) before research spends effort. Hybrid: this is the devPNT M-VISION creation gate — vision first, then the milestone.
|
|
128
|
+
|
|
129
|
+
### 3. Research (Situation — external)
|
|
130
|
+
- Follow `research.md`. Prefer the deep-research skill as the engine when available; fallback to the manual playbook.
|
|
131
|
+
- Mandatory sweeps: market sizing (bottom-up preferred), competitor scan, voice-of-customer mining, channel benchmarks. Every number lands in the ledger with source + date.
|
|
132
|
+
- Two independent sources for any number that will drive a budget decision.
|
|
133
|
+
|
|
134
|
+
### 4. Situation Analysis
|
|
135
|
+
- Synthesize research into `ICP_PERSONAS.md` (every persona trait traces to VoC evidence) and `THREAT_MAP.md` (competitor moves, risks, mitigations).
|
|
136
|
+
- SWOT built from ledger entries, not adjectives. PESTEL / Five Forces only when the market warrants them (`frameworks.md` says when).
|
|
137
|
+
|
|
138
|
+
### 5. Objectives — **USER GATE**
|
|
139
|
+
- Run elicitation **Wave 2** (ambition, trade-offs, risk appetite, timeline).
|
|
140
|
+
- Draft `OBJECTIVES.md`: SMART objectives (`O1`, `O2`, ...) + KPI tree. Each objective cites the ledger entries that make it plausible.
|
|
141
|
+
- The user approves objectives before strategy. Objectives the user did not set are proposals, and say so.
|
|
142
|
+
|
|
143
|
+
### 6. Strategy — **REVIEW + USER GATE**
|
|
144
|
+
- Draft `STRATEGY.md`: segmentation, targeting choice with rationale, positioning (Dunford components + statement), messaging house.
|
|
145
|
+
- **Adversarial review** (`review.md`) before the user sees it. Fix or answer every finding.
|
|
146
|
+
- The user approves the strategy. Hybrid: propose as governed doc, user accepts in devPNT.
|
|
147
|
+
|
|
148
|
+
### 7. Tactics — **VALIDATOR GATE**
|
|
149
|
+
- Run elicitation **Wave 3** (execution capacity: who writes, who runs ads, tooling, sales follow-up).
|
|
150
|
+
- Draft `TACTICAL_PLAN.md`: channel table (channel | objective served | KPI | budget | owner), budget allocation, funnel model per acquisition channel.
|
|
151
|
+
- `mkt_check.py budget && mkt_check.py funnel && mkt_check.py trace` must pass. A tactic that serves no objective is deleted or the objective set is revisited — never silently kept.
|
|
152
|
+
|
|
153
|
+
### 8. Action
|
|
154
|
+
- Draft `ACTION_90D.md`: sequenced 90-day plan (what starts when, owner, dependency), first 2 weeks day-level, rest weekly.
|
|
155
|
+
|
|
156
|
+
### 9. Control & Packaging — **FINAL REVIEW GATE**
|
|
157
|
+
- Draft `MEASUREMENT_PLAN.md`: KPI tree with targets and benchmark references, review cadence, explicit kill/scale criteria per channel.
|
|
158
|
+
- Assemble `MARKETING_PLAN.md` (the SOSTAC deliverable) and `ONE_PAGER.md` from the approved artifacts — assembly, not rewriting; on divergence the approved artifact wins.
|
|
159
|
+
- Final adversarial review on the assembled plan + `mkt_check.py check` CLEAN.
|
|
160
|
+
- Offer exports: PDF, slide deck, budget spreadsheet (use the client's document skills when available).
|
|
161
|
+
- Update `handoff.md`. Hybrid: mark plan nodes DONE only after the user accepts the final artifacts.
|
|
162
|
+
|
|
163
|
+
## E2 Workflow (campaign)
|
|
164
|
+
|
|
165
|
+
A bounded version of the same discipline: mini-brief (objective, audience, budget, KPI — from an approved strategy context) → targeted research (channel benchmarks for the chosen channel, ledger discipline) → `CAMPAIGN_[name].md` with budget + funnel tables (validator: `budget`, `funnel`) → measurement section with kill/scale criteria. No E2 without strategy context: escalate to E3 instead.
|
|
166
|
+
|
|
167
|
+
## mkt_docs documents: indexes + lifecycle
|
|
168
|
+
|
|
169
|
+
- **`mkt_docs/README.md` (curated, by hand):** reading priority, few lines.
|
|
170
|
+
- **`mkt_docs/INDEX.md` (generated, `mkt_check.py index`):** manifest of every canonical doc (`vision/`, `strategy/`, `tactics/`, `deliverables/`) with description and status. Never by hand.
|
|
171
|
+
- `research/`, `spikes/`, `audit/` are discovery-by-grep: they do not enter the manifest. Research freshness is carried by ledger dates, not by the manifest.
|
|
172
|
+
|
|
173
|
+
Every canonical document opens with frontmatter:
|
|
174
|
+
|
|
175
|
+
```markdown
|
|
176
|
+
---
|
|
177
|
+
description: One line — what it is and when to read it.
|
|
178
|
+
status: CURRENT # CURRENT | SUPERSEDED | DRAFT | DEPRECATED
|
|
179
|
+
supersedes: old_doc.md # only if it replaces another doc
|
|
180
|
+
---
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
`Status: DRAFT` informs; `Status: APPROVED` (inside MKT_VISION/OBJECTIVES/STRATEGY bodies, granted only by the user) binds. A superseded doc stays as history with `status: SUPERSEDED`. Missing `status` = warning in `validate`.
|
|
184
|
+
|
|
185
|
+
## Deliverable quality bar
|
|
186
|
+
|
|
187
|
+
The final plan must be recognizable by a marketing professional:
|
|
188
|
+
- SOSTAC section structure, executive summary first.
|
|
189
|
+
- Every number carries `[EV-nn]`; the ledger ships as an appendix.
|
|
190
|
+
- Assumptions section on page one when material assumptions exist.
|
|
191
|
+
- Positioning passes the swap test; messaging house has proof points, not slogans.
|
|
192
|
+
- Budget table, funnel model, 90-day plan and kill/scale criteria present — a plan without a control loop is a brochure.
|
|
193
|
+
|
|
194
|
+
## Mechanical Enforcement
|
|
195
|
+
|
|
196
|
+
The prompt is not enforcement. When the project needs repeatable guarantees:
|
|
197
|
+
- read `ENFORCEMENT.md`;
|
|
198
|
+
- use `scripts/mkt_check.py validate --strict` in CI;
|
|
199
|
+
- run `scripts/mkt_check.py check` before declaring any E2/E3 deliverable done.
|
|
200
|
+
|
|
201
|
+
The validator is a support, not a universal prerequisite: the skill must stay usable in environments without Python, declaring what it cannot verify automatically.
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
# Elicitation — question waves
|
|
2
|
+
|
|
3
|
+
The cardinal rule: **ask only what the user uniquely owns.** Facts about their
|
|
4
|
+
business come from them; everything derivable from research comes from
|
|
5
|
+
research. Asking the user "who are your competitors and how are you
|
|
6
|
+
positioned?" is outsourcing the skill's own job — the failure mode this file
|
|
7
|
+
exists to prevent.
|
|
8
|
+
|
|
9
|
+
Question style (all waves):
|
|
10
|
+
- Plain language, zero marketing jargon. Not "what's your ICP?" but "describe
|
|
11
|
+
your best current customer".
|
|
12
|
+
- Max 4 questions per round; multiple rounds per wave allowed but each round
|
|
13
|
+
must be worth the interruption.
|
|
14
|
+
- Offer concrete options where a real choice exists (narrows the reply,
|
|
15
|
+
speeds the round). Use the client's structured-question facility when
|
|
16
|
+
available.
|
|
17
|
+
- **Pre-authorize "I don't know" on numeric asks.** When you ask for a figure
|
|
18
|
+
the client may never have measured (conversion rate, CAC, open rate),
|
|
19
|
+
append the permission in the question itself — "...ma se non l'avete mai
|
|
20
|
+
misurato, va bene 'non lo so'." It removes the pressure to invent a number
|
|
21
|
+
and keeps the ledger honest (an unmeasured figure becomes a researched
|
|
22
|
+
BENCHMARK or a declared ASSUMPTION, never a fabricated FACT).
|
|
23
|
+
- Every answer that is a fact becomes a `FACT` entry in the evidence ledger,
|
|
24
|
+
same discipline as researched numbers.
|
|
25
|
+
- **Seeds are allowed, analysis is not:** "which competitors do you lose
|
|
26
|
+
deals to?" is a fact the user owns (their perceived competitive set) and a
|
|
27
|
+
legitimate research seed. "What are their strengths and weaknesses?" is
|
|
28
|
+
analysis — forbidden to ask, mandatory to research.
|
|
29
|
+
|
|
30
|
+
## Wave 1 — Discovery (phase 2, before any research)
|
|
31
|
+
|
|
32
|
+
Cover, across rounds:
|
|
33
|
+
1. **Offer** — what they sell, in their words; what problem it solves.
|
|
34
|
+
2. **Price & margin** — price point(s), rough margin, discount reality.
|
|
35
|
+
3. **Current traction** — customers today (how many, what kind), revenue
|
|
36
|
+
order of magnitude, where the current customers came from.
|
|
37
|
+
4. **Market & language** — geography, target market, language for the
|
|
38
|
+
deliverables.
|
|
39
|
+
5. **Budget & horizon** — marketing budget range (a range is fine), planning
|
|
40
|
+
horizon (quarter / year / launch window).
|
|
41
|
+
6. **Team & capacity** — who will execute marketing (nobody / founder /
|
|
42
|
+
person / team / agency), hours realistically available.
|
|
43
|
+
7. **Sales motion** — how a sale happens today (self-serve, demo calls,
|
|
44
|
+
proposals, retail...), typical cycle length.
|
|
45
|
+
8. **Existing assets** — website, mailing list, social accounts and their
|
|
46
|
+
real state; brand materials.
|
|
47
|
+
9. **Constraints** — legal/regulatory limits, channels they refuse, brand
|
|
48
|
+
red lines.
|
|
49
|
+
10. **Competitor seeds** — who they lose deals to / who customers compare
|
|
50
|
+
them with (seed, not analysis).
|
|
51
|
+
|
|
52
|
+
Skip path: any item already answered by an approved MKT-VISION or earlier
|
|
53
|
+
session record is not re-asked — note where the answer came from.
|
|
54
|
+
|
|
55
|
+
## Wave 2 — Ambition (phase 5 entry, after research)
|
|
56
|
+
|
|
57
|
+
Now the user chooses with research on the table. Present the relevant
|
|
58
|
+
evidence first (one short paragraph), then ask:
|
|
59
|
+
1. **Growth vs margin** — push volume or protect profitability?
|
|
60
|
+
2. **Risk appetite** — proven channels only, or reserve an experimental slice?
|
|
61
|
+
3. **Timeline pressure** — is there a hard date (launch, season, runway)?
|
|
62
|
+
4. **Non-negotiables** — anything the objectives must include or avoid?
|
|
63
|
+
|
|
64
|
+
## Wave 3 — Execution capacity (phase 7 entry)
|
|
65
|
+
|
|
66
|
+
1. **Content capacity** — who writes/records, in which language, how often
|
|
67
|
+
realistically?
|
|
68
|
+
2. **Paid capacity** — who runs ads; any platform experience in-house?
|
|
69
|
+
3. **Follow-up capacity** — if leads double, who answers them? CRM/tooling?
|
|
70
|
+
4. **Budget flexibility** — is the budget fixed or scalable if a channel
|
|
71
|
+
proves itself?
|
|
72
|
+
|
|
73
|
+
## Reflect
|
|
74
|
+
|
|
75
|
+
Fold answers into the artifacts (MKT_VISION, OBJECTIVES, TACTICAL_PLAN) and
|
|
76
|
+
the ledger — never leave them only in chat. The written document is what the
|
|
77
|
+
next session and the reviewer read.
|
|
78
|
+
|
|
79
|
+
## Anti-patterns
|
|
80
|
+
|
|
81
|
+
- **Outsourcing analysis**: asking the user for market size, competitor
|
|
82
|
+
strengths, channel choice, or positioning. That is the skill's work.
|
|
83
|
+
- **Jargon**: ICP, CAC, SOM, funnel — translate or don't ask.
|
|
84
|
+
- **Interrogation**: more than 4 questions per round, or drip-feeding across
|
|
85
|
+
many turns instead of structured rounds.
|
|
86
|
+
- **Re-asking the recorded**: anything an approved vision or ledger FACT
|
|
87
|
+
already answers.
|
|
88
|
+
- **Collecting without folding in**: answers that never reach a document or
|
|
89
|
+
the ledger are lost to the next session.
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
# Framework Selection Guide
|
|
2
|
+
|
|
3
|
+
A framework is a lens, not a form. Pick per relevance; an empty section is
|
|
4
|
+
declared ("Five Forces skipped: single-competitor niche, structure analysis
|
|
5
|
+
adds nothing"), never padded. A deliverable stuffed with every framework is a
|
|
6
|
+
student essay, not a plan.
|
|
7
|
+
|
|
8
|
+
## The spine: SOSTAC
|
|
9
|
+
|
|
10
|
+
The plan's section structure is always SOSTAC (PR Smith) — the skeleton
|
|
11
|
+
professionals recognize:
|
|
12
|
+
|
|
13
|
+
| SOSTAC | Phase(s) | Output |
|
|
14
|
+
|---|---|---|
|
|
15
|
+
| **S**ituation | 2-4 (Discovery, Research, Situation Analysis) | where we are: market, competitors, customers, own assets |
|
|
16
|
+
| **O**bjectives | 5 | where we want to be: SMART + KPI tree |
|
|
17
|
+
| **S**trategy | 6 | how we get there at altitude: STP, positioning, messaging |
|
|
18
|
+
| **T**actics | 7 | with which instruments: channels, budget, funnel |
|
|
19
|
+
| **A**ction | 8 | who does what when: 90-day plan |
|
|
20
|
+
| **C**ontrol | 9 | how we know it works: measurement, kill/scale |
|
|
21
|
+
|
|
22
|
+
## Situation-phase lenses (pick, don't stack)
|
|
23
|
+
|
|
24
|
+
| Lens | Use when | Skip when |
|
|
25
|
+
|---|---|---|
|
|
26
|
+
| **SWOT** | always — the synthesis container for research findings | never skipped, but every cell must cite `[EV-nn]` entries; adjectives without evidence are deleted |
|
|
27
|
+
| **PESTEL** | regulated markets, macro-exposed sectors (energy, health, finance), international expansion | stable domestic niche — declare the skip |
|
|
28
|
+
| **Porter Five Forces** | entering a new market or industry-structure questions (margins, supplier power) | plan for an existing position in a known market |
|
|
29
|
+
| **TAM/SAM/SOM** | always for E3 | — (method rules below) |
|
|
30
|
+
|
|
31
|
+
**Market sizing rules:** bottom-up preferred (number of reachable potential
|
|
32
|
+
customers × realistic price point, from ledger entries); top-down (industry
|
|
33
|
+
report % slicing) only as a cross-check. A TAM that exists only top-down is a
|
|
34
|
+
`WARN` in review. SOM must be defendable from channel capacity, not ambition.
|
|
35
|
+
|
|
36
|
+
## Customer lenses
|
|
37
|
+
|
|
38
|
+
- **ICP (Ideal Customer Profile):** firmographic/demographic criteria table —
|
|
39
|
+
who we sell to and, as important, who we do NOT sell to.
|
|
40
|
+
- **Personas + JTBD:** at most 2-3 personas, each built from voice-of-customer
|
|
41
|
+
evidence (mined reviews, forums, support threads — see `research.md`). Each
|
|
42
|
+
persona carries: job-to-be-done, buying trigger, top objections, watering
|
|
43
|
+
holes (where they actually are). A persona trait with no VoC evidence is an
|
|
44
|
+
ASSUMPTION and is labeled as one; an invented persona is a review finding.
|
|
45
|
+
|
|
46
|
+
## Strategy lenses
|
|
47
|
+
|
|
48
|
+
- **STP:** Segmentation (from research) → Targeting (a CHOICE, with rationale
|
|
49
|
+
and explicit rejections: "segment B rejected because...") → Positioning.
|
|
50
|
+
- **Positioning (April Dunford components):** competitive alternatives (what
|
|
51
|
+
the customer does today, including "nothing"), unique attributes, value
|
|
52
|
+
(evidence-backed), best-fit segment, market category. Then the statement:
|
|
53
|
+
|
|
54
|
+
> For [segment] who [need], [name] is the [category] that [unique value],
|
|
55
|
+
> unlike [main alternative] which [limitation].
|
|
56
|
+
|
|
57
|
+
**Swap test (mandatory):** replace [name] with the top competitor. If the
|
|
58
|
+
statement still holds, the positioning does not exclude and FAILS.
|
|
59
|
+
- **Messaging house:** roof = value proposition (one sentence), pillars = 2-4
|
|
60
|
+
messages, foundation = proof points per pillar. A pillar without proof
|
|
61
|
+
points is a slogan; the review flags it.
|
|
62
|
+
|
|
63
|
+
## Objectives
|
|
64
|
+
|
|
65
|
+
- **SMART**, each objective `O1`, `O2`, ... with owner-visible target and date.
|
|
66
|
+
- **KPI tree:** north-star metric → driver metrics → channel KPIs. Every
|
|
67
|
+
objective maps into the tree; every channel KPI rolls up. The tree lives in
|
|
68
|
+
`MEASUREMENT_PLAN.md`; `mkt_check.py trace` verifies the chain.
|
|
69
|
+
- 3-5 objectives maximum. Ten objectives = no objectives.
|
|
70
|
+
|
|
71
|
+
## Tactics lenses
|
|
72
|
+
|
|
73
|
+
- **Funnel model:** AARRR (acquisition, activation, retention, referral,
|
|
74
|
+
revenue) for product-led; classic lead funnel (traffic → lead → MQL → SQL →
|
|
75
|
+
customer) for sales-led. Pick per the sales motion captured in Discovery.
|
|
76
|
+
Funnel rows must recompute (`mkt_check.py funnel`).
|
|
77
|
+
- **Sales-led / B2B funnel (important — the funnel table is shaped for
|
|
78
|
+
immediate-purchase e-commerce).** In a long-cycle B2B motion the monthly
|
|
79
|
+
funnel output is a **qualified lead / demo**, NOT a closed customer — today's
|
|
80
|
+
lead closes in 3-5 months. So: (a) put ONLY the paid click channels in the
|
|
81
|
+
`Funnel Model` table, and read its `Customers` column as *qualified
|
|
82
|
+
demos/leads* and `CAC` as *cost per qualified demo* — state the relabel
|
|
83
|
+
explicitly; (b) the primary sales-led motions (referral, content, outbound)
|
|
84
|
+
are NOT click funnels — represent their yield in a separate **Pipeline
|
|
85
|
+
build-up table** (per-source qualified leads/month vs the objective target);
|
|
86
|
+
(c) model the multi-stage sales funnel (MQL→SQL→demo→POC→won) and the
|
|
87
|
+
closed-won LAG in that pipeline section, not in the click-funnel table.
|
|
88
|
+
Forcing closed customers into a monthly click-funnel produces absurd CAC.
|
|
89
|
+
- **Channel selection matrix:** score candidate channels on ICP presence
|
|
90
|
+
(from VoC watering holes), intent level, benchmark cost `[EV-nn]`, and
|
|
91
|
+
execution capacity (from Wave 3). Choose few: 2-3 core channels beat 8
|
|
92
|
+
half-run ones. A channel chosen against the matrix needs written rationale.
|
|
93
|
+
- **Budget heuristics:** 70/20/10 (core / adjacent / experimental) as the
|
|
94
|
+
default split; deviations argued. Industry %-of-revenue norms are
|
|
95
|
+
BENCHMARKS — they enter only with a sourced ledger entry, never from memory.
|
|
96
|
+
- **4P/7P:** use as a completeness checklist on the tactical plan (price,
|
|
97
|
+
place and product decisions the plan silently makes), not as a section.
|
|
98
|
+
|
|
99
|
+
## Control
|
|
100
|
+
|
|
101
|
+
- Review cadence: weekly channel KPIs, monthly objective review, quarterly
|
|
102
|
+
strategy review.
|
|
103
|
+
- **Kill/scale criteria per channel, set BEFORE launch:** "kill if CAC > X
|
|
104
|
+
after spend Y; scale if CAC < Z at volume W" — thresholds justified by
|
|
105
|
+
ledger benchmarks. A plan without kill criteria is a brochure (review BLOCK).
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Research Playbook + Evidence Ledger Discipline
|
|
2
|
+
|
|
3
|
+
Research turns the user's facts into a defendable picture of the outside
|
|
4
|
+
world. Its output is never prose alone: every number lands in the ledger,
|
|
5
|
+
every claim carries its reference.
|
|
6
|
+
|
|
7
|
+
## The Evidence Ledger
|
|
8
|
+
|
|
9
|
+
Single file: `mkt_docs/research/evidence_ledger.md`. One table, one row per
|
|
10
|
+
piece of evidence:
|
|
11
|
+
|
|
12
|
+
| ID | Claim | Class | Value / Range | Source | Date | Confidence |
|
|
13
|
+
|---|---|---|---|---|---|---|
|
|
14
|
+
|
|
15
|
+
- **ID**: `EV-01`, `EV-02`, ... sequential, never reused. Artifacts cite
|
|
16
|
+
numbers as `[EV-nn]`.
|
|
17
|
+
- **Class** (exactly one):
|
|
18
|
+
- `FACT` — user input or primary data (their analytics, their CRM export).
|
|
19
|
+
Source = "user, Wave 1" or the data file.
|
|
20
|
+
- `BENCHMARK` — external number. Source URL **and** publication date
|
|
21
|
+
mandatory. The Source cell must carry the actual external URL, NOT a
|
|
22
|
+
pointer to one of your own research documents that aggregates it ("see
|
|
23
|
+
VOC.md" is not a source — the validator rejects a BENCHMARK whose Source
|
|
24
|
+
has no `http`). A benchmark older than 24 months is flagged in review.
|
|
25
|
+
- `ASSUMPTION` — a number we need but could not source. Range mandatory
|
|
26
|
+
(not a point estimate), Confidence mandatory (HIGH/MED/LOW), and the
|
|
27
|
+
rationale in the Claim cell. Assumptions that drive budget decisions are
|
|
28
|
+
listed in the plan's page-one Assumptions section.
|
|
29
|
+
- **Laundering is the cardinal sin:** an ASSUMPTION never migrates to
|
|
30
|
+
BENCHMARK without a real source; a stale benchmark is not refreshed by
|
|
31
|
+
editing its date. `mkt_check.py ledger` enforces the mechanical part
|
|
32
|
+
(references resolve, benchmarks have URLs, assumptions have confidence);
|
|
33
|
+
honesty enforces the rest.
|
|
34
|
+
|
|
35
|
+
**Two-source rule:** any number that will drive a budget allocation or an
|
|
36
|
+
objective target needs two independent sources (two ledger rows or one row
|
|
37
|
+
citing both). One vendor's blog post does not size a market.
|
|
38
|
+
|
|
39
|
+
**Source hierarchy** (prefer higher): primary data > official statistics /
|
|
40
|
+
regulator data > industry analyst reports > trade press > vendor benchmarks >
|
|
41
|
+
individual blog posts (last resort, flag as weak in Confidence).
|
|
42
|
+
|
|
43
|
+
## The engine
|
|
44
|
+
|
|
45
|
+
**Preferred:** when the `deep-research` skill (or an equivalent multi-agent
|
|
46
|
+
research harness) is available, use it as the engine — one refined question
|
|
47
|
+
per sweep, findings adversarially verified, sources cited. Feed its cited
|
|
48
|
+
findings into the ledger; do not bypass the ledger because the engine already
|
|
49
|
+
cites.
|
|
50
|
+
|
|
51
|
+
**Fallback:** manual web search per the sweep playbooks below. Slower;
|
|
52
|
+
the ledger discipline is identical.
|
|
53
|
+
|
|
54
|
+
## Mandatory sweeps (E3)
|
|
55
|
+
|
|
56
|
+
### 1. Market sizing
|
|
57
|
+
- Bottom-up first: reachable potential customers (from official statistics,
|
|
58
|
+
association registries, platform audience tools) × realistic price
|
|
59
|
+
`[EV: price FACT]`. Top-down (report % slicing) only as cross-check.
|
|
60
|
+
- Output: TAM/SAM/SOM with every input as a ledger row.
|
|
61
|
+
|
|
62
|
+
### 2. Competitor scan
|
|
63
|
+
- Start from the user's seeds (Wave 1) + search-discovered players.
|
|
64
|
+
- Per competitor: positioning claim (their own words, from their site),
|
|
65
|
+
visible pricing, observed channels (where do they show up: ads
|
|
66
|
+
transparency libraries, social presence, SEO footprint), review sentiment.
|
|
67
|
+
- Output: `mkt_docs/research/COMPETITORS.md` + ledger rows for anything
|
|
68
|
+
numeric. Observed facts, not speculation about their strategy.
|
|
69
|
+
|
|
70
|
+
### 3. Voice of customer (VoC)
|
|
71
|
+
- Mine reviews (their category on G2/Capterra/Trustpilot/Amazon/app stores as
|
|
72
|
+
applicable), forums, Reddit, comment sections — where the target segment
|
|
73
|
+
already speaks.
|
|
74
|
+
- Harvest verbatim quotes with URLs: pains, desired outcomes, objections,
|
|
75
|
+
vocabulary (the actual words become messaging raw material).
|
|
76
|
+
- Output: `mkt_docs/research/VOC.md`. Persona traits in `ICP_PERSONAS.md`
|
|
77
|
+
must trace here.
|
|
78
|
+
|
|
79
|
+
### 4. Channel benchmarks
|
|
80
|
+
- For candidate channels: typical CPC/CPM, CTR, conversion rates, CAC ranges
|
|
81
|
+
for the industry — each a BENCHMARK row with URL + date.
|
|
82
|
+
- These feed the funnel model; without them the funnel is fiction.
|
|
83
|
+
|
|
84
|
+
### Optional sweeps
|
|
85
|
+
- Trends/seasonality (search-volume tools, industry calendars) when timing
|
|
86
|
+
matters; regulatory scan when PESTEL is in play.
|
|
87
|
+
|
|
88
|
+
## Research spikes
|
|
89
|
+
|
|
90
|
+
A standalone market question outside a full engagement:
|
|
91
|
+
`mkt_docs/spikes/RESEARCH_[topic].md` — question, time-box, method, answer,
|
|
92
|
+
ledger rows created, consequences. Max 1 page + ledger entries.
|
|
93
|
+
|
|
94
|
+
## Anti-patterns
|
|
95
|
+
|
|
96
|
+
- **Numbers from memory:** model knowledge is not a source. If it matters,
|
|
97
|
+
search it; if unsearchable, it is an ASSUMPTION with a range.
|
|
98
|
+
- **Single-source budget decisions** (violates the two-source rule).
|
|
99
|
+
- **Prose-only research:** findings that never become ledger rows are lost
|
|
100
|
+
and unverifiable.
|
|
101
|
+
- **Competitor mind-reading:** report what is observable; label inference as
|
|
102
|
+
inference.
|
|
103
|
+
- **Benchmark hoarding:** 50 ledger rows nobody cites. Research serves the
|
|
104
|
+
plan; unreferenced rows get pruned at closure (validator warns).
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
# CMO Review Discipline
|
|
2
|
+
|
|
3
|
+
Applies at the Strategy gate (phase 6), the final packaging gate (phase 9),
|
|
4
|
+
and any independent review slot in a connected governance layer (devPNT
|
|
5
|
+
review gates). This is the single definition of how to request, receive, and
|
|
6
|
+
perform a marketing review; other places point here instead of restating it.
|
|
7
|
+
|
|
8
|
+
The reviewer is a skeptical CMO with a fresh context: different session or
|
|
9
|
+
subagent, read-only, given the artifacts — never "review my session".
|
|
10
|
+
Fallback when no independent context is available: run the battery yourself
|
|
11
|
+
as an explicit, separate adversarial pass, and say so (independence is
|
|
12
|
+
reduced).
|
|
13
|
+
|
|
14
|
+
## Requesting
|
|
15
|
+
|
|
16
|
+
Hand the reviewer:
|
|
17
|
+
- **Scope**: which artifact, which gate, in one or two lines.
|
|
18
|
+
- **The artifact itself** — full text, not a paraphrase.
|
|
19
|
+
- **The constraints it derives from**: the approved MKT-VISION, the
|
|
20
|
+
OBJECTIVES (for strategy/tactics reviews), the ICP_PERSONAS and THREAT_MAP,
|
|
21
|
+
and the **evidence ledger** — the reviewer checks the artifact **against**
|
|
22
|
+
them, not only for internal consistency.
|
|
23
|
+
- Which finding classes to cover when the default is not obvious.
|
|
24
|
+
|
|
25
|
+
## Receiving
|
|
26
|
+
|
|
27
|
+
**Answer findings one by one — fix, or justify with evidence.** Silent drops
|
|
28
|
+
turn review into theater. Disagree explicitly with reasoning; never resolve a
|
|
29
|
+
disagreement by rewording the finding. Cap 3 rounds; then surface open
|
|
30
|
+
findings to the user rather than looping. If any edit is made after a PASS,
|
|
31
|
+
re-review: reviewed text must equal shipped text.
|
|
32
|
+
|
|
33
|
+
## Reviewing — the red-flag battery
|
|
34
|
+
|
|
35
|
+
Severity: `BLOCK` (artifact does not pass the gate) / `WARN` (ships only with
|
|
36
|
+
explicit user acknowledgment). Every finding cites its location.
|
|
37
|
+
|
|
38
|
+
| # | Check | Severity |
|
|
39
|
+
|---|---|---|
|
|
40
|
+
| R1 | **Swap test**: replace our name with the top competitor in the positioning STATEMENT ACTUALLY PUBLISHED (not a stronger paraphrase — test the exact sentence that ships); if it still holds for any competitor, positioning does not exclude | BLOCK |
|
|
41
|
+
| R2 | **Untraced number**: any figure without `[EV-nn]` | BLOCK |
|
|
42
|
+
| R3 | **Laundered assumption**: ASSUMPTION used as certainty in prose ("the market is worth X" vs "we assume X-Y") | BLOCK |
|
|
43
|
+
| R4 | **Orphan tactic**: tactic serving no objective; **orphan objective**: objective with no KPI or no serving tactic | BLOCK |
|
|
44
|
+
| R5 | **Broken funnel math**: chain does not recompute, or projected outcome does not meet the objective target and no gap is declared | BLOCK |
|
|
45
|
+
| R6 | **Missing kill/scale criteria** on any funded channel | BLOCK |
|
|
46
|
+
| R7 | **Stale benchmark**: >24 months old, not flagged | WARN |
|
|
47
|
+
| R8 | **Top-down-only TAM**: no bottom-up cross-check | WARN |
|
|
48
|
+
| R9 | **Invented persona**: persona trait with no VoC trace and no ASSUMPTION label | WARN |
|
|
49
|
+
| R10 | **Channel vs ICP mismatch**: channel scores poorly on the selection matrix with no written rationale | WARN |
|
|
50
|
+
| R11 | **Generic messaging**: pillar without proof points; value prop interchangeable with any competitor's | WARN |
|
|
51
|
+
| R11b | **Low-cost trap / price-led positioning**: the positioning leads with cheapness ("prezzo onesto", "senza pagarlo caro", price comparison as the hook) instead of leading with value and framing price as a consequence — invites the customer to leave for the next cheaper option | WARN (BLOCK if the whole prop reduces to price) |
|
|
52
|
+
| R12 | **Vision divergence**: artifact pursues a goal absent from the approved MKT-VISION, or violates a non-goal | BLOCK |
|
|
53
|
+
| R13 | **Capacity fiction**: plan requires execution capacity Wave 3 says does not exist | BLOCK |
|
|
54
|
+
| R14 | **SMART violation**: objective without number, date, or owner | WARN |
|
|
55
|
+
| R15 | **Strawman swap-test**: the swap-test verdict tests a differentiated formulation while a WEAKER, generic sentence is what actually ships as the positioning line | BLOCK |
|
|
56
|
+
|
|
57
|
+
## Conformance statement (strategy & final-plan reviews)
|
|
58
|
+
|
|
59
|
+
A PASS is **not valid on "found nothing"**. The verdict must map each
|
|
60
|
+
constraint to evidence: every approved objective → the strategy element
|
|
61
|
+
serving it → the tactics funding it → the KPI measuring it (cite sections);
|
|
62
|
+
every MKT-VISION benefit and non-goal → where the artifact honors it; every
|
|
63
|
+
material ledger ASSUMPTION → where the plan declares it. A gap in the chain
|
|
64
|
+
is a finding, not a footnote. Quick E1/E2 reviews stay findings-only.
|
|
65
|
+
|
|
66
|
+
## Anti-patterns
|
|
67
|
+
|
|
68
|
+
- **Praise padding** — a review reports problems and fixes.
|
|
69
|
+
- **Batch-dismissal** of a findings list with one blanket reply.
|
|
70
|
+
- **Severity inflation/deflation** — a style preference is not a BLOCK; a
|
|
71
|
+
broken funnel is not a nit.
|
|
72
|
+
- **Scope-creep findings** — issues outside the artifact under review are
|
|
73
|
+
filed separately, not mixed in.
|