Author a shaped slice's marketing lens as an MD grounding doc — discoverability (SEO + AEO + GEO), accessibility (moved here from the profile), and marketing analytics — from the slice's hub (its functionalities' grounding docs + the spine profile) and KB grounding. An internal tool behind auth says "SEO/AEO/GEO not applicable" plainly, with the reason. Under direct-model-write (ADR 026) it writes the slice's marketing.md STRAIGHT to the live model (a re-derive) and emits any material decisio...
Installs into .claude/skills of the current project.
Are you the author of Author Marketing Lens?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/kapilvirenahuja-author-marketing-lens)
---
name: author-marketing-lens
description: Author a shaped slice's marketing lens as an MD grounding doc — discoverability (SEO + AEO + GEO), accessibility (moved here from the profile), and marketing analytics — from the slice's hub (its functionalities' grounding docs + the spine profile) and KB grounding. An internal tool behind auth says "SEO/AEO/GEO not applicable" plainly, with the reason. Under direct-model-write (ADR 026) it writes the slice's marketing.md STRAIGHT to the live model (a re-derive) and emits any material decision plus the grounding map as structured data in a manifest; it reads the functionality.md docs for the hub, never another lens, and never writes the spine, the profile, the slice record, or a decision file. Generative artifact production for the /marketing play.
version: 0.2.0
user-invocable: false
model: opus
allowed-tools: Read, Write, Bash, Glob
---
# author-marketing-lens
Turns a shaped slice's **hub** — the grounding docs of the functionalities it bundles, plus the
product profile — into the slice's **marketing lens**, written as the grounding doc
`marketing.md`: how the slice is found and reached (SEO / AEO / GEO), the accessibility bar it
meets, and the reach/usage signals worth capturing. An internal tool behind auth answers
discoverability with "not applicable — behind auth", plainly and with the reason. It reads the
hub only (never another realize lens).
**Direct-model-write (ADR 026, `standards/rules/direct-model-write.md`).** This skill writes ONLY
the per-node lens doc `marketing.md` — straight to the **live model** under
`<product_base>product-os/…/slices/<slice>/lens/marketing.md` (a re-derive: it overwrites a prior
marketing lens for this slice). It writes NO shared model file: it never writes the spine
(`_spine.yaml`), the profile, the slice record, another lens, or a `decisions/*.yaml` file. Any
material marketing decision is emitted as **structured data in the manifest** — the play's keyed
persist script (`persist_marketing.py`) reads the manifest and writes the decision file, add-only,
keyed to the slice. The play's post-write scoped guard and single human checkpoint gate and commit
the change; this skill neither commits nor persists a shared file.
## What it produces (against the locked template)
`marketing.md` conforms to `standards/schemas/product-os/grounding/lens/marketing.md` — H1
`# Marketing Lens`, sections **Intent** (who needs to find/reach this slice, and why), **Discoverability**
(SEO / AEO / GEO, or why not applicable), **Accessibility** (the bar — e.g. WCAG level — and how the
slice meets it; this MOVED here from the profile), **Marketing analytics** (reach/conversion or, for an
internal tool, usage signals). It must clear the linter (shape) and the content-quality eval (the play
runs both). Alongside it, a structured `marketing-manifest.yaml` (STM, non-model) carries the
machine-checkable grounding the prose can't — which functionalities the assessment is grounded in, any
material choice, and any material decision as a full record for the keyed persist to write.
## Inputs
| Field | Required | Description |
|-------|----------|-------------|
| `slice_ref` | yes | `{domain}/{slice-id}` — display reference and the containment key the keyed persist enforces. |
| `slice_file` | yes | Path to the live slice record (read-only — for the functionalities it bundles and its surfaces). |
| `functionality_groundings` | yes | Paths to each functionality's `functionality.md` grounding doc (the hub, resolved by `check_ready_slice`). Read these for behavior/acceptance — NOT `ice.yaml` (retired). |
| `profile` | yes | The product profile (from the spine) — conditions + surfaces (stage / users / monetization). Read-only. |
| `kb_search` | yes | Path to the KB search script, for discoverability/accessibility-pattern grounding. |
| `kb_root` | yes | Path to `knowledge/`, to resolve learning ids. |
| `product_base` | yes | Product model root — the skill writes `marketing.md` IN PLACE under `<product_base>product-os/`. |
| `lens_rel` | yes | Relative path the lens is written at: `product-os/{domain}/slices/{slice}/lens/marketing.md`. |
| `manifest_path` | yes | Output path for `marketing-manifest.yaml` under STM (grounding map + any decision). |
| `proposals_dir` | yes | STM dir for KB-learning-gap proposals (the play resolves `<working>/proposals/`; the skill never reconstructs it). |
| `stm_base` | yes | From config. |
## Procedure
Reasoning (the reach verdict, the accessibility bar, the signals worth capturing) is yours.
Template conformance, grounding, honesty, and the write discipline are non-negotiable.
1. **Read the hub.** Load each functionality's `functionality.md` (its behavior, who it serves) and
the profile (stage / users / monetization / surfaces). Do NOT read any other lens.
2. **Frame the intent.** Who needs to find or reach this slice's surface, and why. An internal tool
says so plainly — it scopes the rest.
3. **Assess discoverability.** SEO (search), AEO (answer engines), GEO (generative engines): how the
slice's surface is made findable/answerable, OR why it's not applicable (behind auth, internal),
grounded in the profile's stage/users/monetization. Never invent public-marketing where there's none.
4. **Set the accessibility bar.** The standard the slice meets (e.g. WCAG 2.1 AA) and HOW it meets it —
concrete. This is now the lens's job, not the profile's.
5. **Name the analytics.** The reach/conversion signals (or internal usage signals) worth capturing, each
with why it matters and what it feeds.
6. **Write the lens to the live model.** Write `marketing.md` to `<product_base>/<lens_rel>` (per the
template) — straight to the live tree, a re-derive that overwrites any prior marketing lens for this
slice. Write NOTHING else on the live tree — no spine, no profile, no slice record, no decision file.
7. **Emit the manifest.** Write `marketing-manifest.yaml` to `manifest_path` (STM): the functionalities
the assessment grounds in; any material choice; and any material marketing decision as a full record
under `decisions:` for the keyed persist to write. Write any KB proposals under `<working>/proposals/`.
## Output
Written IN PLACE on the live model:
```
<product_base>/product-os/{domain}/slices/{slice}/
lens/marketing.md # the Marketing lens grounding doc (re-derive)
```
Written to STM (non-model), returned by path:
```
{manifest_path} # marketing-manifest.yaml — grounding map + any decision
<working>/proposals/<gap>.yaml # KB-learning-gap proposals (only if gaps)
```
`marketing-manifest.yaml`:
```yaml
marketing:
slice_ref: token-dash/slice-trusted-coverage
discoverability: not-applicable # public | not-applicable (with the reason in the doc)
accessibility: "WCAG 2.1 AA"
grounds: # the functionalities the assessment considered
- { source_type: functionality, source: "func-source-usage-ingest", functionality_ref: func-source-usage-ingest }
- { source_type: functionality, source: "func-dashboard-presentation", functionality_ref: func-dashboard-presentation }
choices: [] # KB-grounded discoverability/accessibility choices (if any)
decisions: [] # material marketing decisions as full records (the keyed persist writes them);
# each entry's node_ref MUST be this slice_ref
```
Each `decisions` entry is a full decision record (id, node_ref == this `slice_ref`, level, title,
reason, alternatives, status, superseded_by, metadata) — the keyed persist writes it to the slice's
`decisions/` add-only, and refuses any record naming another slice. Return the enriched contract with
the `lens_rel` (live path) and `manifest_path` — paths, never inline content.
## Rules
- **Direct-model-write.** Write ONLY `marketing.md` to the live tree; emit any decision as manifest data —
never write `_spine.yaml`, the profile, the slice record, another lens, or a `decisions/*.yaml` file.
- **Hub only.** Derive from the functionalities' grounding docs + the profile; never read or ground on
another realize lens.
- **Template-true.** `marketing.md` conforms to the Marketing lens template (Intent / Discoverability /
Accessibility / Marketing analytics) and must clear the linter + the content eval — every item
self-explaining.
- **Honest reach.** An internal tool behind auth says "SEO/AEO/GEO not applicable" with the reason; never
invent public-marketing where there is none.
- **Accessibility lives here.** Set the concrete accessibility bar and how the slice meets it — it moved
out of the profile into this lens.
- **Cover the hub.** The assessment considers every functionality the slice bundles, recorded in the
manifest grounds.
- **Grounded, not invented.** Discoverability and accessibility choices ground in a KB learning or a
proposal; any material choice is emitted as a decision record in the manifest, keyed to this slice.