Stats
Actions
Tags
From jerry
Facilitates AJ&Smart Design Sprint 2.0: structured four-day process for challenge mapping, solution sketching, storyboarding, prototyping, and user testing to validate product concepts before development.
How this skill is triggered — by the user, by Claude, or both
Slash command
/jerry:ux-design-sprintThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- VERSION: 1.1.0 | DATE: 2026-03-04 | SOURCE: skills/user-experience/SKILL.md | PARENT: /user-experience skill | REVISION: iter2 — add Context7 MCP to allowed-tools (T3 consistency), add HMW/interview citations, consolidate Wave Gating duplication -->
Version: 1.1.0 Framework: Jerry User-Experience -- Design Sprint 2.0 Constitutional Compliance: Jerry Constitution v1.0 Parent Skill:
/user-experience(skills/user-experience/SKILL.md) Wave: 5 (Process Intensives) Project: PROJ-022 User Experience Skill | GitHub Issue #138
| Section | Purpose |
|---|---|
| Document Audience | Triple-Lens audience guide |
| Purpose | Sub-skill overview and key capabilities |
| When to Use This Sub-Skill | Activation triggers and scope boundaries |
| Available Agents | Single agent with role, model, and output location |
| P-003 Compliance | Worker agent hierarchy position |
| Invoking the Agent | Invocation via ux-orchestrator |
| Methodology | AJ&Smart Design Sprint 2.0 four-day process with detailed phase activities |
| Output Specification | Output location, L0/L1/L2 structure, required sections |
| Routing | Keywords and lifecycle-stage routing integration |
| Cross-Framework Integration | Handoff from JTBD/heuristic evaluation and to Lean UX/HEART metrics |
| Synthesis Hypothesis Confidence | Confidence classifications for Design Sprint outputs |
| Quality Gate Integration | S-014 scoring and H-13 threshold enforcement |
| Degraded Mode Behavior | Operation when Figma or Miro MCP unavailable |
| Wave Architecture | Wave 5 entry criteria, bypass conditions |
| Constitutional Compliance | Governing principles and AI-facilitated sprint limitations |
| Registration | H-26 parent-routed registration model and AGENTS.md confirmation |
| Deployment Status | Wave 5 stub agent status and implementation timeline |
| Quick Reference | Common workflows and agent selection hints |
| References | Full repo-relative paths, requirements traceability, external citations |
This SKILL.md serves multiple audiences:
| Level | Audience | Sections to Focus On |
|---|---|---|
| L0 (Stakeholder) | Product managers, designers, sprint participants | Purpose, When to Use This Sub-Skill, Quick Reference |
| L1 (Developer) | Engineers invoking the agent | Invoking the Agent, Methodology, Output Specification |
| L2 (Architect) | Workflow designers, skill maintainers | Cross-Framework Integration, Synthesis Hypothesis Confidence, Degraded Mode Behavior |
The Design Sprint sub-skill provides structured facilitation for the AJ&Smart Design Sprint 2.0 process -- a four-day compressed format (Courtney, 2019) adapted from the original Google Ventures five-day Design Sprint (Knapp, Zeratsky & Kowitz, 2016). It targets tiny teams (1-5 people) who need to rapidly move from a design challenge to a tested prototype without committing months to development.
This sub-skill is part of Wave 5 (Process Intensives), requiring Wave 4 completion before standard deployment. It provides the most intensive, end-to-end design validation process in the /user-experience skill, producing high-confidence synthesis signals from direct user testing on Day 4. A wave bypass condition allows teams at product inception ("don't know what to build") to access Design Sprint without completing prior waves.
/ux-lean-ux (hypothesis generation from validated learnings), /ux-jtbd (validated job stories from user interviews), and /ux-heuristic-eval (post-sprint evaluation of the prototype).Activate when:
Do NOT use for:
/ux-heuristic-eval (Nielsen's 10) instead. Use heuristic evaluation for existing products; Design Sprint is for new concepts and major redesigns./ux-atomic-design (Atomic Design) instead./ux-inclusive-design (WCAG 2.2) instead./ux-heart-metrics (Google GSM) instead. Use HEART after the sprint to measure the validated concept./ux-jtbd (Jobs-to-Be-Done) instead. JTBD identifies what users want; Design Sprint tests specific solutions./ux-behavior-design (Fogg B=MAP) instead./ux-lean-ux (Lean UX) instead. Lean UX iterates; Design Sprint validates a single prototype in 4 days./ux-kano-model (Kano) instead./eng-team instead./problem-solving instead.| Agent | Role | Tier | Mode | Model | Output Location |
|---|---|---|---|---|---|
ux-sprint-facilitator | AJ&Smart Design Sprint 2.0 facilitation | T4 | Systematic | Opus | projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-sprint-facilitator-{topic-slug}.md |
STUB: The agent definition file (skills/ux-design-sprint/agents/ux-sprint-facilitator.md) is pending Wave 5 Phase 2 implementation as part of PROJ-022 EPIC-005. The SKILL.md specifies the methodology and output contract that the agent will implement.
Tool tier: T4 (External) = Read, Write, Edit, Glob, Grep, Bash + WebSearch, WebFetch, Context7 MCP. T4 access is required because Design Sprint facilitation benefits from external research during Day 1 expert interviews and Day 2 lightning demos (competitive analysis, industry precedent research). See .context/rules/agent-development-standards.md [Tool Security Tiers].
The agent produces output at three levels per AD-M-004:
The /ux-design-sprint sub-skill contains a single worker agent. It is invoked by the ux-orchestrator (T5) via the Agent tool. The agent does NOT have Agent tool access and MUST NOT spawn sub-agents.
MAIN CONTEXT (user request)
|
v
ux-orchestrator (T5, Opus, Integrative) -- parent orchestrator
|
+-- ux-sprint-facilitator (T4, Systematic, Opus) -- THIS sub-skill's worker
+-- [other sub-skill workers...]
Enforcement:
disallowedTools: [Agent] declared in skills/ux-design-sprint/agents/ux-sprint-facilitator.md frontmatterskills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml capabilities.forbidden_actionsskills/user-experience/rules/ci-checks.md)This is a sub-skill invoked by the ux-orchestrator, not directly by users. Users interact with the parent /user-experience skill, which routes to this sub-skill based on lifecycle-stage triage.
"We don't know what to build -- help us figure it out"
"Run a design sprint for the new mobile navigation"
"We need to validate our checkout redesign concept with real users"
"Facilitate a 4-day design sprint to explore our onboarding problem"
"Help us go from idea to tested prototype for the dashboard feature"
"Our team has 3 competing ideas for the settings page -- which one works?"
"Use ux-sprint-facilitator to facilitate a design sprint for the new payment flow"
"Have ux-sprint-facilitator run a Design Sprint 2.0 for our mobile app onboarding"
The ux-orchestrator invokes the agent via the Agent tool:
Agent(
description="ux-sprint-facilitator: Design Sprint 2.0 for mobile navigation redesign",
subagent_type="jerry:ux-sprint-facilitator",
prompt="""
## UX CONTEXT (REQUIRED)
- **Engagement ID:** UX-0012
- **Topic:** Mobile Navigation Redesign Design Sprint
- **Product:** [product name, domain, and current navigation description]
- **Target Users:** [user segments and behavioral context]
- **Sprint Challenge:** [the big challenge or question the sprint aims to answer]
- **Sprint Questions:** [2-5 specific questions to answer by end of sprint]
- **Existing Research:** [upstream JTBD job statements, heuristic findings, user interviews]
- **MCP Availability:** Figma=[available/unavailable], Miro=[available/unavailable]
## TASK
Facilitate a complete AJ&Smart Design Sprint 2.0 for mobile navigation redesign.
1. Day 1 (Map): Define challenge, map user journey, identify target user + key moment, structure expert interviews, set sprint questions
2. Day 2 (Sketch): Conduct lightning demos, facilitate 4-step sketch (notes, ideas, crazy 8s, solution sketch), run Art Museum voting
3. Day 3 (Decide): Facilitate straw poll, supervote, select winning sketch, identify assumptions, create storyboard
4. Day 4 (Test): Specify realistic prototype, structure interviews with 5 users, analyze patterns, synthesize findings
## MANDATORY PERSISTENCE (P-002)
Create file at: projects/${JERRY_PROJECT}/engagements/UX-0012/ux-sprint-facilitator-mobile-navigation.md
"""
)
Governance codification (AD-M-007): The session_context contract (on_receive/on_send) is specified in
ux-sprint-facilitator.governance.yamlper AD-M-007. Fields are enumerated below:
on_receive fields:
| Field | Type | Required | Description |
|---|---|---|---|
engagement_id | string | Yes | UX engagement identifier (format: UX-{NNNN}) |
product_context | string | Yes | Product name, domain, current state, and target user description |
sprint_challenge | string | Yes | The big question or problem the sprint aims to solve (e.g., "How might we reduce checkout abandonment for first-time buyers?") |
sprint_questions | array | No | 2-5 specific questions to answer by end of sprint; if absent, Day 1 generates them |
upstream_artifacts | array | No | File paths to upstream handoff artifacts (JTBD job statements, heuristic evaluation findings, prior research) |
mcp_availability | object | No | MCP tool availability: figma (boolean), miro (boolean); determines degraded mode behavior |
on_send fields:
| Field | Type | Required | Description |
|---|---|---|---|
sprint_day_completed | integer | Yes | Last completed sprint day (1-4); 4 indicates full sprint completion |
challenge_statement | string | Yes | Finalized challenge statement from Day 1 |
prototype_fidelity | enum | Yes | high (Figma interactive), medium (static mockups), low (paper/whiteboard) |
interview_count | integer | Yes | Number of user interviews completed (target: 5 per Nielsen, 2000) |
theme_strength | enum | Yes | strong (identified by >= 3 of 5 users), moderate (2 of 5), weak (1 of 5) |
usability_findings_count | integer | Yes | Total usability findings from Day 4 interviews |
sprint_questions_answered | array | Yes | Each sprint question with pass/fail/partial verdict and supporting evidence |
winning_sketch_summary | string | Yes | Description of the selected solution direction from Day 3 |
validated_assumptions | array | Yes | Assumptions confirmed by Day 4 testing |
invalidated_assumptions | array | Yes | Assumptions disproven by Day 4 testing |
synthesis_judgments | array | Yes | AI judgment calls with confidence classification and rationale |
The AJ&Smart Design Sprint 2.0 (Courtney, 2019) compresses the original Google Ventures five-day Design Sprint (Knapp, Zeratsky & Kowitz, 2016) into four days by combining the original Day 1 (Understand) and Day 2 (Diverge) into a single Day 1 (Map), and merging the original Day 3 (Decide) with Day 4 (Prototype) into Day 3 (Decide + Storyboard). This produces a more intensive but faster sprint cadence while preserving the core methodology.
| Sprint Day | GV Equivalent | Primary Activity | Key Output |
|---|---|---|---|
| Day 1: Map | GV Days 1-2 | Challenge definition, journey mapping, expert interviews, sprint questions, sketching | Challenge map, sprint questions, solution sketches |
| Day 2: Sketch | GV Day 2 (cont.) | Lightning demos, 4-step sketch, Art Museum voting | Individual solution sketches with vote data |
| Day 3: Decide | GV Days 3-4 | Straw poll, supervote, winning sketch, storyboard, prototype specification | Storyboard, prototype plan |
| Day 4: Test | GV Day 5 | Prototype construction, 5-user interviews, pattern analysis | Validated findings, sprint verdict |
Purpose: Align the sprint team around the challenge, map the problem space, gather expert knowledge, and set measurable sprint questions.
Activities:
Challenge Definition -- Articulate the sprint challenge as a "How Might We" (HMW) question (IDEO design thinking technique, Brown, 2009; adopted in Sprint methodology per Knapp et al., 2016, Chapter 4). The challenge should be specific enough to test in 4 days but broad enough to allow creative solutions. Example: "How might we reduce first-time buyer checkout abandonment from 68% to under 40%?"
Long-Term Goal -- Define what success looks like 6-12 months from now. This anchors the sprint against strategic objectives, not just tactical improvements.
Sprint Questions -- Formulate 2-5 specific, testable questions that the sprint must answer. Sprint questions should be phrased as "Can we...?" or "Will users...?" to enable clear pass/fail assessment on Day 4. Example: "Will users understand the new progress indicator without instruction?"
User Journey Map -- Map the end-to-end user journey for the target behavior, from first awareness through the desired action. Identify: entry points, key decision moments, friction points, and the critical moment (the single most important interaction to get right).
Target Selection -- Choose the target user segment and the key moment in the journey that the sprint will focus on. The key moment is the narrowest scope that still addresses the sprint challenge. Per Knapp et al. (2016): "Pick the most important customer and the most important moment."
Expert Interviews -- Conduct structured "How Might We" interviews with 3-5 domain experts (product owner, support representative, technical lead, existing users if available). Each interview is 15-20 minutes. Capture HMW notes on individual cards/items for later clustering.
HMW Clustering -- Group HMW notes by theme. Vote to identify the most promising opportunity areas. Place winning HMW clusters on the journey map at the relevant moments.
Output: Challenge map document containing: HMW challenge statement, long-term goal, sprint questions (2-5), annotated user journey map, target user + key moment selection, expert interview summaries, clustered HMW notes.
Purpose: Generate individual solution ideas through structured sketching exercises, then surface and compare solutions through Art Museum voting.
Activities:
Lightning Demos -- Each participant (or the facilitator for the team) reviews 3-5 inspiring examples from other products, industries, or domains that solve analogous problems. Capture "big ideas" from each demo. External research via WebSearch/WebFetch supports this activity.
Four-Step Sketch -- Individual sketching process (Knapp et al., 2016):
Art Museum -- All solution sketches posted on a wall (or Miro board). Silent review period where participants place dot votes on compelling elements. Heat map emerges showing which solutions and elements attract the most attention.
Speed Critiques -- Brief 3-minute presentations of each sketch by the facilitator (not the author). Author clarifies only at the end. Team discusses strengths and concerns.
Output: Collection of solution sketches with vote data, lightning demo research notes, Art Museum heat map results.
Purpose: Select the winning solution, identify critical assumptions, and create a detailed storyboard for prototype construction.
Activities:
Straw Poll -- Each team member places one "super dot" on the solution (or solution element) they believe best addresses the sprint challenge. Non-binding poll to surface initial preferences.
Supervote -- The Decider (product owner or designated decision-maker) places 3 supervote dots. The Decider's votes determine the direction. Per Knapp et al. (2016): "The Decider has final say." If no human Decider is designated, the facilitator presents a ranked recommendation based on straw poll consensus, Day 1 sprint question alignment, and feasibility assessment, then asks the user to confirm.
Rumble or All-in-One -- If two strong but incompatible solutions survive the supervote: Rumble (test both in the prototype as A/B variants) or All-in-One (combine compatible elements). The Decider chooses the approach.
Assumption Identification -- Extract the critical assumptions embedded in the winning solution. Each assumption is phrased as a testable statement: "Users will [expected behavior] when [condition]." Classify as: must-be-true (sprint fails if wrong), nice-to-have (enhances but not critical), or unknown (requires investigation).
Storyboard -- Create a detailed 10-16 panel storyboard that narrates the user's interaction with the prototype from opening scene through completion. Each panel specifies: screen state, user action, system response, and emotional state. The storyboard serves as the prototype construction blueprint.
Prototype Specification -- Define the prototype scope: which screens to build, interaction fidelity level (clickable prototype vs. static mockups vs. wizard-of-oz), data requirements (realistic content vs. placeholder), and tools (Figma, paper, presentation software).
Output: Decision record (winning sketch, selection rationale, Decider identity), assumption inventory, detailed storyboard (10-16 panels), prototype specification.
Purpose: Build a realistic prototype, test it with 5 representative users, and identify validated patterns.
Activities:
Prototype Construction -- Build the prototype per the Day 3 storyboard and specification. Fidelity should be "just enough" to feel real without over-investing. Per Knapp et al. (2016): "A Goldilocks quality prototype -- just real enough." The facilitator provides guidance on prototype scope and structure; actual construction may use Figma MCP (if available) or manual methods.
Interview Script Preparation -- Structure a 60-minute interview protocol (Knapp et al., 2016, Chapter 14 "Friday: Test"):
User Interviews -- Conduct structured interviews with 5 representative users (Nielsen, 2000). Five users are sufficient to identify approximately 85% of usability problems. Each interview follows the prepared script. Record observations against the sprint questions.
Observation Grid -- During each interview, the sprint team (or facilitator) records observations in a grid: rows = sprint questions + key screens, columns = users (U1-U5). Each cell captures: positive reaction (+), negative reaction (-), or neutral observation (~). Color-code for quick pattern identification.
Pattern Analysis -- After all 5 interviews, analyze the observation grid:
Sprint Question Verdict -- For each sprint question, assign a verdict:
Findings Synthesis -- Compile validated findings, categorize by severity and frequency, map findings to assumptions (validated vs. invalidated), and produce the sprint outcome summary.
Output: Prototype reference (file path or description), interview observation grid, thematic analysis with pattern strength, sprint question verdicts, assumption validation results, findings synthesis with confidence classifications.
Note: This execution procedure describes target behavior for the fully-implemented
ux-sprint-facilitatoragent. The current agent definition is a Wave 5 stub; full implementation will follow this specification.
The facilitator follows a 5-phase sequential workflow corresponding to the sprint structure plus a synthesis phase. Each phase produces intermediate artifacts that feed the next.
Purpose: Establish sprint context, confirm wave entry criteria, and execute Day 1 activities.
Activities:
WAVE-4-SIGNOFF.md in projects/${JERRY_PROJECT}/engagements/; if absent, ask user per H-31.)/ux-jtbd job statements (job statement + switch forces feed the challenge statement); check for /ux-heuristic-eval findings (severity-rated findings provide problem context)Output: Sprint setup brief (wave entry verification, upstream input inventory) and Day 1 challenge map.
Purpose: Generate and surface solution ideas.
Activities:
Output: Lightning demo research notes, solution sketch descriptions, Art Museum results.
Purpose: Select winning solution and create prototype blueprint.
Activities:
Output: Decision record, assumption inventory, storyboard, prototype specification.
Purpose: Construct prototype, test with users, and analyze results.
Activities:
Output: Prototype reference, interview observation grid, pattern analysis, sprint question verdicts.
Purpose: Synthesize all sprint findings, produce L0/L1/L2 output artifact, and construct downstream handoffs.
Activities:
/ux-lean-ux (validated prototype + Day 4 findings for hypothesis iteration), /ux-heuristic-eval (prototype for post-sprint evaluation), /ux-jtbd (validated job stories from user interviews)Output: Complete output artifact per Required Output Sections. Handoff payloads for downstream sub-skills.
projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-sprint-facilitator-{topic-slug}.md
Where:
{engagement-id} follows the pattern UX-{NNNN} (e.g., UX-0012){topic-slug} is a kebab-case descriptor of the sprint challenge (e.g., mobile-navigation, checkout-redesign, onboarding-flow)| Section | Level | Content |
|---|---|---|
| Executive Summary | L0 | Sprint challenge statement; winning solution summary; Day 4 test results (pass/fail/partial per sprint question); top validated findings; recommended next steps |
| Sprint Context | L1 | Product description, target users, sprint participants, upstream inputs (JTBD job statements, heuristic findings), wave entry verification, MCP availability |
| Day 1: Map | L1 | HMW challenge statement, long-term goal, sprint questions (2-5), annotated user journey map, target user + key moment, expert interview summaries, HMW clusters |
| Day 2: Sketch | L1 | Lightning demo research notes, solution sketch descriptions, Crazy 8s variations summary, Art Museum vote results, speed critique highlights |
| Day 3: Decide | L1 | Straw poll results, supervote outcome, Decider identity and rationale, Rumble/All-in-One decision, assumption inventory (must-be-true/nice-to-have/unknown), storyboard (10-16 panels), prototype specification |
| Day 4: Test | L1 | Prototype reference (fidelity level, tool used), interview script summary, observation grid (5 users x sprint questions), pattern analysis with theme strength, sprint question verdicts (pass/fail/partial), assumption validation results |
| Strategic Implications | L2 | Sprint learning synthesis; validated vs. invalidated assumptions mapped to product strategy; recommended follow-up (Lean UX cycles, heuristic evaluation, development planning); organizational sprint maturity assessment; competitive positioning insights from lightning demos |
| Synthesis Judgments Summary | L1 | Each AI judgment call listed for synthesis confidence gate compliance |
| Handoff Data | L1 | Structured data for downstream sub-skills: validated prototype + findings for /ux-lean-ux; prototype reference for /ux-heuristic-eval; validated job stories for /ux-jtbd |
Synthesis Judgments Summary requirements: MUST list every AI judgment (sprint question framing, sketch selection recommendations, assumption classification, pattern strength assessment, sprint question verdicts) with confidence classification (HIGH/MEDIUM/LOW) and rationale. Each judgment row includes: finding ID, framework source (e.g., Day 1 challenge framing, Day 3 assumption classification, Day 4 pattern analysis), confidence level (HIGH/MEDIUM/LOW), and rationale explaining the classification basis and evidence chain. Follows the pattern in skills/user-experience/rules/synthesis-validation.md.
| Template | Path | Purpose |
|---|---|---|
| Design Sprint Template | skills/ux-design-sprint/templates/design-sprint-template.md | Four-day sprint artifact structure with observation grid, storyboard panels, and sprint question verdict format |
| Keyword | Routing Context |
|---|---|
| design sprint | Direct match -- primary trigger |
| GV sprint | Direct match (Google Ventures sprint) |
| rapid prototyping | In combination with sprint/validation context |
| sprint week | Direct match |
| map sketch decide test | Direct match (sprint day names) |
| 4-day sprint | Direct match |
| design sprint 2.0 | Direct match (AJ&Smart format) |
| AJ Smart sprint | Direct match |
| validate prototype | In combination with sprint/user testing context |
| test with users | In combination with prototype/sprint context (not general usability testing) |
| sprint facilitation | Direct match |
| design sprint challenge | Direct match |
| sprint storyboard | In combination with sprint/prototype context |
This sub-skill is routed to by the ux-orchestrator in the following lifecycle-stage scenarios:
| Stage | User Intent | Route Condition |
|---|---|---|
| Before design | "Need validated prototype" | Direct route to /ux-design-sprint; source: skills/user-experience/rules/ux-routing-rules.md Stage Routing Table (pending EPIC-001 completion) |
| Product inception | "Don't know what to build" | Wave bypass route to /ux-design-sprint; team has no existing product but needs structured exploration |
| Before design | Follow-up from JTBD discovery | When /ux-jtbd has produced job statements + switch forces; job statement feeds the sprint challenge definition |
| Any stage | "Validate a design concept quickly" | Qualification question: "Do you need a full 4-day sprint process or a quick evaluation?" -> Full sprint: /ux-design-sprint; Quick evaluation: /ux-heuristic-eval; source: skills/user-experience/rules/ux-routing-rules.md Common Intent Resolution (pending EPIC-001 completion) |
This sub-skill is in Wave 5 (Process Intensives). See Wave Architecture for entry criteria, bypass condition, and terminal wave status.
This sub-skill receives context from other sub-skills when invoked as part of a multi-sub-skill workflow:
| From Sub-Skill | Handoff Artifact | Key Fields | Usage |
|---|---|---|---|
/ux-jtbd | Job statement + switch forces | Job statement, push/pull forces, hiring criteria, anxieties, habits | JTBD job statement feeds the Day 1 challenge definition; switch forces inform sprint question formulation; hiring criteria shape the target user selection |
/ux-heuristic-eval | Severity-rated findings | Finding ID, heuristic violated, severity (0-4), affected screen/flow | Heuristic findings identify specific usability problems that the sprint can address; high-severity findings (>= 3) may define the sprint challenge directly |
This sub-skill produces artifacts that feed into other sub-skills via the Jerry handoff protocol (docs/schemas/handoff-v2.schema.json).
| To Sub-Skill | Handoff Artifact | Key Fields | Trigger |
|---|---|---|---|
/ux-lean-ux | Validated prototype + Day 4 findings | Prototype reference, validated/invalidated assumptions, sprint question verdicts, usability findings, theme strength | After Day 4 completion; Lean UX uses sprint findings to generate hypothesis backlog for iterative experimentation |
/ux-heuristic-eval | Prototype for post-sprint evaluation | Prototype reference (Figma link or file path), prototype fidelity level, key interaction flows | After sprint completion; heuristic evaluation provides systematic usability audit of the sprint prototype |
/ux-jtbd | Validated job stories from user interviews | Interview observation grid, user quotes, validated behaviors, job story candidates | After Day 4 interviews; user testing reveals actual jobs and switching triggers that refine JTBD job statements |
Handoff data format (handoff-v2 + ux-ext):
handoff:
from_agent: ux-sprint-facilitator
to_agent: ux-lean-ux-experimenter
task: "Generate Lean UX hypothesis backlog from Design Sprint findings"
success_criteria:
- "Hypotheses generated for each validated and invalidated sprint assumption"
- "Experiment designs prioritize assumptions that were partially validated"
artifacts:
- "projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-sprint-facilitator-{topic-slug}.md"
key_findings:
- "Sprint verdict: {pass/fail/partial} on {N} sprint questions"
- "Strong themes (>= 3/5 users): {theme_count} findings"
- "Invalidated assumptions: {list}"
blockers: []
confidence: 0.75
criticality: C2
ux_ext:
sprint_day_completed: 4
prototype_fidelity: "{high|medium|low}"
interview_count: 5
theme_strength: "{strong|moderate|weak}"
usability_findings_count: "{N}"
This sub-skill participates in the following canonical sequences:
| Sequence | Skills Involved | This Sub-Skill's Role |
|---|---|---|
| Discovery to Sprint | /ux-jtbd then /ux-design-sprint | Receives JTBD job statement and switch forces; uses them to frame the sprint challenge and target user selection |
| Sprint to Iterate to Measure | /ux-design-sprint then /ux-lean-ux then /ux-heart-metrics | Produces validated prototype and Day 4 findings; Lean UX iterates on hypotheses; HEART measures validated concept |
| Sprint to Evaluate | /ux-design-sprint then /ux-heuristic-eval | Produces prototype for systematic usability evaluation against Nielsen's 10 heuristics |
Design Sprint outputs include synthesis hypotheses that carry confidence classifications per the synthesis validation protocol.
| Synthesis Step | Typical Confidence | Rationale |
|---|---|---|
| Day 4 interview thematic analysis | HIGH | Based on direct user interviews (5 users per Sprint methodology; Knapp, Zeratsky & Kowitz, 2016). Themes identified by >= 3 of 5 users meet the strong theme threshold. Direct user observation provides the highest-quality evidence available in the UX skill framework. |
| Day 2 sketch selection rationale | MEDIUM | Selection rationale involves subjective judgment among sprint participants. Art Museum voting provides structured input but the Decider's supervote introduces individual judgment. Rationale is documented but not empirically validated until Day 4. |
Gate enforcement:
Note on confidence dynamics: Day 4 thematic analysis represents one of the highest-confidence synthesis sources in the entire /user-experience skill because it is based on direct user observation. When Design Sprint findings converge with findings from a second framework (e.g., /ux-heuristic-eval confirms usability issues identified in Day 4), synthesis confidence is reinforced. Day 2 sketch selection starts at MEDIUM but is validated or invalidated by Day 4 testing, creating an internal confidence progression within a single sprint.
Design Sprint outputs are subject to the Jerry quality gate per H-13 and H-14:
| Quality Check | Threshold | Application |
|---|---|---|
| S-014 LLM-as-Judge scoring | >= 0.92 composite (C2+) | Applied at Phase 5 completion |
| Creator-critic-revision | Minimum 3 iterations (H-14) | Orchestrator manages revision cycles |
| Self-review (S-010) | Required before presenting | Self-review before returning to orchestrator |
| Wave transition gate | S-014 composite >= 0.85 | Applied at Wave 4 -> 5 transition |
Scoring dimensions (Design Sprint interpretation):
| Dimension | Weight | Interpretation |
|---|---|---|
| Completeness | 0.20 | All four sprint days documented; all sprint questions addressed; observation grid complete for 5 users |
| Internal Consistency | 0.20 | Day 4 findings consistent with Day 3 assumptions; sprint verdicts consistent with observation grid data; handoff data consistent with findings |
| Methodological Rigor | 0.20 | AJ&Smart Design Sprint 2.0 methodology correctly applied; 4-step sketch process followed; 5-user interview target met; observation grid structured per sprint questions |
| Evidence Quality | 0.15 | Day 4 findings cite specific user observations; pattern strength based on user count threshold (>= 3 of 5); quotes and behaviors recorded per user |
| Actionability | 0.15 | Sprint verdicts clearly pass/fail/partial; next steps specific and actionable; handoff data sufficient for downstream sub-skills |
| Traceability | 0.10 | Sprint questions trace to challenge statement; findings trace to observation grid; assumptions trace to storyboard; synthesis judgments documented |
The following CI gate criteria apply to this sub-skill (full gate definitions in skills/user-experience/rules/ci-checks.md):
| Gate | Check | Enforcement |
|---|---|---|
| No Agent tool access | disallowedTools: [Agent] present in agent frontmatter; agent MUST NOT have Agent in tools list | L5 (CI): grep agent frontmatter for Agent tool presence |
| P-003 forbidden action | capabilities.forbidden_actions in .governance.yaml MUST include P-003 recursive subagent prohibition | L5 (CI): schema validation of governance YAML against docs/schemas/agent-governance-v1.schema.json |
| Output schema validation | Agent output MUST contain all Required Output Sections (Executive Summary, Sprint Context, Day 1-4, Strategic Implications, Synthesis Judgments Summary, Handoff Data) | L4 (post-tool): section heading presence check on output artifact |
The ux-sprint-facilitator operates at T4 (External) and has access to WebSearch, WebFetch, and Context7 MCP. Additionally, it depends on Figma (REQ) for prototype creation and Miro (REQ) for collaborative sprint activities. Both MCP dependencies are required, so degraded mode behavior is significant.
When Figma MCP is not available, prototype creation falls back to manual methods:
| Limitation | Impact | Mitigation |
|---|---|---|
| No interactive prototype creation | Cannot build clickable Figma prototype for Day 4 testing | Guide user to create prototype manually using presentation software (Keynote, PowerPoint), paper prototyping, or an alternative prototyping tool. Adjust prototype_fidelity to medium or low. |
| No component inspection | Cannot reference existing design system components in prototype | Ask user to provide screenshots of existing components or describe their design system manually |
| Reduced prototype realism | Day 4 test results may be influenced by lower prototype fidelity | Note prototype fidelity in output; flag that findings may differ with higher-fidelity prototype per P-022 |
Fallback mode: Miro-only mode -- sprint exercises (journey mapping, HMW clustering, Art Museum) conducted in Miro; prototype constructed manually outside the MCP ecosystem. Per parent SKILL.md: "Miro-only mode: sprint exercises in Miro; manual prototype reference."
When Miro MCP is not available, collaborative sprint activities fall back to local-file methods:
| Limitation | Impact | Mitigation |
|---|---|---|
| No collaborative whiteboarding | Cannot use shared Miro board for journey mapping, HMW clustering, Art Museum voting | Use markdown-based sprint boards: journey map as a structured table, HMW notes as a bulleted list, Art Museum as a ranked list with vote counts |
| No real-time visual collaboration | Sprint team cannot see each other's contributions simultaneously | Facilitator compiles contributions into a single markdown document; sequential rather than simultaneous input |
| Reduced Art Museum effectiveness | Dot voting less intuitive without visual spatial layout | Use numbered ranking instead of spatial dot voting; facilitator tabulates votes |
Fallback mode: Local-file sprint boards -- all sprint artifacts produced as structured markdown documents. The methodology remains identical; only the collaboration medium changes from visual board to text-based format.
When both required MCPs are unavailable, the sprint operates in fully degraded text-only mode:
| Aspect | Degraded Approach |
|---|---|
| Day 1 journey map | Structured markdown table: steps, user actions, pain points, opportunities |
| Day 2 sketches | Text descriptions of solution concepts; user asked to sketch manually and describe |
| Day 3 storyboard | Numbered panel descriptions in markdown; user asked to sketch panels manually |
| Day 4 prototype | Paper prototype or presentation-based prototype; user constructs offline |
Degraded mode disclosure (P-022):
[DEGRADED MODE] This sprint was facilitated without Figma and/or Miro MCP access.
Limitations:
- Prototype fidelity: {low|medium} (no Figma interactive prototype)
- Sprint board format: {markdown-based|text-only} (no Miro collaborative board)
- Day 4 findings may be influenced by prototype fidelity limitations
- Art Museum voting conducted via {ranked list|numbered voting} (no spatial dot voting)
Impact: Sprint methodology is fully preserved; collaboration and prototype fidelity are reduced.
When invoked without prior /ux-jtbd output or /ux-heuristic-eval findings (e.g., direct invocation for product inception), the facilitator runs Day 1 challenge definition from scratch using user-provided context and sprint team knowledge. This is a valid and common sprint entry point -- many sprints begin without prior formal research.
This sub-skill is part of Wave 5 (Process Intensives), alongside /ux-ai-first-design (CONDITIONAL).
Entry criteria: Wave 4 completed -- 30+ users for Kano survey OR 1 B=MAP bottleneck diagnosed.
Bypass condition: Design Sprint can proceed without Kano prerequisite if team has existing user research. This is the most significant bypass in the wave architecture because teams at product inception have the strongest need for Design Sprint and the least ability to satisfy Wave 4 advanced analytics prerequisites. Bypass requires 3-field documentation: unmet criterion, impact assessment ("sprint proceeds without Kano feature prioritization context; team has user research from other sources"), and remediation plan with target date.
Wave transition (terminal wave): Wave 5 is the final wave. When WAVE-5-SIGNOFF.md is valid, the orchestrator enters full operational mode with all 10 sub-skills deployed.
All agents in this sub-skill adhere to the Jerry Constitution v1.0:
| Principle | Requirement | Consequence of Violation |
|---|---|---|
| P-003 | NEVER spawn recursive subagents -- worker agent, no Agent tool access | Agent hierarchy violation; uncontrolled token consumption |
| P-020 | NEVER override the Decider's sprint decisions or user priorities on solution selection | Unauthorized action; trust erosion; sprint methodology violation (Decider authority is core to GV Sprint) |
| P-022 | NEVER present sprint findings as certain without disclosing evidence limitations; NEVER inflate theme strength without meeting the >= 3/5 user threshold; NEVER omit degraded mode disclosure when operating without Figma or Miro | Governance undermined; quality assessment invalidated |
| P-001 | NEVER present Day 4 findings without citing specific user observations from the interview grid | Unreliable outputs; unfounded claims propagate downstream |
| P-002 | NEVER leave sprint artifacts in transient context only -- persist all four days of output to files | Context rot vulnerability; sprint artifacts lost on session compaction |
| P-004 | NEVER make sprint verdict decisions without documenting the observation evidence and reasoning chain | Untraceable decisions; audit trail broken |
| P-011 | NEVER recommend next steps without supporting evidence from Day 4 testing | Unsupported recommendations; confidence inflated without basis |
Per-agent enforcement: The ux-sprint-facilitator agent declares:
constitution.principles_applied: P-003, P-020, P-022, P-001, P-002, P-004, P-011 in skills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yamlcapabilities.forbidden_actions: 3 entries in NPT-009 format referencing the constitutional tripletdisallowedTools: [Agent] in skills/ux-design-sprint/agents/ux-sprint-facilitator.md frontmatterThe Design Sprint facilitator agent operates as an AI-augmented facilitation tool. The following limitations apply to all outputs and MUST be disclosed per P-022 (no deception):
This sub-skill follows a parent-routed registration model per H-26. Sub-skills are routed through the parent /user-experience orchestrator; independent registration would create duplicate triggers (AP-02).
| Registration Point | Status | Detail |
|---|---|---|
CLAUDE.md skill table | Registered via parent | /user-experience registered; sub-skills not independently listed |
mandatory-skill-usage.md trigger map | Routed via parent | "design sprint" keyword routes to parent, which dispatches here |
AGENTS.md agent registry | Registered | ux-sprint-facilitator listed under User-Experience Skill Agents |
| Parent SKILL.md agent table | Registered | Listed in skills/user-experience/SKILL.md [Available Agents] |
Wave 5 Sub-Skill -- Phase 1 Complete, Phase 2 Pending.
This sub-skill follows a two-phase implementation sequence:
- Wave 5 Phase 1 (this deliverable): SKILL.md specification -- methodology, output format, routing integration, template stub, cross-framework integration, and quality gate criteria. This document is the Phase 1 artifact.
- Wave 5 Phase 2 (pending): Agent implementation --
skills/ux-design-sprint/agents/ux-sprint-facilitator.md(agent definition with<input>,<capabilities>,<methodology>,<output>sections) andskills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml(governance metadata). Tracked under PROJ-022 EPIC-005.
| Need | Command Example |
|---|---|
| New product exploration | "We don't know what to build -- help us figure it out" |
| Validate redesign concept | "Run a design sprint for the checkout redesign" |
| Test with real users | "We need to validate our mobile navigation with 5 users" |
| Full 4-day sprint | "Facilitate a Design Sprint 2.0 for the dashboard feature" |
| Post-JTBD solution exploration | "We have our JTBD job statements -- now run a sprint to explore solutions" |
| Competing ideas resolution | "Our team has 3 ideas for the settings page -- which one works?" |
| Keywords | Routes To |
|---|---|
| design sprint, GV sprint, rapid prototyping, sprint week, map sketch decide test, 4-day sprint, design sprint 2.0, validate prototype, sprint facilitation | ux-sprint-facilitator |
| heuristic, usability, Nielsen, severity, inspection, evaluation | /ux-heuristic-eval (not this sub-skill) |
| JTBD, jobs to be done, switch interview, user motivation, job statement | /ux-jtbd (not this sub-skill) |
| lean UX, hypothesis, assumption, experiment, build-measure-learn | /ux-lean-ux (not this sub-skill) |
| HEART, metrics, measurement, GSM, happiness, engagement | /ux-heart-metrics (not this sub-skill) |
| behavior design, B=MAP, Fogg model, behavior bottleneck | /ux-behavior-design (not this sub-skill) |
| Kano, feature prioritization, must-be, attractive, performance | /ux-kano-model (not this sub-skill) |
| Source | Content | Path |
|---|---|---|
| Parent SKILL.md | Sub-skill scope, wave architecture, routing, MCP dependencies, synthesis protocol | skills/user-experience/SKILL.md |
| Agent definition | Agent frontmatter, identity, expertise, guardrails | skills/ux-design-sprint/agents/ux-sprint-facilitator.md [PLANNED] |
| Agent governance | Tool tier, forbidden actions, output validation, constitutional compliance | skills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml [PLANNED] |
| UX routing rules | Lifecycle-stage routing, handoff data contracts, common intent resolution | skills/user-experience/rules/ux-routing-rules.md |
| Synthesis validation | Confidence gate protocol, per-sub-skill confidence map, signal extraction criteria | skills/user-experience/rules/synthesis-validation.md |
| Wave progression | Wave 5 entry criteria, signoff requirements | skills/user-experience/rules/wave-progression.md |
| CI checks | P-003 enforcement, sub-skill validation gates | skills/user-experience/rules/ci-checks.md |
| Design sprint template | Four-day sprint artifact structure, observation grid, storyboard format | skills/ux-design-sprint/templates/design-sprint-template.md |
| Skill standards | H-25/H-26 skill structure requirements | .context/rules/skill-standards.md |
| Agent development standards | H-34 dual-file architecture, tool tiers, handoff protocol | .context/rules/agent-development-standards.md |
| Quality enforcement | Quality gate thresholds, criticality levels, strategy catalog | .context/rules/quality-enforcement.md |
| Handoff schema | Canonical handoff schema v2 | docs/schemas/handoff-v2.schema.json |
| Agent governance schema | Governance YAML validation schema | docs/schemas/agent-governance-v1.schema.json |
| Source | Content | Path |
|---|---|---|
| PROJ-022 PLAN.md | Project plan: sub-skill scope, wave assignment, acceptance criteria, implementation phases | projects/PROJ-022-user-experience-skill/PLAN.md |
| EPIC-005 (Wave 5 Deployment) | Parent work item for Wave 5 sub-skill implementation including this sub-skill | PROJ-022 EPIC-005 in projects/PROJ-022-user-experience-skill/WORKTRACKER.md |
| ORCHESTRATION.yaml | Orchestration plan governing the build sequence for this sub-skill | projects/PROJ-022-user-experience-skill/orchestration/ux-skill-build-20260303-001/ORCHESTRATION.yaml |
| Source | Citation |
|---|---|
| Knapp, J., Zeratsky, J., & Kowitz, B. (2016) | "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days." Simon & Schuster. Chapter 1: sprint overview and Decider role; Chapters 2-6: Day 1 Map methodology (long-term goal, sprint questions, user journey map, HMW interviews, target selection); Chapter 7: Day 2 lightning demos; Chapter 8: four-step sketch (Notes, Ideas, Crazy 8s, Solution Sketch); Chapter 9: Art Museum voting; Chapters 10-11: Day 3 straw poll, supervote, storyboard; Chapters 12-13: Day 4 prototype construction ("Goldilocks quality"); Chapter 14: 5-user interview protocol and pattern analysis. |
| Courtney, J. (2019) | "The Design Sprint 2.0." AJ&Smart. Compressed four-day format: Day 1 combines GV Days 1-2 (Map + Sketch begin), Day 2 completes sketching, Day 3 combines GV Days 3-4 (Decide + Storyboard), Day 4 is GV Day 5 (Test). Adopted here as the primary sprint format for time efficiency. |
| Nielsen, J. (2000) | "Why You Only Need to Test with 5 Users." Nielsen Norman Group. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ (accessed 2026-03-04). Validates 5-user interview sample size for Day 4 testing: 5 users uncover approximately 85% of usability problems. |
| Brown, T. (2009) | "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation." Harper Business. Origin of the "How Might We" (HMW) technique adopted by IDEO and subsequently incorporated into the Google Ventures Sprint methodology (Knapp et al., 2016, Chapter 4). |
Sub-Skill Version: 1.1.0
Parent Skill: /user-experience v1.0.0
Constitutional Compliance: Jerry Constitution v1.0
Wave: 5 (Process Intensives)
SSOT: skills/user-experience/SKILL.md
Project: PROJ-022 User Experience Skill
Created: 2026-03-04
npx claudepluginhub geekatron/jerry --plugin jerryGuides a 5-day design sprint to answer critical design or business questions through rapid prototyping and user testing.
Orchestrates AI-augmented UX methodology for tiny teams (1-5 people), routing to 10 sub-skills for evaluation, user research, design systems, metrics, behavior diagnosis, prioritization, sprints, and AI interaction design.
Plans and facilitates design sprints from challenge framing through prototype testing, with 5-day structure, variations, checklists, and best practices.