@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.
- package/CHANGELOG.md +96 -22
- package/README.md +67 -57
- package/gemini-extension.json +6 -6
- package/package.json +50 -45
- package/scripts/init.js +207 -147
- package/scripts/lib.js +66 -3
- package/scripts/postinstall.js +42 -42
- package/scripts/preuninstall.js +17 -17
- package/skills/mkt-agentic-sdlc/ENFORCEMENT.md +116 -82
- package/skills/mkt-agentic-sdlc/SKILL.md +236 -201
- package/skills/mkt-agentic-sdlc/dispatch.md +87 -0
- package/skills/mkt-agentic-sdlc/elicitation.md +147 -89
- package/skills/mkt-agentic-sdlc/frameworks.md +105 -105
- package/skills/mkt-agentic-sdlc/guides.md +287 -0
- package/skills/mkt-agentic-sdlc/research.md +110 -104
- package/skills/mkt-agentic-sdlc/review.md +180 -73
- package/skills/mkt-agentic-sdlc/routing.md +100 -0
- package/skills/mkt-agentic-sdlc/scripts/mkt_check.py +703 -567
- package/skills/mkt-agentic-sdlc/scripts/sdlc_core.py +1996 -0
- package/skills/mkt-agentic-sdlc/templates.md +616 -444
- package/skills/mkt-agentic-sdlc/vision.md +245 -0
|
@@ -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
|
|
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
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
-
|
|
53
|
-
-
|
|
54
|
-
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
-
|
|
122
|
-
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
###
|
|
139
|
-
-
|
|
140
|
-
-
|
|
141
|
-
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
- **
|
|
146
|
-
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
-
|
|
151
|
-
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
-
|
|
160
|
-
-
|
|
161
|
-
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
-
|
|
171
|
-
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
1
|
+
---
|
|
2
|
+
name: mkt-agentic-sdlc
|
|
3
|
+
description: Evidence-First marketing planning protocol with engagement triage, SOSTAC workflow, evidence ledger, adversarial CMO review, a complete Standalone mode and optional symbiosis with devPNT. Use for marketing plans, go-to-market strategy, campaign planning and market research.
|
|
4
|
+
author: Antonio Pinto (https://github.com/Antoneeo)
|
|
5
|
+
copyright: (c) 2026 Antonio Pinto
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Marketing Agentic SDLC
|
|
9
|
+
|
|
10
|
+
This skill guides marketing strategy work with an Evidence-First process proportional to the engagement. It turns the agent into a disciplined marketing strategist: facts come from the user, analysis comes from real research, numbers come from a ledger, and the plan ships only after mechanical validation and adversarial review. It must work fully even without devPNT. When devPNT is available and configured for the current project, plans and strategy artifacts become governed, versioned documents with proposal/approval workflow.
|
|
11
|
+
|
|
12
|
+
Support files in the skill directory:
|
|
13
|
+
- `frameworks.md`: which professional framework to use in which phase (SOSTAC, STP, JTBD, positioning, KPI tree) — and when NOT to use one.
|
|
14
|
+
- `elicitation.md`: the question waves and the only-facts-you-own rule.
|
|
15
|
+
- `research.md`: the research playbook and the evidence ledger discipline.
|
|
16
|
+
- `templates.md`: templates for every artifact and deliverable.
|
|
17
|
+
- `review.md`: the 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.
|