jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/impediment-prioritization/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: impediment-prioritization
+description: 'Ranks any list of impediments and their countermeasures using a value-stream scoring model (ROI, Cost to Implement, Ease of Deployment, Risk Factor) and a fixed prioritization formula. Use this whenever the user asks what to fix first across findings, risks, gaps, remediation items, action items, or backlog entries, including Jump Start discovery outputs, AI readiness gaps, architecture review findings, governance blockers, and AI Innovation Pod delivery impediments. Trigger even when the user talks in consulting language like roadmap, phased remediation, decision support, risk reduction, readiness gaps, or backlog sequencing rather than explicitly saying prioritization.'
+license: MIT
+compatibility: 'Cross-platform. Optional web access helps when countermeasures need authoritative public citations.'
+metadata:
+  author: Jo Otey
+  version: "2.1.0"
+  created: "2026-04-19"
+  updated: "2026-04-29"
+  framework: value-stream-prioritization
+  domain: jumpstart-and-pod
+argument-hint: 'Optional: source artifact type, desired output shape, owner tags, or whether to recommend Jump Start, Ignition, Turbo, or Overdrive next'
+---
+
+# Impediment Prioritization
+
+Use this skill to turn messy gaps into a defendable sequence of action. The core job is not only ranking items, but helping the user move from raw findings to a client-safe remediation backlog, decision-ready readout, or delivery-ready sequence.
+
+This skill is domain-agnostic, but it is especially useful in this workspace for Jump Start and AI Innovation Pod work where teams need to convert discovery outputs, readiness gaps, governance blockers, or build impediments into a prioritized next-step plan.
+
+## Trigger Cues
+
+Use this skill when the user:
+- asks to prioritize, rank, sequence, or triage impediments, gaps, risks, findings, remediation items, or backlog entries
+- provides a list of problems and wants you to propose or compare countermeasures
+- asks what to fix first before a Jump Start, before a Pod engagement, or during an active Pod delivery motion
+- wants to turn discovery notes, workshop findings, readiness assessments, architecture review gaps, or governance concerns into a phased action plan
+- mentions value-stream prioritization, A3 countermeasures, ROI vs. effort, remediation backlog, decision log, readiness gap closure, or blocker sequencing
+
+Do not use this skill for use-case ideation, account qualification, detailed PRD writing, or broad solution design when there is no meaningful list of impediments or remediation items to rank.
+
+## Modes
+
+| User need | Mode | Primary output |
+|-----------|------|----------------|
+| Rank a generic remediation list | Standard | Prioritized impediments table with Top 3 actions |
+| Turn Jump Start or assessment findings into a client-safe sequence | Jump Start | Prioritized table plus implications for engagement path and open questions |
+| Sequence blockers during an active Pod motion | Pod Delivery | Prioritized table with owner, timing, and next execution lane |
+
+## First Response
+
+Lock these items before scoring. If the user already supplied them, do not ask again.
+
+1. Source artifact or input shape
+2. Whether countermeasures already exist or need to be proposed
+3. Desired output format: simple table, client-ready readout, or delivery backlog
+4. Whether owner, phase, confidence, or source columns are needed
+
+## Resource Map
+
+Use bundled files instead of overloading this prompt.
+
+| File | Use when |
+|------|----------|
+| [references/workflow.md](./references/workflow.md) | You need the end-to-end workflow, source normalization rules, or output mode selection |
+| [references/jumpstart-pod-mapping.md](./references/jumpstart-pod-mapping.md) | The impediments come from Jump Start, readiness, or Pod delivery artifacts and need engagement-aware interpretation |
+| [references/scoring-rubric.md](./references/scoring-rubric.md) | You need anchored scoring examples or calibration help |
+| [templates/prioritized-impediments-template.md](./templates/prioritized-impediments-template.md) | The user wants the standard ranked table only |
+| [templates/jumpstart-pod-remediation-template.md](./templates/jumpstart-pod-remediation-template.md) | The output needs executive context, owners, timing, and engagement implications |
+| [examples/impediment-prioritization-examples.md](./examples/impediment-prioritization-examples.md) | You want finished examples across generic, Jump Start, and Pod contexts |
+| [evals/evals.json](./evals/evals.json) | You are regression-testing or improving this skill |
+
+## Accepted Inputs
+
+Accepted input is a list of `{impediment, countermeasure}` pairs or any artifact that can be normalized into that shape. Common sources are covered in [references/workflow.md](./references/workflow.md).
+
+Use these rules every time:
+
+1. Keep one primary countermeasure per impediment. If several paths exist, choose the main path and note alternatives in the rationale.
+2. Collapse duplicates before scoring.
+3. Attach a source link or citation when one exists.
+4. Surface confidence, owner, or dependency columns only when the source supports them or the user asks for them.
+5. Preserve scope boundaries. Discovery findings and readiness gaps do not justify implementation commitments on their own.
+
+## Scoring Rubric (1–10 scales)
+
+Score each countermeasure against all four criteria. See [references/scoring-rubric.md](./references/scoring-rubric.md) for anchoring examples, including Jump Start and Pod-aligned calibration.
+
+| Criterion | Scale | Definition |
+|-----------|-------|------------|
+| **Return on Investment (ROI)** | 1 = low, 10 = high | Efficiency gain delivered by the countermeasure to this step AND to the overall value stream. Not purely financial — weight throughput, cycle-time reduction, defect removal, user / developer experience, and compliance lift. |
+| **Cost to Implement** | 1 = inexpensive, 10 = very expensive | Human capital (salary + time of people needed) plus any purchases, licenses, or infrastructure required to implement the countermeasure. |
+| **Ease of Deployment** | 1 = extremely hard, 10 = very easy | Remediation effort required to actually deploy the countermeasure end-to-end. Reflects technical complexity, change-management burden, and rollback risk. |
+| **Risk Factor** | 1 = low risk, 10 = very high risk | Risk weighted on impact to the overall value stream if the countermeasure goes wrong, stalls, or is deferred. |
+
+Every score must be accompanied by a one-line rationale. When a score is an estimate rather than drawn from explicit data, mark the rationale with `(estimated)`.
+
+## Formula
+
+```
+Priority = ((ROI * (10 / Cost)) + (Ease * (10 / Risk))) / 2
+```
+
+- Theoretical range: **1 → 100**. Practical range on typical backlogs: ~1 → 100.
+- The scale minimum of `1` guarantees Cost and Risk are never zero (no divide-by-zero).
+- Higher Priority = do first.
+- Boundary checks:
+  - ROI=10, Cost=1, Ease=10, Risk=1 → `((10*10)+(10*10))/2 = 100`
+  - ROI=1, Cost=10, Ease=1, Risk=10 → `((1*1)+(1*1))/2 = 1`
+
+Use the formula verbatim. Do not reweight, normalize, or substitute.
+
+## Operating Workflow
+
+1. Pick the mode, then read the relevant bundled references before drafting.
+2. Normalize the source into one impediment and one primary countermeasure per row.
+3. Confirm or propose the countermeasure. Prefer documented best practice and authoritative citations when available.
+4. Score ROI, Cost, Ease, and Risk with a one-line rationale for each criterion.
+5. Compute Priority using the formula and round to one decimal place.
+6. Sort descending by Priority and assign Rank starting at 1.
+7. Render the output using the closest bundled template.
+8. Call out the Top 3 items with a short explanation of why they should move first.
+9. If the context is Jump Start or Pod delivery, add a short implication section covering ownership, timing, and whether the work points toward Jump Start, Ignition, Turbo, Overdrive, or adjacent-team support.
+
+## Output Rules
+
+- Default to pasteable markdown.
+- Keep the ranked table as the centerpiece. Do not hide the formula or the rationale.
+- Separate confirmed facts from estimates, assumptions, and open questions.
+- For Jump Start work, frame the output as decision support, not a hidden implementation promise.
+- For Pod work, name owner and timing when the user needs execution guidance.
+- Use the templates unless the user already gave a required format.
+
+## Standard Output Shape
+
+```markdown
+## Prioritized Impediments
+
+**Scoring:** ROI (1 low → 10 high), Cost (1 cheap → 10 expensive), Ease (1 hard → 10 easy), Risk (1 low → 10 high).
+**Formula:** `Priority = ((ROI * (10/Cost)) + (Ease * (10/Risk))) / 2`
+
+| Rank | Impediment | Countermeasure | ROI | Cost | Ease | Risk | Priority | Rationale |
+|------|------------|----------------|-----|------|------|------|----------|-----------|
+| 1 | [gap] | [action + link] | [n] | [n] | [n] | [n] | [n.n] | ROI: …<br>Cost: …<br>Ease: …<br>Risk: … |
+
+### Top 3 — Act First
+1. **[Impediment]** — [why it wins on the formula + optional ownership tag]
+2. …
+3. …
+```
+
+Use the richer template in [templates/jumpstart-pod-remediation-template.md](./templates/jumpstart-pod-remediation-template.md) when the output must support Jump Start positioning, proposal shaping, or Pod backlog decisions.
+
+## Worked Example (GitHub Enterprise adoption)
+
+| Rank | Impediment | Countermeasure | ROI | Cost | Ease | Risk | Priority | Rationale |
+|------|------------|----------------|-----|------|------|------|----------|-----------|
+| 1 | 2FA not enforced at org level | Enforce org-wide 2FA ([docs](https://docs.github.com/en/organizations/keeping-your-organization-secure/setting-up-two-factor-authentication/requiring-two-factor-authentication-in-your-organization)) | 9 | 2 | 8 | 2 | 42.5 | ROI: removes broad credential-compromise class<br>Cost: admin toggle + member comms<br>Ease: single org setting, members re-enroll<br>Risk: low — can stage with grace period |
+| 2 | Secret scanning disabled | Enable secret scanning + push protection org-wide ([docs](https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning)) | 8 | 3 | 7 | 3 | 25.0 | ROI: catches leaked creds pre-merge<br>Cost: GHAS seats if not bundled (estimated)<br>Ease: org-level default<br>Risk: push-protection may block legitimate commits; stage per repo |
+| 3 | No CODEOWNERS on critical repos | Add CODEOWNERS to top-20 repos ([docs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)) | 6 | 4 | 6 | 4 | 15.0 | ROI: targeted review coverage<br>Cost: team time to define owners (estimated)<br>Ease: file-level change, but requires owner buy-in<br>Risk: review bottlenecks if owners are undersized |
+
+## Assumptions and Guardrails
+
+- Scores are estimates informed by the rubric and any available source or citation. Mark estimated rationales explicitly with `(estimated)`.
+- Never fabricate team size, budget, tool inventory, timelines, or ownership.
+- Final ranking is a recommendation for decision-making. It still needs review by the accountable team.
+- Read-only by default. This skill does not execute remediations.
+- When an item is really a dependency, assumption, or out-of-scope blocker rather than an impediment, label it honestly instead of forcing false precision.
+
+## Validation Checklist
+
+Before finishing, confirm that:
+
+1. Every impediment has exactly one primary countermeasure.
+2. Every score includes a rationale.
+3. The formula was applied verbatim and the rows are sorted descending.
+4. Estimates, assumptions, and unknowns are explicitly labeled.
+5. The output matches the requested delivery context: standard, Jump Start, or Pod.
+
+## Downstream Integration
+
+The ranked table is the core deliverable. Wire it into the user's next artifact as needed: workshop readout, proposal appendix, risk register, delivery backlog, decision log, Jira epic, or architecture review response.

package/.jumpstart/skills/impediment-prioritization/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "impediment-prioritization",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We ran an AI readiness assessment and the weak spots are governance, unclear success metrics, no named pilot users, and unresolved access to the ticket-history data source. Can you prioritize what we should address first and tell me whether this feels like direct Pod build work or a Jump Start or Ignition-style motion first?",
+      "expected_output": "A client-safe prioritized remediation list that scores the items, distinguishes confirmed facts from estimates, and gives a directional engagement implication without overcommitting to implementation.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Turn these workshop findings into a prioritized impediment backlog for a proposal appendix: sponsor alignment is weak, the target use case is still broad, security review timing is unknown, and the team has not agreed what systems are in scope for phase 1. I need a polished markdown output, not just rough notes.",
+      "expected_output": "A Jump Start-oriented output with a ranked table, top actions, and clear assumptions, dependencies, and open questions suitable for proposal support.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "We are already in a Turbo-style Pod motion. Current blockers are no eval harness for prompt changes, platform team has not finalized production secrets access, and nobody owns the runbook and monitoring handoff. Rank these and tell me what the Pod should do now versus what needs adjacent-team help.",
+      "expected_output": "A Pod-delivery style prioritization that includes owner or dependency guidance, sequences immediate execution versus adjacent-team items, and keeps the formula visible.",
+      "files": []
+    }
+  ]
+}

package/.jumpstart/skills/impediment-prioritization/examples/impediment-prioritization-examples.md

@@ -0,0 +1,53 @@
+# Examples
+
+Use these examples to calibrate tone and output shape. They are intentionally short so the skill can adapt them to the user's actual context.
+
+## Example 1: Jump Start readiness gaps
+
+**Input shape:** AI readiness assessment plus discovery notes.
+
+**What the skill should do:**
+- combine overlapping findings
+- prioritize the remediation items
+- explain whether the client is ready for direct Pod build work or needs earlier clarity work
+
+**Example output excerpt:**
+
+| Rank | Impediment | Countermeasure | Source | ROI | Cost | Ease | Risk | Priority | Owner / Timing | Rationale |
+|------|------------|----------------|--------|-----|------|------|------|----------|----------------|-----------|
+| 1 | No agreed success metrics or pilot evaluator group | Define pilot KPIs, baseline measures, and evaluator list during a focused discovery workshop | Readiness assessment + discovery notes | 9 | 2 | 8 | 2 | 42.5 | Sponsor + business owner / before build commitment | ROI: speeds go or no-go decisions and reduces fuzzy backlog debates<br>Cost: small workshop and artifact updates<br>Ease: fast if sponsors attend<br>Risk: without this, later build work lacks acceptance criteria |
+| 2 | Security approval path for knowledge-source access is unclear | Run a security and data-access spike to confirm approval steps, data classes, and blockers | Discovery notes | 8 | 4 | 5 | 6 | 13.3 | Security + platform owner / early engagement | ROI: prevents surprise delivery stalls<br>Cost: multi-stakeholder coordination (estimated)<br>Ease: moderate due to approvals<br>Risk: unresolved access can halt the pilot |
+
+**Why this is good:**
+- It keeps the output advisory.
+- It does not promise implementation scope.
+- It makes the implication clear: do the clarity and approval work before committing to a high-velocity build motion.
+
+## Example 2: Active Pod delivery blockers
+
+**Input shape:** Sprint retrospective plus architect review notes.
+
+**What the skill should do:**
+- rank blockers affecting the current delivery motion
+- include owner and timing
+- distinguish Pod work from client-owned dependencies
+
+**Example output excerpt:**
+
+| Rank | Impediment | Countermeasure | Source | ROI | Cost | Ease | Risk | Priority | Owner / Timing | Rationale |
+|------|------------|----------------|--------|-----|------|------|------|----------|----------------|-----------|
+| 1 | No evaluation harness for answer quality and regression checks | Stand up a lightweight golden set and release-gate evaluation workflow before expanding pilot users | Architect review | 9 | 4 | 6 | 4 | 18.8 | Pod architect + QA / now | ROI: protects learning velocity and release confidence<br>Cost: moderate setup effort<br>Ease: achievable in current motion<br>Risk: low-quality changes may slip into demos or pilot use |
+| 2 | Production monitoring ownership is not agreed | Define telemetry, alert ownership, and handoff responsibilities with client operations before launch planning | Retro + delivery governance notes | 8 | 3 | 5 | 7 | 12.3 | Client ops + Pod lead / next | ROI: reduces launch and support risk<br>Cost: mostly coordination<br>Ease: depends on client availability (estimated)<br>Risk: unclear ownership weakens production readiness |
+
+**Why this is good:**
+- It sequences immediate build enablers before broader operating-model work.
+- It names dependencies plainly instead of silently assigning them to the Pod.
+
+## Example 3: Generic remediation backlog
+
+**Input shape:** Architecture review with explicit recommendations.
+
+**What the skill should do:**
+- score and rank the list
+- keep the output compact
+- call out the top 3 without extra consulting framing when the user does not need it

package/.jumpstart/skills/impediment-prioritization/references/jumpstart-pod-mapping.md

@@ -0,0 +1,74 @@
+# Jump Start and Pod Mapping
+
+Use this reference when the impediments come from readiness work, Jump Start discovery, or an active AI Innovation Pod engagement.
+
+## Positioning lens
+
+This workspace treats prioritization as decision support. The ranking should help the team answer one of these questions:
+
+- What needs to be resolved before we commit to build?
+- What should the Jump Start clarify or de-risk?
+- What should the Pod do now versus hand off to adjacent teams?
+
+## Common Jump Start interpretations
+
+| Pattern in the findings | What it usually means | Typical implication |
+|-------------------------|-----------------------|---------------------|
+| Many gaps are about use-case clarity, sponsorship, value proof, or stakeholder alignment | The client lacks decision readiness more than build capacity | Recommend Jump Start or Ignition-style clarity work first |
+| Gaps cluster around data access, governance, privacy, or security approvals | Delivery may fail or stall without foundation work | Prioritize remediation before or during early engagement and mark dependencies clearly |
+| Findings point to weak current-state understanding or missing success metrics | The path to a defendable backlog is not ready | Focus countermeasures on discovery depth and measurable outcomes |
+| Highest-value actions are architectural, feasibility, or roadmap decisions | The client needs direction rather than throughput | Position the output as advisory and decision-enabling |
+
+## Common Pod interpretations
+
+| Pattern in the findings | What it usually means | Typical implication |
+|-------------------------|-----------------------|---------------------|
+| One use case is prioritized and blockers are mostly around execution details | The motion can stay in Turbo if owners are real and dependencies are manageable | Add owner and timing columns and sequence within current delivery |
+| Top impediments are production controls, scale, governance evidence, or multi-team integration | The work is moving beyond MVP concerns | Call out Overdrive or adjacent-team support without overcommitting |
+| The Pod is blocked by client-owned platform access, approvals, or run-state responsibilities | This is a dependency management problem, not purely a build problem | Name client responsibilities and dependency risk explicitly |
+| The backlog contains many low-readiness items mixed with build tasks | The team is trying to build before the path is stable | Separate advisory closure items from active sprint work |
+
+## Practical mapping cues
+
+Use these cues when describing the next motion.
+
+### Jump Start first
+
+Use when the ranked items are mostly about:
+- business clarity
+- use-case prioritization
+- sponsor alignment
+- value hypothesis definition
+- roadmap or architecture direction
+
+### Ignition
+
+Use when the team needs:
+- feasibility validation
+- architecture review
+- prioritization support
+- risk reduction and decision logs
+
+### Turbo
+
+Use when the team already has:
+- one primary use case or pilot
+- workable backlog direction
+- product owner availability
+- accessible business and platform stakeholders
+
+### Overdrive or adjacent teams
+
+Use when the blockers center on:
+- production hardening
+- enterprise integration
+- governance controls
+- operating model and support readiness
+- multiple business units or regulated rollout constraints
+
+## Guardrails
+
+- Keep Pod language optional when the findings do not justify a Pod recommendation.
+- Do not force every ranked list into a tier recommendation.
+- If the evidence is thin, say the implication is directional.
+- If the blocker is really client-owned infrastructure, release approval, or long-term run-state, say so plainly instead of implying the Pod owns it by default.

package/.jumpstart/skills/impediment-prioritization/references/scoring-rubric.md

@@ -0,0 +1,79 @@
+# Scoring Rubric — Anchoring Examples
+
+Anchor examples for each criterion at scores **1**, **5**, and **10**. Use these to calibrate estimates. Interpolate for intermediate scores.
+
+All scales are 1–10. See the main [SKILL.md](../SKILL.md) for formal definitions and the prioritization formula.
+
+Anchors are drawn from multiple domains — pick the row closest to your countermeasure's character and adjust. If your domain isn't represented, reason by analogy.
+
+---
+
+## Return on Investment (ROI)
+
+*1 = low efficiency gain to the step and value stream. 10 = high efficiency gain.*
+
+| Score | Platform / DevEx | Security | SRE / Ops | App Dev / Governance |
+|-------|------------------|----------|-----------|----------------------|
+| **1** | Cosmetic repo metadata cleanup (description, topics) on low-traffic repos. | Rotating a credential no service actually uses. | Renaming a dashboard widget. | Renaming variables to fix a lint warning nobody reads. |
+| **5** | Adding CODEOWNERS to the top-20 most-active repos — targeted review coverage. | Enabling MFA for a single high-privilege admin group. | Adding SLO alerting to one tier-2 service. | Documenting API contracts for one service via OpenAPI. |
+| **10** | Enforcing 2FA org-wide, enabling secret scanning + push protection, or shipping a CI pipeline to a team that previously merged untested. | Enforcing SSO + MFA enterprise-wide; removing standing admin rights. | Auto-remediating the top-2 pager-driving alert classes. | Replacing a failing manual approval gate with automated policy-as-code. |
+
+## Cost to Implement
+
+*1 = inexpensive (minutes of admin time). 10 = very expensive (multi-quarter program, new licenses, dedicated headcount).*
+
+| Score | Platform / DevEx | Security | SRE / Ops | App Dev / Governance |
+|-------|------------------|----------|-----------|----------------------|
+| **1** | Flipping an org-level toggle — single admin, < 1 hour, no purchase. | Enabling a free advisory scanner in alert-only mode. | Adjusting an alert threshold. | Adding a `CONTRIBUTING.md`. |
+| **5** | Rolling out org-wide rulesets across 50–200 repos — cross-team coordination, a week of engineering, no new SKU. | Implementing a secrets manager for one business unit. | Standing up centralized logging for a mid-size estate. | Refactoring a shared library used by ~10 services. |
+| **10** | Enterprise-wide GHAS rollout on unlicensed repos — new seat purchase, procurement, security-team ownership, training funded for months. | Replacing identity provider; zero-trust program. | Multi-region active/active rearchitecture. | Re-platforming a monolith to services; multi-quarter, funded team. |
+
+## Ease of Deployment
+
+*1 = extremely hard to deploy. 10 = very easy to deploy.*
+
+| Score | Platform / DevEx | Security | SRE / Ops | App Dev / Governance |
+|-------|------------------|----------|-----------|----------------------|
+| **1** | GHES → GHEC migration with custom SAML, self-hosted runners, LFS. Deep cut-over planning, downtime windows. | Enforcing SSO for the first time on a large enterprise without a grace period. | Live database engine swap with zero downtime. | Breaking API change across hundreds of downstream consumers. |
+| **5** | Enabling Dependabot across all active repos — technically simple, operationally non-trivial (PR triage capacity, owner education). | Rolling out EDR agents to a mid-size fleet. | Adding distributed tracing to existing services — library upgrades + coordination. | Moving a shared config to a feature-flag service across ~20 services. |
+| **10** | Adding a `CODEOWNERS` file or enabling auto-delete head branches on a single repo — one commit / one checkbox, immediate effect, trivial rollback. | Toggling secret scanning alerts on one repo. | Adjusting a retry policy in one service. | Adding a README section or a single lint rule. |
+
+## Risk Factor
+
+*1 = low risk to the value stream. 10 = very high risk.*
+
+| Score | Platform / DevEx | Security | SRE / Ops | App Dev / Governance |
+|-------|------------------|----------|-----------|----------------------|
+| **1** | Enabling secret scanning in **alerts-only** mode. No developer-facing block; worst case is noisy alerts. | Adding a passive audit log export. | Adding a new dashboard; read-only. | Adding optional documentation. |
+| **5** | Rolling out required status checks on default branches — can block releases if CI is flaky; recoverable by loosening rules or fixing CI. | Enforcing MFA on a subset of admins with a grace period. | Changing autoscaling thresholds — could over/under-provision temporarily. | Introducing a new required review policy. |
+| **10** | Changing SAML SSO provider or enforcing SSO estate-wide without a grace period. Can lock users out and halt merges across the value stream. | Rotating all production secrets simultaneously without staged cutover. | Cut-over migration of the primary datastore with no parallel run. | Removing a widely-used public API version with no deprecation window. |
+
+---
+
+## Calibration Tips
+
+- **Cross-check**: If ROI is 10 but Cost is also 10, the Priority formula still rewards it when Ease is high and Risk is low. That's intentional — high-leverage, high-investment work remains visible.
+- **Don't anchor Cost on license price alone.** Human-capital time (security triage, onboarding, change management, review burden) dominates most rollouts.
+- **Risk ≠ Cost.** A cheap change (toggle enforcement) can carry very high Risk if staged poorly.
+- **Ease ≠ ROI.** A one-click change with low ROI still ranks modestly; the formula only pushes it up if Risk is also very low.
+- **Estimate explicitly.** When you don't have data or user-confirmed context, score against the anchor and mark the rationale `(estimated)`.
+- **Domain mapping.** If your item doesn't match any column, pick the closest analog (scale of blast radius, reversibility, and human-hours is what matters — not the technology).
+
+---
+
+## Jump Start and Pod Calibration
+
+Use these examples when the items come from discovery, readiness, governance, or active AI delivery.
+
+| Criterion | 1 | 5 | 10 |
+|-----------|---|---|----|
+| **ROI** | Polishing a workshop artifact without changing any decision or unblock path. | Closing one material readiness gap that improves proposal confidence or de-risks a pilot. | Resolving a blocker that unlocks go or no-go clarity, backlog movement, or production readiness across the engagement. |
+| **Cost** | Clarifying an owner, documenting an approval path, or adding a small decision log update. | Running a focused architecture spike, governance workshop, or limited integration validation with several stakeholders. | Multi-team control implementation, enterprise data remediation, or operating-model redesign requiring sustained funded effort. |
+| **Ease** | One team can act with little coordination and easy rollback. | Moderate coordination across sponsor, security, data, and delivery stakeholders. | The action depends on procurement, platform owners, regulatory review, or major cross-team change management. |
+| **Risk** | Deferring the item creates little more than mild inefficiency or reporting noise. | Deferral can delay the engagement, weaken adoption, or create avoidable rework. | Deferral can stall the entire motion, block funding or approvals, or create major production or governance exposure. |
+
+### Quick examples
+
+- **Low-cost, high-ROI Jump Start item:** confirm success metrics and pilot evaluators before proposing a Pod follow-on.
+- **Moderate item:** run a data-access and security approval spike to validate whether the pilot can use the intended knowledge sources.
+- **High-risk item:** establish production monitoring, governance evidence, and support ownership before a regulated rollout.

package/.jumpstart/skills/impediment-prioritization/references/workflow.md

@@ -0,0 +1,95 @@
+# Workflow
+
+Use this reference when the input is not already a clean `{impediment, countermeasure}` list, or when you need to decide how much consulting structure to add around the ranked table.
+
+## 1. Normalize the source
+
+Map common source artifacts into the working shape below.
+
+| Source artifact | Impediment | Countermeasure | Helpful optional fields |
+|----------------|------------|----------------|-------------------------|
+| GHQR or health-check findings | Status gap or control deficiency | Recommendation or expected state | Source link, owner tag, confidence |
+| AI readiness assessment | Dimension-level gap, blocker, or weak capability | Remediation step needed before or during delivery | Readiness score, dimension, evidence |
+| Discovery notes or workshop output | Repeated pain point, missing dependency, unclear decision, or governance gap | Practical next action that reduces ambiguity or risk | Stakeholder, current-state evidence, assumption |
+| Architecture review | Gap between current and target state | Proposed change or staged mitigation | Architectural area, dependency, risk note |
+| Risk register | Risk statement | Mitigation or control | Risk owner, due timing |
+| Pod delivery backlog | Delivery blocker or dependency | Countermeasure that unblocks progress | Owner, sprint timing, adjacent team |
+| Retrospective | What went wrong | Agreed improvement | Team owner, next sprint |
+
+If the input contains only impediments and no countermeasures, propose the primary countermeasure first, then score.
+
+## 2. Collapse duplicates without losing signal
+
+Combine items when they describe the same blocker from different angles.
+
+Examples:
+- "Security has not approved access to ticket history" and "Data access pending security review" should usually become one impediment.
+- "No eval harness" and "We cannot measure answer quality" may combine if the missing evaluation capability is the real issue.
+
+Preserve important nuance in the rationale or optional evidence column.
+
+## 3. Choose the right output mode
+
+### Standard mode
+
+Use this when the user simply wants a ranked list.
+
+Output:
+- Prioritized impediments table
+- Top 3 act first
+
+### Jump Start mode
+
+Use this when the source comes from discovery, readiness, workshop, proposal shaping, or pre-Pod advisory work.
+
+Output:
+- Executive summary
+- Prioritized impediments table
+- Top 3 act first
+- Engagement implication: what should be resolved before Jump Start, during Jump Start, or in a follow-on Pod motion
+- Open questions
+
+### Pod Delivery mode
+
+Use this when the work is already in Ignition, Turbo, or Overdrive and the user needs sequencing.
+
+Output:
+- Prioritized impediments table
+- Top 3 act first
+- Execution lane: now, next, later or sprint-oriented timing
+- Owner and dependency notes
+
+## 4. Countermeasure selection rules
+
+Choose countermeasures that are practical, scope-aware, and appropriate for the current phase.
+
+Good countermeasures:
+- reduce uncertainty or unblock a dependency
+- can be explained and owned by a real team
+- fit the maturity of the engagement
+- avoid implying hidden implementation scope
+
+Weak countermeasures:
+- vague phrases like "improve governance" or "fix data"
+- big-bang replatforming when a staged control or pilot would do
+- actions that assume budget, authority, or access not in evidence
+
+## 5. Scoring guidance for consulting work
+
+When the user is working in Jump Start or Pod context, score with the delivery path in mind.
+
+- ROI: weigh decision acceleration, risk reduction, stakeholder alignment, and unblock value, not only delivery speed.
+- Cost: include client coordination, approvals, change management, and cross-team time, not only build effort.
+- Ease: reflect technical difficulty plus organizational friction.
+- Risk: consider the value-stream impact if the issue is deferred or if the countermeasure is handled badly.
+
+## 6. When to include engagement implications
+
+Add a short implication section when the ranking influences what the client should buy or how the Pod should proceed.
+
+Examples:
+- "These blockers suggest a Jump Start or Ignition-style motion before a Turbo build commitment."
+- "These items fit inside Turbo, but two require adjacent security and platform support."
+- "The highest-ranked items are production hardening and governance controls, which points toward Overdrive or adjacent-team involvement rather than pure MVP work."
+
+Do not turn that implication into a pricing or scope commitment unless the user explicitly asks for it.

package/.jumpstart/skills/impediment-prioritization/templates/jumpstart-pod-remediation-template.md

@@ -0,0 +1,31 @@
+## Executive Summary
+
+[2-4 sentences on what the ranked list says about readiness, risk, or delivery sequencing. Keep this advisory and decision-oriented.]
+
+## Prioritized Impediments
+
+**Scoring:** ROI (1 low -> 10 high), Cost (1 cheap -> 10 expensive), Ease (1 hard -> 10 easy), Risk (1 low -> 10 high).
+**Formula:** `Priority = ((ROI * (10 / Cost)) + (Ease * (10 / Risk))) / 2`
+
+| Rank | Impediment | Countermeasure | Source | ROI | Cost | Ease | Risk | Priority | Owner / Timing | Rationale |
+|------|------------|----------------|--------|-----|------|------|------|----------|----------------|-----------|
+| 1 | [gap or blocker] | [primary action plus citation if available] | [assessment, workshop, review, or backlog source] | [n] | [n] | [n] | [n] | [n.n] | [owner, phase, or dependency] | ROI: ...<br>Cost: ...<br>Ease: ...<br>Risk: ... |
+
+### Top 3 - Act First
+1. **[Impediment]** - [why it wins on the formula and why it matters now]
+2. **[Impediment]** - [why it matters next]
+3. **[Impediment]** - [why it stays in the first wave]
+
+## Engagement Implications
+
+- **Recommended next motion:** [Jump Start, Ignition, Turbo, Overdrive, adjacent-team support, or directional only]
+- **What should happen before build commitment:** [short list]
+- **What can be handled during delivery:** [short list]
+- **Out of scope unless explicitly added:** [short list when relevant]
+
+## Assumptions, Dependencies, and Open Questions
+
+- **Confirmed facts:** [evidence-backed observations]
+- **Assumptions:** [estimated or unconfirmed items]
+- **Dependencies:** [client approvals, platform access, procurement, adjacent teams]
+- **Open questions:** [what still needs confirmation]

package/.jumpstart/skills/impediment-prioritization/templates/prioritized-impediments-template.md

@@ -0,0 +1,18 @@
+## Prioritized Impediments
+
+**Scoring:** ROI (1 low -> 10 high), Cost (1 cheap -> 10 expensive), Ease (1 hard -> 10 easy), Risk (1 low -> 10 high).
+**Formula:** `Priority = ((ROI * (10 / Cost)) + (Ease * (10 / Risk))) / 2`
+
+| Rank | Impediment | Countermeasure | ROI | Cost | Ease | Risk | Priority | Rationale |
+|------|------------|----------------|-----|------|------|------|----------|-----------|
+| 1 | [gap or blocker] | [primary action plus citation if available] | [n] | [n] | [n] | [n] | [n.n] | ROI: ...<br>Cost: ...<br>Ease: ...<br>Risk: ... |
+
+### Top 3 - Act First
+1. **[Impediment]** - [why it should move first]
+2. **[Impediment]** - [why it should move second]
+3. **[Impediment]** - [why it should move third]
+
+### Notes
+- **Confirmed facts:** [only include if needed]
+- **Estimated assumptions:** [only include if needed]
+- **Open questions:** [only include if needed]

package/.jumpstart/skills/integration-surface-mapper/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: integration-surface-mapper
+description: Inventory the systems-of-record, APIs, events, identity providers, auth patterns, network paths, rate limits, and integration risks that an AI build will touch, and produce an integration surface map plus a risk-ranked dependency register. Use this whenever the user needs an integration inventory, API surface review, system-of-record map, identity and auth review, or a check on whether a proposed AI agent or workflow can actually reach the systems it needs, even when phrased as "what systems does this hit," "is the API ready," "can the agent log in," or "what integrations do we need."
+argument-hint: Paste the AI use case, candidate systems, known APIs, identity providers, auth patterns, and any integration constraints already known.
+---
+
+# Integration Surface Mapper
+
+## Positioning
+
+Use this skill to surface the integration reality behind a proposed AI build before it gets committed to a Jump Start scope or Pod backlog. The output should let an architect, Pod lead, or seller see, system by system, what the agent or workflow needs, what already exists, and what is at risk.
+
+Bias toward concrete dependency calls (auth model, throughput, owner, contract) over generic "we'll integrate with X."
+
+## When To Use This
+
+- The user is shaping or hardening an AI use case that touches multiple systems.
+- The team needs to know whether existing APIs, events, or auth patterns can support the workflow.
+- The Pod or Jump Start needs an integration risk register before SOW or PRD freeze.
+- Phrased as "what does this hit," "what integrations do we need," "is the API ready," or "what's the auth path."
+
+## When Not To Use This Alone
+
+- Do not use this for end-to-end architecture. Pair with `../solution-architecture-patterns/SKILL.md` or `../azure-architecture-autopilot/SKILL.md`.
+- Do not use this for data-source quality scoring. Use `../data-readiness-assessor/SKILL.md`.
+- Do not use this for full NFR elicitation. Use `../non-functional-requirements-elicitor/SKILL.md`.
+
+## Required Inputs
+
+- AI use case and the agent or workflow steps that need integration,
+- candidate systems-of-record (CRM, ERP, ITSM, EHR, HRIS, custom apps),
+- known APIs, events, queues, file drops, or batch interfaces,
+- identity provider (Entra, Okta, Ping, custom),
+- auth patterns in use (OAuth client credentials, on-behalf-of, SAML, API keys, service accounts),
+- known constraints (rate limits, network egress, regional residency, contractual scope),
+- known integration owners or platform team contacts.
+
+## Working Rules
+
+1. Inventory systems before APIs. A system can have several integration paths; pick the one that fits the use case, do not just take the first API found.
+2. Distinguish read vs. write vs. event vs. tool-call integration patterns.
+3. Capture the auth path in concrete terms: which identity, which scope, who consents, how it rotates.
+4. Treat rate limits and quota as first-class scope risks.
+5. Mark any integration the team has not actually verified as `Assumed` and flag the validation step.
+
+## Workflow
+
+1. Restate the use case and the agent / workflow steps. For each step, identify the system it must reach and the action (read, write, event, lookup, tool-call).
+2. Inventory each system using [templates/integration-surface-template.md](./templates/integration-surface-template.md).
+3. Pick the integration pattern per system (sync API, async event, webhook, scheduled batch, file, RPA-as-fallback) using [references/integration-pattern-catalog.md](./references/integration-pattern-catalog.md).
+4. Map the auth path per system: identity, scope, consent, rotation.
+5. Score integration risk per system on: maturity, throughput vs. need, auth fit, ownership clarity, contractual fit, blast radius if it fails.
+6. Produce the dependency and risk register with explicit `Confirmed`, `Assumed`, and `Unknown` labels.
+7. Recommend validation steps (test calls, sandbox access, IT/security tickets) before SOW freeze.
+
+## Output Mode
+
+Default artifact:
+
+- Executive summary (overall integration health, top three risks).
+- System and integration inventory table.
+- Per-step → system → pattern → auth mapping.
+- Auth and identity model summary.
+- Rate limit, quota, and throughput summary.
+- Mermaid integration flow diagram.
+- Risk-ranked dependency register.
+- Validation actions before SOW or PRD freeze.
+
+## Style
+
+- Architect-readable; executive-readable summary on top.
+- Prefer short concrete entries over prose.
+- Never present an unverified integration as if it were confirmed.