@antoneeo/mkt-agentic-sdlc-skill 0.20.0 → 0.21.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
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## [0.21.1] - 2026-10-18
|
|
4
|
+
|
|
5
|
+
### Fixed
|
|
6
|
+
- F-072 (field run): the `SKILL.md` line that announces the docs site now reads `scripts/docs_site.py --root <project> --open` and says to use it to show the project state. Asked for the state, an agent had opened the site in its own client pane, where it renders blank, and improvised a local server; `--open` opens it in the user's browser, where it works offline.
|
|
7
|
+
|
|
8
|
+
## [0.21.0] - 2026-10-18
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
- F-074: every Vision is born from an owner interview. Before any Vision text is written (project, feature, the MKT-VISION, and the devPNT M-VISION), the agent asks the owner six questions in order, re-asking an answer that has the wrong form: the problem as one concrete case, the benefit as a result for someone, the actors including who takes the initiative, a success signal with its starting value, the boundaries, and the known constraints with where each comes from. Then the owner approves a one- or two-sentence north star in their own words; without it no Vision is written, not even a draft. The blind check still tests that the rules hold; the approved north star shows they are the owner's. `vision.md` §The owner interview.
|
|
12
|
+
|
|
13
|
+
### Changed
|
|
14
|
+
- `elicitation.md`: the skip path never covers the MKT-VISION; Wave 1 gathers the facts, the interview gathers the Vision.
|
|
15
|
+
- Bootstrap no longer writes a Vision reconstructed by the agent: the installer seeds `mkt_docs/vision/MKT_VISION.md` as a stub awaiting the interview (an existing file is never overwritten).
|
|
16
|
+
- A Non-Goal now bounds scope. It rejects a proposal that pursues what it names; it is not a ban on behaviour that already exists and creates no obligation. A behaviour that must never happen is an Invariant or a constraint with its source.
|
|
17
|
+
- The MKT_VISION template gains North Star and Problem, the actor with the initiative, signals with starting values, Non-Goals as scope, and the source of every constraint.
|
|
18
|
+
|
|
3
19
|
## [0.20.0] - 2026-10-18
|
|
4
20
|
|
|
5
21
|
### Added
|
package/gemini-extension.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "mkt-agentic-sdlc",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.21.1",
|
|
4
4
|
"description": "Evidence-First marketing planning protocol with engagement triage, SOSTAC workflow, evidence ledger and optional devPNT integration.",
|
|
5
5
|
"author": "Antonio Pinto (https://github.com/Antoneeo)"
|
|
6
6
|
}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@antoneeo/mkt-agentic-sdlc-skill",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.21.1",
|
|
4
4
|
"description": "Evidence-First marketing planning protocol for Claude Code, Gemini CLI, Google Antigravity and Codex: engagement triage, SOSTAC workflow, evidence ledger, mechanical validator and optional devPNT integration.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"claude-code",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: mkt-agentic-sdlc
|
|
3
|
-
version: 0.
|
|
3
|
+
version: 0.21.1
|
|
4
4
|
description: Evidence-First marketing planning protocol with engagement triage, SOSTAC workflow, evidence ledger, adversarial CMO review, a complete Standalone mode and optional symbiosis with devPNT. Use for marketing plans, go-to-market strategy, campaign planning and market research.
|
|
5
5
|
author: Antonio Pinto (https://github.com/Antoneeo)
|
|
6
6
|
copyright: (c) 2026 Antonio Pinto
|
|
@@ -18,7 +18,7 @@ Support files in the skill directory:
|
|
|
18
18
|
- `templates.md`: templates for every artifact and deliverable.
|
|
19
19
|
- `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.
|
|
20
20
|
- `scripts/mkt_check.py` + `scripts/sdlc_core.py`: the mechanical validator (`check`, `validate`, `ledger`, `benefit`, `budget`, `funnel`, `trace`, `index`, plus the spine's `stale`/`mark`/`gate`/`orient`/`plan`/`migrate`). Keep the entry point, `scripts/sdlc_core.py` and `scripts/knowledge.py` together; the last supplies common memory and KB integrity.
|
|
21
|
-
- `scripts/docs_site.py --root <project
|
|
21
|
+
- `scripts/docs_site.py --root <project> --open`: opens in the user's browser a read-only site of what the agent reads; use it to show the project state.
|
|
22
22
|
- `hybrid.md`: the devPNT seam — the authoritative hierarchy, the ownership matrix (which artifact is mastered where), and the Hybrid rules. Read it when the `devpnt_*` tools point at this project; a Standalone engagement never needs it.
|
|
23
23
|
- `ENFORCEMENT.md`: optional setup for CI and hooks.
|
|
24
24
|
|
|
@@ -86,7 +86,7 @@ One event, one destination: when the trigger fires and the document does not exi
|
|
|
86
86
|
| `audit/HANDOFF_[engagement].md` | Session ends with that engagement unfinished AND there is volatile resume state. Ephemeral, deleted at closure. | 8 / 9 / session end |
|
|
87
87
|
| `audit/reviews/REVIEW_LOG.md` | Every completed review — when and what to write is `review.md`; schema is `templates.md`. | 6 / 9 |
|
|
88
88
|
| `reference/GUIDE_[topic].md` | Origin+purpose test (`guides.md`), or a proactive proposal the user accepted. | 8 / 9 |
|
|
89
|
-
| `vision/` documents | Bootstrap
|
|
89
|
+
| `vision/` documents | Bootstrap writes a **stub** awaiting the owner interview (`Status: DRAFT`) — never a Vision reconstructed by the agent; the Vision is written only after the owner interview and its approved north star (`vision.md` §The owner interview); promoted to APPROVED only by explicit user confirmation, and only after the blind check (`vision.md` §6). | 1 / 5 |
|
|
90
90
|
|
|
91
91
|
## Operating Modes
|
|
92
92
|
|
|
@@ -139,7 +139,7 @@ Deliverable language: ask for (or infer) the target market's language in Discove
|
|
|
139
139
|
|
|
140
140
|
### 2. Discovery (Situation — internal)
|
|
141
141
|
- Run elicitation **Wave 1** (`elicitation.md`): business facts only, plain language, max 4 questions per round, options where a real choice exists.
|
|
142
|
-
- Every fact captured becomes a `FACT` ledger entry whose source cites its request-record entry (`user, REQUEST_[engagement].md#R2`).
|
|
142
|
+
- Every fact captured becomes a `FACT` ledger entry whose source cites its request-record entry (`user, REQUEST_[engagement].md#R2`). Then run the owner interview (`vision.md` §The owner interview) — Wave 1 gathers the facts, the interview gathers the Vision — and draft `MKT_VISION.md` (Status: DRAFT) from its answers only after the north star is approved in the owner's words.
|
|
143
143
|
- **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.
|
|
144
144
|
|
|
145
145
|
### 3. Research (Situation — external)
|
|
@@ -177,7 +177,12 @@ Cover, across rounds:
|
|
|
177
177
|
them with (seed, not analysis).
|
|
178
178
|
|
|
179
179
|
Skip path: any item already answered by an approved MKT-VISION or earlier
|
|
180
|
-
session record is not re-asked — note where the answer came from.
|
|
180
|
+
session record is not re-asked — note where the answer came from. The skip path
|
|
181
|
+
never covers the MKT-VISION itself: it is written only after the owner interview
|
|
182
|
+
in `vision.md` §The owner interview, with its north star approved first (Gate 1);
|
|
183
|
+
these waves gather the facts, the interview gathers the Vision. The interview is
|
|
184
|
+
a planned occasion like a wave: one numbered set, and only an answer in the wrong
|
|
185
|
+
form is asked again.
|
|
181
186
|
|
|
182
187
|
## Wave 2 — Ambition (phase 5 entry, after research)
|
|
183
188
|
|
|
@@ -49,6 +49,22 @@ exports), `spikes/` (research spikes), `audit/` (handoff).
|
|
|
49
49
|
|
|
50
50
|
## mkt_docs/vision/MKT_VISION.md
|
|
51
51
|
|
|
52
|
+
Until the owner interview (`vision.md` §The owner interview) has an approved north
|
|
53
|
+
star, the file is this stub, and nothing traces to it:
|
|
54
|
+
|
|
55
|
+
```markdown
|
|
56
|
+
---
|
|
57
|
+
description: Marketing vision — awaiting the owner interview.
|
|
58
|
+
status: DRAFT
|
|
59
|
+
---
|
|
60
|
+
# Marketing Vision
|
|
61
|
+
Status: DRAFT
|
|
62
|
+
<!-- STUB: awaiting the owner interview (vision.md §The owner interview). Not a
|
|
63
|
+
Vision: no artifact traces to it. Wave 1 facts live in the evidence ledger. -->
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
After Gate 1, written from the interview's answers:
|
|
67
|
+
|
|
52
68
|
```markdown
|
|
53
69
|
---
|
|
54
70
|
description: Marketing vision — expected benefit, market, non-goals, success signals.
|
|
@@ -56,9 +72,17 @@ status: DRAFT
|
|
|
56
72
|
---
|
|
57
73
|
# Marketing Vision
|
|
58
74
|
Status: DRAFT
|
|
59
|
-
<!-- Status: DRAFT (
|
|
75
|
+
<!-- Status: DRAFT (written from the owner interview, NOT yet a gating authority)
|
|
60
76
|
or APPROVED (by <who>, <date>) — only after the user's explicit confirmation -->
|
|
61
77
|
|
|
78
|
+
## North Star
|
|
79
|
+
<!-- One or two sentences in the owner's words, approved before any other section
|
|
80
|
+
(vision.md §The owner interview, Gate 1): REQUEST_[engagement].md#R<n>. -->
|
|
81
|
+
|
|
82
|
+
## Problem
|
|
83
|
+
<!-- One concrete case that today does not get the expected result, with its
|
|
84
|
+
example (interview question 1). -->
|
|
85
|
+
|
|
62
86
|
## Business Goal
|
|
63
87
|
<!-- the business outcome marketing must serve, in one paragraph. Cite FACTs. -->
|
|
64
88
|
|
|
@@ -67,17 +91,22 @@ Status: DRAFT
|
|
|
67
91
|
|
|
68
92
|
## Market & Audience
|
|
69
93
|
<!-- target market, geography, deliverable language; who we serve (short — the
|
|
70
|
-
detailed ICP lives in strategy/ICP_PERSONAS.md)
|
|
94
|
+
detailed ICP lives in strategy/ICP_PERSONAS.md). Name who receives the
|
|
95
|
+
benefit, who acts, and who has the initiative (interview question 3). -->
|
|
71
96
|
|
|
72
97
|
## Non-Goals
|
|
73
|
-
<!-- what this plan explicitly does NOT pursue (markets, segments, channels)
|
|
98
|
+
<!-- what this plan explicitly does NOT pursue (markets, segments, channels) —
|
|
99
|
+
scope, not a ban on what the business already does.
|
|
74
100
|
The strategy review checks divergence against these. -->
|
|
75
101
|
|
|
76
102
|
## Success Signals
|
|
77
|
-
<!-- how the user recognizes the plan is working, in their words
|
|
103
|
+
<!-- how the user recognizes the plan is working, in their words, each with its
|
|
104
|
+
starting value -->
|
|
78
105
|
|
|
79
106
|
## Constraints
|
|
80
|
-
<!-- budget range [EV-nn], team capacity [EV-nn], legal/brand limits
|
|
107
|
+
<!-- budget range [EV-nn], team capacity [EV-nn], legal/brand limits — each with
|
|
108
|
+
its provenance: owner REQUEST_[engagement].md#R<n>, a FACT, or an inference
|
|
109
|
+
the owner confirmed. -->
|
|
81
110
|
```
|
|
82
111
|
|
|
83
112
|
## mkt_docs/vision/principles.md
|
|
@@ -47,14 +47,67 @@ Four consequences, each operational:
|
|
|
47
47
|
|
|
48
48
|
Extracting the benefit from a discussion is real work: a discourse arrives with
|
|
49
49
|
solutions, preferences and constraints tangled together, and the Vision is the
|
|
50
|
-
distilled benefit only. The
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
actor obtains.
|
|
50
|
+
distilled benefit only. The owner interview below asks for it — and a mechanism
|
|
51
|
+
("a dashboard") is not an acceptable answer to a benefit question ("never lose
|
|
52
|
+
the thread"); ask again until the answer names what the actor obtains.
|
|
54
53
|
|
|
55
54
|
The deletion test decides **which** rules exist. Everything below decides **how**
|
|
56
55
|
to write a rule so it holds once you know it must exist.
|
|
57
56
|
|
|
57
|
+
## The owner interview (before any Vision text)
|
|
58
|
+
|
|
59
|
+
A Vision is the **owner's** statement of what is to be obtained. Nothing in this
|
|
60
|
+
file after this section can detect a Vision the author wrote alone: the blind
|
|
61
|
+
check (§6) tests whether the rules survive a hostile reader, never whether they
|
|
62
|
+
are the owner's. So every Vision is born from an interview of the owner, and its
|
|
63
|
+
north star is approved **before** a line of it is drafted.
|
|
64
|
+
|
|
65
|
+
**Scope — every Vision, in every mode:** `project_vision.md`, a feature
|
|
66
|
+
`VISION_*.md`, a lens Vision (course, marketing), and the devPNT M-VISION in
|
|
67
|
+
Hybrid; also an ANALYSIS `## Feature Vision` that states a benefit no existing
|
|
68
|
+
Vision names (one that cites an approved Vision's benefit is alignment, not a
|
|
69
|
+
Vision). An amendment re-runs the questions whose answers it changes, and Gate 1
|
|
70
|
+
again when the north star changes. **There is no skip path**: one sentence from
|
|
71
|
+
the user plus a spike is not a complete spec — that exact shortcut produced a
|
|
72
|
+
Vision with an imported prohibition, no north star and a missing actor, and four
|
|
73
|
+
downstream artifacts built on it (field case, 2026-10). A reply already on record
|
|
74
|
+
in the owner's words is read back for confirmation, never re-asked as an open
|
|
75
|
+
question; an answer the author derived (from a spike, the code, another Vision)
|
|
76
|
+
is never an answer — it is a proposal the owner confirms or rejects.
|
|
77
|
+
|
|
78
|
+
**The questions, in this order.** Each is repeated until its answer has the form
|
|
79
|
+
stated; the wrong form is named so it can be recognized and asked again.
|
|
80
|
+
|
|
81
|
+
| # | Question | Right form | Wrong form — ask again |
|
|
82
|
+
|---|---|---|---|
|
|
83
|
+
| 1 | **Problem** — which concrete case today does not get the expected result? | one real case, with an example | a missing feature ("there is no drawing tool") |
|
|
84
|
+
| 2 | **Benefit** — once solved, who obtains what? | a result for a named actor | a function or mechanism ("a renderer") |
|
|
85
|
+
| 3 | **Actors** — who receives the benefit, who acts, who has the initiative? | all three named, initiative included | only the one who asks — the actor who acts unprompted goes missing |
|
|
86
|
+
| 4 | **Success** — what observable signal shows the benefit arrived? | a signal with its starting value | a feeling, or a signal with no baseline |
|
|
87
|
+
| 5 | **Boundaries** — what does this NOT pursue? | scope excluded from this work | a ban on behaviour ("X must never happen") — that is a constraint (6) or an obligation (2, 4) |
|
|
88
|
+
| 6 | **Known constraints** — each with its provenance: owner, a quoted line of a higher Vision, or author inference | every constraint sourced; every inference asked here | a constraint written in silently, or imported from a higher Vision without asking whether it applies here |
|
|
89
|
+
|
|
90
|
+
A **Non-Goal bounds scope**: it rejects a proposal that pursues what it names; it
|
|
91
|
+
is not a ban on behaviour that already exists, and it creates no obligation.
|
|
92
|
+
Obligations come from the Benefit and the Success Signals.
|
|
93
|
+
|
|
94
|
+
**Gate 1 — north star.** One or two sentences, in the owner's words, explicitly
|
|
95
|
+
approved by the owner. The author may compose a wording from the answers; the
|
|
96
|
+
approval is of that exact text, recorded verbatim in the request record
|
|
97
|
+
(`audit/requests/REQUEST_[unit].md`; a Vision written outside any unit, such as
|
|
98
|
+
the project Vision after bootstrap, records its interview in
|
|
99
|
+
`audit/requests/REQUEST_project_vision.md`). **Without it no Vision text is written** —
|
|
100
|
+
not a DRAFT, not a reconstruction: bootstrap writes a stub awaiting the
|
|
101
|
+
interview, and what the agent observed goes to `strategic/`.
|
|
102
|
+
Unattended, the unit is `BLOCKED on the user` (`elicitation.md` Unattended path).
|
|
103
|
+
|
|
104
|
+
**Gate 2 — the full Vision**, written from the answers. Every section traces to
|
|
105
|
+
an answer or a stated provenance (`REQUEST_[unit].md#R<n>`); every rule carries
|
|
106
|
+
its provenance; an author inference the owner did not confirm is not in it. The
|
|
107
|
+
blind check (§6) verifies that it holds; the approved north star verifies that it
|
|
108
|
+
is the owner's. Promotion to APPROVED still needs the owner's explicit
|
|
109
|
+
confirmation — Gate 2 is that confirmation, given on the written text.
|
|
110
|
+
|
|
58
111
|
## 0. The one-line test
|
|
59
112
|
|
|
60
113
|
> Could a reader who has never seen this project rule ACCEPT or REJECT on a
|
|
@@ -138,7 +191,14 @@ rule that survived and the same rule leaking.
|
|
|
138
191
|
This is the most common structural failure and it is invisible from the inside.
|
|
139
192
|
|
|
140
193
|
- **A Goal cannot reject anything.** If the admission test says "advances a Goal
|
|
141
|
-
and violates no Non-Goal", then rejection power lives *only* in the Non-Goals
|
|
194
|
+
and violates no Non-Goal", then rejection power lives *only* in the Non-Goals
|
|
195
|
+
(and the Invariants, where the Vision has them).
|
|
196
|
+
- **A Non-Goal rejects scope, not behaviour.** It turns away a proposal that
|
|
197
|
+
pursues what it names; it never forbids a behaviour the product already has, and
|
|
198
|
+
it never creates an obligation — obligations come from the Benefit and the
|
|
199
|
+
Success Signals. A behaviour the product must never have is an Invariant, or a
|
|
200
|
+
constraint with its provenance (§The owner interview, question 6). Written as a
|
|
201
|
+
Non-Goal, it reads as a ban the owner never stated.
|
|
142
202
|
A Goal that says "scale cost to risk in both directions" cannot stop cost
|
|
143
203
|
inflation — you need a prohibition for that.
|
|
144
204
|
- **A prohibition scoped to one rung of your own scale protects only that rung.**
|
|
@@ -204,7 +264,10 @@ it.
|
|
|
204
264
|
## 6. The blind check (procedure)
|
|
205
265
|
|
|
206
266
|
Run this **before promoting any Vision to APPROVED, and before any amendment of an
|
|
207
|
-
approved one**.
|
|
267
|
+
approved one**. It runs on a Vision that already passed Gate 1 (§The owner
|
|
268
|
+
interview): it tests whether the rules hold against a hostile reader, and it
|
|
269
|
+
cannot see whether they are the owner's — a Vision the author wrote alone passes
|
|
270
|
+
it cleanly. Not for DRAFT edits — promotion is when authority is granted, and
|
|
208
271
|
it is rare, so the cost lands where it buys most.
|
|
209
272
|
|
|
210
273
|
1. **Give the reviewer the document text and nothing else.** Not a path — the
|