jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/use-case-dependency-mapper/references/dependency-categories.md

@@ -0,0 +1,201 @@
+# Dependency Categories
+
+Detailed definitions, discovery prompts, and worked examples for each of the six dependency dimensions used in use case dependency mapping.
+
+---
+
+## Data Dependencies
+
+**What they are:** Everything a use case needs from data — availability, quality, access, structure, governance, and freshness.
+
+**Why they matter:** Most AI and automation use cases fail or stall on data long before they reach technical build. Surfacing data dependencies early protects delivery scope and prevents false feasibility signals.
+
+**Discovery prompts:**
+- What data does this use case consume? Where does it live today?
+- What format, structure, or schema does it need to be in?
+- How current does the data need to be (real-time, hourly, daily, batch)?
+- Who currently owns or stewards that data?
+- Is the data clean and complete enough to trust the output?
+- Is there a data governance process that must approve access or use?
+- Are there consent, privacy, or retention constraints on this data?
+- Does a data contract or formal SLA exist between the source and consumer?
+
+**Common dependency types:**
+- Source system does not expose the data in a usable form
+- Data quality is insufficient for the output accuracy the use case requires
+- Access rights are not in place and the approval path is undefined
+- Data governance review has not been initiated
+- No labeled training or ground truth data exists for an ML-dependent use case
+- Schema changes frequently with no stability guarantee
+
+**Example (confirmed):** The use case depends on customer interaction history from the CRM. The CRM team has confirmed read API access can be provisioned with a 2-week approval cycle.
+
+**Example (inferred):** The use case likely depends on order data from the ERP. The data team has not confirmed whether ERP data is exposed in a format usable downstream.
+
+**Example (unknown):** The use case may require historical sensor data. It is not yet clear whether that data has been archived, is accessible, or meets the quality bar needed for the model.
+
+---
+
+## Systems Dependencies
+
+**What they are:** The platforms, applications, services, APIs, and infrastructure that must be available, integrated, or built for the use case to function.
+
+**Why they matter:** Integration work is often the longest-lead item in delivery. Identifying system dependencies early surfaces integration effort before it becomes a sprint blocker.
+
+**Discovery prompts:**
+- What systems must the use case read from or write to?
+- Are APIs available for those systems, or would new ones need to be built?
+- What authentication and authorization mechanisms do those systems require?
+- Are there rate limits, quotas, or SLA constraints on those systems?
+- Are any of those systems legacy, unsupported, or being decommissioned?
+- What hosting environment does the use case need to run in?
+- Are there middleware, orchestration, or event-streaming dependencies?
+- What version or configuration of a system does the use case assume?
+
+**Common dependency types:**
+- Source system lacks an API and requires ETL or file-based extraction instead
+- Target system does not accept programmatic writes
+- Integration middleware (message bus, API gateway) must be provisioned
+- A key system is being replaced or upgraded on a timeline that conflicts with delivery
+- Infrastructure (cloud account, compute, storage) is not yet provisioned
+- Third-party service requires a vendor contract before access can be established
+
+**Example (confirmed):** The use case requires an API connection to the HR system. IT has confirmed an existing REST API with OAuth 2.0 authentication is available for internal integrations.
+
+**Example (inferred):** The use case likely requires a webhook or event trigger from the ticketing system. It is not yet confirmed whether the current version supports webhooks or whether an upgrade is needed.
+
+**Example (unknown):** The use case may need a vector database or embedding store. No decision has been made on which infrastructure to use or whether it exists in the current environment.
+
+---
+
+## Process Dependencies
+
+**What they are:** The business workflows, handoffs, approvals, and operational practices that must exist, be redesigned, or be actively owned before the use case can operate as intended.
+
+**Why they matter:** A technically functional use case can fail in operation if the surrounding process has not been designed. Process dependencies are frequently underdiscovered in pre-sales and early delivery planning.
+
+**Discovery prompts:**
+- What process is this use case sitting inside or replacing?
+- What happens upstream and downstream from where this use case operates?
+- Who initiates the process, and who receives the output?
+- Are there approval or review steps the use case depends on?
+- What does an exception or error look like in this process, and who handles it?
+- What runbooks or escalation paths must exist for this to run in production?
+- Are there regulatory or audit process requirements attached to this workflow?
+- Who owns this process today, and are they engaged?
+
+**Common dependency types:**
+- No process owner has been identified or confirmed
+- The downstream process does not yet exist and must be designed alongside the use case
+- An approval workflow the use case feeds into has not been redesigned to accept AI-assisted input
+- Exception handling and human review steps are undefined
+- The use case sits across two processes owned by different teams with no integration agreement
+
+**Example (confirmed):** The use case feeds into a weekly review process. The process owner has confirmed they are available and have reviewed the proposed integration point.
+
+**Example (inferred):** The use case likely requires an exception queue for low-confidence outputs to be reviewed by an analyst. That queue and review process have not been designed yet.
+
+**Example (unknown):** It is unclear whether the upstream data entry process would need to change to feed the use case correctly. No process mapping has been done on that step.
+
+---
+
+## Security Dependencies
+
+**What they are:** The controls, policies, compliance requirements, governance frameworks, and approvals that must be in place before the use case can be built, tested, or deployed.
+
+**Why they matter:** Security and compliance dependencies are often long-lead and non-negotiable. Discovering them late creates rework, launch delays, or scope rollback. AI use cases frequently carry additional governance requirements that standard software does not.
+
+**Discovery prompts:**
+- What data classification levels does this use case touch?
+- Who must approve access to that data, and on what timeline?
+- Is there a data residency or sovereignty requirement for this use case?
+- Does the use case fall under any regulatory framework (GDPR, HIPAA, SOC 2, etc.)?
+- Is a privacy impact assessment or AI governance review required before launch?
+- What threat model applies — is there user-facing output that could be manipulated?
+- What audit logging is required for this use case?
+- Who owns security sign-off, and are they engaged?
+
+**Common dependency types:**
+- Data classification requires a security review before access can be provisioned
+- AI governance policy has not been established and must be created before this use case can proceed
+- A privacy impact assessment is required and has not been initiated
+- Regulatory controls require human-in-the-loop steps that are not yet designed
+- The use case involves PII or sensitive data with no defined handling procedure
+- Penetration testing or security review is required before production deployment
+
+**Example (confirmed):** The use case processes employee PII. The privacy team has confirmed a DPIA is required and has agreed to a timeline.
+
+**Example (inferred):** The use case likely requires audit logging for all model decisions. No logging design or tooling has been chosen yet.
+
+**Example (unknown):** It is not yet clear whether the client's AI governance policy applies to this use case or whether an exception process exists.
+
+---
+
+## People Dependencies
+
+**What they are:** The human roles, skills, authority, and availability that must be present for the use case to be designed, built, governed, and operated.
+
+**Why they matter:** Use cases stall when key people are unavailable, undefined, or not engaged. People dependencies are often the least visible on paper and the most impactful in practice.
+
+**Discovery prompts:**
+- Who is the business sponsor for this use case, and are they actively engaged?
+- Who owns the process this use case operates in?
+- Who stewards the data this use case depends on?
+- What subject matter expertise is required to design, validate, or operate this use case?
+- Are there any key individuals whose availability could block progress?
+- What roles must the delivery team have, and are they staffed?
+- Who will operate this use case after delivery, and are they identified?
+- Are there vendor or partner team dependencies on specific people?
+
+**Common dependency types:**
+- No confirmed business sponsor — no one is accountable for decisions and sign-off
+- Data steward is identified but has not committed capacity
+- Subject matter expert required for model validation is shared across multiple projects
+- Operations team that will own the use case post-launch is not yet identified or trained
+- A key integration point requires involvement from a third-party vendor with no active contract
+
+**Example (confirmed):** The process owner for the claims workflow has been identified and has committed two hours per week to the pilot.
+
+**Example (inferred):** A data steward for the product catalog data will likely be required. The analytics team owns that data but no individual has been named.
+
+**Example (unknown):** It is unclear whether the client has internal AI operations capability to own this use case after delivery, or whether a managed service arrangement would be needed.
+
+---
+
+## Change Dependencies
+
+**What they are:** The organizational change, user adoption, communication, and enablement work that must happen for the use case to be accepted, adopted, and sustained after delivery.
+
+**Why they matter:** A use case that delivers technically but fails to land with users or the organization produces no value. Change dependencies are as real as technical dependencies — they just manifest later in delivery if not surfaced early.
+
+**Discovery prompts:**
+- Who will use this in day-to-day work, and how does it change their current job?
+- Is there known resistance or skepticism toward this use case?
+- What training or enablement is required before go-live?
+- What communication needs to happen before launch, and who owns it?
+- Are there union, works council, or labor relations dependencies?
+- How will success be measured after launch, and who is accountable for adoption?
+- What change management process does the client use, and is it engaged?
+- Are there competing initiatives that could reduce user attention or adoption?
+
+**Common dependency types:**
+- No change management plan or owner identified
+- Users have expressed resistance or concern about the use case
+- Training materials must be developed and delivery timeline has not been scoped
+- A communication plan to affected teams is required before rollout
+- Labor or HR policies require consultation before an AI-assisted workflow changes job tasks
+- No adoption metrics or success measurement framework has been defined
+
+**Example (confirmed):** The client change management team has been briefed and has committed to owning the communication plan for the pilot rollout.
+
+**Example (inferred):** The use case automates parts of a role that currently employs a large team. A change communication plan will likely be required before rollout, but none has been started.
+
+**Example (unknown):** It is unclear whether union or works council consultation is required for this client before automating any part of this workflow.
+
+---
+
+## Using This Reference
+
+When mapping dependencies, work through each dimension systematically rather than stopping at the first-order items that are obvious. Most delivery problems originate in second-order dependencies — not that the API exists, but that the API has rate limits that will require redesign; not that data is available, but that the data owner is unavailable to approve access before the sprint starts.
+
+Use the discovery prompts to generate questions for the client or delivery team when evidence is thin. A dependency map with well-labeled unknowns and clear next steps is more valuable than a confident-sounding map that papers over gaps.

package/.jumpstart/skills/use-case-prioritization/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: use-case-prioritization
+description: 'Prioritize AI or automation use cases using a structured matrix that balances value, feasibility, risk, readiness, and delivery complexity. Use this whenever the user needs a defensible shortlist of candidate pilots or follow-on work from Jump Start or discovery output.'
+argument-hint: 'Provide the candidate use cases and any known business, data, or delivery constraints.'
+---
+
+# Use Case Prioritization
+
+## Positioning
+
+Use this skill to create a defensible shortlist from competing use cases. The output should help the team explain why one use case should move first and which assumptions, dependencies, or delivery constraints still need validation.
+
+## When To Use This
+
+- Workshop outputs need prioritization.
+- The team needs to compare pilots or candidate use cases.
+- The user wants a value-versus-feasibility view.
+- The team needs to justify a pilot choice for Jump Start follow-on or Pod work.
+
+## Typical Need Shapes
+
+- "Prioritize these workshop use cases and recommend the first Pod candidate."
+- "Create a value, feasibility, risk, and readiness matrix from these candidate ideas."
+- "Explain why one use case should move forward now and what still needs validation."
+
+## When Not To Use This
+
+- Do not use it when the use cases themselves are still undefined.
+- Do not treat scoring as objective truth; show the evidence and assumptions behind the scores.
+
+## Required Inputs
+
+- Candidate use cases
+- Any known constraints, readiness signals, or risk concerns
+
+## Evidence And Boundary Discipline
+
+Treat scores as a decision aid, not objective truth. Show which scores are evidence-backed, which rely on assumptions, and which could change after data, stakeholder, governance, or integration validation. If use cases are too vague to score responsibly, clarify or normalize them first.
+
+## Workflow
+
+1. Define the scoring dimensions.
+2. Score each use case using evidence where possible.
+3. Explain tradeoffs and ranking logic.
+4. Recommend the shortlist and next validation steps.
+5. Highlight what could change the ranking later.
+
+## Output Structure
+
+1. Prioritization dimensions
+2. Scored matrix
+3. Top candidates and rationale
+4. Risks, dependencies, or follow-up checks
+
+## Reference Files
+
+- Use [matrix-pattern.md](./references/matrix-pattern.md) for default prioritization dimensions, scoring bands, and shortlist guidance.
+- Use [../../../05-reference/the-jumpstart-workshops.md](../../../05-reference/the-jumpstart-workshops.md) when the candidates come from workshop output.
+- Use [../../../05-reference/ai-innovation-pod-tier-matrix.md](../../../05-reference/ai-innovation-pod-tier-matrix.md) when the shortlist needs to align to likely delivery posture.
+
+## Common Pitfalls
+
+### Pitfall 1: False Precision
+
+Bad: presenting scores as exact when the evidence is thin.
+
+Better: use score bands, confidence notes, and validation questions.
+
+### Pitfall 2: Prioritizing Value Alone
+
+Bad: picking the highest-value idea despite unclear data, ownership, or controls.
+
+Better: balance value with feasibility, readiness, risk, and delivery complexity.
+
+## Quality Bar
+
+- Show why a use case ranks where it does.
+- Keep the model usable in workshops and follow-up docs.
+- Make the evidence and assumptions behind the ranking visible.

package/.jumpstart/skills/use-case-prioritization/evals/evals.json

@@ -0,0 +1,34 @@
+{
+  "skill_name": "use-case-prioritization",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Prioritize the six candidate use cases in the attached file and recommend the best shortlist for a Jump Start engagement. Define the scoring dimensions, score each candidate, and explain the shortlist rationale.",
+      "expected_output": "A scored prioritization matrix with ranking logic, a defensible shortlist, and next validation steps.",
+      "files": [
+        "evals/files/candidate-use-cases.md"
+      ],
+      "expectations": [
+        "The output covers all six candidate use cases in a scored comparison.",
+        "The output uses explicit prioritization dimensions such as value, feasibility, risk, readiness, or delivery complexity.",
+        "The output recommends a narrowed shortlist instead of treating all six use cases as equal.",
+        "The output explains tradeoffs or next validation steps for the top candidates."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Use the attached candidate list and workshop output notes to build a defensible use-case prioritization model for an AI Innovation Pod pilot. Balance value, feasibility, risk, readiness, and delivery complexity, then recommend what should be piloted first.",
+      "expected_output": "A usable matrix that reflects workshop evidence, clear scoring dimensions, and a grounded pilot recommendation.",
+      "files": [
+        "evals/files/candidate-use-cases.md",
+        "evals/files/workshop-output-notes.md"
+      ],
+      "expectations": [
+        "The output incorporates workshop constraints such as the six-week pilot, no CRM write-back, and low tolerance for PII in phase 1.",
+        "The output reflects stakeholder concern about client-facing hallucination risk or approval needs.",
+        "The output ranks or shortlists use cases using explicit scoring logic rather than only narrative opinions.",
+        "The output identifies validation steps or dependencies for the top recommendation."
+      ]
+    }
+  ]
+}

package/.jumpstart/skills/use-case-prioritization/evals/files/candidate-use-cases.md

@@ -0,0 +1,43 @@
+# Candidate Use Cases
+
+## 1. Opportunity Intake Triage Assistant
+
+- Users: sellers and solution leads
+- Problem: incoming AI opportunity asks are inconsistent and hard to route
+- Data available now: intake forms, seller notes, prior qualification templates
+- Notes: internal-only workflow, moderate process clarity, low external risk
+
+## 2. Proposal Draft Copilot
+
+- Users: solution architects and proposal leads
+- Problem: proposal sections are slow to draft and inconsistent across teams
+- Data available now: prior proposals, SOW patterns, seller notes
+- Notes: high value, but quality review still needed before client delivery
+
+## 3. Client-Facing Policy Q&A Assistant
+
+- Users: external client contacts
+- Problem: clients want immediate answers to policy and delivery questions
+- Data available now: mixed quality documentation, some stale content
+- Notes: high hallucination risk, external exposure, weak content governance today
+
+## 4. Workshop Agenda Generator
+
+- Users: facilitators and account teams
+- Problem: workshop planning is repetitive and inconsistent
+- Data available now: agenda templates, prior workshop notes, audience profiles
+- Notes: internal-facing, lower risk, good template reuse potential
+
+## 5. Delivery Status Summarizer
+
+- Users: delivery leads and sponsors
+- Problem: status reporting is manual and spread across Teams and Planner
+- Data available now: Planner tasks, status notes, RAID logs
+- Notes: medium integration complexity, sponsor value is clear
+
+## 6. CRM Update Recommender
+
+- Users: sellers
+- Problem: CRM updates are inconsistent after discovery calls
+- Data available now: meeting notes, action items, CRM schema
+- Notes: would need write-back later, pilot should probably avoid direct write-back

package/.jumpstart/skills/use-case-prioritization/evals/files/workshop-output-notes.md

@@ -0,0 +1,8 @@
+# Workshop Output Notes
+
+- Client wants one pilot started within 6 weeks.
+- Team has low tolerance for customer-facing hallucination risk in phase 1.
+- No direct CRM write-back approved for the pilot.
+- Sponsor wants a use case that demonstrates measurable productivity improvement quickly.
+- Architecture lead is comfortable with internal copilots and summarization patterns first.
+- Facilitators noted strong appetite for workflow acceleration and internal decision support.

package/.jumpstart/skills/use-case-prioritization/references/matrix-pattern.md

@@ -0,0 +1,52 @@
+# Matrix Pattern
+
+Use this pattern when prioritizing candidate use cases. The matrix should help the team narrow the field, explain the ranking, and show what could still change the decision.
+
+## Default Dimensions
+
+Use these dimensions unless the context suggests a better set:
+
+1. Business value
+2. Feasibility
+3. Data readiness
+4. Delivery complexity
+5. Risk and governance burden
+6. Stakeholder readiness
+
+## Dimension Guide
+
+| Dimension | What A High Score Means |
+| --- | --- |
+| Business value | clear impact on cost, speed, quality, or decision quality |
+| Feasibility | a credible technical and workflow path exists |
+| Data readiness | needed data appears available, usable, and appropriately governed |
+| Delivery complexity | the work can be bounded without excessive integration or coordination overhead |
+| Risk and governance burden | controls look manageable for the current phase |
+| Stakeholder readiness | sponsor, user, and owner participation appear strong enough to move |
+
+## Score Bands
+
+- `1`: weak or poor fit
+- `2`: mixed, partial, or uncertain fit
+- `3`: strong fit for the current motion
+
+## Shortlist Rules
+
+- Do not choose only on value.
+- Use confidence notes where the evidence is thin.
+- Call out the top one to three candidates, not just a ranked list.
+- State what validation could move a lower-ranked use case up or down.
+
+## Example Interpretation
+
+Example:
+
+- Use case A scores highest on value but low on data readiness.
+- Use case B scores slightly lower on value but much higher on feasibility and readiness.
+- Recommendation: start with B now, keep A as a follow-on candidate once data access is validated.
+
+## Common Failure Modes
+
+- Presenting the matrix as objective truth.
+- Ranking all ideas but never narrowing to a shortlist.
+- Ignoring governance or stakeholder readiness because value is attractive.

package/.jumpstart/skills/user-persona-development/README.md

@@ -0,0 +1,44 @@
+# User Persona Development
+
+Creates practical personas from Phase 0 stakeholder maps and discovery evidence.
+
+For each high or medium impact stakeholder, this skill produces:
+
+- Name and role
+- Impact level
+- Goals
+- Frustrations
+- Technical proficiency
+- Relevant context
+- Current workaround
+- Quote
+
+It avoids generic marketing personas and focuses on outputs useful for solution design, MVP scoping, workflow design, backlog planning, and change management.
+
+## Finalized Defaults
+
+- Exclude low-impact personas by default, except high-influence executive sponsors.
+- Require a source basis note for every persona.
+- For AI-enabled workflows, always include trust, citation, and human-review needs.
+- For Jump Start deliverables, auto-include design, backlog, and change implications unless persona-only is requested.
+
+## Included Assets
+
+- Skill contract: [SKILL.md](./SKILL.md)
+- References: [references](./references)
+- Templates: [templates](./templates)
+- Examples: [examples](./examples)
+- Evals: [evals/evals.json](./evals/evals.json)
+- Validation tool: [scripts/validate_persona_fields.py](./scripts/validate_persona_fields.py)
+
+## Companion Customizations
+
+- Persona quality evaluator skill: [../user-persona-quality-evaluator/SKILL.md](../user-persona-quality-evaluator/SKILL.md)
+- Stakeholder normalizer prompt: [../../prompts/normalize-stakeholder-map.prompt.md](../../prompts/normalize-stakeholder-map.prompt.md)
+- Journey map companion skill: [../persona-journey-map-companion/SKILL.md](../persona-journey-map-companion/SKILL.md)
+
+## Example Prompts
+
+- Build user personas from this Phase 0 stakeholder map.
+- Convert these workshop stakeholders into medium and high impact personas with source basis notes.
+- Create AI-solution personas and include design and change implications.

package/.jumpstart/skills/user-persona-development/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: user-persona-development
+description: Create practical user personas from stakeholder maps, discovery notes, workshop outputs, transcripts, PRDs, BRDs, SOWs, MVP scopes, and Phase 0 artifacts. Use this whenever the user asks to create personas, convert stakeholders to personas, build Jump Start personas, or derive AI-solution user needs and adoption implications. Always prefer this skill over generic persona writing when source stakeholder evidence exists.
+argument-hint: Paste a stakeholder map, discovery notes, or workshop transcript and specify if you want standard personas only or personas plus design, backlog, and change implications.
+---
+
+# User Persona Development
+
+## Purpose
+
+Create discovery-grounded personas from stakeholder evidence.
+
+Use this skill after stakeholder mapping to produce personas that are useful for solution design, MVP scoping, workflow mapping, backlog shaping, AI use-case prioritization, and change impact planning.
+
+Do not produce generic marketing personas.
+
+## Required Inputs
+
+Start from the best available source:
+
+- Stakeholder map rows
+- Phase 0 workshop notes
+- Discovery notes or transcript excerpts
+- PRD, BRD, SOW, or MVP scope fragments
+
+Prefer evidence with these fields:
+
+- Stakeholder name or group
+- Role and responsibilities
+- Impact level
+- Pain points and goals
+- Current workaround
+- Tools and systems used
+- Constraints, context, and blockers
+
+When fields are missing, infer carefully and label assumptions.
+
+## Selection Rule
+
+Create full personas only for stakeholders with:
+
+- High impact
+- Medium impact
+
+Do not create full low-impact personas unless explicitly requested.
+
+Exception: include a low-impact stakeholder as an executive sponsor persona only when both conditions are true:
+
+- Influence is high
+- They own funding, KPI accountability, or go/no-go decisions
+
+When this exception is used, label clearly:
+
+`Impact Level: Low user impact, high influence sponsor`
+
+If impact is missing, infer it and label it as inferred.
+
+## Output Contract
+
+Always produce:
+
+1. Persona Summary table
+2. Detailed personas
+3. Gaps and follow-up questions section when needed
+
+Each persona must include:
+
+1. Name and role
+2. Impact level
+3. Goals (2 to 3)
+4. Frustrations (2 to 3)
+5. Technical proficiency (Low, Medium, or High)
+6. Relevant context
+7. Current workaround
+8. Realistic quote
+
+Use the default output template in [persona-template.md](./templates/persona-template.md) and summary format in [persona-summary-table.md](./templates/persona-summary-table.md).
+
+## Workflow
+
+1. Extract candidate stakeholders from source material.
+2. Filter to high and medium impact stakeholders.
+3. Merge or split candidates using [stakeholder-to-persona-rules.md](./references/stakeholder-to-persona-rules.md).
+4. Draft personas with the required fields using [persona-field-guide.md](./references/persona-field-guide.md).
+5. Run quality checks with [persona-quality-checklist.md](./references/persona-quality-checklist.md).
+6. Add source basis and assumptions using [source-grounding-rules.md](./references/source-grounding-rules.md).
+7. If the solution is AI-enabled, add trust and adoption context using [ai-solution-persona-considerations.md](./references/ai-solution-persona-considerations.md).
+8. If requested, add design/backlog/change implications using templates in [templates](./templates).
+9. If output is in markdown, optionally run [validate_persona_fields.py](./scripts/validate_persona_fields.py).
+
+## Default Policy Decisions
+
+Apply these defaults unless the user overrides them:
+
+1. Low-impact stakeholders are excluded from full personas, except high-influence executive sponsors.
+2. Source basis is required for every persona. If evidence is weak, write `Source Basis: Inferred from provided notes; confirmation needed.`
+3. For AI-enabled workflows, trust, citation visibility, and human-review needs are mandatory persona context fields.
+4. Design/backlog/change implications are optional by default, but auto-include for Jump Start deliverables unless explicitly disabled.
+
+Use [policy-defaults.md](./references/policy-defaults.md) for implementation detail.
+
+## Optional Add-Ons
+
+When requested, include:
+
+- Design implications via [design-implications-template.md](./templates/design-implications-template.md)
+- Backlog implications via [backlog-implications-template.md](./templates/backlog-implications-template.md)
+- Change implications via [change-management-implications-template.md](./templates/change-management-implications-template.md)
+
+Jump Start default: include all three sections unless the user asks for persona-only output.
+
+## Output Quality Rules
+
+- Ground claims in source evidence.
+- Use specific, workflow-tied goals and frustrations.
+- Keep context practical for product, UX, architecture, and delivery teams.
+- Exclude demographic profiling and stereotypes.
+- Do not invent workarounds when evidence is missing.
+- Mark conflicting notes and unresolved ownership as open questions.
+
+## Trigger Phrases
+
+Use this skill when users ask for:
+
+- create personas
+- user persona development
+- build personas from stakeholder map
+- phase 0 personas
+- jumpstart personas
+- personas for MVP or POC
+- personas for AI workflow design
+- stakeholder personas
+
+## Jump Start and AI Innovation Pod Alignment
+
+Position personas as operational delivery assets, not branding artifacts.
+
+- Support Jump Start discovery readouts with evidence-based persona needs.
+- Bridge into Pod follow-on by translating personas into design, backlog, and adoption implications.
+- Keep scope boundaries explicit by separating confirmed evidence from inferred assumptions.
+
+## Evaluation
+
+Use test prompts in [evals.json](./evals/evals.json). Prioritize:
+
+- Correct filtering by impact level
+- Completeness of required persona fields
+- Evidence grounding and assumption labeling
+- AI trust and human-review concerns when relevant
+
+## Companion Customizations
+
+- Persona quality scoring: [../user-persona-quality-evaluator/SKILL.md](../user-persona-quality-evaluator/SKILL.md)
+- Stakeholder map normalization prompt: [../../prompts/normalize-stakeholder-map.prompt.md](../../prompts/normalize-stakeholder-map.prompt.md)
+- Persona to journey mapping: [../persona-journey-map-companion/SKILL.md](../persona-journey-map-companion/SKILL.md)

package/.jumpstart/skills/user-persona-development/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "user-persona-development",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Create user personas from this stakeholder input. Include only high and medium impact roles, and add a gaps section for missing workarounds. Stakeholders: Operations Team Lead (High impact, medium influence, pain: manual reconciliation across two systems, workaround: shared spreadsheet and Teams follow-up, goal: faster exception visibility); Integration Engineer (Medium impact, high influence, pain: brittle handoffs and unclear contracts, workaround: custom retry scripts, goal: reliable traceability); Finance Sponsor (Low impact user, high influence decision maker, pain: delayed monthly reporting, workaround: asks team for manual extracts, goal: predictable KPIs).",
+      "expected_output": "Generates two full personas (Operations Team Lead and Integration Engineer), excludes full low-impact finance sponsor persona, includes required fields and realistic quote, includes gap callouts when needed.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Create personas from these notes and include AI trust concerns. Notes: Claims Processor handles 120 requests/day, worries AI may recommend wrong next action without showing source policy; Compliance Approver owns final signoff, needs audit trail and override reason; Platform Admin supports uptime and access controls, handles incident triage. Impact is missing for Platform Admin. Include assumptions clearly.",
+      "expected_output": "Produces practical personas with AI trust, review, and citation needs; infers and labels impact for Platform Admin; includes source basis and assumptions.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "We have 14 high/medium stakeholders from discovery. Group into persona families and create representative personas with backlog implications for an MVP review queue product.",
+      "expected_output": "Groups stakeholders into persona families and produces representative personas plus backlog implications without creating one persona per job title.",
+      "files": []
+    }
+  ]
+}