jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/azure-pricing/references/REGIONS.md

@@ -0,0 +1,84 @@
+# Azure Region Names Reference
+
+The Azure Retail Prices API requires `armRegionName` values in lowercase with no spaces. Use this table to map common region names to their API values.
+
+## Region Mapping
+
+| Display Name | armRegionName |
+|-------------|---------------|
+| East US | `eastus` |
+| East US 2 | `eastus2` |
+| Central US | `centralus` |
+| North Central US | `northcentralus` |
+| South Central US | `southcentralus` |
+| West Central US | `westcentralus` |
+| West US | `westus` |
+| West US 2 | `westus2` |
+| West US 3 | `westus3` |
+| Canada Central | `canadacentral` |
+| Canada East | `canadaeast` |
+| Brazil South | `brazilsouth` |
+| North Europe | `northeurope` |
+| West Europe | `westeurope` |
+| UK South | `uksouth` |
+| UK West | `ukwest` |
+| France Central | `francecentral` |
+| France South | `francesouth` |
+| Germany West Central | `germanywestcentral` |
+| Germany North | `germanynorth` |
+| Switzerland North | `switzerlandnorth` |
+| Switzerland West | `switzerlandwest` |
+| Norway East | `norwayeast` |
+| Norway West | `norwaywest` |
+| Sweden Central | `swedencentral` |
+| Italy North | `italynorth` |
+| Poland Central | `polandcentral` |
+| Spain Central | `spaincentral` |
+| East Asia | `eastasia` |
+| Southeast Asia | `southeastasia` |
+| Japan East | `japaneast` |
+| Japan West | `japanwest` |
+| Australia East | `australiaeast` |
+| Australia Southeast | `australiasoutheast` |
+| Australia Central | `australiacentral` |
+| Korea Central | `koreacentral` |
+| Korea South | `koreasouth` |
+| Central India | `centralindia` |
+| South India | `southindia` |
+| West India | `westindia` |
+| UAE North | `uaenorth` |
+| UAE Central | `uaecentral` |
+| South Africa North | `southafricanorth` |
+| South Africa West | `southafricawest` |
+| Qatar Central | `qatarcentral` |
+
+## Conversion Rules
+
+1. Remove all spaces
+2. Convert to lowercase
+3. Examples:
+   - "East US" → `eastus`
+   - "West Europe" → `westeurope`
+   - "Southeast Asia" → `southeastasia`
+   - "South Central US" → `southcentralus`
+
+## Common Aliases
+
+Users may refer to regions informally. Map these to the correct `armRegionName`:
+
+| User Says | Maps To |
+|-----------|---------|
+| "US East", "Virginia" | `eastus` |
+| "US West", "California" | `westus` |
+| "Europe", "EU" | `westeurope` (default) |
+| "UK", "London" | `uksouth` |
+| "Asia", "Singapore" | `southeastasia` |
+| "Japan", "Tokyo" | `japaneast` |
+| "Australia", "Sydney" | `australiaeast` |
+| "India", "Mumbai" | `centralindia` |
+| "Korea", "Seoul" | `koreacentral` |
+| "Brazil", "São Paulo" | `brazilsouth` |
+| "Canada", "Toronto" | `canadacentral` |
+| "Germany", "Frankfurt" | `germanywestcentral` |
+| "France", "Paris" | `francecentral` |
+| "Sweden", "Stockholm" | `swedencentral` |

package/.jumpstart/skills/azure-pricing/references/SERVICE-NAMES.md

@@ -0,0 +1,106 @@
+# Azure Service Names Reference
+
+The `serviceName` field in the Azure Retail Prices API is **case-sensitive**. Use this reference to find the exact service name to use in filters.
+
+## Compute
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Virtual Machines | `Virtual Machines` |
+| Azure Functions | `Functions` |
+| Azure App Service | `Azure App Service` |
+| Azure Container Apps | `Azure Container Apps` |
+| Azure Container Instances | `Container Instances` |
+| Azure Kubernetes Service | `Azure Kubernetes Service` |
+| Azure Batch | `Azure Batch` |
+| Azure Spring Apps | `Azure Spring Apps` |
+| Azure VMware Solution | `Azure VMware Solution` |
+
+## Storage
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Storage (Blob, Files, Queues, Tables) | `Storage` |
+| Azure NetApp Files | `Azure NetApp Files` |
+| Azure Backup | `Backup` |
+| Azure Data Box | `Data Box` |
+
+> **Note**: Blob Storage, Files, Disk Storage, and Data Lake Storage are all under the single `Storage` service name. Use `meterName` or `productName` to distinguish between them (e.g., `contains(meterName, 'Blob')`).
+
+## Databases
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Cosmos DB | `Azure Cosmos DB` |
+| Azure SQL Database | `SQL Database` |
+| Azure SQL Managed Instance | `SQL Managed Instance` |
+| Azure Database for PostgreSQL | `Azure Database for PostgreSQL` |
+| Azure Database for MySQL | `Azure Database for MySQL` |
+| Azure Cache for Redis | `Redis Cache` |
+
+## AI + Machine Learning
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure AI Foundry Models (incl. OpenAI) | `Foundry Models` |
+| Azure AI Foundry Tools | `Foundry Tools` |
+| Azure Machine Learning | `Azure Machine Learning` |
+| Azure Cognitive Search (AI Search) | `Azure Cognitive Search` |
+| Azure Bot Service | `Azure Bot Service` |
+
+> **Note**: Azure OpenAI pricing is now under `Foundry Models`. Use `contains(productName, 'OpenAI')` or `contains(meterName, 'GPT')` to filter for OpenAI-specific models.
+
+## Networking
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Load Balancer | `Load Balancer` |
+| Azure Application Gateway | `Application Gateway` |
+| Azure Front Door | `Azure Front Door Service` |
+| Azure CDN | `Azure CDN` |
+| Azure DNS | `Azure DNS` |
+| Azure Virtual Network | `Virtual Network` |
+| Azure VPN Gateway | `VPN Gateway` |
+| Azure ExpressRoute | `ExpressRoute` |
+| Azure Firewall | `Azure Firewall` |
+
+## Analytics
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Synapse Analytics | `Azure Synapse Analytics` |
+| Azure Data Factory | `Azure Data Factory v2` |
+| Azure Stream Analytics | `Azure Stream Analytics` |
+| Azure Databricks | `Azure Databricks` |
+| Azure Event Hubs | `Event Hubs` |
+
+## Integration
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Service Bus | `Service Bus` |
+| Azure Logic Apps | `Logic Apps` |
+| Azure API Management | `API Management` |
+| Azure Event Grid | `Event Grid` |
+
+## Management & Monitoring
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Monitor | `Azure Monitor` |
+| Azure Log Analytics | `Log Analytics` |
+| Azure Key Vault | `Key Vault` |
+| Azure Backup | `Backup` |
+
+## Web
+
+| Service | `serviceName` Value |
+|---------|-------------------|
+| Azure Static Web Apps | `Azure Static Web Apps` |
+| Azure SignalR | `Azure SignalR Service` |
+
+## Tips
+
+- If you're unsure about a service name, **filter by `serviceFamily` first** to discover valid `serviceName` values in the response.
+- Example: `serviceFamily eq 'Databases' and armRegionName eq 'eastus'` will return all database service names.
+- Some services have multiple `serviceName` entries for different tiers or generations.

package/.jumpstart/skills/bias-and-anti-pattern-checker/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: bias-and-anti-pattern-checker
+description: 'Audit Jump Start workshop outputs, use-case shortlists, and AI Innovation Pod scoping artifacts for AI-hype, solutionism, single-vendor lock-in, skipped user-validation, governance gaps, and other delivery-killing anti-patterns. Use this whenever the user is about to lock a recommendation, send a readout, or commit a Pod scope and wants a pre-flight integrity check — even when phrased as "sanity check this", "what are we missing", or "is this too AI-hyped".'
+argument-hint: 'Provide the artifact under review (use-case list, readout, scope draft) and the engagement context.'
+---
+
+# Bias And Anti-Pattern Checker
+
+## Positioning
+
+Use this skill as a pre-flight audit. The output is a structured set of flags, each tied to a specific artifact element, with a recommended fix. It is not a critique of the team; it is a defense against the predictable failure modes of AI consulting.
+
+## When To Use This
+
+- Before sending the Jump Start readout.
+- Before locking a Pod scope or SOW.
+- When a use-case list feels suspiciously "AI-shaped".
+- When the team has not yet talked to a real user.
+
+## Typical Need Shapes
+
+- "Sanity check this use-case shortlist before Friday's exec readout."
+- "Is this scope too vendor-locked?"
+- "Did we skip user validation? Audit our discovery."
+- "Is this just AI hype dressed up?"
+
+## When Not To Use This
+
+- Do not use it for stylistic deck critique. Route to `deck-grim-reaper`.
+- Do not use it as the data-readiness check. Route to `data-readiness-assessor`.
+
+## Required Inputs
+
+- Artifact under review (use-case list, readout, scope, architecture, recommendation)
+- Engagement context (industry, stakeholders, prior decisions)
+
+## Evidence And Boundary Discipline
+
+- Tie every flag to a specific quote, item, or claim in the artifact.
+- Distinguish hard flags (must fix) from soft flags (should consider).
+- Recommend a concrete fix — a question to ask, a section to add, a claim to soften, a validation to run.
+- Do not pile on. The point is to ship a better artifact, not to perform skepticism.
+
+## Workflow
+
+1. Run the artifact through the anti-pattern checklist.
+2. For each hit, capture the evidence (quote / element).
+3. Classify severity: blocker, risk, watchout.
+4. Recommend a fix.
+5. Surface the top 3 flags the team should address before going forward.
+
+## Output Structure
+
+1. Artifact under review and audit scope
+2. Top flags (top 3, with severity, evidence, fix)
+3. Full flag log (table: anti-pattern | evidence | severity | fix)
+4. Anti-patterns checked but not found
+5. Recommended next actions
+
+## Reference Files
+
+- Use [anti-pattern-catalog.md](./references/anti-pattern-catalog.md) for the canonical anti-pattern list and how to evidence each.
+
+## Common Pitfalls
+
+### Pitfall 1: Generic Skepticism
+
+Bad: "This feels AI-hyped."
+
+Better: "The use case promises 60% productivity gain with no baseline measure. Replace with: instrument current cycle time before pilot; commit to ±20% range with caveats."
+
+### Pitfall 2: Listing Every Possible Risk
+
+Bad: a 30-item flag dump that buries the real problems.
+
+Better: top-3 ranked, the rest in an appendix log.
+
+### Pitfall 3: Flagging Without A Fix
+
+Bad: "Single-vendor risk."
+
+Better: "Single-vendor risk on Azure OpenAI — recommend exit-cost paragraph in the SOW and one alternative model documented in the architecture appendix."
+
+## Quality Bar
+
+- Every flag is sourced.
+- Severity is assigned.
+- A concrete fix is offered.
+- Top 3 are isolated; the rest do not drown them.

package/.jumpstart/skills/bias-and-anti-pattern-checker/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "bias-and-anti-pattern-checker",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Audit this Jump Start use-case shortlist before Friday's exec readout. Flag anything that's AI-hyped, vendor-locked, or skips user validation.",
+      "expected_output": "Top-3 sourced flags with severity and concrete fixes, plus a full flag log and items checked but not found.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Sanity check this Pod scope draft. We're worried about scope drift and missing governance.",
+      "expected_output": "Specific scope-drift and governance flags tied to scope-draft language, with fixes referencing in/out-of-scope and HITL design.",
+      "files": []
+    }
+  ]
+}

package/.jumpstart/skills/bias-and-anti-pattern-checker/references/anti-pattern-catalog.md

@@ -0,0 +1,79 @@
+# Anti-Pattern Catalog
+
+Canonical anti-patterns to audit Jump Start and AI Innovation Pod artifacts against.
+
+## AI-Hype And Solutionism
+
+- **Solution-shaped problem.** Use case described as "we need an agent" rather than as a workflow problem with a measurable outcome.
+- **Unbaselined gain claims.** "60% productivity improvement" with no current-state baseline or measurement plan.
+- **Magic-words framing.** "Generative AI will transform X" with no specified workflow, user, or decision.
+- **Demo-driven scoping.** Scope shaped by what a vendor demoed last quarter, not by the user's job.
+- **Fix:** require a JTBD or workflow statement, a baseline metric, and a measurable target.
+
+## Single-Vendor Lock-In
+
+- Architecture assumes one model provider, one cloud, one orchestration framework with no exit story.
+- Cost projections only valid at one vendor's current pricing.
+- Skill or staffing implicitly bound to one ecosystem.
+- **Fix:** add an exit-cost section; document at least one alternative model, vector store, or deployment path.
+
+## Skipped User Validation
+
+- Persona built without interviews.
+- Use case prioritized without talking to the people doing the work.
+- Acceptance criteria written by leadership, not the actual user.
+- **Fix:** insert a discovery action with named users, not roles; defer commitments dependent on user signal.
+
+## Governance And Risk Gaps
+
+- No data classification on data in scope.
+- No HITL design for high-stakes outputs.
+- No mention of evals, drift, or observability.
+- No identity or access model for the agent.
+- **Fix:** add governance section with the missing controls; route to `agent-governance` or `ai-agent-deployment-decision-framework`.
+
+## Scope Drift And Silent Expansion
+
+- Pilot promises that imply production support.
+- Integration "stretch goals" that have not been costed.
+- Phrases like "we will also..." without acceptance criteria.
+- **Fix:** name the in-scope and out-of-scope items explicitly; add to assumptions or dependencies.
+
+## Hidden Dependencies
+
+- Data access assumed but not confirmed.
+- Sponsor named but not committed.
+- Third-party integrations without contracts or APIs verified.
+- **Fix:** convert each into a client responsibility or a pre-pilot dependency.
+
+## Measurement Theater
+
+- KPIs that cannot be instrumented (e.g., "user delight" with no signal).
+- Lagging-only metrics with no leading indicator.
+- No plan for how the metric will be measured at pilot and at production.
+- **Fix:** require a measurement plan with instrumentation owner.
+
+## Stakeholder Mono-culture
+
+- All stakeholders from one function (usually IT or business, not both).
+- No risk, security, legal, or end-user voice.
+- **Fix:** name the missing voices and recommend follow-up.
+
+## Pilot-To-Production Cliff
+
+- No plan for graduation criteria, support model, or production cost.
+- "Pilot" used as an excuse to skip every production concern.
+- **Fix:** route to `pilot-to-production-gate` or add explicit gate criteria.
+
+## Severity Classification
+
+- **Blocker:** the artifact should not ship until fixed.
+- **Risk:** must be acknowledged and tracked; can ship with mitigation.
+- **Watchout:** worth noting; not a blocker.
+
+## Fix Discipline
+
+Every flag must include:
+- the evidence (quoted element of the artifact),
+- the severity,
+- the recommended fix (specific addition, edit, or follow-up).

package/.jumpstart/skills/bottom-up-estimation/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: bottom-up-estimation
+description: Build bottom-up software estimates and ROM packages for software, AI, and AI Innovation Pod work. Use this whenever the user asks for a ROM, bottom-up estimate, effort range, proposal sizing, work-package estimate, scoping estimate, AI Pod estimate, MVP estimate, or asks how AI coding tools like GitHub Copilot, VS Code agent workflows, or Autonav should change the estimate. Also use it when the user has rough notes, discovery outputs, or a partial scope and needs them turned into a structured estimate package rather than generic advice.
+---
+
+# Bottom-Up Estimation
+
+Use this skill to turn incomplete opportunity context into a structured bottom-up estimate that can support internal review, proposal shaping, or scoping decisions.
+
+This skill is designed for AI Innovation Pod work first, but it also works for broader software and AI delivery estimates. Default to the Pod delivery model unless the user clearly asks for a traditional-team estimate.
+
+## What this skill is for
+
+Apply this skill when the user asks for any of the following:
+
+- a bottom-up estimate or ROM
+- a work-package estimate for an MVP, pilot, or scoped build
+- a software estimate from rough notes, discovery outputs, or partial scope
+- an AI Innovation Pod estimate with GitHub Copilot, VS Code agent workflows, or Autonav in the delivery model
+- proposal sizing language, estimate assumptions, or estimate mover analysis
+- a comparison between AI Innovation Pod delivery and a regular team, but only when that comparison is explicitly needed
+
+Do not default to fixed-bid pricing language. Keep the output as an estimate range with assumptions unless the user asks for a pricing conversion.
+
+## Bundled references
+
+Use the bundled references to keep outputs consistent:
+
+- Read `references/estimation-methodology.md` when you need the standard reasoning order, effort-shaping rules, or contingency logic.
+- Read `references/ai-pod-adjustment-guide.md` when you need to separate AI-accelerated work from dependency-bound work or explain how Copilot and Autonav change effort.
+- Read `references/output-package-guide.md` when you need the exact output structure or proposal-ready framing.
+- Read `references/pricing-conversion-guide.md` when the user wants the effort estimate translated into a commercial range or proposal pricing logic.
+- Read `references/pod-tier-mapping.md` when the user wants the estimate translated into Ignition, Turbo, or Overdrive motion guidance.
+
+Use the bundled templates when the user wants file-shaped outputs instead of prose-only outputs:
+
+- `templates/estimate-package-template.md` for the narrative package
+- `templates/estimation-worksheet-template.csv` for the work-package worksheet
+
+## Core objective
+
+Produce an estimate package that:
+
+1. defines scope boundaries clearly
+2. breaks the work into work packages
+3. identifies AI-accelerated versus dependency-bound work
+4. estimates low, likely, and high effort
+5. adds non-build effort and contingency explicitly
+6. converts effort into a realistic delivery shape or Pod-capacity view
+7. states the ROM range and the main estimate movers
+
+## Intake checklist
+
+Before estimating, establish as much of this as the prompt allows:
+
+- business objective and target outcome
+- delivery stage: ROM, proposal sizing, or deeper planning estimate
+- expected delivery shape: Pod-led innovation, embedded co-delivery, or accelerate and handoff
+- in-scope workflows, users, and systems
+- data and integration constraints
+- governance, review, or production-readiness expectations
+- whether the user wants effort only, or effort plus pricing conversion
+- whether the user wants AI Pod versus traditional-team comparison
+
+If a missing point materially changes the estimate, ask a short clarifying question. Otherwise proceed with explicit assumptions.
+
+## Required reasoning order
+
+Follow this order every time:
+
+1. Define what is in scope and out of scope.
+2. Identify the delivery shape and ownership boundaries.
+3. Break the solution into work packages.
+4. Classify each package as AI-accelerated, dependency-bound, or mixed.
+5. Estimate low, likely, and high effort for each package.
+6. Apply complexity drivers and adjustment logic where justified.
+7. Add PM, architecture, QA, deployment, governance, UAT support, and contingency.
+8. Convert total effort into timeline using the implied team or Pod shape.
+9. Present the ROM as a range with assumptions, estimate movers, and next discovery questions.
+
+## Default assumptions for AI Innovation Pod work
+
+Unless the prompt clearly contradicts them, assume:
+
+- the Pod is a smaller senior team, not a large specialist program team
+- GitHub Copilot in VS Code, Autonav, and reusable patterns accelerate repeatable engineering work
+- integration access, security review, data availability, UAT, and release approvals do not accelerate at the same rate
+- the estimate is for a focused MVP, pilot, or scoped first release, not enterprise-wide industrialization
+
+## When to include traditional-team comparison
+
+Do not add a traditional-team comparison by default.
+
+Include it only when the prompt asks for one of these:
+
+- comparison to a regular team
+- explanation for sales or leadership on why the Pod estimate differs
+- side-by-side estimate framing
+- AI Pod versus staff augmentation positioning
+
+When included, keep the comparison brief and decision-oriented.
+
+## Required output package
+
+For substantial requests, produce these sections unless the user asks for a narrower deliverable:
+
+### Estimate framing
+
+State the business objective, the delivery shape, and the current confidence level.
+
+### Scope boundaries
+
+List what is included and excluded.
+
+### Work-package estimate table
+
+Show the major work packages and their low, likely, and high effort.
+
+### AI acceleration assessment
+
+Separate AI-accelerated work from dependency-bound work and explain the consequences.
+
+### Non-build effort and contingency
+
+State what add-ons were applied and why.
+
+### Capacity and timeline
+
+Convert effort into a realistic timeline based on the implied team shape.
+
+### ROM range
+
+State the effort range and, if requested, a pricing range.
+
+### Commercial translation
+
+If the user asks for it, translate effort into a commercial range using explicit pricing assumptions instead of pretending the range is objective.
+
+### Estimate movers
+
+Call out the factors that would move the estimate up or down.
+
+### Pod tier mapping
+
+If the user asks for it, explain whether the estimate best fits Ignition, Turbo, Overdrive, or a broader delivery motion.
+
+### Proposal-ready narrative
+
+End with a short narrative the user can reuse in internal review or proposal drafting.
+
+## File-shaped outputs
+
+When the user wants reusable artifacts or when you are saving files in a workspace, emit separate sibling files with these default names instead of keeping everything inside one response:
+
+- `response.md` for the narrative package
+- `estimation-worksheet.csv` for the work-package table
+
+If the prompt is narrower, emit only what applies, but still favor reusable files over long fenced blocks.
+
+## Output quality rules
+
+- Prefer ranges over single-number certainty.
+- Separate assumptions from facts.
+- State ownership boundaries if another team or the client must do part of the work.
+- Do not claim AI acceleration for work that is clearly approval-bound or dependency-bound.
+- Keep the estimate grounded in delivery reality rather than marketing language.
+- If the prompt is early-stage and ambiguous, increase contingency instead of pretending clarity.
+
+## Estimate heuristics
+
+Use these defaults unless better information is provided:
+
+- repeatable code-heavy work compresses materially under AI-native delivery
+- enterprise integrations compress only modestly
+- governance, approvals, UAT, and production hardening compress very little
+- early ROMs should carry enough contingency to absorb scope and dependency uncertainty
+
+## Using the templates
+
+If the user wants a reusable package, mirror the headings from `templates/estimate-package-template.md` and the columns from `templates/estimation-worksheet-template.csv`.
+
+If the user provides rough notes, normalize them into the template structure instead of preserving the rough order.

package/.jumpstart/skills/bottom-up-estimation/evals/evals.json

@@ -0,0 +1,41 @@
+{
+  "skill_name": "bottom-up-estimation",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Create a bottom-up ROM for an AI Innovation Pod delivering a six-week MVP for an internal knowledge assistant. The client has one clean SharePoint source, a small web front end, basic authentication, and wants an estimate package they can use in internal proposal review.",
+      "expected_output": "A structured AI Innovation Pod estimate with scope boundaries, work packages, AI-accelerated versus dependency-bound work, low likely high effort ranges, contingency, timeline, ROM framing, and proposal-ready narrative.",
+      "files": [],
+      "expectations": [
+        "The output includes explicit scope boundaries or included and excluded scope.",
+        "The output breaks the estimate into work packages rather than only giving one blended number.",
+        "The output distinguishes AI-accelerated work from dependency-bound work.",
+        "The output provides a low, likely, and high effort range or equivalent range-based estimate.",
+        "The output includes assumptions, contingency logic, or estimate movers."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Turn these rough notes into a bottom-up estimate for an AI Innovation Pod pilot: two agentic workflows, unknown data quality, one legacy ticketing integration, governance review required, and a likely handoff to another team after the pilot. Keep the result as a ROM range with assumptions and discovery questions.",
+      "expected_output": "A structured estimate that surfaces ambiguity, uses explicit assumptions, includes delivery-shape and handoff boundaries, and does not overclaim acceleration where dependencies are uncertain.",
+      "files": [],
+      "expectations": [
+        "The output calls out uncertainty around data quality, governance, or integration dependencies.",
+        "The output includes delivery shape, handoff, or ownership boundary language.",
+        "The output does not present the estimate as a fixed single-point commitment.",
+        "The output includes next discovery questions or estimate movers."
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Help me explain the difference between an AI Innovation Pod estimate and a regular team estimate for a proposal. I want a bottom-up estimate first, then a brief side-by-side comparison to justify why Copilot in VS Code and Autonav change some parts of the effort but not governance or integration drag.",
+      "expected_output": "A bottom-up estimate package plus a concise optional comparison section showing where AI-native delivery changes effort and where it does not.",
+      "files": [],
+      "expectations": [
+        "The output contains a bottom-up estimate before the comparison section.",
+        "The output includes a concise AI Innovation Pod versus regular team comparison because the prompt explicitly asked for it.",
+        "The comparison explains that AI tooling changes repeatable engineering work more than governance or integration drag."
+      ]
+    }
+  ]
+}

package/.jumpstart/skills/bottom-up-estimation/references/ai-pod-adjustment-guide.md

@@ -0,0 +1,46 @@
+# AI Pod Adjustment Guide
+
+Use this reference when the estimate assumes AI Innovation Pod delivery.
+
+## Core positioning
+
+The AI Innovation Pod is not a generic software team with a lower price point. It is a smaller senior delivery model that uses AI-native tooling and reusable engineering patterns to compress repeatable work.
+
+## AI-accelerated work
+
+These categories often compress meaningfully:
+
+- code scaffolding
+- standard frontend or API implementation
+- prompt drafting and iteration
+- test generation starter sets
+- documentation and handoff drafting
+- backlog synthesis and structured estimation support
+- evaluation harness setup using known patterns
+
+## Dependency-bound work
+
+These categories usually do not compress much:
+
+- client data access
+- enterprise source system availability
+- security and governance approvals
+- UAT scheduling and signoff
+- production release approvals
+- policy decisions and compliance interpretation
+
+## Typical adjustment logic
+
+| Work Type | Typical AI Pod Adjustment |
+| --- | ---: |
+| Boilerplate-heavy build work | 40% to 60% of traditional effort |
+| Standard frontend or API work | 50% to 75% |
+| Prompt engineering and evaluation setup | 60% to 80% |
+| Complex integrations | 80% to 110% |
+| Governance, UAT, production hardening | 90% to 120% |
+
+Use those ranges as judgment aids rather than as hard-coded formulas.
+
+## Communication guidance
+
+When explaining the estimate, say that Copilot, VS Code agent workflows, and Autonav are accelerators, not scope eliminators. They reduce effort in repeatable engineering work but do not remove the need for senior design judgment, integration validation, governance, or client decisions.