@antoneeo/mkt-agentic-sdlc-skill 0.2.1 → 0.3.1

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.
@@ -1,201 +1,236 @@
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.
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 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.
18
+ - `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.
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
+
43
+ **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`.
44
+
45
+ **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.
46
+
47
+ Always classify the request before choosing the process. Declare the chosen level to the user when you start operational work.
48
+
49
+ | Level | Criteria | Required process |
50
+ |---|---|---|
51
+ | **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. |
52
+ | **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. |
53
+ | **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. |
54
+ | **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. |
55
+
56
+ Cross-cutting rules:
57
+ - 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.
58
+ - Anything touching pricing strategy, brand repositioning, or a new market entry is never E1: those decisions cascade.
59
+ - If a bigger scope emerges during E1/E2 work (e.g. the campaign reveals there is no positioning), stop, reclassify and declare it.
60
+ - When in doubt, pick the higher level.
61
+ - 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.
62
+
63
+ ## Write Triggers
64
+
65
+ One event, one destination: when the trigger fires and the document does not exist, create it; when it exists, update it — never duplicate it.
66
+
67
+ | Document | Write trigger | Phase |
68
+ |---|---|---|
69
+ | `audit/handoff.md` (workstream registry) | One row per OPEN engagement — refresh at every closure and at session end. ≤ 20 lines. | 9 / session end |
70
+ | `audit/HANDOFF_[engagement].md` | Session ends with that engagement unfinished AND there is volatile resume state. Ephemeral, deleted at closure. | 8 / 9 / session end |
71
+ | `audit/reviews/REVIEW_LOG.md` | Every completed review — when and what to write is `review.md`; schema is `templates.md`. | 6 / 9 |
72
+ | `reference/GUIDE_[topic].md` | Origin+purpose test (`guides.md`), or a proactive proposal the user accepted. | 8 / 9 |
73
+ | `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 |
74
+
75
+ ## Operating Modes
76
+
77
+ ### Full Standalone
78
+
79
+ Use this mode when devPNT is unavailable, not configured for the current project, or the user explicitly asks for a filesystem-only workflow.
80
+
81
+ Source of truth:
82
+ - Vision: `mkt_docs/vision/MKT_VISION.md`, `principles.md`.
83
+ - Evidence: `mkt_docs/research/evidence_ledger.md` + research documents in `mkt_docs/research/`.
84
+ - Strategy artifacts: `mkt_docs/strategy/` (ICP_PERSONAS, THREAT_MAP, OBJECTIVES, STRATEGY).
85
+ - Tactical artifacts: `mkt_docs/tactics/` (TACTICAL_PLAN, ACTION_90D, MEASUREMENT_PLAN).
86
+ - Deliverables: `mkt_docs/deliverables/` (MARKETING_PLAN, ONE_PAGER, exports).
87
+ - Spikes and handoff: `mkt_docs/spikes/`, `mkt_docs/audit/handoff.md`.
88
+
89
+ Standalone mode is not reduced: it must handle full plans, campaigns, research spikes, reviews and closure without devPNT.
90
+
91
+ ### Hybrid in symbiosis with devPNT
92
+
93
+ Use this mode when the `devpnt_*` tools are available and point at the current project.
94
+
95
+ Authoritative hierarchy:
96
+ 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.
97
+ 2. **devPNT Master Plan**: the marketing roadmap; milestones are plan cycles (a quarter, a launch, a market entry).
98
+ 3. **devPNT Action Plan**: the nine phases of the active engagement as tactical nodes.
99
+ 4. **devPNT governed artifacts**: the marketing artifact set (table below).
100
+ 5. **Local `mkt_docs/`**: readable context, Standalone fallback, evidence ledger home, shadow/mirror when useful.
101
+
102
+ ### Ownership matrix (the Hybrid seam)
103
+
104
+ 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:
105
+
106
+ | Artifact | Standalone master | Hybrid master (devPNT slot) | Mirror rule |
107
+ |---|---|---|---|
108
+ | Marketing vision | `vision/MKT_VISION.md` | M-VISION (`milestone_vision_<slug>`) | filesystem copy is a shadow; DB wins |
109
+ | ICP & Personas | `strategy/ICP_PERSONAS.md` | `mkt_icp_personas` (D-UC slot) | shadow `SHADOW_[doc_key]_vX.Y.md` |
110
+ | Threat map | `strategy/THREAT_MAP.md` | `mkt_threat_map` (P-TM slot) | shadow |
111
+ | Objectives | `strategy/OBJECTIVES.md` | `mkt_objectives` | shadow |
112
+ | Strategy | `strategy/STRATEGY.md` | `mkt_strategy` (E-ISP slot) | shadow, exported BEFORE tactics work |
113
+ | Tactical plan | `tactics/TACTICAL_PLAN.md` | `mkt_tactical_plan` (E-TDD slot) | shadow, exported BEFORE action phase |
114
+ | Measurement plan | `tactics/MEASUREMENT_PLAN.md` | `mkt_measurement_plan` (E-TP slot) | shadow |
115
+ | 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 |
116
+ | Final plan + one-pager | `deliverables/` | assembled from ACCEPTED artifact versions | PDF via `devpnt_generate_document_pdf` when available |
117
+ | Handoff | `audit/handoff.md` | `audit/handoff.md` | always filesystem |
118
+
119
+ Hybrid rules:
120
+ - devPNT is the governed source for plans and strategy artifacts; do not create a second truth in `mkt_docs/`.
121
+ - The skill stays autonomous: if devPNT is not there, switch to Standalone without losing capability.
122
+ - If the user request, the local vision and the M-VISION diverge, stop and make the conflict explicit.
123
+ - Never auto-accept devPNT proposals: present the preview and wait for explicit confirmation.
124
+ - 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.
125
+
126
+ ## The Three Engineered Guarantees
127
+
128
+ Every E3 (and every E2 with numbers) is bound by these. They are the product; the phases below exist to feed them.
129
+
130
+ 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.
131
+ 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.
132
+ 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.
133
+
134
+ ## E3 Workflow (nine phases on the SOSTAC spine)
135
+
136
+ 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.
137
+
138
+ ### 1. Intake & Triage
139
+ - 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.
140
+ - 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.
141
+ - 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.
142
+ - Hybrid: bootstrap devPNT, restore Master/Action Plan and any existing marketing artifacts before asking the user anything they already answered.
143
+
144
+ ### 2. Discovery (Situation — internal)
145
+ - Run elicitation **Wave 1** (`elicitation.md`): business facts only, plain language, max 4 questions per round, options where a real choice exists.
146
+ - Every fact captured becomes a `FACT` ledger entry. Draft `MKT_VISION.md` (Status: DRAFT) from the answers.
147
+ - **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.
148
+
149
+ ### 3. Research (Situation — external)
150
+ - Follow `research.md`. Prefer the deep-research skill as the engine when available; fallback to the manual playbook.
151
+ - Mandatory sweeps: market sizing (bottom-up preferred), competitor scan, voice-of-customer mining, channel benchmarks. Every number lands in the ledger with source + date.
152
+ - Two independent sources for any number that will drive a budget decision.
153
+
154
+ ### 4. Situation Analysis
155
+ - Synthesize research into `ICP_PERSONAS.md` (every persona trait traces to VoC evidence) and `THREAT_MAP.md` (competitor moves, risks, mitigations).
156
+ - SWOT built from ledger entries, not adjectives. PESTEL / Five Forces only when the market warrants them (`frameworks.md` says when).
157
+
158
+ ### 5. Objectives — **USER GATE**
159
+ - Run elicitation **Wave 2** (ambition, trade-offs, risk appetite, timeline).
160
+ - Draft `OBJECTIVES.md`: SMART objectives (`O1`, `O2`, ...) + KPI tree. Each objective cites the ledger entries that make it plausible.
161
+ - The user approves objectives before strategy. Objectives the user did not set are proposals, and say so.
162
+
163
+ ### 6. Strategy — **REVIEW + USER GATE**
164
+ - **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.
165
+ - Draft `STRATEGY.md`: segmentation, targeting choice with rationale, positioning (Dunford components + statement), messaging house.
166
+ - **Adversarial review** (`review.md`) before the user sees it. Fix or answer every finding.
167
+ - The user approves the strategy. Hybrid: propose as governed doc, user accepts in devPNT.
168
+
169
+ ### 7. Tactics — **VALIDATOR GATE**
170
+ - Run elicitation **Wave 3** (execution capacity: who writes, who runs ads, tooling, sales follow-up).
171
+ - Draft `TACTICAL_PLAN.md`: channel table (channel | objective served | KPI | budget | owner), budget allocation, funnel model per acquisition channel.
172
+ - `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.
173
+
174
+ ### 8. Action
175
+ - **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.
176
+ - **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.
177
+ - **Opt-in subagent execution**: for an approved plan, the work MAY be executed via subagents per `dispatch.md`; default stays same-session.
178
+ - Draft `ACTION_90D.md`: sequenced 90-day plan (what starts when, owner, dependency), first 2 weeks day-level, rest weekly.
179
+
180
+ ### 9. Control & Packaging — **FINAL REVIEW GATE**
181
+ - **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.
182
+ - Draft `MEASUREMENT_PLAN.md`: KPI tree with targets and benchmark references, review cadence, explicit kill/scale criteria per channel.
183
+ - Assemble `MARKETING_PLAN.md` (the SOSTAC deliverable) and `ONE_PAGER.md` from the approved artifacts — assembly, not rewriting; on divergence the approved artifact wins.
184
+ - Final adversarial review on the assembled plan + `mkt_check.py check` CLEAN.
185
+ - Offer exports: PDF, slide deck, budget spreadsheet (use the client's document skills when available).
186
+ - Update `handoff.md`. Hybrid: mark plan nodes DONE only after the user accepts the final artifacts.
187
+
188
+ ## E2 Workflow (campaign)
189
+
190
+ 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.
191
+
192
+ ## mkt_docs documents: indexes + lifecycle
193
+
194
+ - **`mkt_docs/README.md` (curated, by hand):** reading priority, few lines.
195
+ - **`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.
196
+ - `research/`, `spikes/`, `audit/` are discovery-by-grep: they do not enter the manifest. Research freshness is carried by ledger dates, not by the manifest.
197
+
198
+ Every canonical document opens with frontmatter:
199
+
200
+ ```markdown
201
+ ---
202
+ description: One line — what it is and when to read it.
203
+ status: CURRENT # CURRENT | SUPERSEDED | DRAFT | DEPRECATED
204
+ supersedes: old_doc.md # only if it replaces another doc
205
+ ---
206
+ ```
207
+
208
+ `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`.
209
+
210
+ ## Deliverable quality bar
211
+
212
+ The final plan must be recognizable by a marketing professional:
213
+ - SOSTAC section structure, executive summary first.
214
+ - Every number carries `[EV-nn]`; the ledger ships as an appendix.
215
+ - Assumptions section on page one when material assumptions exist.
216
+ - Positioning passes the swap test; messaging house has proof points, not slogans.
217
+ - Budget table, funnel model, 90-day plan and kill/scale criteria present — a plan without a control loop is a brochure.
218
+
219
+ ## Reading the shared doctrine from this lens
220
+
221
+ `review.md`, `dispatch.md` and `guides.md` are the family's shared spine,
222
+ byte-identical in every distribution, written in the family's neutral
223
+ vocabulary. Reading them from this lens: where they say `sdlc_check.py`,
224
+ read `mkt_check.py`; where they say "Phase 3 / Phase 5 closure", read this
225
+ workflow's phase 6 (strategy review) and phase 9 (control & packaging);
226
+ where they say ANALYSIS/feature, read this lens's governed artifacts and
227
+ engagement. The procedures bind as written; only the names translate.
228
+
229
+ ## Mechanical Enforcement
230
+
231
+ The prompt is not enforcement. When the project needs repeatable guarantees:
232
+ - read `ENFORCEMENT.md`;
233
+ - use `scripts/mkt_check.py validate --strict` in CI;
234
+ - run `scripts/mkt_check.py check` before declaring any E2/E3 deliverable done.
235
+
236
+ 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,87 @@
1
+ # Subagent Execution Discipline
2
+
3
+ Opt-in orchestration for L3 work with an approved design: the orchestrator
4
+ drives a `PLAN_[feature].md` through subagents instead of implementing every
5
+ task in the same session. Default stays same-session; this is an escalation,
6
+ never a requirement.
7
+
8
+ ## Trigger
9
+
10
+ Only for L3 (an approved E-TDD in Hybrid, or an ANALYSIS Action Plan in
11
+ Standalone). Never for L1/L2 — the plan/ledger machinery is overhead a small
12
+ change does not need. The plan is always `derived-from` the accepted design:
13
+ it is never independently authored, exactly like an E-TDD is never authored
14
+ without an E-ISP.
15
+
16
+ ## The loop
17
+
18
+ 1. `sdlc_check.py plan validate PLAN_[feature].md` — zero-execution schema +
19
+ confinement + ledger cross-check. Non-zero exit = **no dispatch**. This is
20
+ the hard gate: "no valid plan, no dispatch."
21
+ 2. For each task, in plan order:
22
+ - Read the task's status from the sidecar ledger
23
+ (`PLAN_[feature].ledger.json`). `status: done` (exact sentinel) → skip,
24
+ never re-dispatch. Anything else (pending, failed, missing, or a
25
+ corrupt-but-parseable entry) → treat as pending and dispatch.
26
+ - `sdlc_check.py plan brief PLAN_[feature].md --task <id>` — prints the
27
+ task block, the `produces` of prior-order tasks (interfaces), and
28
+ `guides` pointers (paths, never pasted content) to stdout.
29
+ - Spawn the subagent with that brief as its entire context window.
30
+ - Run `task.verify` out of band (the orchestrator executes it — the
31
+ validator only ever prints it, never runs it) plus the one-shot review
32
+ below.
33
+ - Write `{status, verify_result, timestamp}` back to the ledger. The
34
+ validator never writes the ledger — single-writer, orchestrator-owned.
35
+
36
+ **Guide consumption under dispatch.** Selecting each task's `guides` field IS the
37
+ consult trigger (`guides.md` §0) applied at plan-authoring time: the orchestrator
38
+ runs the router lookup (project router `ai_docs/reference/INDEX.md` + the agent-KB
39
+ router) when populating `guides`. A dispatched context-free subagent does **NOT**
40
+ run its own router consult — it reads the guide pointers handed to it in the
41
+ brief. The router verdict (Rule Zero) is therefore declared ONCE, by the
42
+ orchestrator, when it authors the plan; a dispatched subagent does not declare
43
+ one. (Proactive guide-creation stays at closure — the same broad final pass
44
+ below — so it needs no separate dispatch hook.)
45
+
46
+ ## Model tiers (client-relative, no provider names)
47
+
48
+ - Default dispatch: **economy** implementer tier.
49
+ - After **two** consecutive `verify_result: fail` on the same task: escalate
50
+ to the **deep** tier for the retry (ADR 2026-07-02). Do not escalate on the
51
+ first failure — a single fail is often a brief or environment issue, not a
52
+ capability gap.
53
+
54
+ ## Review slots — one-shot, not iterative
55
+
56
+ Exactly three review touches per task, never a loop:
57
+
58
+ 1. Inline self-review by the implementer subagent before it reports done
59
+ (the standard critical-review pass, not a separate call).
60
+ 2. One reviewer pass per task (Hybrid: reuse the devPNT code-review gate;
61
+ Standalone: the `review.md` discipline).
62
+ 3. One broad final pass over the whole plan at closure, after all tasks are
63
+ DONE — catches cross-task drift a per-task review cannot see.
64
+
65
+ If a review FAILs, fix and re-run `verify` — that is a normal loop iteration
66
+ via the ledger's fail path, not an extra review slot.
67
+
68
+ ## Ledger protocol summary
69
+
70
+ Read → skip-if-done → dispatch-if-pending → write. The ledger is the only
71
+ memory the loop needs across sessions or context compaction: a resumed
72
+ orchestrator re-reads it and picks up exactly where it left off, never
73
+ re-running a DONE task.
74
+
75
+ ## Degradation
76
+
77
+ No subagent-spawning tool available → the orchestrator runs each task in the
78
+ same session, against the same plan and ledger, with the same one-shot review
79
+ slots. No capability is lost, only the parallelism/isolation subagents would
80
+ have added.
81
+
82
+ ## Hybrid note
83
+
84
+ The plan's `derived-from` points at the accepted E-TDD document key. Per-task
85
+ review reuses the devPNT independent reviewers (§4.6 code review gate) rather
86
+ than restating review doctrine — see `review.md` for the single definition
87
+ both modes share.