Product Context
Create a small, durable context artifact that lets later product work start from evidence instead of generic positioning.
Use When
- entering marketing, content, SEO, analytics, sales, or launch work in a repo;
- the product, audience, conversion action, or proof boundary is unclear;
- existing public copy and internal product behavior have drifted.
Workflow
- Read existing product docs, public copy, analytics contracts, and relevant implementation surfaces.
- Separate confirmed facts from assumptions, placeholders, and claims needing owner confirmation.
- Draft or update
docs/product-context.md unless the repo already defines a better canonical path.
- Keep only: product and audience, jobs and conversion action, terminology, proof and known limits, approved voice, prohibited claims, source surfaces, and last-reviewed date.
- Ask for confirmation where positioning, ICP, pricing, competitor claims, or proof cannot be established from the repo.
- Link future work to the context; do not treat it as permission to publish, spend, contact people, or change product behavior.
Guardrails
- Never invent customer quotes, metrics, market position, availability, pricing, partner status, or legal/compliance claims.
- Keep personal data and private sales evidence out of a committed context file.
- Treat a product context as a reviewable input, not a source of truth over code, current policy, or human direction.
- Preserve domain-specific safety language such as financial, booking, or approval boundaries.
Output Shape
Use these headings where applicable: Product, Audience and jobs, Conversion action, Proof and limits, Language, Claim boundaries, Source surfaces, Maintenance.
Pair With
evidence-ledger-research for external facts;social-publishing-gate before distribution;bounded-growth-loop before recurring optimization;loop-readiness-review before scheduling any loop.
Provenance
Adapted from the shared-context architecture in coreyhaines31/marketingskills, narrowed to evidence-backed, product-neutral context with explicit claim boundaries.
1---2name: product-context3description: Build or refresh a compact, evidence-backed product context before marketing, positioning, SEO, analytics, sales-enablement, or launch work. Use when an agent needs to understand the product, audience, proof, conversion goal, terminology, and claim boundaries without inventing commercial facts.4license: MIT5---67# Product Context89Create a small, durable context artifact that lets later product work start from evidence instead of generic positioning.1011## Use When1213- entering marketing, content, SEO, analytics, sales, or launch work in a repo;14- the product, audience, conversion action, or proof boundary is unclear;15- existing public copy and internal product behavior have drifted.1617## Workflow18191. Read existing product docs, public copy, analytics contracts, and relevant implementation surfaces.202. Separate confirmed facts from assumptions, placeholders, and claims needing owner confirmation.213. Draft or update `docs/product-context.md` unless the repo already defines a better canonical path.224. Keep only: product and audience, jobs and conversion action, terminology, proof and known limits, approved voice, prohibited claims, source surfaces, and last-reviewed date.235. Ask for confirmation where positioning, ICP, pricing, competitor claims, or proof cannot be established from the repo.246. Link future work to the context; do not treat it as permission to publish, spend, contact people, or change product behavior.2526## Guardrails2728- Never invent customer quotes, metrics, market position, availability, pricing, partner status, or legal/compliance claims.29- Keep personal data and private sales evidence out of a committed context file.30- Treat a product context as a reviewable input, not a source of truth over code, current policy, or human direction.31- Preserve domain-specific safety language such as financial, booking, or approval boundaries.3233## Output Shape3435Use these headings where applicable: `Product`, `Audience and jobs`, `Conversion action`, `Proof and limits`, `Language`, `Claim boundaries`, `Source surfaces`, `Maintenance`.3637## Pair With3839- `evidence-ledger-research` for external facts;40- `social-publishing-gate` before distribution;41- `bounded-growth-loop` before recurring optimization;42- `loop-readiness-review` before scheduling any loop.4344## Provenance4546Adapted from the shared-context architecture in `coreyhaines31/marketingskills`, narrowed to evidence-backed, product-neutral context with explicit claim boundaries.
markoblogo