@antoneeo/mkt-agentic-sdlc-skill 0.4.7 → 0.5.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 +54 -0
- package/gemini-extension.json +6 -6
- package/package.json +50 -50
- package/scripts/init.js +123 -6
- package/scripts/lib.js +440 -233
- package/skills/mkt-agentic-sdlc/ENFORCEMENT.md +33 -2
- package/skills/mkt-agentic-sdlc/SKILL.md +240 -240
|
@@ -41,7 +41,7 @@ Blocks Edit/Write on protected paths when no `ANALYSIS_*.md` is `IN_PROGRESS`. I
|
|
|
41
41
|
"hooks": [
|
|
42
42
|
{
|
|
43
43
|
"type": "command",
|
|
44
|
-
"command": "python \"C:\\Users\\<user>\\.claude\\skills\\agentic-sdlc\\scripts\\mkt_check.py\" gate --hook --protected \"src/auth;src/crypto\""
|
|
44
|
+
"command": "python \"C:\\Users\\<user>\\.claude\\skills\\mkt-agentic-sdlc\\scripts\\mkt_check.py\" gate --hook --protected \"src/auth;src/crypto\""
|
|
45
45
|
}
|
|
46
46
|
]
|
|
47
47
|
}
|
|
@@ -65,6 +65,37 @@ Emits the `ai_docs/` orientation — reading guide (`README.md`), manifest (`IND
|
|
|
65
65
|
|
|
66
66
|
**Wire it on every project that has `ai_docs/` and a Python interpreter.** It was opt-in until v1.16.0 and the field result was the defect this level exists to prevent: the guide router stayed unread unless the user asked for it by hand, so guides were written and never consulted. Prompt-level placement (Rule Zero declares the router verdict; Phase 1 reads the router) carries the process on its own — this hook is the backstop that survives long contexts, compaction and a session that never enters Phase 1 explicitly. Skip it only where Python is unavailable, and know what you are trading.
|
|
67
67
|
|
|
68
|
+
**`init` wires it for you (F-036).** Running `init` on a project that has a docs root
|
|
69
|
+
and a Python interpreter now installs this hook itself — it was a manual step until
|
|
70
|
+
2026-08-25, and the field result was exactly the defect this level exists to prevent: an
|
|
71
|
+
agent worked a governed project without ever meeting the router. The snippet below is
|
|
72
|
+
the fallback for the cases init declines, and the list is exhaustive: **any client
|
|
73
|
+
other than Claude Code** (Codex and Gemini keep the manual snippet — no fixture in the
|
|
74
|
+
repository pins their hook schema, and writing one in an unverified shape is how a
|
|
75
|
+
wired-but-dead hook is born), no Python, the skill not installed yet, a settings file
|
|
76
|
+
that is not valid JSON or carries a `hooks`/`SessionStart` shape the writer does not
|
|
77
|
+
recognise (it never rewrites one it cannot read), a validator path holding a character
|
|
78
|
+
that cannot be placed in a command safely, or a settings file it cannot write. `init`
|
|
79
|
+
prints which case applied, per client — a silent skip is what let "documented default
|
|
80
|
+
that nobody installs" survive in the first place.
|
|
81
|
+
|
|
82
|
+
**Which settings file, and why it is not always the shared one.** The command names a
|
|
83
|
+
validator, and where that validator lives decides where the hook may be written:
|
|
84
|
+
|
|
85
|
+
| Case | Command | File |
|
|
86
|
+
|---|---|---|
|
|
87
|
+
| The repo vendors the validator (§2) | repo-relative | `.claude/settings.json` — portable, commit it |
|
|
88
|
+
| The validator is only in your skills directory (the normal case) | absolute | `.claude/settings.local.json` — machine-specific, git-ignored; each teammate runs `init` once |
|
|
89
|
+
|
|
90
|
+
Committing an absolute `C:\Users\<you>\...` path into the shared file hands every teammate a hook naming
|
|
91
|
+
a directory they do not have. `init` picks the file for you, and adds
|
|
92
|
+
`.claude/settings.local.json` to `.gitignore` when it uses the local one.
|
|
93
|
+
|
|
94
|
+
**A hook that is wired and DEAD is the worst of the three states**: it emits nothing at
|
|
95
|
+
every session AND it looks installed. `init` checks that an existing hook's validator
|
|
96
|
+
still resolves and reports it as BROKEN with the corrected command, rather than
|
|
97
|
+
reporting "already wired". It never rewrites the entry — it may be hand-tuned.
|
|
98
|
+
|
|
68
99
|
Wire it via each client's SessionStart mechanism — the same command everywhere (add `--hybrid` on devPNT/Hybrid projects):
|
|
69
100
|
|
|
70
101
|
Claude Code — in the project's `.claude/settings.json`:
|
|
@@ -77,7 +108,7 @@ Claude Code — in the project's `.claude/settings.json`:
|
|
|
77
108
|
"hooks": [
|
|
78
109
|
{
|
|
79
110
|
"type": "command",
|
|
80
|
-
"command": "python \"C:\\Users\\<user>\\.claude\\skills\\agentic-sdlc\\scripts\\mkt_check.py\" orient"
|
|
111
|
+
"command": "python \"C:\\Users\\<user>\\.claude\\skills\\mkt-agentic-sdlc\\scripts\\mkt_check.py\" orient"
|
|
81
112
|
}
|
|
82
113
|
]
|
|
83
114
|
}
|
|
@@ -1,240 +1,240 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: mkt-agentic-sdlc
|
|
3
|
-
version: 0.
|
|
4
|
-
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.
|
|
5
|
-
author: Antonio Pinto (https://github.com/Antoneeo)
|
|
6
|
-
copyright: (c) 2026 Antonio Pinto
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Marketing Agentic SDLC
|
|
10
|
-
|
|
11
|
-
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.
|
|
12
|
-
|
|
13
|
-
Support files in the skill directory:
|
|
14
|
-
- `frameworks.md`: which professional framework to use in which phase (SOSTAC, STP, JTBD, positioning, KPI tree) — and when NOT to use one.
|
|
15
|
-
- `elicitation.md`: the question waves and the only-facts-you-own rule.
|
|
16
|
-
- `research.md`: the research playbook and the evidence ledger discipline.
|
|
17
|
-
- `templates.md`: templates for every artifact and deliverable.
|
|
18
|
-
- `review.md`: the family's shared review discipline (independence ladder, rounds, log). The marketing-specific attack surface — swap test, untraced numbers, orphan tactics, missing kill/scale — lives in `frameworks.md`'s falsification rules; the adversarial CMO review applies them through `review.md`'s procedure.
|
|
19
|
-
- `scripts/mkt_check.py` + `scripts/sdlc_core.py`: the mechanical validator (`check`, `validate`, `ledger`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`gate`/`orient`/`plan`/`migrate`). Two files: the core is the family's shared spine, the entry point is this domain's overlay. Copy both, or neither.
|
|
20
|
-
- `ENFORCEMENT.md`: optional setup for CI and hooks.
|
|
21
|
-
|
|
22
|
-
Read these files only when needed. `SKILL.md` is the operating contract; the support files are progressive resources.
|
|
23
|
-
|
|
24
|
-
## Honesty Contract
|
|
25
|
-
|
|
26
|
-
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.
|
|
27
|
-
|
|
28
|
-
## Marketing Values
|
|
29
|
-
|
|
30
|
-
- **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.
|
|
31
|
-
- **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.
|
|
32
|
-
- **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.
|
|
33
|
-
- **Internal consistency:** budget allocations sum, funnel math closes, every tactic serves an objective, every objective has a KPI. Checked mechanically, not rhetorically.
|
|
34
|
-
- **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.
|
|
35
|
-
- **Honesty about uncertainty:** assumptions are declared with ranges and confidence, never laundered into facts. A plan built on assumptions says so on page one.
|
|
36
|
-
- **Measurability:** every tactic has a KPI, every objective a success signal, every plan explicit kill/scale criteria and a review cadence.
|
|
37
|
-
- **Protect the Marketing Vision:** every downstream choice must serve a stated expected benefit or success signal; unauthorized scope is a vision divergence, not initiative.
|
|
38
|
-
|
|
39
|
-
If a strategic choice looks obvious but you cannot trace it to evidence, research first.
|
|
40
|
-
|
|
41
|
-
## Rule Zero: Triage
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
**Declare the level WITH the router verdict** (one line, for every engagement level above the trivial one): the result of the guide-router lookup, i.e. `Level: E2 · router: no match` or `Level: E3 · router: GUIDE_brand_voice.md → read`. The lookup is the consult trigger; making its result a declared output is what keeps it from being skipped — a level declared without a verdict makes "did not look" indistinguishable from "looked, nothing matched". Name the guide you matched, or `no match`.
|
|
45
|
-
|
|
46
|
-
**Domain routing (multi-lens installs only).** After the level is set, and only when a sibling lens skill of this family is installed (`agentic-sdlc`, `kb-agentic`), run the router in `routing.md`: it decides which lens's method and validation rules govern this unit of work. The trivial level never reaches it (L1 never reaches it), and a single-lens install never reads the file — detection fails open. In such a project, never refer to a document whose meaning differs by lens ("threat model", "vision", `principles.md`, `handoff.md`) by its bare name: qualify it with its domain, or name its path.
|
|
47
|
-
|
|
48
|
-
Always classify the request before choosing the process. Declare the chosen level to the user when you start operational work.
|
|
49
|
-
|
|
50
|
-
| Level | Criteria | Required process |
|
|
51
|
-
|---|---|---|
|
|
52
|
-
| **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. |
|
|
53
|
-
| **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. |
|
|
54
|
-
| **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. |
|
|
55
|
-
| **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. |
|
|
56
|
-
|
|
57
|
-
Cross-cutting rules:
|
|
58
|
-
- Every question to the user passes the legality test of the question discipline (`elicitation.md`): searched first with the search named, and the blocked decision named. The waves are where asking is planned; outside them the test gates each ask.
|
|
59
|
-
- Anything touching pricing strategy, brand repositioning, or a new market entry is never E1: those decisions cascade.
|
|
60
|
-
- If a bigger scope emerges during E1/E2 work (e.g. the campaign reveals there is no positioning), stop, reclassify and declare it.
|
|
61
|
-
- When in doubt, pick the higher level.
|
|
62
|
-
- 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.
|
|
63
|
-
|
|
64
|
-
## Write Triggers
|
|
65
|
-
|
|
66
|
-
One event, one destination: when the trigger fires and the document does not exist, create it; when it exists, update it — never duplicate it.
|
|
67
|
-
|
|
68
|
-
| Document | Write trigger | Phase |
|
|
69
|
-
|---|---|---|
|
|
70
|
-
| `audit/handoff.md` (workstream registry) | **Never by hand — generated by `mkt_check.py index` from the `HANDOFF_*.md` sources**, and `validate` errors when the two disagree. Regenerate at every closure and at session end; the `Date:` header is derived, so no writer touches it. Inventory for lookup, never a work board. | 9 / session end |
|
|
71
|
-
| `audit/HANDOFF_[engagement].md` | **One per OPEN engagement, with or without volatile state** — it is the authored home of that engagement's registry row (frontmatter `workstream`/`level`/`branch`/`status`/`since`/`next`/`details`/`updated`), so no file means no row. DELETED at closure — deleting it *is* removing the row. | 9 / session end |
|
|
72
|
-
| `audit/project_notes.md` | A note true for the whole engagement portfolio rather than one engagement. Appended verbatim to the generated registry, so regenerating cannot destroy it. | 9 / session end |
|
|
73
|
-
| `audit/handoff.md` — converting an existing project | **Lazily, at the first write — and then ALL AT ONCE.** Converting one row at a time is the state that loses the others, so `index` refuses to write while anything in the file is unaccounted for and names it. | 9 / session end |
|
|
74
|
-
| `audit/HANDOFF_[engagement].md` | Session ends with that engagement unfinished AND there is volatile resume state. Ephemeral, deleted at closure. | 8 / 9 / session end |
|
|
75
|
-
| `audit/reviews/REVIEW_LOG.md` | Every completed review — when and what to write is `review.md`; schema is `templates.md`. | 6 / 9 |
|
|
76
|
-
| `reference/GUIDE_[topic].md` | Origin+purpose test (`guides.md`), or a proactive proposal the user accepted. | 8 / 9 |
|
|
77
|
-
| `vision/` documents | Bootstrap as `Status: DRAFT`; promoted to APPROVED only by explicit user confirmation, and only after the blind check (`vision.md` §6). | 1 / 5 |
|
|
78
|
-
|
|
79
|
-
## Operating Modes
|
|
80
|
-
|
|
81
|
-
### Full Standalone
|
|
82
|
-
|
|
83
|
-
Use this mode when devPNT is unavailable, not configured for the current project, or the user explicitly asks for a filesystem-only workflow.
|
|
84
|
-
|
|
85
|
-
Source of truth:
|
|
86
|
-
- Vision: `mkt_docs/vision/MKT_VISION.md`, `principles.md`.
|
|
87
|
-
- Evidence: `mkt_docs/research/evidence_ledger.md` + research documents in `mkt_docs/research/`.
|
|
88
|
-
- Strategy artifacts: `mkt_docs/strategy/` (ICP_PERSONAS, THREAT_MAP, OBJECTIVES, STRATEGY).
|
|
89
|
-
- Tactical artifacts: `mkt_docs/tactics/` (TACTICAL_PLAN, ACTION_90D, MEASUREMENT_PLAN).
|
|
90
|
-
- Deliverables: `mkt_docs/deliverables/` (MARKETING_PLAN, ONE_PAGER, exports).
|
|
91
|
-
- Spikes and handoff: `mkt_docs/spikes/`, `mkt_docs/audit/handoff.md`.
|
|
92
|
-
|
|
93
|
-
Standalone mode is not reduced: it must handle full plans, campaigns, research spikes, reviews and closure without devPNT.
|
|
94
|
-
|
|
95
|
-
### Hybrid in symbiosis with devPNT
|
|
96
|
-
|
|
97
|
-
Use this mode when the `devpnt_*` tools are available and point at the current project.
|
|
98
|
-
|
|
99
|
-
Authoritative hierarchy:
|
|
100
|
-
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.
|
|
101
|
-
2. **devPNT Master Plan**: the marketing roadmap; milestones are plan cycles (a quarter, a launch, a market entry).
|
|
102
|
-
3. **devPNT Action Plan**: the nine phases of the active engagement as tactical nodes.
|
|
103
|
-
4. **devPNT governed artifacts**: the marketing artifact set (table below).
|
|
104
|
-
5. **Local `mkt_docs/`**: readable context, Standalone fallback, evidence ledger home, shadow/mirror when useful.
|
|
105
|
-
|
|
106
|
-
### Ownership matrix (the Hybrid seam)
|
|
107
|
-
|
|
108
|
-
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:
|
|
109
|
-
|
|
110
|
-
| Artifact | Standalone master | Hybrid master (devPNT slot) | Mirror rule |
|
|
111
|
-
|---|---|---|---|
|
|
112
|
-
| Marketing vision | `vision/MKT_VISION.md` | M-VISION (`milestone_vision_<slug>`) | filesystem copy is a shadow; DB wins |
|
|
113
|
-
| ICP & Personas | `strategy/ICP_PERSONAS.md` | `mkt_icp_personas` (D-UC slot) | shadow `SHADOW_[doc_key]_vX.Y.md` |
|
|
114
|
-
| Threat map | `strategy/THREAT_MAP.md` | `mkt_threat_map` (P-TM slot) | shadow |
|
|
115
|
-
| Objectives | `strategy/OBJECTIVES.md` | `mkt_objectives` | shadow |
|
|
116
|
-
| Strategy | `strategy/STRATEGY.md` | `mkt_strategy` (E-ISP slot) | shadow, exported BEFORE tactics work |
|
|
117
|
-
| Tactical plan | `tactics/TACTICAL_PLAN.md` | `mkt_tactical_plan` (E-TDD slot) | shadow, exported BEFORE action phase |
|
|
118
|
-
| Measurement plan | `tactics/MEASUREMENT_PLAN.md` | `mkt_measurement_plan` (E-TP slot) | shadow |
|
|
119
|
-
| 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 |
|
|
120
|
-
| Final plan + one-pager | `deliverables/` | assembled from ACCEPTED artifact versions | PDF via `devpnt_generate_document_pdf` when available |
|
|
121
|
-
| Handoff | `audit/handoff.md` | `audit/handoff.md` | always filesystem |
|
|
122
|
-
|
|
123
|
-
Hybrid rules:
|
|
124
|
-
- devPNT is the governed source for plans and strategy artifacts; do not create a second truth in `mkt_docs/`.
|
|
125
|
-
- The skill stays autonomous: if devPNT is not there, switch to Standalone without losing capability.
|
|
126
|
-
- If the user request, the local vision and the M-VISION diverge, stop and make the conflict explicit.
|
|
127
|
-
- Never auto-accept devPNT proposals: present the preview and wait for explicit confirmation.
|
|
128
|
-
- 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.
|
|
129
|
-
|
|
130
|
-
## The Three Engineered Guarantees
|
|
131
|
-
|
|
132
|
-
Every E3 (and every E2 with numbers) is bound by these. They are the product; the phases below exist to feed them.
|
|
133
|
-
|
|
134
|
-
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.
|
|
135
|
-
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.
|
|
136
|
-
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.
|
|
137
|
-
|
|
138
|
-
## E3 Workflow (nine phases on the SOSTAC spine)
|
|
139
|
-
|
|
140
|
-
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.
|
|
141
|
-
|
|
142
|
-
### 1. Intake & Triage
|
|
143
|
-
- Read the docs root's `README.md`, `INDEX.md` and `reference/INDEX.md` (the guide router; the docs root is `mkt_docs/` by default, `ai_docs/` on a migrated tree) before touching the plan. The router is a mandatory read, not an optional one: it is the only orientation step that tells you a guide — a brand guideline, a tone-of-voice SOP, an agency playbook — already governs the work you are about to do.
|
|
144
|
-
- Read `audit/handoff.md` under the docs root, the workstream registry: one row per open engagement. Volatile resume state for an unfinished one lives in `audit/HANDOFF_[engagement].md`, which is ephemeral and deleted at closure.
|
|
145
|
-
- 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.
|
|
146
|
-
- Hybrid: bootstrap devPNT, restore Master/Action Plan and any existing marketing artifacts before asking the user anything they already answered.
|
|
147
|
-
|
|
148
|
-
### 2. Discovery (Situation — internal)
|
|
149
|
-
- Run elicitation **Wave 1** (`elicitation.md`): business facts only, plain language, max 4 questions per round, options where a real choice exists.
|
|
150
|
-
- Every fact captured becomes a `FACT` ledger entry. Draft `MKT_VISION.md` (Status: DRAFT) from the answers.
|
|
151
|
-
- **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.
|
|
152
|
-
|
|
153
|
-
### 3. Research (Situation — external)
|
|
154
|
-
- Follow `research.md`. Prefer the deep-research skill as the engine when available; fallback to the manual playbook.
|
|
155
|
-
- Mandatory sweeps: market sizing (bottom-up preferred), competitor scan, voice-of-customer mining, channel benchmarks. Every number lands in the ledger with source + date.
|
|
156
|
-
- Two independent sources for any number that will drive a budget decision.
|
|
157
|
-
|
|
158
|
-
### 4. Situation Analysis
|
|
159
|
-
- Synthesize research into `ICP_PERSONAS.md` (every persona trait traces to VoC evidence) and `THREAT_MAP.md` (competitor moves, risks, mitigations).
|
|
160
|
-
- SWOT built from ledger entries, not adjectives. PESTEL / Five Forces only when the market warrants them (`frameworks.md` says when).
|
|
161
|
-
|
|
162
|
-
### 5. Objectives — **USER GATE**
|
|
163
|
-
- Run elicitation **Wave 2** (ambition, trade-offs, risk appetite, timeline).
|
|
164
|
-
- Draft `OBJECTIVES.md`: SMART objectives (`O1`, `O2`, ...) + KPI tree. Each objective cites the ledger entries that make it plausible.
|
|
165
|
-
- The user approves objectives before strategy. Objectives the user did not set are proposals, and say so.
|
|
166
|
-
|
|
167
|
-
### 6. Strategy — **REVIEW + USER GATE**
|
|
168
|
-
- **Design review gate:** the strategy is reviewed by somebody other than its author before any tactic is executed — a subagent with fresh context, or a declared self-pass when none is available. Follow `review.md`; log the outcome in `audit/reviews/REVIEW_LOG.md` under the docs root. A strategy reviewed only by the person who wrote it is not reviewed.
|
|
169
|
-
- Draft `STRATEGY.md`: segmentation, targeting choice with rationale, positioning (Dunford components + statement), messaging house.
|
|
170
|
-
- **Adversarial review** (`review.md`) before the user sees it. Fix or answer every finding.
|
|
171
|
-
- The user approves the strategy. Hybrid: propose as governed doc, user accepts in devPNT.
|
|
172
|
-
|
|
173
|
-
### 7. Tactics — **VALIDATOR GATE**
|
|
174
|
-
- Run elicitation **Wave 3** (execution capacity: who writes, who runs ads, tooling, sales follow-up).
|
|
175
|
-
- Draft `TACTICAL_PLAN.md`: channel table (channel | objective served | KPI | budget | owner), budget allocation, funnel model per acquisition channel.
|
|
176
|
-
- `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.
|
|
177
|
-
|
|
178
|
-
### 8. Action
|
|
179
|
-
- **Isolate the work (Branch/worktree hygiene).** Execution rewrites plan documents other people are reading: do it on a branch or a worktree, never directly on the shared plan.
|
|
180
|
-
- **Consult (before acting)**: **consult the guide router** for a guide covering the task and read it first (the consult trigger, `guides.md` §0). A targeted description match, not a blanket read.
|
|
181
|
-
- **Opt-in subagent execution**: for an approved plan, the work MAY be executed via subagents per `dispatch.md`; default stays same-session.
|
|
182
|
-
- Draft `ACTION_90D.md`: sequenced 90-day plan (what starts when, owner, dependency), first 2 weeks day-level, rest weekly.
|
|
183
|
-
|
|
184
|
-
### 9. Control & Packaging — **FINAL REVIEW GATE**
|
|
185
|
-
- **Propose proactively**: if the work was governed by user-provided indications and is reusable, **PROPOSE distilling a guide** (proactive trigger, `guides.md` §1) — a proposal for the user, never a silent write, never from model knowledge.
|
|
186
|
-
- Draft `MEASUREMENT_PLAN.md`: KPI tree with targets and benchmark references, review cadence, explicit kill/scale criteria per channel.
|
|
187
|
-
- Assemble `MARKETING_PLAN.md` (the SOSTAC deliverable) and `ONE_PAGER.md` from the approved artifacts — assembly, not rewriting; on divergence the approved artifact wins.
|
|
188
|
-
- Final adversarial review on the assembled plan + `mkt_check.py check` CLEAN.
|
|
189
|
-
- Offer exports: PDF, slide deck, budget spreadsheet (use the client's document skills when available).
|
|
190
|
-
- Update `handoff.md`. Hybrid: mark plan nodes DONE only after the user accepts the final artifacts.
|
|
191
|
-
|
|
192
|
-
## E2 Workflow (campaign)
|
|
193
|
-
|
|
194
|
-
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.
|
|
195
|
-
|
|
196
|
-
## mkt_docs documents: indexes + lifecycle
|
|
197
|
-
|
|
198
|
-
- **`mkt_docs/README.md` (curated, by hand):** reading priority, few lines.
|
|
199
|
-
- **`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.
|
|
200
|
-
- `research/`, `spikes/`, `audit/` are discovery-by-grep: they do not enter the manifest. Research freshness is carried by ledger dates, not by the manifest.
|
|
201
|
-
|
|
202
|
-
Every canonical document opens with frontmatter:
|
|
203
|
-
|
|
204
|
-
```markdown
|
|
205
|
-
---
|
|
206
|
-
description: One line — what it is and when to read it.
|
|
207
|
-
status: CURRENT # CURRENT | SUPERSEDED | DRAFT | DEPRECATED
|
|
208
|
-
supersedes: old_doc.md # only if it replaces another doc
|
|
209
|
-
---
|
|
210
|
-
```
|
|
211
|
-
|
|
212
|
-
`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`.
|
|
213
|
-
|
|
214
|
-
## Deliverable quality bar
|
|
215
|
-
|
|
216
|
-
The final plan must be recognizable by a marketing professional:
|
|
217
|
-
- SOSTAC section structure, executive summary first.
|
|
218
|
-
- Every number carries `[EV-nn]`; the ledger ships as an appendix.
|
|
219
|
-
- Assumptions section on page one when material assumptions exist.
|
|
220
|
-
- Positioning passes the swap test; messaging house has proof points, not slogans.
|
|
221
|
-
- Budget table, funnel model, 90-day plan and kill/scale criteria present — a plan without a control loop is a brochure.
|
|
222
|
-
|
|
223
|
-
## Reading the shared doctrine from this lens
|
|
224
|
-
|
|
225
|
-
`review.md`, `dispatch.md` and `guides.md` are the family's shared spine,
|
|
226
|
-
byte-identical in every distribution, written in the family's neutral
|
|
227
|
-
vocabulary. Reading them from this lens: where they say `sdlc_check.py`,
|
|
228
|
-
read `mkt_check.py`; where they say "Phase 3 / Phase 5 closure", read this
|
|
229
|
-
workflow's phase 6 (strategy review) and phase 9 (control & packaging);
|
|
230
|
-
where they say ANALYSIS/feature, read this lens's governed artifacts and
|
|
231
|
-
engagement. The procedures bind as written; only the names translate.
|
|
232
|
-
|
|
233
|
-
## Mechanical Enforcement
|
|
234
|
-
|
|
235
|
-
The prompt is not enforcement. When the project needs repeatable guarantees:
|
|
236
|
-
- read `ENFORCEMENT.md`;
|
|
237
|
-
- use `scripts/mkt_check.py validate --strict` in CI;
|
|
238
|
-
- run `scripts/mkt_check.py check` before declaring any E2/E3 deliverable done.
|
|
239
|
-
|
|
240
|
-
The validator is a support, not a universal prerequisite: the skill must stay usable in environments without Python, declaring what it cannot verify automatically.
|
|
1
|
+
---
|
|
2
|
+
name: mkt-agentic-sdlc
|
|
3
|
+
version: 0.5.0
|
|
4
|
+
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.
|
|
5
|
+
author: Antonio Pinto (https://github.com/Antoneeo)
|
|
6
|
+
copyright: (c) 2026 Antonio Pinto
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Marketing Agentic SDLC
|
|
10
|
+
|
|
11
|
+
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.
|
|
12
|
+
|
|
13
|
+
Support files in the skill directory:
|
|
14
|
+
- `frameworks.md`: which professional framework to use in which phase (SOSTAC, STP, JTBD, positioning, KPI tree) — and when NOT to use one.
|
|
15
|
+
- `elicitation.md`: the question waves and the only-facts-you-own rule.
|
|
16
|
+
- `research.md`: the research playbook and the evidence ledger discipline.
|
|
17
|
+
- `templates.md`: templates for every artifact and deliverable.
|
|
18
|
+
- `review.md`: the family's shared review discipline (independence ladder, rounds, log). The marketing-specific attack surface — swap test, untraced numbers, orphan tactics, missing kill/scale — lives in `frameworks.md`'s falsification rules; the adversarial CMO review applies them through `review.md`'s procedure.
|
|
19
|
+
- `scripts/mkt_check.py` + `scripts/sdlc_core.py`: the mechanical validator (`check`, `validate`, `ledger`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`gate`/`orient`/`plan`/`migrate`). Two files: the core is the family's shared spine, the entry point is this domain's overlay. Copy both, or neither.
|
|
20
|
+
- `ENFORCEMENT.md`: optional setup for CI and hooks.
|
|
21
|
+
|
|
22
|
+
Read these files only when needed. `SKILL.md` is the operating contract; the support files are progressive resources.
|
|
23
|
+
|
|
24
|
+
## Honesty Contract
|
|
25
|
+
|
|
26
|
+
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.
|
|
27
|
+
|
|
28
|
+
## Marketing Values
|
|
29
|
+
|
|
30
|
+
- **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.
|
|
31
|
+
- **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.
|
|
32
|
+
- **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.
|
|
33
|
+
- **Internal consistency:** budget allocations sum, funnel math closes, every tactic serves an objective, every objective has a KPI. Checked mechanically, not rhetorically.
|
|
34
|
+
- **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.
|
|
35
|
+
- **Honesty about uncertainty:** assumptions are declared with ranges and confidence, never laundered into facts. A plan built on assumptions says so on page one.
|
|
36
|
+
- **Measurability:** every tactic has a KPI, every objective a success signal, every plan explicit kill/scale criteria and a review cadence.
|
|
37
|
+
- **Protect the Marketing Vision:** every downstream choice must serve a stated expected benefit or success signal; unauthorized scope is a vision divergence, not initiative.
|
|
38
|
+
|
|
39
|
+
If a strategic choice looks obvious but you cannot trace it to evidence, research first.
|
|
40
|
+
|
|
41
|
+
## Rule Zero: Triage
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
**Declare the level WITH the router verdict** (one line, for every engagement level above the trivial one): the result of the guide-router lookup, i.e. `Level: E2 · router: no match` or `Level: E3 · router: GUIDE_brand_voice.md → read`. The lookup is the consult trigger; making its result a declared output is what keeps it from being skipped — a level declared without a verdict makes "did not look" indistinguishable from "looked, nothing matched". Name the guide you matched, or `no match`.
|
|
45
|
+
|
|
46
|
+
**Domain routing (multi-lens installs only).** After the level is set, and only when a sibling lens skill of this family is installed (`agentic-sdlc`, `kb-agentic`), run the router in `routing.md`: it decides which lens's method and validation rules govern this unit of work. The trivial level never reaches it (L1 never reaches it), and a single-lens install never reads the file — detection fails open. In such a project, never refer to a document whose meaning differs by lens ("threat model", "vision", `principles.md`, `handoff.md`) by its bare name: qualify it with its domain, or name its path.
|
|
47
|
+
|
|
48
|
+
Always classify the request before choosing the process. Declare the chosen level to the user when you start operational work.
|
|
49
|
+
|
|
50
|
+
| Level | Criteria | Required process |
|
|
51
|
+
|---|---|---|
|
|
52
|
+
| **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. |
|
|
53
|
+
| **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. |
|
|
54
|
+
| **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. |
|
|
55
|
+
| **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. |
|
|
56
|
+
|
|
57
|
+
Cross-cutting rules:
|
|
58
|
+
- Every question to the user passes the legality test of the question discipline (`elicitation.md`): searched first with the search named, and the blocked decision named. The waves are where asking is planned; outside them the test gates each ask.
|
|
59
|
+
- Anything touching pricing strategy, brand repositioning, or a new market entry is never E1: those decisions cascade.
|
|
60
|
+
- If a bigger scope emerges during E1/E2 work (e.g. the campaign reveals there is no positioning), stop, reclassify and declare it.
|
|
61
|
+
- When in doubt, pick the higher level.
|
|
62
|
+
- 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.
|
|
63
|
+
|
|
64
|
+
## Write Triggers
|
|
65
|
+
|
|
66
|
+
One event, one destination: when the trigger fires and the document does not exist, create it; when it exists, update it — never duplicate it.
|
|
67
|
+
|
|
68
|
+
| Document | Write trigger | Phase |
|
|
69
|
+
|---|---|---|
|
|
70
|
+
| `audit/handoff.md` (workstream registry) | **Never by hand — generated by `mkt_check.py index` from the `HANDOFF_*.md` sources**, and `validate` errors when the two disagree. Regenerate at every closure and at session end; the `Date:` header is derived, so no writer touches it. Inventory for lookup, never a work board. | 9 / session end |
|
|
71
|
+
| `audit/HANDOFF_[engagement].md` | **One per OPEN engagement, with or without volatile state** — it is the authored home of that engagement's registry row (frontmatter `workstream`/`level`/`branch`/`status`/`since`/`next`/`details`/`updated`), so no file means no row. DELETED at closure — deleting it *is* removing the row. | 9 / session end |
|
|
72
|
+
| `audit/project_notes.md` | A note true for the whole engagement portfolio rather than one engagement. Appended verbatim to the generated registry, so regenerating cannot destroy it. | 9 / session end |
|
|
73
|
+
| `audit/handoff.md` — converting an existing project | **Lazily, at the first write — and then ALL AT ONCE.** Converting one row at a time is the state that loses the others, so `index` refuses to write while anything in the file is unaccounted for and names it. | 9 / session end |
|
|
74
|
+
| `audit/HANDOFF_[engagement].md` | Session ends with that engagement unfinished AND there is volatile resume state. Ephemeral, deleted at closure. | 8 / 9 / session end |
|
|
75
|
+
| `audit/reviews/REVIEW_LOG.md` | Every completed review — when and what to write is `review.md`; schema is `templates.md`. | 6 / 9 |
|
|
76
|
+
| `reference/GUIDE_[topic].md` | Origin+purpose test (`guides.md`), or a proactive proposal the user accepted. | 8 / 9 |
|
|
77
|
+
| `vision/` documents | Bootstrap as `Status: DRAFT`; promoted to APPROVED only by explicit user confirmation, and only after the blind check (`vision.md` §6). | 1 / 5 |
|
|
78
|
+
|
|
79
|
+
## Operating Modes
|
|
80
|
+
|
|
81
|
+
### Full Standalone
|
|
82
|
+
|
|
83
|
+
Use this mode when devPNT is unavailable, not configured for the current project, or the user explicitly asks for a filesystem-only workflow.
|
|
84
|
+
|
|
85
|
+
Source of truth:
|
|
86
|
+
- Vision: `mkt_docs/vision/MKT_VISION.md`, `principles.md`.
|
|
87
|
+
- Evidence: `mkt_docs/research/evidence_ledger.md` + research documents in `mkt_docs/research/`.
|
|
88
|
+
- Strategy artifacts: `mkt_docs/strategy/` (ICP_PERSONAS, THREAT_MAP, OBJECTIVES, STRATEGY).
|
|
89
|
+
- Tactical artifacts: `mkt_docs/tactics/` (TACTICAL_PLAN, ACTION_90D, MEASUREMENT_PLAN).
|
|
90
|
+
- Deliverables: `mkt_docs/deliverables/` (MARKETING_PLAN, ONE_PAGER, exports).
|
|
91
|
+
- Spikes and handoff: `mkt_docs/spikes/`, `mkt_docs/audit/handoff.md`.
|
|
92
|
+
|
|
93
|
+
Standalone mode is not reduced: it must handle full plans, campaigns, research spikes, reviews and closure without devPNT.
|
|
94
|
+
|
|
95
|
+
### Hybrid in symbiosis with devPNT
|
|
96
|
+
|
|
97
|
+
Use this mode when the `devpnt_*` tools are available and point at the current project.
|
|
98
|
+
|
|
99
|
+
Authoritative hierarchy:
|
|
100
|
+
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.
|
|
101
|
+
2. **devPNT Master Plan**: the marketing roadmap; milestones are plan cycles (a quarter, a launch, a market entry).
|
|
102
|
+
3. **devPNT Action Plan**: the nine phases of the active engagement as tactical nodes.
|
|
103
|
+
4. **devPNT governed artifacts**: the marketing artifact set (table below).
|
|
104
|
+
5. **Local `mkt_docs/`**: readable context, Standalone fallback, evidence ledger home, shadow/mirror when useful.
|
|
105
|
+
|
|
106
|
+
### Ownership matrix (the Hybrid seam)
|
|
107
|
+
|
|
108
|
+
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:
|
|
109
|
+
|
|
110
|
+
| Artifact | Standalone master | Hybrid master (devPNT slot) | Mirror rule |
|
|
111
|
+
|---|---|---|---|
|
|
112
|
+
| Marketing vision | `vision/MKT_VISION.md` | M-VISION (`milestone_vision_<slug>`) | filesystem copy is a shadow; DB wins |
|
|
113
|
+
| ICP & Personas | `strategy/ICP_PERSONAS.md` | `mkt_icp_personas` (D-UC slot) | shadow `SHADOW_[doc_key]_vX.Y.md` |
|
|
114
|
+
| Threat map | `strategy/THREAT_MAP.md` | `mkt_threat_map` (P-TM slot) | shadow |
|
|
115
|
+
| Objectives | `strategy/OBJECTIVES.md` | `mkt_objectives` | shadow |
|
|
116
|
+
| Strategy | `strategy/STRATEGY.md` | `mkt_strategy` (E-ISP slot) | shadow, exported BEFORE tactics work |
|
|
117
|
+
| Tactical plan | `tactics/TACTICAL_PLAN.md` | `mkt_tactical_plan` (E-TDD slot) | shadow, exported BEFORE action phase |
|
|
118
|
+
| Measurement plan | `tactics/MEASUREMENT_PLAN.md` | `mkt_measurement_plan` (E-TP slot) | shadow |
|
|
119
|
+
| 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 |
|
|
120
|
+
| Final plan + one-pager | `deliverables/` | assembled from ACCEPTED artifact versions | PDF via `devpnt_generate_document_pdf` when available |
|
|
121
|
+
| Handoff | `audit/handoff.md` | `audit/handoff.md` | always filesystem |
|
|
122
|
+
|
|
123
|
+
Hybrid rules:
|
|
124
|
+
- devPNT is the governed source for plans and strategy artifacts; do not create a second truth in `mkt_docs/`.
|
|
125
|
+
- The skill stays autonomous: if devPNT is not there, switch to Standalone without losing capability.
|
|
126
|
+
- If the user request, the local vision and the M-VISION diverge, stop and make the conflict explicit.
|
|
127
|
+
- Never auto-accept devPNT proposals: present the preview and wait for explicit confirmation.
|
|
128
|
+
- 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.
|
|
129
|
+
|
|
130
|
+
## The Three Engineered Guarantees
|
|
131
|
+
|
|
132
|
+
Every E3 (and every E2 with numbers) is bound by these. They are the product; the phases below exist to feed them.
|
|
133
|
+
|
|
134
|
+
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.
|
|
135
|
+
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.
|
|
136
|
+
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.
|
|
137
|
+
|
|
138
|
+
## E3 Workflow (nine phases on the SOSTAC spine)
|
|
139
|
+
|
|
140
|
+
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.
|
|
141
|
+
|
|
142
|
+
### 1. Intake & Triage
|
|
143
|
+
- Read the docs root's `README.md`, `INDEX.md` and `reference/INDEX.md` (the guide router; the docs root is `mkt_docs/` by default, `ai_docs/` on a migrated tree) before touching the plan. The router is a mandatory read, not an optional one: it is the only orientation step that tells you a guide — a brand guideline, a tone-of-voice SOP, an agency playbook — already governs the work you are about to do.
|
|
144
|
+
- Read `audit/handoff.md` under the docs root, the workstream registry: one row per open engagement. Volatile resume state for an unfinished one lives in `audit/HANDOFF_[engagement].md`, which is ephemeral and deleted at closure.
|
|
145
|
+
- 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.
|
|
146
|
+
- Hybrid: bootstrap devPNT, restore Master/Action Plan and any existing marketing artifacts before asking the user anything they already answered.
|
|
147
|
+
|
|
148
|
+
### 2. Discovery (Situation — internal)
|
|
149
|
+
- Run elicitation **Wave 1** (`elicitation.md`): business facts only, plain language, max 4 questions per round, options where a real choice exists.
|
|
150
|
+
- Every fact captured becomes a `FACT` ledger entry. Draft `MKT_VISION.md` (Status: DRAFT) from the answers.
|
|
151
|
+
- **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.
|
|
152
|
+
|
|
153
|
+
### 3. Research (Situation — external)
|
|
154
|
+
- Follow `research.md`. Prefer the deep-research skill as the engine when available; fallback to the manual playbook.
|
|
155
|
+
- Mandatory sweeps: market sizing (bottom-up preferred), competitor scan, voice-of-customer mining, channel benchmarks. Every number lands in the ledger with source + date.
|
|
156
|
+
- Two independent sources for any number that will drive a budget decision.
|
|
157
|
+
|
|
158
|
+
### 4. Situation Analysis
|
|
159
|
+
- Synthesize research into `ICP_PERSONAS.md` (every persona trait traces to VoC evidence) and `THREAT_MAP.md` (competitor moves, risks, mitigations).
|
|
160
|
+
- SWOT built from ledger entries, not adjectives. PESTEL / Five Forces only when the market warrants them (`frameworks.md` says when).
|
|
161
|
+
|
|
162
|
+
### 5. Objectives — **USER GATE**
|
|
163
|
+
- Run elicitation **Wave 2** (ambition, trade-offs, risk appetite, timeline).
|
|
164
|
+
- Draft `OBJECTIVES.md`: SMART objectives (`O1`, `O2`, ...) + KPI tree. Each objective cites the ledger entries that make it plausible.
|
|
165
|
+
- The user approves objectives before strategy. Objectives the user did not set are proposals, and say so.
|
|
166
|
+
|
|
167
|
+
### 6. Strategy — **REVIEW + USER GATE**
|
|
168
|
+
- **Design review gate:** the strategy is reviewed by somebody other than its author before any tactic is executed — a subagent with fresh context, or a declared self-pass when none is available. Follow `review.md`; log the outcome in `audit/reviews/REVIEW_LOG.md` under the docs root. A strategy reviewed only by the person who wrote it is not reviewed.
|
|
169
|
+
- Draft `STRATEGY.md`: segmentation, targeting choice with rationale, positioning (Dunford components + statement), messaging house.
|
|
170
|
+
- **Adversarial review** (`review.md`) before the user sees it. Fix or answer every finding.
|
|
171
|
+
- The user approves the strategy. Hybrid: propose as governed doc, user accepts in devPNT.
|
|
172
|
+
|
|
173
|
+
### 7. Tactics — **VALIDATOR GATE**
|
|
174
|
+
- Run elicitation **Wave 3** (execution capacity: who writes, who runs ads, tooling, sales follow-up).
|
|
175
|
+
- Draft `TACTICAL_PLAN.md`: channel table (channel | objective served | KPI | budget | owner), budget allocation, funnel model per acquisition channel.
|
|
176
|
+
- `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.
|
|
177
|
+
|
|
178
|
+
### 8. Action
|
|
179
|
+
- **Isolate the work (Branch/worktree hygiene).** Execution rewrites plan documents other people are reading: do it on a branch or a worktree, never directly on the shared plan.
|
|
180
|
+
- **Consult (before acting)**: **consult the guide router** for a guide covering the task and read it first (the consult trigger, `guides.md` §0). A targeted description match, not a blanket read.
|
|
181
|
+
- **Opt-in subagent execution**: for an approved plan, the work MAY be executed via subagents per `dispatch.md`; default stays same-session.
|
|
182
|
+
- Draft `ACTION_90D.md`: sequenced 90-day plan (what starts when, owner, dependency), first 2 weeks day-level, rest weekly.
|
|
183
|
+
|
|
184
|
+
### 9. Control & Packaging — **FINAL REVIEW GATE**
|
|
185
|
+
- **Propose proactively**: if the work was governed by user-provided indications and is reusable, **PROPOSE distilling a guide** (proactive trigger, `guides.md` §1) — a proposal for the user, never a silent write, never from model knowledge.
|
|
186
|
+
- Draft `MEASUREMENT_PLAN.md`: KPI tree with targets and benchmark references, review cadence, explicit kill/scale criteria per channel.
|
|
187
|
+
- Assemble `MARKETING_PLAN.md` (the SOSTAC deliverable) and `ONE_PAGER.md` from the approved artifacts — assembly, not rewriting; on divergence the approved artifact wins.
|
|
188
|
+
- Final adversarial review on the assembled plan + `mkt_check.py check` CLEAN.
|
|
189
|
+
- Offer exports: PDF, slide deck, budget spreadsheet (use the client's document skills when available).
|
|
190
|
+
- Update `handoff.md`. Hybrid: mark plan nodes DONE only after the user accepts the final artifacts.
|
|
191
|
+
|
|
192
|
+
## E2 Workflow (campaign)
|
|
193
|
+
|
|
194
|
+
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.
|
|
195
|
+
|
|
196
|
+
## mkt_docs documents: indexes + lifecycle
|
|
197
|
+
|
|
198
|
+
- **`mkt_docs/README.md` (curated, by hand):** reading priority, few lines.
|
|
199
|
+
- **`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.
|
|
200
|
+
- `research/`, `spikes/`, `audit/` are discovery-by-grep: they do not enter the manifest. Research freshness is carried by ledger dates, not by the manifest.
|
|
201
|
+
|
|
202
|
+
Every canonical document opens with frontmatter:
|
|
203
|
+
|
|
204
|
+
```markdown
|
|
205
|
+
---
|
|
206
|
+
description: One line — what it is and when to read it.
|
|
207
|
+
status: CURRENT # CURRENT | SUPERSEDED | DRAFT | DEPRECATED
|
|
208
|
+
supersedes: old_doc.md # only if it replaces another doc
|
|
209
|
+
---
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
`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`.
|
|
213
|
+
|
|
214
|
+
## Deliverable quality bar
|
|
215
|
+
|
|
216
|
+
The final plan must be recognizable by a marketing professional:
|
|
217
|
+
- SOSTAC section structure, executive summary first.
|
|
218
|
+
- Every number carries `[EV-nn]`; the ledger ships as an appendix.
|
|
219
|
+
- Assumptions section on page one when material assumptions exist.
|
|
220
|
+
- Positioning passes the swap test; messaging house has proof points, not slogans.
|
|
221
|
+
- Budget table, funnel model, 90-day plan and kill/scale criteria present — a plan without a control loop is a brochure.
|
|
222
|
+
|
|
223
|
+
## Reading the shared doctrine from this lens
|
|
224
|
+
|
|
225
|
+
`review.md`, `dispatch.md` and `guides.md` are the family's shared spine,
|
|
226
|
+
byte-identical in every distribution, written in the family's neutral
|
|
227
|
+
vocabulary. Reading them from this lens: where they say `sdlc_check.py`,
|
|
228
|
+
read `mkt_check.py`; where they say "Phase 3 / Phase 5 closure", read this
|
|
229
|
+
workflow's phase 6 (strategy review) and phase 9 (control & packaging);
|
|
230
|
+
where they say ANALYSIS/feature, read this lens's governed artifacts and
|
|
231
|
+
engagement. The procedures bind as written; only the names translate.
|
|
232
|
+
|
|
233
|
+
## Mechanical Enforcement
|
|
234
|
+
|
|
235
|
+
The prompt is not enforcement. When the project needs repeatable guarantees:
|
|
236
|
+
- read `ENFORCEMENT.md`;
|
|
237
|
+
- use `scripts/mkt_check.py validate --strict` in CI;
|
|
238
|
+
- run `scripts/mkt_check.py check` before declaring any E2/E3 deliverable done.
|
|
239
|
+
|
|
240
|
+
The validator is a support, not a universal prerequisite: the skill must stay usable in environments without Python, declaring what it cannot verify automatically.
|