foundation-persona
# ClaudeWave: foundation-persona The foundation-persona skill generates structured product or marketing personas using a standardized v2.5 template, with explicit confidence ratings tied to available evidence. Use it when teams need a behavior-grounded perspective to align on user priorities, stress-test product decisions, or frame go-to-market strategy before drafting requirements, messaging, or enablement materials.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/foundation-persona && cp -r /tmp/foundation-persona/skills/foundation-persona ~/.claude/skills/foundation-personaSKILL.md
<!-- 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.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines 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.
Creates 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.
Creates 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.
Run 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.
Creates 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.
Generates 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.
Documents 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.