jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/roi-calculator-builder/references/ai-cost-categories.md

@@ -0,0 +1,112 @@
+# AI Cost Categories (TCO Stack)
+
+Use this reference to build a complete cost stack for an AI use case. AI TCO is dominated by recurring costs that generic IT models miss — model usage, eval, observability, governance, and adoption. Never zero these out to make ROI look better.
+
+Group costs into one-time build cost and ongoing run-rate. Show both per year across the horizon.
+
+## A. One-time build cost
+
+### A1. Discovery / Jump Start
+
+Workshop fees, discovery effort, value-case shaping, data readiness assessment.
+
+### A2. Pod or build delivery
+
+Engineering, design, architecture, and PM effort to deliver the MVP or pilot. State whether estimated using `bottom-up-estimation` or another approach.
+
+### A3. Data preparation
+
+Source identification, cleansing, chunking, labeling, golden-set creation, redaction, and any data contract work.
+
+### A4. Integration build
+
+API, identity, secrets, and data-pipeline work for systems-of-record. Often underestimated.
+
+### A5. Initial governance and RAI sign-off
+
+DPIA, RAI impact assessment, security review, model risk review (especially for FS / healthcare).
+
+### A6. Initial change management
+
+Persona research, training material, comms, role redesign.
+
+## B. Ongoing run-rate (per year)
+
+### B1. Model usage
+
+Token costs at expected volume. Model with three points: low / base / high token volume per user per month, multiplied by users and price per million tokens. State the model and pricing tier assumed and flag that pricing may change.
+
+Variables:
+- prompts per user per period
+- input tokens per prompt (system + retrieved context + user input)
+- output tokens per response
+- model and pricing tier (frontier vs. small vs. fine-tuned)
+- caching assumptions (prompt caching, semantic cache hit rate)
+
+### B2. Retrieval / vector / search infra
+
+Vector store (managed or self-hosted), index storage, query volume, hybrid search, reranking, embedding regeneration when content changes.
+
+### B3. Hosting and orchestration
+
+Compute for orchestration, queueing, function endpoints, memory store, agent runtime. Networking and egress where relevant.
+
+### B4. Evaluation and observability
+
+Eval set maintenance, regression eval runs on every prompt or model change, tracing and logging, drift monitors, red-team testing. This is recurring, not one-time.
+
+### B5. Governance, RAI, and compliance run-rate
+
+Periodic RAI reviews, audit logging, policy updates, security re-reviews, model-risk re-attestation (where required), regulatory reporting.
+
+### B6. Support and operations
+
+L1/L2 support, incident response runbooks, on-call, prompt and tool maintenance, dataset refresh.
+
+### B7. Change management run-rate
+
+Ongoing training, role-based enablement, internal comms, adoption coaching. Recurring as the user population grows or rotates.
+
+### B8. Licensing
+
+Copilot, Copilot Studio, AI Foundry, third-party SaaS, vector store SaaS, observability SaaS.
+
+### B9. Reserve for model and pricing change
+
+The first model is not the last model. Assume at least one model swap or pricing change inside the horizon and reserve a percentage of run-rate accordingly (commonly 10–20 percent on top of B1–B3).
+
+## C. Costs that often get missed
+
+- Prompt and tool maintenance over time
+- Embedding regeneration when underlying content changes
+- Eval set growth and re-labeling
+- RAI reattestation when models or use cases change
+- Data refresh pipelines for retrieval freshness
+- Internal training for new joiners after rollout
+- Decommission cost if the use case fails
+
+## D. Pricing inputs to state explicitly
+
+When you use placeholder rates, label them:
+
+- Token price per million (state model and date of pricing assumption)
+- Loaded hourly rate per role (state whether fully loaded)
+- Vector store cost per million vectors per month
+- Observability cost per ingested GB or per span
+- Pod day rate or blended rate (if pricing conversion is requested — see `bottom-up-estimation`'s `pricing-conversion-guide.md`)
+
+## E. Output pattern
+
+Show costs as a table by year:
+
+| Cost line | Y0 (build) | Y1 | Y2 | Y3 | Source |
+|---|---|---|---|---|---|
+| Pod delivery | ... | ... | ... | ... | estimate |
+| Model usage (base) | ... | ... | ... | ... | hypothesis |
+| Vector / retrieval | ... | ... | ... | ... | benchmark |
+| Eval and observability | ... | ... | ... | ... | hypothesis |
+| Governance and RAI | ... | ... | ... | ... | interview |
+| Change management | ... | ... | ... | ... | hypothesis |
+| Reserve for model change | ... | ... | ... | ... | assumption |
+
+State which lines are hypothesis and therefore candidates for sensitivity flexing.

package/.github/skills/roi-calculator-builder/references/risk-adjusted-roi.md

@@ -0,0 +1,76 @@
+# Risk-Adjusted ROI
+
+AI use cases carry risks that classic IT ROI models do not. A defensible business case applies an explicit risk discount and shows the adjusted view alongside the unadjusted view.
+
+The point is not to make the number smaller for its own sake. The point is to show the sponsor that the risk has been thought about, quantified, and the case still holds.
+
+## The three discounts
+
+Apply each discount as a multiplier on the relevant benefit lines, not on costs.
+
+### 1. Accuracy discount
+
+How much of the modeled benefit actually realizes given expected accuracy of the AI output.
+
+Reasoning:
+- If the AI must be right 100 percent of the time and is 92 percent accurate, the 8 percent error path eats into benefits via rework, escalation, or shadow review.
+- For high-stakes workflows, even small accuracy gaps compound.
+
+Pattern:
+- accuracy-adjusted benefit = gross benefit × (accuracy − required_accuracy_floor) / (1 − required_accuracy_floor), bounded at 0
+- or simpler: gross benefit × expected accuracy, with a separate line item for the cost of the error path (review, rework, escalation)
+
+State the assumed accuracy and how it was estimated (eval set, comparable rollout, hypothesis).
+
+### 2. Adoption discount
+
+How much of the eligible user population actually uses the system at the assumed frequency, given organizational and behavioral friction.
+
+Pattern:
+- adoption-adjusted benefit = gross benefit × adoption rate × usage frequency factor
+
+State the adoption rate and the basis (comparable rollout, change-readiness assessment, hypothesis). Adoption is consistently the single biggest reason AI ROI underdelivers — do not skip this.
+
+### 3. Dependency discount
+
+How much benefit is at risk because of integration, data, vendor, or governance dependencies that the Pod does not control.
+
+Pattern:
+- dependency-adjusted benefit = gross benefit × (1 − dependency risk factor)
+
+The dependency risk factor is a judgment call. A pragmatic approach:
+
+| Dependency posture | Factor |
+|---|---|
+| Clean access, owner identified, integration tested | 0.05–0.10 |
+| Access ambiguous, owner unclear, integration unproven | 0.15–0.25 |
+| Multiple unowned dependencies, governance gates unscheduled | 0.30+ |
+
+State the named dependencies and which ones drive the factor.
+
+## Combined risk-adjusted view
+
+Apply the three discounts in sequence on the relevant benefit lines:
+
+risk-adjusted benefit = gross benefit × accuracy factor × adoption factor × (1 − dependency risk factor)
+
+Recompute ROI, payback, and NPV using the adjusted benefits and report alongside the unadjusted base case.
+
+## Output pattern
+
+| Metric | Base case | Risk-adjusted | Drivers of the adjustment |
+|---|---|---|---|
+| 3-yr ROI | 180% | 110% | adoption 0.65, accuracy 0.92, dependency 0.15 |
+| Payback | 11 months | 14 months | same |
+| NPV @ 10% | $4.2M | $2.6M | same |
+
+If the risk-adjusted case is still positive, state that explicitly — that is the strongest sentence in the business case.
+
+If the risk-adjusted case is negative or marginal, say so and recommend the discovery actions that would reduce the discount factors (for example: validate adoption with a comparable rollout, run an accuracy eval on a representative sample, name dependency owners and confirm integration ownership).
+
+## What not to do
+
+- Do not apply the risk discount to costs. Costs are what they are.
+- Do not present the risk-adjusted number alone — always show alongside the base case so the sponsor sees both.
+- Do not assume 100 percent adoption or 100 percent accuracy. There is no AI rollout where both are true.
+- Do not invent precise risk factors. State them as judgment with a basis and offer to tighten them with named discovery actions.

package/.github/skills/roi-calculator-builder/references/roi-methodology.md

@@ -0,0 +1,93 @@
+# ROI Methodology
+
+Use this reference when building any ROI/TCO model. It defines the reasoning order, formulas, and benefit-realization logic.
+
+## Reasoning order
+
+1. Frame the use case (workflow, users, decision, horizon).
+2. Establish a baseline with labeled sources.
+3. Define the AI intervention — what step or outcome changes.
+4. Quantify benefits per category using `users × frequency × baseline × uplift × realization`.
+5. Build the cost stack (see `ai-cost-categories.md`).
+6. Compute headline metrics: ROI, payback, NPV, optionally IRR.
+7. Run sensitivity (see `sensitivity-analysis-guide.md`).
+8. Apply risk adjustment (see `risk-adjusted-roi.md`).
+9. Compare scenarios (do-nothing, proposed, optional buy and scale).
+10. Write the defensible narrative and the next-discovery questions.
+
+## Source labels
+
+Every benefit and cost line should carry a label so the reader can retrace it:
+
+- `logged` — pulled from a system, ticketing tool, or telemetry
+- `interview` — stated by an SME or workflow owner
+- `benchmark` — taken from an industry or analyst benchmark (cite source)
+- `hypothesis` — assumed for the model and needs validation
+
+If a line is `hypothesis`, it is a candidate variable for sensitivity analysis.
+
+## Formulas
+
+### ROI (simple)
+
+$$
+\text{ROI \%} = \frac{\text{Net Benefits}}{\text{Total Costs}} \times 100
+$$
+
+Net benefits = total benefits over horizon − total costs over horizon.
+
+### Payback period
+
+The first month or year in which cumulative net cash flow turns positive. State it in months for pilots and years for scale-ups.
+
+### NPV
+
+$$
+\text{NPV} = \sum_{t=0}^{T} \frac{CF_t}{(1+r)^t}
+$$
+
+Where $CF_t$ is the net cash flow in period $t$ and $r$ is the discount rate. Default to client WACC if known; otherwise use a labeled placeholder (often 8–12 percent for enterprise IT).
+
+### IRR
+
+Only include IRR if the user asks. State that IRR is unstable for short horizons and small cash flows and should be read alongside NPV, not instead of it.
+
+## Benefit-realization curve
+
+AI benefits do not start on day 1. Apply a realization factor to each year:
+
+| Year | Default realization | Notes |
+|---|---|---|
+| Year 0 (build) | 0 percent | benefits not yet flowing |
+| Year 1 | 40–70 percent | depends on adoption ramp and rollout phasing |
+| Year 2 | 80–95 percent | steady state if adoption holds |
+| Year 3 | 90–100 percent | mature; may decline if model drift unaddressed |
+
+Ramp slower for workflows that require behavior change or training. Ramp faster for workflows where AI is silently inserted into an existing tool.
+
+## Three-point ranges
+
+For each meaningful driver, model low / base / high. Examples:
+
+- Adoption rate: 30 / 55 / 75 percent of eligible users
+- Time saved per task: 2 / 5 / 9 minutes
+- Error reduction: 10 / 25 / 40 percent
+- Model run-rate: high / base / low based on token volume assumption
+
+The base case is what you defend. The low and high cases bound the conversation.
+
+## Headline metric pattern
+
+State headline metrics like this:
+
+> Base case: 3-year ROI of 180 percent, payback in 11 months, NPV of $4.2M at a 10 percent discount rate.
+> Low case: ROI 60 percent, payback 22 months. High case: ROI 320 percent, payback 7 months.
+> Risk-adjusted base case (after accuracy and adoption discounts): ROI 110 percent, payback 14 months.
+
+## Anti-patterns
+
+- Single-point ROI numbers with no range.
+- Treating year 1 benefits as full steady-state.
+- Comparing AI build cost to a baseline of zero rather than the real cost of the current process.
+- Hiding model, eval, or governance run-rate to make payback look faster.
+- Reporting IRR without NPV.

package/.github/skills/roi-calculator-builder/references/sensitivity-analysis-guide.md

@@ -0,0 +1,72 @@
+# Sensitivity Analysis Guide
+
+Sensitivity analysis is what separates a defensible model from a marketing slide. Without it, the headline number depends on assumptions the reader cannot see.
+
+## Goal
+
+Show the reader which 3–5 variables actually move the answer, by how much, and at what point the use case stops paying back.
+
+## Variables to flex first
+
+These are the variables that almost always dominate AI ROI sensitivity. Start here:
+
+1. **Adoption rate** — percent of eligible users who actually use the system at the assumed frequency.
+2. **Time saved per task** (or equivalent uplift metric for the workflow).
+3. **Token volume per user per month** (drives model run-rate).
+4. **Error reduction percent** (when the case relies on quality lift).
+5. **Realization curve** — how fast benefits ramp in year 1.
+6. **Loaded hourly rate** — when the case relies on labor productivity.
+7. **Conversion rate from hours saved to cash** — only relevant if the client is committing to actual headcount or contractor reduction.
+
+## Patterns
+
+### One-way sensitivity
+
+Hold all variables at their base case, flex one variable across its low / high range, and report the impact on ROI and payback.
+
+Output format:
+
+| Variable | Low | Base | High | ROI at low | ROI at high | Δ ROI |
+|---|---|---|---|---|---|---|
+| Adoption rate | 30% | 55% | 75% | ... | ... | ... |
+| Time saved per task | 2 min | 5 min | 9 min | ... | ... | ... |
+
+### Tornado chart (ranked one-way)
+
+Rank the one-way deltas largest to smallest. The top of the tornado is the variable the model is most sensitive to and therefore the variable to validate first in discovery.
+
+### Two-way sensitivity
+
+When two variables interact strongly (commonly adoption × time-saved, or token volume × prompts per user), show a 3×3 grid of ROI outcomes:
+
+|  | Adoption 30% | Adoption 55% | Adoption 75% |
+|---|---|---|---|
+| Time saved 2 min | ... | ... | ... |
+| Time saved 5 min | ... | ... | ... |
+| Time saved 9 min | ... | ... | ... |
+
+Highlight the cells where ROI turns negative or payback exceeds the horizon.
+
+### Breakeven / "what has to be true"
+
+Solve for the value of each key variable at which NPV = 0 or payback = horizon. State as: "Adoption must reach at least 28 percent for the case to break even at a 10 percent discount rate."
+
+This framing is highly defensible because it lets the sponsor judge whether the breakeven assumption is achievable.
+
+### Monte-Carlo-lite
+
+If the user wants probabilistic framing, model 3–5 key variables as triangular distributions (low / base / high) and report the percent of trials in which NPV is positive. Do not over-engineer — a 1,000-trial sample is plenty for a directional answer.
+
+## What to flag
+
+- Variables where the low case turns NPV negative or pushes payback beyond the horizon. These are the variables to validate first.
+- Variables that look high-impact but are actually dominated by another variable in the two-way view.
+- Variables labeled `hypothesis` in the benefit and cost worksheets — these are by definition unvalidated and belong in sensitivity.
+
+## Output pattern
+
+End the sensitivity section with:
+
+- a tornado-style ranking of the top 3–5 variables
+- one or two breakeven statements ("X must be at least Y for the case to clear breakeven")
+- a recommended next-discovery action for each top variable (run a usage log pull, do a 5-user time study, get token estimates from a comparable rollout, etc.)

package/.github/skills/roi-calculator-builder/templates/roi-model-template.md

@@ -0,0 +1,132 @@
+# ROI Model — [Use Case Name]
+
+## Business case framing
+
+- **Use case**: [named workflow and decision being supported]
+- **User population**: [count, role, geography]
+- **Time horizon**: [typically 3 years; 1 year for pilots]
+- **Currency**: [USD / EUR / ...]
+- **Discount rate**: [client WACC if known; otherwise labeled placeholder, e.g., 10% (assumed)]
+- **Fiscal calendar alignment**: [calendar year / client FY]
+- **Confidence level**: [pre-discovery / post-Jump Start / post-pilot]
+
+## Baseline
+
+Today's cost, throughput, error rate, or revenue contribution for the affected workflow.
+
+| Baseline metric | Value | Source |
+|---|---|---|
+| [e.g., tickets per month] | [n] | [logged / interview / benchmark / hypothesis] |
+| [current cycle time] | [n] | [...] |
+| [current error rate] | [n] | [...] |
+| [loaded hourly rate] | [n] | [...] |
+
+## AI intervention
+
+What the AI does in this workflow. Which step or outcome changes. Which step does **not** change.
+
+## Benefit model
+
+For each benefit line: `users × frequency × baseline × uplift × realization`. State category (cash / capacity / risk-avoidance) and source label.
+
+| Benefit line | Category | Y1 | Y2 | Y3 | Source | Notes |
+|---|---|---|---|---|---|---|
+| [labor productivity — first-line tickets] | capacity | ... | ... | ... | hypothesis | reallocated, not cash |
+| [throughput — tickets resolved] | cash | ... | ... | ... | logged | demand-bound |
+| [quality — escalation reduction] | cash | ... | ... | ... | interview | net of new error class |
+| [revenue lift — conversion] | cash | ... | ... | ... | hypothesis | gross-margin adjusted |
+| [risk avoidance — compliance miss] | risk | ... | ... | ... | benchmark | probabilistic |
+
+**Total benefits by year**: Y1 [...] / Y2 [...] / Y3 [...]
+
+## Cost stack (TCO)
+
+| Cost line | Y0 (build) | Y1 | Y2 | Y3 | Source |
+|---|---|---|---|---|---|
+| Discovery / Jump Start | ... | — | — | — | quoted |
+| Pod or build delivery | ... | — | — | — | bottom-up estimate |
+| Data preparation | ... | — | — | — | hypothesis |
+| Integration build | ... | — | — | — | estimate |
+| Initial governance / RAI | ... | — | — | — | interview |
+| Initial change management | ... | — | — | — | hypothesis |
+| Model usage (base) | — | ... | ... | ... | hypothesis |
+| Vector / retrieval | — | ... | ... | ... | benchmark |
+| Hosting / orchestration | — | ... | ... | ... | benchmark |
+| Eval / observability | — | ... | ... | ... | hypothesis |
+| Governance / RAI run-rate | — | ... | ... | ... | interview |
+| Support / operations | — | ... | ... | ... | hypothesis |
+| Change management run-rate | — | ... | ... | ... | hypothesis |
+| Licensing | — | ... | ... | ... | quoted |
+| Reserve for model / pricing change | — | ... | ... | ... | assumption |
+
+**Total costs by year**: Y0 [...] / Y1 [...] / Y2 [...] / Y3 [...]
+
+## Headline metrics
+
+| Metric | Low | Base | High |
+|---|---|---|---|
+| 3-year ROI | ...% | ...% | ...% |
+| Payback period | ... | ... | ... |
+| NPV @ [r]% | ... | ... | ... |
+| IRR (optional) | ... | ... | ... |
+
+State the base case in plain language:
+
+> Base case: 3-year ROI of [X]%, payback in [Y] months, NPV of [$Z] at a [r]% discount rate.
+
+## Sensitivity analysis
+
+Top variables, ranked by impact on ROI:
+
+| Variable | Low | Base | High | ROI at low | ROI at high | Δ ROI |
+|---|---|---|---|---|---|---|
+| Adoption rate | ... | ... | ... | ... | ... | ... |
+| Time saved per task | ... | ... | ... | ... | ... | ... |
+| Token volume per user / month | ... | ... | ... | ... | ... | ... |
+| Realization curve (Y1) | ... | ... | ... | ... | ... | ... |
+| Error reduction | ... | ... | ... | ... | ... | ... |
+
+**Breakeven statements**:
+
+- [Variable] must be at least [value] for the case to clear breakeven at the assumed discount rate.
+
+## Risk-adjusted ROI
+
+| Metric | Base case | Risk-adjusted | Adjustment drivers |
+|---|---|---|---|
+| 3-yr ROI | ...% | ...% | adoption [a], accuracy [b], dependency [c] |
+| Payback | ... | ... | same |
+| NPV @ [r]% | ... | ... | same |
+
+State whether the risk-adjusted case still clears the bar. If marginal or negative, list the discovery actions that would reduce the discount factors.
+
+## Scenario comparison
+
+| Scenario | 3-yr cost | 3-yr benefit | Net | Notes |
+|---|---|---|---|---|
+| Do nothing | ... | ... | ... | the cost of the current process continues |
+| Proposed Pod build | ... | ... | ... | base case |
+| Buy / SaaS alternative (optional) | ... | ... | ... | lower control, faster start |
+| Scale-up after pilot (optional) | ... | ... | ... | requires successful pilot exit criteria |
+
+## Defensible narrative
+
+[A short paragraph the sponsor can drop into a proposal, steering committee deck, or funding memo. Include the headline number, the assumptions it depends on, the risk-adjusted view, and what would break it.]
+
+## Open questions and next discovery
+
+1. [Top sensitivity variable] — confirm via [named action]
+2. [Baseline source needing validation] — confirm via [named action]
+3. [Dependency owner not yet named] — confirm with [named stakeholder]
+4. [Adoption assumption] — validate via [comparable rollout, change-readiness assessment]
+5. [Pricing or licensing assumption] — confirm with [vendor or sourcing]
+
+## Appendix: assumptions register
+
+| Assumption | Value | Source label | Sensitivity-tested? |
+|---|---|---|---|
+| Discount rate | [r]% | placeholder / WACC | yes / no |
+| Loaded hourly rate | ... | benchmark | yes / no |
+| Token price per million | ... | vendor pricing as of [date] | yes / no |
+| Adoption rate | ... | hypothesis | yes |
+| ... | ... | ... | ... |

package/.github/skills/roi-calculator-builder/templates/roi-worksheet-template.csv

@@ -0,0 +1,31 @@
+section,line_id,line_name,category,unit,low,base,high,year_0,year_1,year_2,year_3,source_label,sensitivity_tested,notes
+benefit,B1,Labor productivity - first-line tickets,capacity,USD,,,,0,,,,hypothesis,yes,reallocated capacity not cash
+benefit,B2,Throughput - tickets resolved,cash,USD,,,,0,,,,logged,yes,demand-bound
+benefit,B3,Quality - escalation reduction,cash,USD,,,,0,,,,interview,yes,net of new error class
+benefit,B4,Revenue lift - conversion,cash,USD,,,,0,,,,hypothesis,yes,gross-margin adjusted
+benefit,B5,Risk avoidance - compliance miss,risk,USD,,,,0,,,,benchmark,no,probabilistic
+cost,C1,Discovery / Jump Start,one-time,USD,,,,,0,0,0,quoted,no,
+cost,C2,Pod or build delivery,one-time,USD,,,,,0,0,0,bottom-up,no,
+cost,C3,Data preparation,one-time,USD,,,,,0,0,0,hypothesis,yes,
+cost,C4,Integration build,one-time,USD,,,,,0,0,0,estimate,yes,
+cost,C5,Initial governance / RAI,one-time,USD,,,,,0,0,0,interview,no,
+cost,C6,Initial change management,one-time,USD,,,,,0,0,0,hypothesis,yes,
+cost,C7,Model usage,run-rate,USD,,,,0,,,,hypothesis,yes,token volume x price
+cost,C8,Vector / retrieval,run-rate,USD,,,,0,,,,benchmark,yes,
+cost,C9,Hosting / orchestration,run-rate,USD,,,,0,,,,benchmark,no,
+cost,C10,Eval / observability,run-rate,USD,,,,0,,,,hypothesis,yes,recurring not one-time
+cost,C11,Governance / RAI run-rate,run-rate,USD,,,,0,,,,interview,no,
+cost,C12,Support / operations,run-rate,USD,,,,0,,,,hypothesis,yes,
+cost,C13,Change management run-rate,run-rate,USD,,,,0,,,,hypothesis,yes,
+cost,C14,Licensing,run-rate,USD,,,,0,,,,quoted,no,
+cost,C15,Reserve for model / pricing change,run-rate,USD,,,,0,,,,assumption,yes,10-20% on top of B1-B3
+parameter,P1,Adoption rate,driver,percent,0.30,0.55,0.75,,,,,hypothesis,yes,top sensitivity variable
+parameter,P2,Time saved per task,driver,minutes,2,5,9,,,,,hypothesis,yes,
+parameter,P3,Token volume per user per month,driver,tokens,,,,,,,,hypothesis,yes,
+parameter,P4,Realization Y1,driver,percent,0.40,0.55,0.70,,,,,assumption,yes,
+parameter,P5,Realization Y2,driver,percent,0.80,0.90,0.95,,,,,assumption,no,
+parameter,P6,Realization Y3,driver,percent,0.90,0.95,1.00,,,,,assumption,no,
+parameter,P7,Discount rate,driver,percent,,0.10,,,,,,placeholder,no,client WACC if known
+parameter,P8,Accuracy factor,risk,percent,0.85,0.92,0.97,,,,,hypothesis,yes,
+parameter,P9,Adoption factor (risk view),risk,percent,0.40,0.65,0.80,,,,,hypothesis,yes,
+parameter,P10,Dependency risk factor,risk,percent,0.05,0.15,0.30,,,,,judgment,yes,named dependencies drive this

package/.github/skills/scope-creep-detector/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: scope-creep-detector
+description: Compare a current scope draft, SOW, or PRD against discovery notes, transcripts, emails, workshop outputs, and prior versions to surface silent scope expansions, implicit commitments, ambiguity, missing exclusions, and inconsistent acceptance criteria for an AI Innovation Pod or Jump Start engagement. Use this whenever the user needs a scope creep check, SOW vs. discovery diff, hidden-commitment audit, ambiguity scan, or a way to keep the Pod from being held to things never actually scoped, even when phrased as "did we promise that," "is this in scope," "what's drifting," or "audit this SOW against the notes."
+argument-hint: Paste the current scope draft (or SOW / PRD section), the discovery notes / transcripts / emails / workshop outputs, and any prior scope versions if available.
+---
+
+# Scope Creep Detector
+
+## Positioning
+
+Use this skill to protect Pod and Jump Start delivery from silent expansion. The output should let the engagement owner see, line by line, where the current scope is wider, narrower, or fuzzier than what discovery actually supports.
+
+Bias toward concrete diffs and ambiguity calls over generic "watch for scope creep" advice.
+
+## When To Use This
+
+- The user has a scope draft, SOW section, PRD, or backlog and a body of discovery artifacts to compare against.
+- The team needs to harden scope before SOW signature, PRD freeze, or Pod kickoff.
+- Phrased as "did we promise that," "is this in scope," "where did this come from," "is the SOW tight," or "audit this against the notes."
+
+## When Not To Use This Alone
+
+- Do not use this for full SOW critique. Pair with `../sow-proposal-reviewer/SKILL.md`.
+- Do not use this for proposal storytelling. Use `../proposal-narrative/SKILL.md`.
+- Do not use this for raw discovery quality scoring. Use `../discovery-depth-scorecard/SKILL.md`.
+
+## Required Inputs
+
+- current scope draft (SOW scope, PRD, backlog, deliverables list, acceptance criteria),
+- discovery artifacts (notes, transcripts, emails, workshop outputs, exec readouts),
+- prior scope versions if available,
+- any verbal commitments the seller or facilitator remembers.
+
+## Detection Categories
+
+1. Silent expansion — scope item not supported by discovery evidence.
+2. Implicit commitment — verbal promise (in transcripts or emails) not reflected in scope.
+3. Ambiguity — scope language that two reasonable readers will interpret differently.
+4. Missing exclusion — common adjacent ask that is not explicitly out-of-scope.
+5. Acceptance drift — acceptance criteria that exceed or contradict the scoped deliverable.
+6. Dependency gap — scope assumes client / third-party action that is not named with owner and date.
+7. Non-functional drift — NFRs implied in discovery but missing from scope, or vice versa.
+8. Pricing / effort mismatch — scope volume inconsistent with the quoted effort or fee.
+9. Phase boundary blur — Jump Start work that smells like Pod delivery, or vice versa.
+10. AI-specific drift — promises about accuracy, autonomy, or coverage that exceed what the use case can support.
+
+See [references/scope-creep-patterns.md](./references/scope-creep-patterns.md) for canonical examples and the language to use in pushback.
+
+## Workflow
+
+1. Inventory the current scope: deliverables, acceptance criteria, assumptions, exclusions, dependencies, NFRs.
+2. Inventory the discovery evidence: confirmed asks, hypotheses, parking-lot items, verbal commitments.
+3. Diff scope vs. evidence in both directions. Flag items in scope without evidence, and items in evidence not addressed in scope.
+4. Walk the ambiguity, missing exclusion, acceptance drift, and dependency checks.
+5. Score each finding: severity (low / med / high), confidence, and recommended action (tighten language, add exclusion, escalate, accept and document).
+6. Produce the audit using [templates/scope-audit-template.md](./templates/scope-audit-template.md).
+
+## Output Mode
+
+Default artifact:
+
+- Executive summary (overall scope tightness, top three risks).
+- Findings table (category, current scope text, evidence, gap, severity, recommended action).
+- Recommended exclusions and assumptions to add.
+- Recommended acceptance criteria adjustments.
+- Verbal commitments to confirm in writing.
+- Open questions for the seller, facilitator, or sponsor.
+
+## Working Rules
+
+1. Cite evidence (or the absence of it) for every finding.
+2. Distinguish "we promised this" from "the client hopes this."
+3. Treat acceptance criteria as scope. They often expand silently.
+4. Do not strip the client's actual asks; surface them honestly so the team can decide to include, exclude, or defer.
+5. Recommend explicit pushback language only when the gap is concrete and supported.

package/.github/skills/scope-creep-detector/evals/evals.json

@@ -0,0 +1,30 @@
+{
+  "skill_name": "scope-creep-detector",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Audit this SOW scope draft against my discovery notes. Scope says: 'Build a Jump Start prototype agent that drafts responses for customer service inquiries, integrates with Salesforce and similar systems, and is production-ready with SSO. Acceptance: agent accurately answers customer questions across all scenarios.' Discovery notes say: 'Customer wants to test agent on top-3 inquiry types — billing, shipping, returns. They mentioned in the room that broker support would be nice but not critical. Salesforce is the only system in scope. They use Okta. They expect to validate the prototype with a small pilot group.'",
+      "expected_output": "A scope audit identifying ambiguous integration language, acceptance drift, AI-overpromise, missing exclusions, phase boundary blur (Jump Start prototype vs. production-ready), and a verbal commitment (broker support) that needs explicit treatment.",
+      "files": [],
+      "assertions": [
+        {"text": "Audit flags 'and similar systems' as ambiguous and recommends enumerating the systems"},
+        {"text": "Acceptance criterion ('accurately answers across all scenarios') is flagged as AI-overpromise and unbounded"},
+        {"text": "Phase boundary blur (Jump Start prototype labeled 'production-ready with SSO') is flagged"},
+        {"text": "Broker support is identified as a verbal commitment requiring explicit in/out/deferred treatment"},
+        {"text": "Output recommends concrete exclusions to add"},
+        {"text": "Findings include severity and recommended action per item"}
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "The client just sent over their version of the SOW with a new line under deliverables: 'Knowledge transfer to the client team including documentation, training, and 90 days of post-launch hypercare.' Our pricing didn't include hypercare. How do I respond?",
+      "expected_output": "Pricing/effort mismatch finding with recommended response options (re-price, de-scope hypercare, define hypercare boundaries) and pushback language.",
+      "files": [],
+      "assertions": [
+        {"text": "Audit identifies the pricing mismatch explicitly"},
+        {"text": "Output proposes at least two response options (re-price, scope-down, define boundaries)"},
+        {"text": "Recommended pushback language is professional and tied to concrete fact"}
+      ]
+    }
+  ]
+}