@antoneeo/mkt-agentic-sdlc-skill 0.14.0 → 0.15.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 +6 -0
- package/README.md +157 -150
- package/gemini-extension.json +1 -1
- package/package.json +1 -1
- package/scripts/init.js +6 -6
- package/skills/mkt-agentic-sdlc/ENFORCEMENT.md +5 -5
- package/skills/mkt-agentic-sdlc/SKILL.md +2 -2
- package/skills/mkt-agentic-sdlc/elicitation.md +217 -217
- package/skills/mkt-agentic-sdlc/hybrid.md +47 -47
- package/skills/mkt-agentic-sdlc/memory.md +88 -88
- package/skills/mkt-agentic-sdlc/routing.md +28 -16
- package/skills/mkt-agentic-sdlc/scripts/knowledge.py +2089 -2089
- package/skills/mkt-agentic-sdlc/scripts/mkt_check.py +752 -718
- package/skills/mkt-agentic-sdlc/scripts/sdlc_core.py +6 -1
- package/skills/mkt-agentic-sdlc/templates.md +2 -0
|
@@ -1,217 +1,217 @@
|
|
|
1
|
-
# Elicitation — question waves
|
|
2
|
-
|
|
3
|
-
`## The question discipline` below governs EVERY doubt and EVERY question to the
|
|
4
|
-
user — any phase, any level, inside or outside the waves. The waves are the only
|
|
5
|
-
place the process *plans* the cost of asking.
|
|
6
|
-
|
|
7
|
-
Ask for the **benefit** the user wants, never for the mechanism they imagine delivers it: a mechanism stated as a requirement forecloses every better one.
|
|
8
|
-
|
|
9
|
-
The cardinal rule: **ask only what the user uniquely owns.** Facts about their
|
|
10
|
-
business come from them; everything derivable from research comes from
|
|
11
|
-
research. Asking the user "who are your competitors and how are you
|
|
12
|
-
positioned?" is outsourcing the skill's own job — the failure mode this file
|
|
13
|
-
exists to prevent.
|
|
14
|
-
|
|
15
|
-
Unattended path: when the user is not reachable (a scheduled or autonomous run)
|
|
16
|
-
and a real doubt remains, do not stall and do not invent consensus. Record it as
|
|
17
|
-
a **declared assumption** (§Ask before the write). At E3 the artifact stays
|
|
18
|
-
`DRAFT` and the plan holds at the next user gate; at E1/E2, proceed and list the
|
|
19
|
-
assumption in the reply.
|
|
20
|
-
|
|
21
|
-
## The question discipline
|
|
22
|
-
|
|
23
|
-
A doubt kept silent is decided by the agent alone and reaches the plan looking
|
|
24
|
-
settled; a useless question wastes the user's attention. This section rules on
|
|
25
|
-
both.
|
|
26
|
-
|
|
27
|
-
### When a doubt emerges
|
|
28
|
-
|
|
29
|
-
A **candidate doubt** is an open point whose answer changes the plan. The usual
|
|
30
|
-
signals — they illustrate, they do not close the definition:
|
|
31
|
-
|
|
32
|
-
| Thought | What it means |
|
|
33
|
-
|---|---|
|
|
34
|
-
| "They probably mean…", "I'll assume…" | you are choosing between readings of the request |
|
|
35
|
-
| "The brief doesn't say, so I'll fill it in" | a gap in scope, a non-goal, a budget or a priority |
|
|
36
|
-
| "Either would work, I'll pick one" | equivalent in effect: yours, pick and do not ask; different in effect: weigh them below |
|
|
37
|
-
| "I'll note it as an assumption and move on" | with the user reachable, that note is where doubts go to be forgotten |
|
|
38
|
-
|
|
39
|
-
- **A fact about the business, or information only the user holds** (a budget,
|
|
40
|
-
a margin, a red line): settled only by evidence, cited —
|
|
41
|
-
never settled by a weighing. A ledger ASSUMPTION backed by a benchmark, a
|
|
42
|
-
comparable or a stated policy is a researched answer with its confidence, not a
|
|
43
|
-
doubt; a gap only the user can fill is a real doubt.
|
|
44
|
-
- **A choice** — a reading of the brief, a strategic trade-off: cite the user's
|
|
45
|
-
statement that settles it (the brief, an APPROVED MKT-VISION, an earlier answer);
|
|
46
|
-
failing one, weigh the pros and cons of each option, stating each rejected option
|
|
47
|
-
at its strongest — the need it serves best; a weighing won against a weak version
|
|
48
|
-
of the alternative is not a weighing. One clearly outweighs: take it and write the
|
|
49
|
-
weighing with the choice — "I take X over Z: pro …, contro …". Balanced, or
|
|
50
|
-
turning on a priority of theirs not on record: a **real doubt** — and it turns on
|
|
51
|
-
one whenever the options serve different needs of the audience or the business,
|
|
52
|
-
each better at one the user would notice in the results (reach against
|
|
53
|
-
conversion, speed to market against completeness of the launch) and
|
|
54
|
-
none good enough at both, and nothing the user wrote ranks those needs — however
|
|
55
|
-
clear your own ranking feels. "The more natural reading" with no pros and cons
|
|
56
|
-
written is not a weighing. Reserved approvals never enter this test
|
|
57
|
-
(§The form of a question).
|
|
58
|
-
|
|
59
|
-
### Ask before the write
|
|
60
|
-
|
|
61
|
-
A real doubt that passes the legality test below is **owed**, not merely allowed.
|
|
62
|
-
Ask it before the first write that would embed its answer, grouped with every
|
|
63
|
-
doubt open at that point — the next wave when one is due, otherwise one round —
|
|
64
|
-
following the question style below. Never defer a doubt to the deliverable, where
|
|
65
|
-
the user must find it inside the plan; never drip one question per turn. An
|
|
66
|
-
intent choice with neither a source nor a weighing is a finding (`review.md`
|
|
67
|
-
§Reviewing).
|
|
68
|
-
|
|
69
|
-
**Declared assumptions exist only where no question can be asked:**
|
|
70
|
-
|
|
71
|
-
- **Unattended** — the user is not reachable (the Unattended path above).
|
|
72
|
-
- **Delegated** — their own words handed you this choice; quote them. A general
|
|
73
|
-
"go ahead" is not a delegation.
|
|
74
|
-
|
|
75
|
-
Each states **what it is taken from** and **the alternative it excludes** —
|
|
76
|
-
a number goes in the ledger as an ASSUMPTION row, anything else in the artifact it
|
|
77
|
-
touches — and is listed where the user will read it: an unshown assumption is a
|
|
78
|
-
fabricated FACT waiting to happen. (A researched ASSUMPTION row, with its range and
|
|
79
|
-
confidence, is an answer, not a declared assumption.) A dispatched subagent returns
|
|
80
|
-
its open points in its final output (`dispatch.md`); the orchestrator treats them as
|
|
81
|
-
its own candidate doubts (§When a doubt emerges).
|
|
82
|
-
|
|
83
|
-
### The legality test
|
|
84
|
-
|
|
85
|
-
A question outside the waves is legal only when BOTH hold:
|
|
86
|
-
|
|
87
|
-
1. **Searched first, and the search is named — with its result.** The answer is
|
|
88
|
-
not on record (MKT-VISION, ledger, session notes) and not derivable from
|
|
89
|
-
research — and the question states what you searched or researched **and what
|
|
90
|
-
it returned**. **Never fake the search**: "I looked and found nothing" that
|
|
91
|
-
names no sources and no queries is a search not run. A question research can
|
|
92
|
-
answer is research outsourced to the client — the cardinal rule's own
|
|
93
|
-
failure mode, restated as a legality test.
|
|
94
|
-
2. **It names what is blocked.** The question states the decision or fact that
|
|
95
|
-
cannot be resolved without the reply — what changes in the plan depending on
|
|
96
|
-
the answer. If nothing downstream changes, there is no question.
|
|
97
|
-
|
|
98
|
-
Never legal:
|
|
99
|
-
|
|
100
|
-
- **Generic confirmation** — "shall I proceed?", "is the plan OK so far?". The
|
|
101
|
-
gates are where approval lives; if a real risk motivates the ask, name the
|
|
102
|
-
risk and the fork — that is a blocking question and carries the form below.
|
|
103
|
-
- **Preference-fishing** — asking the client to pick among options equivalent
|
|
104
|
-
in their effect on the objective. Cheapness to undo is NOT the test.
|
|
105
|
-
- **Re-asking the record** — anything an approved MKT-VISION, a ledger entry
|
|
106
|
-
or an earlier answer already states.
|
|
107
|
-
|
|
108
|
-
**Precedence:** a choice the user uniquely owns (budget, risk appetite,
|
|
109
|
-
non-negotiables, brand red lines, approvals the gates reserve) is never
|
|
110
|
-
preference-fishing; the list above reaches choices that are *not* theirs.
|
|
111
|
-
|
|
112
|
-
### The form of a question
|
|
113
|
-
|
|
114
|
-
The approvals the gates reserve and every stop the doctrine mandates are asked
|
|
115
|
-
whatever you expect the answer: **legal by mandate**, never weighed, never
|
|
116
|
-
re-argued here. Unattended, they are never assumed: the plan holds at the gate,
|
|
117
|
-
unless the mandating rule prescribes its own unattended handling (`review.md`'s
|
|
118
|
-
gated rung does).
|
|
119
|
-
|
|
120
|
-
One mandating file prescribes its own hand-over, and there this form does not
|
|
121
|
-
apply: `review.md`'s round cap (the artifact plus the open findings).
|
|
122
|
-
That list is closed. A question outside the waves carries the **blocking form**,
|
|
123
|
-
one line per element:
|
|
124
|
-
|
|
125
|
-
- the fork: the options, each with its pros and cons, and what each implies for
|
|
126
|
-
the plan;
|
|
127
|
-
- the evidence: what you researched and what it leaves undecided;
|
|
128
|
-
- why no assumption survives — why the weighing does not settle it, and what a
|
|
129
|
-
wrong pick costs; a reserved approval or a mandated stop cites the approval or
|
|
130
|
-
the mandate instead;
|
|
131
|
-
- why it is the user's call;
|
|
132
|
-
- what stays blocked until answered.
|
|
133
|
-
|
|
134
|
-
Question style (all waves):
|
|
135
|
-
- Plain language, zero marketing jargon. Not "what's your ICP?" but "describe
|
|
136
|
-
your best current customer".
|
|
137
|
-
- Max 4 questions per round; multiple rounds per wave allowed but each round
|
|
138
|
-
must be worth the interruption. More than 4 open doubts: the next round follows
|
|
139
|
-
at once, still before the write.
|
|
140
|
-
- Offer concrete options where a real choice exists, each with its pros and
|
|
141
|
-
cons (narrows the reply, speeds the round). Use the client's
|
|
142
|
-
structured-question facility when available.
|
|
143
|
-
- **Pre-authorize "I don't know" on numeric asks.** When you ask for a figure
|
|
144
|
-
the client may never have measured (conversion rate, CAC, open rate),
|
|
145
|
-
append the permission in the question itself — "...ma se non l'avete mai
|
|
146
|
-
misurato, va bene 'non lo so'." It removes the pressure to invent a number
|
|
147
|
-
and keeps the ledger honest (an unmeasured figure becomes a researched
|
|
148
|
-
BENCHMARK or a declared ASSUMPTION, never a fabricated FACT).
|
|
149
|
-
- Every answer that is a fact becomes a `FACT` entry in the evidence ledger,
|
|
150
|
-
same discipline as researched numbers.
|
|
151
|
-
- **Seeds are allowed, analysis is not:** "which competitors do you lose
|
|
152
|
-
deals to?" is a fact the user owns (their perceived competitive set) and a
|
|
153
|
-
legitimate research seed. "What are their strengths and weaknesses?" is
|
|
154
|
-
analysis — forbidden to ask, mandatory to research.
|
|
155
|
-
|
|
156
|
-
## Wave 1 — Discovery (phase 2, before any research)
|
|
157
|
-
|
|
158
|
-
Cover, across rounds:
|
|
159
|
-
1. **Offer** — what they sell, in their words; what problem it solves.
|
|
160
|
-
2. **Price & margin** — price point(s), rough margin, discount reality.
|
|
161
|
-
3. **Current traction** — customers today (how many, what kind), revenue
|
|
162
|
-
order of magnitude, where the current customers came from.
|
|
163
|
-
4. **Market & language** — geography, target market, language for the
|
|
164
|
-
deliverables.
|
|
165
|
-
5. **Budget & horizon** — marketing budget range (a range is fine), planning
|
|
166
|
-
horizon (quarter / year / launch window).
|
|
167
|
-
6. **Team & capacity** — who will execute marketing (nobody / founder /
|
|
168
|
-
person / team / agency), hours realistically available.
|
|
169
|
-
7. **Sales motion** — how a sale happens today (self-serve, demo calls,
|
|
170
|
-
proposals, retail...), typical cycle length.
|
|
171
|
-
8. **Existing assets** — website, mailing list, social accounts and their
|
|
172
|
-
real state; brand materials.
|
|
173
|
-
9. **Constraints** — legal/regulatory limits, channels they refuse, brand
|
|
174
|
-
red lines.
|
|
175
|
-
10. **Competitor seeds** — who they lose deals to / who customers compare
|
|
176
|
-
them with (seed, not analysis).
|
|
177
|
-
|
|
178
|
-
Skip path: any item already answered by an approved MKT-VISION or earlier
|
|
179
|
-
session record is not re-asked — note where the answer came from.
|
|
180
|
-
|
|
181
|
-
## Wave 2 — Ambition (phase 5 entry, after research)
|
|
182
|
-
|
|
183
|
-
Now the user chooses with research on the table. Present the relevant
|
|
184
|
-
evidence first (one short paragraph), then ask:
|
|
185
|
-
1. **Growth vs margin** — push volume or protect profitability?
|
|
186
|
-
2. **Risk appetite** — proven channels only, or reserve an experimental slice?
|
|
187
|
-
3. **Timeline pressure** — is there a hard date (launch, season, runway)?
|
|
188
|
-
4. **Non-negotiables** — anything the objectives must include or avoid?
|
|
189
|
-
|
|
190
|
-
## Wave 3 — Execution capacity (phase 7 entry)
|
|
191
|
-
|
|
192
|
-
1. **Content capacity** — who writes/records, in which language, how often
|
|
193
|
-
realistically?
|
|
194
|
-
2. **Paid capacity** — who runs ads; any platform experience in-house?
|
|
195
|
-
3. **Follow-up capacity** — if leads double, who answers them? CRM/tooling?
|
|
196
|
-
4. **Budget flexibility** — is the budget fixed or scalable if a channel
|
|
197
|
-
proves itself?
|
|
198
|
-
|
|
199
|
-
## Reflect
|
|
200
|
-
|
|
201
|
-
Fold answers into the artifacts (MKT_VISION, OBJECTIVES, TACTICAL_PLAN) and
|
|
202
|
-
the ledger — never leave them only in chat. The written document is what the
|
|
203
|
-
next session and the reviewer read.
|
|
204
|
-
|
|
205
|
-
## Anti-patterns
|
|
206
|
-
|
|
207
|
-
- **Deferring a doubt into the plan**: writing a guess into the artifact and
|
|
208
|
-
leaving the user to find it there.
|
|
209
|
-
- **Outsourcing analysis**: asking the user for market size, competitor
|
|
210
|
-
strengths, channel choice, or positioning. That is the skill's work.
|
|
211
|
-
- **Jargon**: ICP, CAC, SOM, funnel — translate or don't ask.
|
|
212
|
-
- **Interrogation**: more than 4 questions per round, or drip-feeding across
|
|
213
|
-
many turns instead of structured rounds.
|
|
214
|
-
- **Re-asking the recorded**: anything an approved vision or ledger FACT
|
|
215
|
-
already answers.
|
|
216
|
-
- **Collecting without folding in**: answers that never reach a document or
|
|
217
|
-
the ledger are lost to the next session.
|
|
1
|
+
# Elicitation — question waves
|
|
2
|
+
|
|
3
|
+
`## The question discipline` below governs EVERY doubt and EVERY question to the
|
|
4
|
+
user — any phase, any level, inside or outside the waves. The waves are the only
|
|
5
|
+
place the process *plans* the cost of asking.
|
|
6
|
+
|
|
7
|
+
Ask for the **benefit** the user wants, never for the mechanism they imagine delivers it: a mechanism stated as a requirement forecloses every better one.
|
|
8
|
+
|
|
9
|
+
The cardinal rule: **ask only what the user uniquely owns.** Facts about their
|
|
10
|
+
business come from them; everything derivable from research comes from
|
|
11
|
+
research. Asking the user "who are your competitors and how are you
|
|
12
|
+
positioned?" is outsourcing the skill's own job — the failure mode this file
|
|
13
|
+
exists to prevent.
|
|
14
|
+
|
|
15
|
+
Unattended path: when the user is not reachable (a scheduled or autonomous run)
|
|
16
|
+
and a real doubt remains, do not stall and do not invent consensus. Record it as
|
|
17
|
+
a **declared assumption** (§Ask before the write). At E3 the artifact stays
|
|
18
|
+
`DRAFT` and the plan holds at the next user gate; at E1/E2, proceed and list the
|
|
19
|
+
assumption in the reply.
|
|
20
|
+
|
|
21
|
+
## The question discipline
|
|
22
|
+
|
|
23
|
+
A doubt kept silent is decided by the agent alone and reaches the plan looking
|
|
24
|
+
settled; a useless question wastes the user's attention. This section rules on
|
|
25
|
+
both.
|
|
26
|
+
|
|
27
|
+
### When a doubt emerges
|
|
28
|
+
|
|
29
|
+
A **candidate doubt** is an open point whose answer changes the plan. The usual
|
|
30
|
+
signals — they illustrate, they do not close the definition:
|
|
31
|
+
|
|
32
|
+
| Thought | What it means |
|
|
33
|
+
|---|---|
|
|
34
|
+
| "They probably mean…", "I'll assume…" | you are choosing between readings of the request |
|
|
35
|
+
| "The brief doesn't say, so I'll fill it in" | a gap in scope, a non-goal, a budget or a priority |
|
|
36
|
+
| "Either would work, I'll pick one" | equivalent in effect: yours, pick and do not ask; different in effect: weigh them below |
|
|
37
|
+
| "I'll note it as an assumption and move on" | with the user reachable, that note is where doubts go to be forgotten |
|
|
38
|
+
|
|
39
|
+
- **A fact about the business, or information only the user holds** (a budget,
|
|
40
|
+
a margin, a red line): settled only by evidence, cited —
|
|
41
|
+
never settled by a weighing. A ledger ASSUMPTION backed by a benchmark, a
|
|
42
|
+
comparable or a stated policy is a researched answer with its confidence, not a
|
|
43
|
+
doubt; a gap only the user can fill is a real doubt.
|
|
44
|
+
- **A choice** — a reading of the brief, a strategic trade-off: cite the user's
|
|
45
|
+
statement that settles it (the brief, an APPROVED MKT-VISION, an earlier answer);
|
|
46
|
+
failing one, weigh the pros and cons of each option, stating each rejected option
|
|
47
|
+
at its strongest — the need it serves best; a weighing won against a weak version
|
|
48
|
+
of the alternative is not a weighing. One clearly outweighs: take it and write the
|
|
49
|
+
weighing with the choice — "I take X over Z: pro …, contro …". Balanced, or
|
|
50
|
+
turning on a priority of theirs not on record: a **real doubt** — and it turns on
|
|
51
|
+
one whenever the options serve different needs of the audience or the business,
|
|
52
|
+
each better at one the user would notice in the results (reach against
|
|
53
|
+
conversion, speed to market against completeness of the launch) and
|
|
54
|
+
none good enough at both, and nothing the user wrote ranks those needs — however
|
|
55
|
+
clear your own ranking feels. "The more natural reading" with no pros and cons
|
|
56
|
+
written is not a weighing. Reserved approvals never enter this test
|
|
57
|
+
(§The form of a question).
|
|
58
|
+
|
|
59
|
+
### Ask before the write
|
|
60
|
+
|
|
61
|
+
A real doubt that passes the legality test below is **owed**, not merely allowed.
|
|
62
|
+
Ask it before the first write that would embed its answer, grouped with every
|
|
63
|
+
doubt open at that point — the next wave when one is due, otherwise one round —
|
|
64
|
+
following the question style below. Never defer a doubt to the deliverable, where
|
|
65
|
+
the user must find it inside the plan; never drip one question per turn. An
|
|
66
|
+
intent choice with neither a source nor a weighing is a finding (`review.md`
|
|
67
|
+
§Reviewing).
|
|
68
|
+
|
|
69
|
+
**Declared assumptions exist only where no question can be asked:**
|
|
70
|
+
|
|
71
|
+
- **Unattended** — the user is not reachable (the Unattended path above).
|
|
72
|
+
- **Delegated** — their own words handed you this choice; quote them. A general
|
|
73
|
+
"go ahead" is not a delegation.
|
|
74
|
+
|
|
75
|
+
Each states **what it is taken from** and **the alternative it excludes** —
|
|
76
|
+
a number goes in the ledger as an ASSUMPTION row, anything else in the artifact it
|
|
77
|
+
touches — and is listed where the user will read it: an unshown assumption is a
|
|
78
|
+
fabricated FACT waiting to happen. (A researched ASSUMPTION row, with its range and
|
|
79
|
+
confidence, is an answer, not a declared assumption.) A dispatched subagent returns
|
|
80
|
+
its open points in its final output (`dispatch.md`); the orchestrator treats them as
|
|
81
|
+
its own candidate doubts (§When a doubt emerges).
|
|
82
|
+
|
|
83
|
+
### The legality test
|
|
84
|
+
|
|
85
|
+
A question outside the waves is legal only when BOTH hold:
|
|
86
|
+
|
|
87
|
+
1. **Searched first, and the search is named — with its result.** The answer is
|
|
88
|
+
not on record (MKT-VISION, ledger, session notes) and not derivable from
|
|
89
|
+
research — and the question states what you searched or researched **and what
|
|
90
|
+
it returned**. **Never fake the search**: "I looked and found nothing" that
|
|
91
|
+
names no sources and no queries is a search not run. A question research can
|
|
92
|
+
answer is research outsourced to the client — the cardinal rule's own
|
|
93
|
+
failure mode, restated as a legality test.
|
|
94
|
+
2. **It names what is blocked.** The question states the decision or fact that
|
|
95
|
+
cannot be resolved without the reply — what changes in the plan depending on
|
|
96
|
+
the answer. If nothing downstream changes, there is no question.
|
|
97
|
+
|
|
98
|
+
Never legal:
|
|
99
|
+
|
|
100
|
+
- **Generic confirmation** — "shall I proceed?", "is the plan OK so far?". The
|
|
101
|
+
gates are where approval lives; if a real risk motivates the ask, name the
|
|
102
|
+
risk and the fork — that is a blocking question and carries the form below.
|
|
103
|
+
- **Preference-fishing** — asking the client to pick among options equivalent
|
|
104
|
+
in their effect on the objective. Cheapness to undo is NOT the test.
|
|
105
|
+
- **Re-asking the record** — anything an approved MKT-VISION, a ledger entry
|
|
106
|
+
or an earlier answer already states.
|
|
107
|
+
|
|
108
|
+
**Precedence:** a choice the user uniquely owns (budget, risk appetite,
|
|
109
|
+
non-negotiables, brand red lines, approvals the gates reserve) is never
|
|
110
|
+
preference-fishing; the list above reaches choices that are *not* theirs.
|
|
111
|
+
|
|
112
|
+
### The form of a question
|
|
113
|
+
|
|
114
|
+
The approvals the gates reserve and every stop the doctrine mandates are asked
|
|
115
|
+
whatever you expect the answer: **legal by mandate**, never weighed, never
|
|
116
|
+
re-argued here. Unattended, they are never assumed: the plan holds at the gate,
|
|
117
|
+
unless the mandating rule prescribes its own unattended handling (`review.md`'s
|
|
118
|
+
gated rung does).
|
|
119
|
+
|
|
120
|
+
One mandating file prescribes its own hand-over, and there this form does not
|
|
121
|
+
apply: `review.md`'s round cap (the artifact plus the open findings).
|
|
122
|
+
That list is closed. A question outside the waves carries the **blocking form**,
|
|
123
|
+
one line per element:
|
|
124
|
+
|
|
125
|
+
- the fork: the options, each with its pros and cons, and what each implies for
|
|
126
|
+
the plan;
|
|
127
|
+
- the evidence: what you researched and what it leaves undecided;
|
|
128
|
+
- why no assumption survives — why the weighing does not settle it, and what a
|
|
129
|
+
wrong pick costs; a reserved approval or a mandated stop cites the approval or
|
|
130
|
+
the mandate instead;
|
|
131
|
+
- why it is the user's call;
|
|
132
|
+
- what stays blocked until answered.
|
|
133
|
+
|
|
134
|
+
Question style (all waves):
|
|
135
|
+
- Plain language, zero marketing jargon. Not "what's your ICP?" but "describe
|
|
136
|
+
your best current customer".
|
|
137
|
+
- Max 4 questions per round; multiple rounds per wave allowed but each round
|
|
138
|
+
must be worth the interruption. More than 4 open doubts: the next round follows
|
|
139
|
+
at once, still before the write.
|
|
140
|
+
- Offer concrete options where a real choice exists, each with its pros and
|
|
141
|
+
cons (narrows the reply, speeds the round). Use the client's
|
|
142
|
+
structured-question facility when available.
|
|
143
|
+
- **Pre-authorize "I don't know" on numeric asks.** When you ask for a figure
|
|
144
|
+
the client may never have measured (conversion rate, CAC, open rate),
|
|
145
|
+
append the permission in the question itself — "...ma se non l'avete mai
|
|
146
|
+
misurato, va bene 'non lo so'." It removes the pressure to invent a number
|
|
147
|
+
and keeps the ledger honest (an unmeasured figure becomes a researched
|
|
148
|
+
BENCHMARK or a declared ASSUMPTION, never a fabricated FACT).
|
|
149
|
+
- Every answer that is a fact becomes a `FACT` entry in the evidence ledger,
|
|
150
|
+
same discipline as researched numbers.
|
|
151
|
+
- **Seeds are allowed, analysis is not:** "which competitors do you lose
|
|
152
|
+
deals to?" is a fact the user owns (their perceived competitive set) and a
|
|
153
|
+
legitimate research seed. "What are their strengths and weaknesses?" is
|
|
154
|
+
analysis — forbidden to ask, mandatory to research.
|
|
155
|
+
|
|
156
|
+
## Wave 1 — Discovery (phase 2, before any research)
|
|
157
|
+
|
|
158
|
+
Cover, across rounds:
|
|
159
|
+
1. **Offer** — what they sell, in their words; what problem it solves.
|
|
160
|
+
2. **Price & margin** — price point(s), rough margin, discount reality.
|
|
161
|
+
3. **Current traction** — customers today (how many, what kind), revenue
|
|
162
|
+
order of magnitude, where the current customers came from.
|
|
163
|
+
4. **Market & language** — geography, target market, language for the
|
|
164
|
+
deliverables.
|
|
165
|
+
5. **Budget & horizon** — marketing budget range (a range is fine), planning
|
|
166
|
+
horizon (quarter / year / launch window).
|
|
167
|
+
6. **Team & capacity** — who will execute marketing (nobody / founder /
|
|
168
|
+
person / team / agency), hours realistically available.
|
|
169
|
+
7. **Sales motion** — how a sale happens today (self-serve, demo calls,
|
|
170
|
+
proposals, retail...), typical cycle length.
|
|
171
|
+
8. **Existing assets** — website, mailing list, social accounts and their
|
|
172
|
+
real state; brand materials.
|
|
173
|
+
9. **Constraints** — legal/regulatory limits, channels they refuse, brand
|
|
174
|
+
red lines.
|
|
175
|
+
10. **Competitor seeds** — who they lose deals to / who customers compare
|
|
176
|
+
them with (seed, not analysis).
|
|
177
|
+
|
|
178
|
+
Skip path: any item already answered by an approved MKT-VISION or earlier
|
|
179
|
+
session record is not re-asked — note where the answer came from.
|
|
180
|
+
|
|
181
|
+
## Wave 2 — Ambition (phase 5 entry, after research)
|
|
182
|
+
|
|
183
|
+
Now the user chooses with research on the table. Present the relevant
|
|
184
|
+
evidence first (one short paragraph), then ask:
|
|
185
|
+
1. **Growth vs margin** — push volume or protect profitability?
|
|
186
|
+
2. **Risk appetite** — proven channels only, or reserve an experimental slice?
|
|
187
|
+
3. **Timeline pressure** — is there a hard date (launch, season, runway)?
|
|
188
|
+
4. **Non-negotiables** — anything the objectives must include or avoid?
|
|
189
|
+
|
|
190
|
+
## Wave 3 — Execution capacity (phase 7 entry)
|
|
191
|
+
|
|
192
|
+
1. **Content capacity** — who writes/records, in which language, how often
|
|
193
|
+
realistically?
|
|
194
|
+
2. **Paid capacity** — who runs ads; any platform experience in-house?
|
|
195
|
+
3. **Follow-up capacity** — if leads double, who answers them? CRM/tooling?
|
|
196
|
+
4. **Budget flexibility** — is the budget fixed or scalable if a channel
|
|
197
|
+
proves itself?
|
|
198
|
+
|
|
199
|
+
## Reflect
|
|
200
|
+
|
|
201
|
+
Fold answers into the artifacts (MKT_VISION, OBJECTIVES, TACTICAL_PLAN) and
|
|
202
|
+
the ledger — never leave them only in chat. The written document is what the
|
|
203
|
+
next session and the reviewer read.
|
|
204
|
+
|
|
205
|
+
## Anti-patterns
|
|
206
|
+
|
|
207
|
+
- **Deferring a doubt into the plan**: writing a guess into the artifact and
|
|
208
|
+
leaving the user to find it there.
|
|
209
|
+
- **Outsourcing analysis**: asking the user for market size, competitor
|
|
210
|
+
strengths, channel choice, or positioning. That is the skill's work.
|
|
211
|
+
- **Jargon**: ICP, CAC, SOM, funnel — translate or don't ask.
|
|
212
|
+
- **Interrogation**: more than 4 questions per round, or drip-feeding across
|
|
213
|
+
many turns instead of structured rounds.
|
|
214
|
+
- **Re-asking the recorded**: anything an approved vision or ledger FACT
|
|
215
|
+
already answers.
|
|
216
|
+
- **Collecting without folding in**: answers that never reach a document or
|
|
217
|
+
the ledger are lost to the next session.
|
|
@@ -1,47 +1,47 @@
|
|
|
1
|
-
# The Hybrid Seam — coexistence with devPNT (marketing lens)
|
|
2
|
-
|
|
3
|
-
**For whom**: the agent working a marketing engagement where the `devpnt_*` tools
|
|
4
|
-
are available and point at this project.
|
|
5
|
-
**Answers**: "which mode am I in, and who owns what when both authorities are live".
|
|
6
|
-
**Does not answer**: the process itself — the engagement triage, the SOSTAC
|
|
7
|
-
phases, the gates and the evidence discipline are `SKILL.md`'s, identical in both
|
|
8
|
-
modes.
|
|
9
|
-
|
|
10
|
-
Moved out of `SKILL.md` by F-052 so a Standalone session stops paying for a seam
|
|
11
|
-
it cannot reach. **The content below is unchanged**: a relocation, not a rewrite.
|
|
12
|
-
|
|
13
|
-
<!-- moved-block-sha256: b9b19d58a104e858f38460065160a61e64a6cd6f64f92c1bbf47fbf534d25ef6 -->
|
|
14
|
-
### Hybrid in symbiosis with devPNT
|
|
15
|
-
|
|
16
|
-
Use this mode when the `devpnt_*` tools are available and point at the current project.
|
|
17
|
-
|
|
18
|
-
Authoritative hierarchy:
|
|
19
|
-
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.
|
|
20
|
-
2. **devPNT Master Plan**: the marketing roadmap; milestones are plan cycles (a quarter, a launch, a market entry).
|
|
21
|
-
3. **devPNT Action Plan**: the nine phases of the active engagement as tactical nodes.
|
|
22
|
-
4. **devPNT governed artifacts**: the marketing artifact set (table below).
|
|
23
|
-
5. **Local `mkt_docs/`**: readable context, Standalone fallback, evidence ledger home, shadow/mirror when useful.
|
|
24
|
-
|
|
25
|
-
### Ownership matrix (the Hybrid seam)
|
|
26
|
-
|
|
27
|
-
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:
|
|
28
|
-
|
|
29
|
-
| Artifact | Standalone master | Hybrid master (devPNT slot) | Mirror rule |
|
|
30
|
-
|---|---|---|---|
|
|
31
|
-
| Marketing vision | `vision/MKT_VISION.md` | M-VISION (`milestone_vision_<slug>`) | filesystem copy is a shadow; DB wins |
|
|
32
|
-
| ICP & Personas | `strategy/ICP_PERSONAS.md` | `mkt_icp_personas` (D-UC slot) | shadow `SHADOW_[doc_key]_vX.Y.md` |
|
|
33
|
-
| Threat map | `strategy/THREAT_MAP.md` | `mkt_threat_map` (P-TM slot) | shadow |
|
|
34
|
-
| Objectives | `strategy/OBJECTIVES.md` | `mkt_objectives` | shadow |
|
|
35
|
-
| Strategy | `strategy/STRATEGY.md` | `mkt_strategy` (E-ISP slot) | shadow, exported BEFORE tactics work |
|
|
36
|
-
| Tactical plan | `tactics/TACTICAL_PLAN.md` | `mkt_tactical_plan` (E-TDD slot) | shadow, exported BEFORE action phase |
|
|
37
|
-
| Measurement plan | `tactics/MEASUREMENT_PLAN.md` | `mkt_measurement_plan` (E-TP slot) | shadow |
|
|
38
|
-
| 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 |
|
|
39
|
-
| Final plan + one-pager | `deliverables/` | assembled from ACCEPTED artifact versions | PDF via `devpnt_generate_document_pdf` when available |
|
|
40
|
-
| Handoff | `audit/handoff.md` | `audit/handoff.md` | always filesystem |
|
|
41
|
-
|
|
42
|
-
Hybrid rules:
|
|
43
|
-
- devPNT is the governed source for plans and strategy artifacts; do not create a second truth in `mkt_docs/`.
|
|
44
|
-
- The skill stays autonomous: if devPNT is not there, switch to Standalone without losing capability.
|
|
45
|
-
- If the user request, the local vision and the M-VISION diverge, stop and make the conflict explicit.
|
|
46
|
-
- Never auto-accept devPNT proposals: present the preview and wait for explicit confirmation.
|
|
47
|
-
- 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.
|
|
1
|
+
# The Hybrid Seam — coexistence with devPNT (marketing lens)
|
|
2
|
+
|
|
3
|
+
**For whom**: the agent working a marketing engagement where the `devpnt_*` tools
|
|
4
|
+
are available and point at this project.
|
|
5
|
+
**Answers**: "which mode am I in, and who owns what when both authorities are live".
|
|
6
|
+
**Does not answer**: the process itself — the engagement triage, the SOSTAC
|
|
7
|
+
phases, the gates and the evidence discipline are `SKILL.md`'s, identical in both
|
|
8
|
+
modes.
|
|
9
|
+
|
|
10
|
+
Moved out of `SKILL.md` by F-052 so a Standalone session stops paying for a seam
|
|
11
|
+
it cannot reach. **The content below is unchanged**: a relocation, not a rewrite.
|
|
12
|
+
|
|
13
|
+
<!-- moved-block-sha256: b9b19d58a104e858f38460065160a61e64a6cd6f64f92c1bbf47fbf534d25ef6 -->
|
|
14
|
+
### Hybrid in symbiosis with devPNT
|
|
15
|
+
|
|
16
|
+
Use this mode when the `devpnt_*` tools are available and point at the current project.
|
|
17
|
+
|
|
18
|
+
Authoritative hierarchy:
|
|
19
|
+
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.
|
|
20
|
+
2. **devPNT Master Plan**: the marketing roadmap; milestones are plan cycles (a quarter, a launch, a market entry).
|
|
21
|
+
3. **devPNT Action Plan**: the nine phases of the active engagement as tactical nodes.
|
|
22
|
+
4. **devPNT governed artifacts**: the marketing artifact set (table below).
|
|
23
|
+
5. **Local `mkt_docs/`**: readable context, Standalone fallback, evidence ledger home, shadow/mirror when useful.
|
|
24
|
+
|
|
25
|
+
### Ownership matrix (the Hybrid seam)
|
|
26
|
+
|
|
27
|
+
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:
|
|
28
|
+
|
|
29
|
+
| Artifact | Standalone master | Hybrid master (devPNT slot) | Mirror rule |
|
|
30
|
+
|---|---|---|---|
|
|
31
|
+
| Marketing vision | `vision/MKT_VISION.md` | M-VISION (`milestone_vision_<slug>`) | filesystem copy is a shadow; DB wins |
|
|
32
|
+
| ICP & Personas | `strategy/ICP_PERSONAS.md` | `mkt_icp_personas` (D-UC slot) | shadow `SHADOW_[doc_key]_vX.Y.md` |
|
|
33
|
+
| Threat map | `strategy/THREAT_MAP.md` | `mkt_threat_map` (P-TM slot) | shadow |
|
|
34
|
+
| Objectives | `strategy/OBJECTIVES.md` | `mkt_objectives` | shadow |
|
|
35
|
+
| Strategy | `strategy/STRATEGY.md` | `mkt_strategy` (E-ISP slot) | shadow, exported BEFORE tactics work |
|
|
36
|
+
| Tactical plan | `tactics/TACTICAL_PLAN.md` | `mkt_tactical_plan` (E-TDD slot) | shadow, exported BEFORE action phase |
|
|
37
|
+
| Measurement plan | `tactics/MEASUREMENT_PLAN.md` | `mkt_measurement_plan` (E-TP slot) | shadow |
|
|
38
|
+
| 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 |
|
|
39
|
+
| Final plan + one-pager | `deliverables/` | assembled from ACCEPTED artifact versions | PDF via `devpnt_generate_document_pdf` when available |
|
|
40
|
+
| Handoff | `audit/handoff.md` | `audit/handoff.md` | always filesystem |
|
|
41
|
+
|
|
42
|
+
Hybrid rules:
|
|
43
|
+
- devPNT is the governed source for plans and strategy artifacts; do not create a second truth in `mkt_docs/`.
|
|
44
|
+
- The skill stays autonomous: if devPNT is not there, switch to Standalone without losing capability.
|
|
45
|
+
- If the user request, the local vision and the M-VISION diverge, stop and make the conflict explicit.
|
|
46
|
+
- Never auto-accept devPNT proposals: present the preview and wait for explicit confirmation.
|
|
47
|
+
- 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.
|