Skip to content
pm-skills

Foundation Sprint Skills Contract

Status: Canonical (enforced by CI) Version: 0.3.0 Applies to: tool-foundation-sprint-readiness, tool-foundation-sprint-brief, tool-foundation-sprint-basics, tool-foundation-sprint-differentiation, tool-foundation-sprint-approach-options, tool-foundation-sprint-magic-lenses, tool-foundation-sprint-founding-hypothesis Last updated: 2026-05-16

v0.3.0 changes from v0.2.0 (from 2026-05-16 user-clarified naming discipline):

  • Added Naming Discipline section codifying the qualified-naming style rule for “Foundation Sprint” vs bare “sprint” (which collides with agile / Scrum sprint terminology in PM contexts). Style guidance; not validator-enforced.

v0.2.0 changes from v0.1.0 (all from 2026-05-15 Codex adversarial review acceptance):

  • Library sample requirements made version-tiered (F32): v0.1.0 requires Brainshelf; v1.0.0 requires all 3 threads. With this v0.2.0 contract the FS family ships Brainshelf + Storevine + Workbench (24 samples).
  • Frameworks metadata field clarified as subset (F13): foundation-sprint REQUIRED; click + character-note-and-vote present when the skill body draws on those sources. Previously the example implied a fixed 3-element list.
  • CI enforcement list reorganized to separate family-level checks from per-member checks (F10); validator coverage gaps explicitly documented for future v0.3.0/v1.0.0 promotion.

What this document is

This is the shared behavioral and structural contract that governs all 7 skills in the pm-skills Foundation Sprint family. It defines what they have in common: the frontmatter they emit, the directory and file naming they use, the Decider Checkpoint pattern they all enforce, the library sample requirements they each meet, and the relationship between the family and the broader pm-skills tool classification.

Individual SKILL.md files implement the per-skill behavior (what they produce, how their process differs); this document defines what they share. A skill in this family is not conforming to the family unless it conforms to this contract.

Enforcement: the scripts/validate-foundation-sprint-skills-family.sh validator (and its PowerShell parity) runs against every PR touching skills/tool-foundation-sprint-*/ and fails the build if the contract is violated.

Why a family contract exists

The Foundation Sprint is a workshop methodology with a fixed two-day arc. The 7 skills implement the 7 canonical moves of that arc. If each skill were implemented independently, the family would drift: differentiation might omit the Decider Checkpoint, founding-hypothesis might use a different frontmatter shape, readiness might not reference the canonical Knapp/Zeratsky sources. The family contract makes the shared surface explicit and enforceable so the skills compose cleanly across a real sprint and across the library samples that demonstrate them.

The contract also makes the family’s relationship to the broader classification: tool taxonomy explicit. Tool skills represent named external methodologies; the foundation-sprint family is the first inhabitant of that lane.

The 7 skills at a glance

SkillMoveTimeboxDay-and-section
tool-foundation-sprint-readinessreadiness30-45 minPre-sprint
tool-foundation-sprint-briefbrief45-60 minPre-sprint
tool-foundation-sprint-basicsbasics90-120 minDay 1 morning
tool-foundation-sprint-differentiationdifferentiation120-180 minDay 1 afternoon
tool-foundation-sprint-approach-optionsapproach-options60-90 minDay 2 morning
tool-foundation-sprint-magic-lensesmagic-lenses90-120 minDay 2 afternoon
tool-foundation-sprint-founding-hypothesisfounding-hypothesis30-45 minDay 2 end

All 7 are classified tool (the methodology-bound classification added 2026-05-13), with metadata.tool: foundation-sprint.

How they chain

The canonical Foundation Sprint arc:

readiness  ->  brief  ->  basics  ->  differentiation  ->  approach-options  ->  magic-lenses  ->  founding-hypothesis
   (prep)     (prep)    (Day 1 AM)    (Day 1 PM)         (Day 2 AM)            (Day 2 PM)         (Day 2 end)

Each step’s bundled output becomes the next step’s primary input. metadata.prerequisites in each SKILL.md lists the upstream skills whose outputs the skill expects (advisory, not enforced by validator).

tool-note-and-vote is invoked many times throughout the arc at decision moments. It is not a family member; it is a standalone tool referenced inline by family-member SKILL.md files.

Cross-family note: Foundation-to-Design transition

There is no bridge skill in this family. When a Foundation Sprint’s Founding Hypothesis is the input to a downstream Design Sprint, the handoff is narrative content in _workflows/foundation-to-design.md and in docs/guides/using-foundation-sprint.md. Canonical Knapp/Zeratsky methodology has no formal handoff move; pm-skills does not invent one.

Frontmatter contract

Every family-member SKILL.md MUST emit the following frontmatter shape. The split between root-level fields and metadata-nested fields is intentional and enforced.

Root-level fields (required)

name: tool-foundation-sprint-<move>
description: <one-line description with Use-when triggers; 20-100 words>
classification: tool
version: "X.Y.Z"
updated: YYYY-MM-DD
license: Apache-2.0

Root-level fields are universal pm-skills frontmatter. phase is NOT permitted on tool-classified skills (mirrors foundation/utility behavior).

Metadata-nested fields (required unless otherwise noted)

metadata:
  tool: foundation-sprint
  move: <kebab-case move identifier; see "The 7 skills at a glance" table>
  category: <see docs/reference/categories.md>
  frameworks: <subset of [foundation-sprint, click, character-note-and-vote]; foundation-sprint REQUIRED; click present when the skill draws on Click book content; character-note-and-vote present when the skill body uses the note-and-vote mechanic>
  timebox_minutes: <integer; per spec timebox>
  roles: <array of: facilitator, decider, pm, design, engineering, researcher, customer-expert, whole-team>
  prerequisites: <array of skill names; optional; semantics defined below>
  inputs: <array of input artifacts the skill consumes>
  outputs: <array of output artifacts the skill produces>
  author: product-on-purpose

Prerequisite semantics

The metadata.prerequisites array lists recommended-but-not-required upstream skills. The family validator does NOT block invocation when prerequisites are missing. The skill body documents what happens when a prerequisite output is absent (typically: skill prompts the user to confirm equivalent context). Multi-prerequisite cases (e.g., readiness OR equivalent context) are captured as an array of all valid upstream skill names; the skill body explains the OR logic in its “When to use” section.

Naming discipline (workshop sprints vs agile sprints)

The word “sprint” is overloaded in product management contexts. Most readers will assume “sprint” = agile / Scrum iteration cycle first; Foundation Sprint and Design Sprint are different methodologies (workshop sprints from Knapp/Zeratsky/Kowitz) that happen to share the word. To prevent reader confusion, this family contract codifies the following naming discipline for all pm-skills documentation that touches Foundation Sprint content:

  1. Always include the full method name on first reference per document. “Foundation Sprint” on first mention; “the Foundation Sprint” or “your Foundation Sprint output” thereafter is acceptable but qualified forms are preferred.
  2. Prefer qualified terms over bare “sprint” in body prose. “The Foundation Sprint week” beats “the sprint week”; “your Founding Hypothesis from the Foundation Sprint” beats “your hypothesis from the sprint”.
  3. Reserve bare “sprint” for agile / Scrum iteration context only. When discussing agile sprints in pm-skills documentation, prefer “agile sprint” or “Scrum sprint” if there is any chance the surrounding context could be confused with workshop sprints.
  4. Cross-link to the disambiguation reference when reader confusion is likely. Link to docs/concepts/workshop-sprints-vs-agile-sprints.md at the top of any doc that introduces Foundation Sprint to readers who may carry agile-sprint assumptions.

Rationale: pm-skills audience is PMs who work in agile environments AND use Knapp methodology. The word “sprint” is overloaded in their mental model. The naming discipline prevents readers from carrying agile-sprint assumptions into workshop-methodology content.

This rule is style guidance, NOT validator-enforced. Reviewers should flag bare “sprint” usage in PRs when context is ambiguous. The same discipline applies to the parallel design-sprint-skills-contract.md v0.2.0+.

Naming convention

LayerPattern
Directoryskills/tool-foundation-sprint-{move}/
SKILL name fieldMatches directory name
Slash command/tool-foundation-sprint-{move}
Library sample directorylibrary/skill-output-samples/tool-foundation-sprint-{move}/
Library sample filenamesample_tool-foundation-sprint-{move}_{thread}_{scenario}.md

The {move} token always matches metadata.move exactly. The validator enforces this.

File anatomy

Every family-member skill directory MUST contain three files:

skills/tool-foundation-sprint-<move>/
  SKILL.md
  references/
    TEMPLATE.md
    EXAMPLE.md
  • SKILL.md contains the skill body: when to use, when NOT to use, zero-friction execution flow, common pitfalls, Decider role guidance, references to canonical sources.
  • TEMPLATE.md contains the skeleton of the bundled output the skill produces. Every TEMPLATE.md MUST end with a ## Decider Checkpoint section (see below).
  • EXAMPLE.md contains a single fully-filled instance of the template. Use the Brainshelf, Storevine, or Workbench thread from the library samples; pick the strongest match per skill.

Decider Checkpoint requirement

Every TEMPLATE.md in this family MUST end with a ## Decider Checkpoint section. The validator enforces:

  1. The literal heading ## Decider Checkpoint (any level 1-6 hash count) is present.
  2. The section appears in the last 25% of TEMPLATE.md (positionally near the end).

The Decider Checkpoint section captures the explicit sign-off that closes that move’s contribution to the sprint. Without it, the team can complete the move’s activities without committing to the output, and the sprint loses decision discipline.

Recommended Decider Checkpoint structure:

## Decider Checkpoint


**Decider sign-off required before [next move].**


- [ ] [First explicit confirmation, e.g., "Decider confirms target customer is specific enough to design for"]
- [ ] [Second explicit confirmation]
- [ ] [Third explicit confirmation]
- [ ] [Acknowledgement of constraints or what is being chosen against]


**Signed:** [Decider name and role], [ISO date and local time]

SKILL.md must reference the Decider Checkpoint at appropriate decision points in its instructions.

Library sample requirements

Each family-member skill ships library samples in library/skill-output-samples/tool-foundation-sprint-{move}/ following the canonical 3-thread structure:

ThreadScenarioSample filename
Brainshelfbook-catalogsample_tool-foundation-sprint-{move}_brainshelf_book-catalog.md
Storevineretail-directionsample_tool-foundation-sprint-{move}_storevine_retail-direction.md
Workbenchdebugging-toolchainsample_tool-foundation-sprint-{move}_workbench_debugging-toolchain.md

Coverage requirements by contract version:

  • v0.1.0 (current; SHIPPED in v2.15.0): Brainshelf thread REQUIRED for all 7 family members. Storevine and Workbench threads RECOMMENDED. This matches the v2.11.0 meeting-skills-family precedent where the 3-thread arc was introduced incrementally; “functionally shippable” means the canonical Brainshelf arc exists end-to-end. (Note: 3-thread coverage was authored in v2.15.0 Phase 5 alongside Brainshelf to match precedent, exceeding the v0.1.0 minimum.)
  • v1.0.0 (future): All 3 threads REQUIRED for all family members. Promote when both Storevine and Workbench arcs are authored and the family validator can enforce the 3-thread check.

When a sample is authored, it MUST tell a coherent story across the 7-skill arc for its thread. The Brainshelf basics sample’s customer becomes the Brainshelf differentiation sample’s input; that differentiation becomes the Brainshelf magic-lenses input; and so on through the Founding Hypothesis. The same is true for Storevine and Workbench when those threads are completed.

Zero-friction execution behavior

Every family-member skill is a single-invocation skill. When invoked, it reads whatever input is provided, runs the move’s activities (potentially with inline tool-note-and-vote invocations), produces the bundled output described in its TEMPLATE.md, and ends with the Decider Checkpoint section requiring explicit sign-off.

The skill does NOT block on multi-turn interrogation. It does NOT require all inputs upfront. It does run an inference pass on missing context and surfaces inferences in the output so the Decider can correct them at checkpoint time.

Versioning policy

Each family-member skill version is independent and follows pm-skills SemVer (version: in root frontmatter). The family contract itself has its own version (declared at the top of this document) and follows the same SemVer rules:

  • Patch (0.1.0 to 0.1.1): clarifications, typo fixes, error message wording changes that do not alter validator behavior.
  • Minor (0.1.0 to 0.2.0): new optional frontmatter fields, new optional checks, new family member added.
  • Major (0.1.0 to 1.0.0): breaking frontmatter changes, removed required fields, changed enforcement of an existing check.

Validator behavior changes that affect ship-readiness are major-bumps.

CI enforcement

ValidatorScope
scripts/validate-foundation-sprint-skills-family.shBash; runs on every PR touching skills/tool-foundation-sprint-*/
scripts/validate-foundation-sprint-skills-family.ps1PowerShell parity; runs on every PR on Windows runners
scripts/lint-skills-frontmatter.sh and .ps1Universal frontmatter checks (classification, version, license, etc.)
scripts/validate-agents-md.sh and .ps1AGENTS.md sync (enumerates skills/tool-* directories automatically)

The family validator enforces these checks once any skill is authored:

Family-level (1 check): 0. Canonical contract document (this file) exists at docs/reference/skill-families/foundation-sprint-skills-contract.md

Per family member (6 checks):

  1. Directory contains SKILL.md + references/TEMPLATE.md + references/EXAMPLE.md
  2. SKILL.md classification is tool
  3. SKILL.md metadata.tool is foundation-sprint
  4. SKILL.md metadata.move matches the expected kebab-case identifier for the skill slug
  5. SKILL.md references the canonical contract path (this document)
  6. TEMPLATE.md contains a Decider Checkpoint section in the last 25% of the file

In scaffolding state (zero family skills authored), the validator exits 0 with notices. This permits the family contract to land before the first skill ships, mirroring the meeting-skills precedent.

Validator coverage gap (v0.1.0): the contract specifies additional clauses that the v0.1.0 validator does not enforce: full root-field and metadata-field shape checks (F1/F2 from the 2026-05-15 adversarial review), library-sample 3-thread coverage (F4; gated on the v0.1.0 -> v1.0.0 promotion), and prerequisite-fallback content shape (F6/F15). The universal lint-skills-frontmatter provides the floor for root-field shape; the gap is documented and scheduled for v2.16 validator expansion.

Relationship to other families

FamilyClassificationRelationship
foundation-sprint-skills (this contract)toolFoundation Sprint methodology (7 skills)
design-sprint-skillstoolDesign Sprint methodology (7 skills); narrative handoff from this family
meeting-skillsfoundationCross-cutting meeting artifacts (5 skills)

The Foundation Sprint family produces a single coherent strategic artifact (the Founding Hypothesis). It does NOT compose with meeting-skills directly (a sprint is not a meeting). It does compose with the design-sprint-skills family via the narrative handoff documented in _workflows/foundation-to-design.md.

Future tool families (JTBD process, Double Diamond, Shape Up, etc.) would follow this contract’s pattern: one classification value (tool), one family per named methodology, one validator pair per family, one contract per family.

Change log

VersionDateChange
0.1.02026-05-14Initial contract authored alongside Foundation Sprint family scaffolding
0.2.02026-05-15Codex adversarial review acceptance: library samples version-tiered (F32; v0.1.0 Brainshelf REQUIRED + Storevine/Workbench RECOMMENDED; v1.0.0 all 3 threads REQUIRED); metadata.frameworks clarified as subset semantics with foundation-sprint required (F13); CI enforcement list reorganized into family-level + per-member splits with explicit validator-coverage gap documentation (F10)
0.3.02026-05-16Naming Discipline section added (workshop sprints vs agile sprints): codifies the qualified-naming style rule for “Foundation Sprint” vs bare “sprint” with explicit rationale tied to the agile-sprint cognitive collision. Style guidance only; not validator-enforced. Mirrored in design-sprint-skills-contract.md v0.2.0.