foundation-persona

$npx mdskill add product-on-purpose/pm-skills/foundation-persona

Generates persona for product or marketing decisions

  • Identifies user needs and behaviors to inform decision-making.
  • Deploys canonical template pack to produce personas in `product` or `marketing` modes.
  • Analyzes evidence to calibrate personas, ensuring they are grounded in data.
  • Outputs persona for review and use in drafting PM or GTM artifacts.

SKILL.md

.github/skills/foundation-personaView on GitHub ↗
---
name: foundation-persona
description: Generates an evidence-calibrated product or marketing persona using the canonical v2.5 output contract. Use when shaping artifact perspective, stress-testing decisions, or framing product and GTM strategy.
license: Apache-2.0
metadata:
  classification: foundation
  version: "2.6.0"
  updated: 2026-06-10
  category: research
  frameworks: [triple-diamond, lean-startup, design-thinking]
  author: product-on-purpose
---
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Persona Builder

This skill produces decision-usable personas from one canonical template pack.

## Supported Modes

- `product`
- `marketing`
- `buyer` as input alias for `marketing` (output remains labeled `Marketing`)

Generated `agent` mode is out of scope for `v2.5.0`.
If the user asks for `agent`, ask them to choose `product` or `marketing`.

## When to Use

- Before drafting PM or GTM artifacts that need a clear persona viewpoint
- When teams disagree on priorities and need behavior-grounded tradeoff framing
- When assumptions and confidence levels must be explicit for decision review
- When tailoring downstream work (PRD, stories, launch, messaging, enablement) to a specific user or buyer profile

## When NOT to Use

- You need the job context rather than the person -> use `define-jtbd-canvas`; the canvas captures what customers hire products to do, the persona captures who they are
- You are mapping internal stakeholders, not customers -> use `discover-stakeholder-summary`
- You have raw interviews to synthesize first -> use `discover-interview-synthesis`; a persona built on unsynthesized notes inherits their noise
- No evidence exists at all and a real decision rides on the persona: gather research first; the skill labels assumptions honestly but cannot substitute for evidence

## Instructions

When asked to generate a persona, follow these steps:

1. **Resolve mode and intent**
   Determine whether the request is `product` or `marketing` (`buyer` alias allowed).
   If mode is omitted, ask for mode selection.
   If execution must continue without reply, default to `product` and state that fallback explicitly.

2. **Collect context and evidence**
   Use user-provided context first (goals, audience, domain, constraints, sources).
   If evidence is thin, continue generation but mark gaps and calibrate confidence.

3. **Select exactly one template**
   Use `references/TEMPLATE.md` and choose exactly one of:
   - `Product Persona Template`
   - `Marketing Persona Template`

4. **Generate a complete artifact**
   Fill the selected template end-to-end:
   - header + one-sentence core-reality statement
   - metadata table
   - `Persona Card`
   - sections `1` through `11`
   - `Evidence & Confidence`

5. **Enforce mode boundaries**
   - Product mode: focus on workflow behavior, decision patterns, friction, quality bar, and product tradeoffs.
   - Marketing mode: focus on buying triggers, evaluation criteria, committee dynamics, objections, messaging, and GTM implications.

6. **Apply evidence and confidence policy**
   - Use `High|Medium|Low` confidence with rationale.
   - Distinguish validated evidence from assumptions.
   - State open questions and governance follow-up.

7. **Finalize for direct use**
   Remove template guidance blockquotes (`>` notes) from the final output.
   Ensure narrative entries are concrete and decision-changing, not placeholder bullets.

## Output Contract (v2.5.0)

- Use one mode only (`Product` or `Marketing`) per output.
- Keep section numbering and headings from the selected template.
- Preserve the evidence table plus validated/assumed/open-questions/governance blocks.

## Quality Checklist

Before finalizing, verify:

- [ ] Exactly one mode is used and clearly labeled
- [ ] `buyer` inputs are normalized to `Marketing`
- [ ] Header, core-reality statement, metadata table, and `Persona Card` are present
- [ ] All `1` through `11` sections from the selected template are present and complete
- [ ] Includes/not-valid boundaries are explicit in the metadata and narrative
- [ ] Evidence table is populated with concrete sources
- [ ] Confidence is `High`, `Medium`, or `Low` with rationale
- [ ] `Validated`, `Assumed`, `Open questions`, and `Governance` blocks are present
- [ ] Template authoring notes (`>` guidance lines) are removed from the completed output

## Examples

See `references/EXAMPLE.md` for a completed sample output.

More from product-on-purpose/pm-skills

SkillDescription
define-hypothesisDefines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
define-jtbd-canvasCreates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
define-opportunity-treeCreates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
define-prioritization-frameworkRun applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
define-problem-statementCreates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
define-xFixture skill for phase-map and phase-router tests.
deliver-acceptance-criteriaGenerates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
deliver-edge-casesDocuments edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.
deliver-launch-checklistCreates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.
deliver-prdCreates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.