jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/database-schema-designer/assets/templates/migration-template.sql

@@ -0,0 +1,60 @@
+-- Migration: YYYYMMDDHHMMSS_descriptive_name.sql
+-- Description: [What this migration does]
+-- Author: [Your Name]
+-- Date: YYYY-MM-DD
+
+-- ============================================================================
+-- UP MIGRATION
+-- ============================================================================
+
+BEGIN;
+
+-- Step 1: Create table
+CREATE TABLE IF NOT EXISTS table_name (
+  id BIGINT AUTO_INCREMENT PRIMARY KEY,
+  column_name VARCHAR(255) NOT NULL,
+  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
+);
+
+-- Step 2: Add indexes
+CREATE INDEX idx_table_column ON table_name(column_name);
+
+-- Step 3: Add foreign keys
+ALTER TABLE table_name
+  ADD CONSTRAINT fk_table_reference
+  FOREIGN KEY (reference_id) REFERENCES other_table(id)
+  ON DELETE CASCADE;
+
+-- Step 4: Data migration (if needed)
+-- UPDATE table_name SET new_column = old_column;
+
+COMMIT;
+
+-- ============================================================================
+-- DOWN MIGRATION
+-- ============================================================================
+
+-- BEGIN;
+-- ALTER TABLE table_name DROP FOREIGN KEY fk_table_reference;
+-- DROP INDEX idx_table_column ON table_name;
+-- DROP TABLE IF EXISTS table_name;
+-- COMMIT;
+
+-- ============================================================================
+-- VALIDATION
+-- ============================================================================
+
+-- Check table exists:
+-- SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
+-- WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'table_name';
+
+-- Check indexes:
+-- SHOW INDEX FROM table_name;
+
+-- ============================================================================
+-- NOTES
+-- ============================================================================
+-- Estimated time: [X seconds on Y rows]
+-- Requires downtime: [Yes/No]
+-- Rollback tested: [Yes/No]

package/.github/skills/database-schema-designer/references/schema-design-checklist.md

@@ -0,0 +1,118 @@
+# Database Schema Design Checklist
+
+Complete checklist for designing and reviewing database schemas.
+
+---
+
+## Pre-Design
+
+- [ ] **Requirements Gathered**: Understand data entities and relationships
+- [ ] **Access Patterns Identified**: Know how data will be queried
+- [ ] **SQL vs NoSQL Decision**: Chosen appropriate database type
+- [ ] **Scale Estimate**: Expected data volume and growth rate
+- [ ] **Read/Write Ratio**: Understand if read-heavy or write-heavy
+
+---
+
+## Normalization (SQL)
+
+- [ ] **1NF**: Atomic values, no repeating groups
+- [ ] **2NF**: No partial dependencies on composite keys
+- [ ] **3NF**: No transitive dependencies
+- [ ] **Denormalization Justified**: If denormalized, reason documented
+
+---
+
+## Table Design
+
+### Primary Keys
+
+- [ ] **Primary Key Defined**: Every table has primary key
+- [ ] **Key Type Chosen**: INT auto-increment or UUID
+- [ ] **Meaningful Keys Avoided**: Not using email/username as PK
+
+### Data Types
+
+- [ ] **Appropriate Types**: Correct data types for each column
+- [ ] **String Sizes**: VARCHAR sized appropriately
+- [ ] **Numeric Precision**: DECIMAL for money, INT for counts
+- [ ] **Dates in UTC**: TIMESTAMP for datetime columns
+
+### Constraints
+
+- [ ] **NOT NULL**: Required columns marked NOT NULL
+- [ ] **Unique Constraints**: Unique columns (email, username)
+- [ ] **Check Constraints**: Validation rules (price >= 0)
+- [ ] **Default Values**: Sensible defaults where appropriate
+
+---
+
+## Relationships
+
+### Foreign Keys
+
+- [ ] **Foreign Keys Defined**: All relationships have FK constraints
+- [ ] **ON DELETE Strategy**: CASCADE, RESTRICT, SET NULL chosen
+- [ ] **ON UPDATE Strategy**: Usually CASCADE
+- [ ] **Indexes on Foreign Keys**: All FKs are indexed
+
+### Relationship Types
+
+- [ ] **One-to-Many**: Modeled correctly
+- [ ] **Many-to-Many**: Junction table created
+- [ ] **Self-Referencing**: Parent-child relationships handled
+- [ ] **Polymorphic**: Strategy chosen (separate FKs or type+id)
+
+---
+
+## Indexing
+
+### Index Strategy
+
+- [ ] **Primary Key Indexed**: Automatic, verify
+- [ ] **Foreign Keys Indexed**: All FKs have indexes
+- [ ] **WHERE Columns**: Columns in WHERE clauses indexed
+- [ ] **ORDER BY Columns**: Sort columns indexed
+- [ ] **Composite Indexes**: Multi-column queries optimized
+- [ ] **Column Order**: Most selective column first
+
+### Index Limits
+
+- [ ] **Not Over-Indexed**: Only necessary indexes
+- [ ] **Index Maintenance**: Aware of write impact
+
+---
+
+## Performance
+
+- [ ] **Joins Optimized**: N+1 queries avoided
+- [ ] **SELECT * Avoided**: Only fetch needed columns
+- [ ] **Pagination**: LIMIT/OFFSET or cursor-based
+- [ ] **Aggregations**: Pre-calculated for expensive queries
+
+---
+
+## Migrations
+
+- [ ] **Backward Compatible**: New columns nullable initially
+- [ ] **Up and Down**: Rollback scripts provided
+- [ ] **Data Migrations Separate**: Schema vs data separated
+- [ ] **Tested on Staging**: Migrations tested
+
+---
+
+## Security
+
+- [ ] **Least Privilege**: Minimal database permissions
+- [ ] **Separate Accounts**: Read-only vs read-write
+- [ ] **Sensitive Data**: Passwords hashed, PII encrypted
+- [ ] **Parameterized Queries**: SQL injection prevented
+
+---
+
+## Documentation
+
+- [ ] **ERD Created**: Entity-relationship diagram
+- [ ] **Schema Documented**: Column descriptions
+- [ ] **Indexes Documented**: Why each index exists
+- [ ] **Migration History**: Changelog of changes

package/.github/skills/dependency-bottleneck-detector/README.md

@@ -0,0 +1,77 @@
+# dependency-bottleneck-detector
+
+Identify, classify, and unblock external dependencies that are stalling or threatening delivery timelines for AI Innovation Pod and Jump Start engagements.
+
+## What This Skill Does
+
+Analyzes delivery situations to find hidden and visible dependency bottlenecks across 12 categories (infrastructure, identity, integration, data, security, legal, decision, people, procurement, client, vendor, organizational), classifies them by severity, recommends specific unblock strategies, and produces escalation-ready communication.
+
+## When to Use
+
+- A sprint is blocked and you need to structure what's happening
+- Client steering committee needs a clear "what we need from you" summary
+- Multiple dependencies are piling up and prioritization is unclear
+- You need escalation messaging for overdue items
+- Sprint planning and you want to proactively detect upcoming dependencies
+- Retrospective reveals recurring dependency patterns
+
+## Skill Structure
+
+```
+dependency-bottleneck-detector/
+├── SKILL.md                              # Core skill instructions
+├── README.md                             # This file
+├── references/
+│   ├── dependency-taxonomy.md            # 12-category taxonomy with examples
+│   ├── unblock-strategies.md             # 10 named strategies with decision criteria
+│   ├── escalation-patterns.md            # Timing, templates, anti-patterns
+│   └── proactive-detection.md            # Early warning signals and prevention
+├── templates/
+│   ├── dependency-bottleneck-report.md   # Full analysis report structure
+│   ├── dependency-inventory.md           # Inventory tracking format
+│   ├── escalation-email.md              # Ready-to-send escalation templates
+│   ├── client-dependency-summary.md     # Client-facing dependency view
+│   └── unblock-action-plan.md           # Prioritized action plan
+├── scripts/
+│   ├── dependency_tracker.py            # CLI tool: add, update, list, report
+│   ├── escalation_timer.py             # Monitor escalation thresholds
+│   └── dependency_scan.py              # Scan docs for undeclared dependencies
+└── evals/
+    └── evals.json                       # 3 realistic evaluation scenarios
+```
+
+## Scripts
+
+All scripts use Python 3 standard library only.
+
+### dependency_tracker.py
+```bash
+python dependency_tracker.py init --engagement "Project Name"
+python dependency_tracker.py add --name "API Key" --category Integration --owner "Platform Team"
+python dependency_tracker.py list --severity Critical
+python dependency_tracker.py overdue --threshold 5
+python dependency_tracker.py report --format markdown
+```
+
+### escalation_timer.py
+```bash
+python escalation_timer.py --file dependency-inventory.json
+python escalation_timer.py --file dependency-inventory.json --output json
+```
+
+### dependency_scan.py
+```bash
+python dependency_scan.py --path ./sprint-plans/
+python dependency_scan.py --path ./notes.md --output json
+```
+
+## Example Prompt
+
+> "We're in week 4 of a 12-week build. Our team is blocked on three things: client hasn't sent test data (2 weeks), security review is overdue by 10 days, and the only person who knows the legacy API is on leave. Help me structure this and figure out what to do."
+
+## Related Skills
+
+- `pre-deployment-gotcha-review` — Catches issues before go-live
+- `risk-assumption-register` — Tracks risks and assumptions across the engagement
+- `scope-creep-detector` — Catches expanding scope that adds new dependencies
+- `impediment-prioritization` — Prioritizes blockers in a sprint context

package/.github/skills/dependency-bottleneck-detector/SKILL.md

@@ -0,0 +1,307 @@
+---
+name: dependency-bottleneck-detector
+description: >-
+  Find external dependencies blocking or threatening delivery and recommend unblocks.
+  Use this skill whenever a Pod, sprint, or delivery team is stuck waiting on something
+  outside their direct control — data access, environment provisioning, SME availability,
+  security review, legal sign-off, client decisions, vendor responses, infrastructure requests,
+  API onboarding, license procurement, credential provisioning, compliance approvals,
+  design authority reviews, change advisory boards, procurement, hiring, training,
+  third-party contracts, or any dependency owned by another team, department, or organization.
+  Also trigger when the user says "what's blocking us", "why are we stuck", "dependency map",
+  "critical path blockers", "unblock this", "waiting on", "bottleneck analysis",
+  "what do we need from the client", "external dependencies", "delivery risk from blockers",
+  or asks to triage, prioritize, escalate, or resolve delivery dependencies even if they
+  do not use the word "dependency" explicitly.
+---
+
+# Dependency Bottleneck Detector
+
+## Purpose
+
+Identify, classify, prioritize, and recommend unblock strategies for external dependencies that are blocking or threatening active delivery. This skill operates during build and delivery phases when the team is actively working and hitting walls that are outside their direct control.
+
+Unlike pre-deployment review (which looks forward at what *could* block), this skill examines what *is* blocking or *will imminently* block if not resolved.
+
+## Positioning Within Jump Start and AI Innovation Pod
+
+This skill is most valuable during:
+- **Sprint 0 / Sprint 1** — When the team discovers that assumed access, environments, or approvals don't exist
+- **Mid-delivery** — When velocity drops because the team is waiting on external parties
+- **Escalation preparation** — When a delivery lead needs to articulate what's stuck and what they need
+- **Client check-ins** — When framing "what we need from you" in a structured way
+- **Risk mitigation** — When spotting dependencies about to become blockers before they do
+
+It complements:
+- `pre-deployment-gotcha-review` — Which finds potential issues before commitment
+- `impediment-prioritization` — Which ranks impediments by impact
+- `risk-assumption-register` — Which tracks risks and assumptions formally
+
+## When to Use
+
+- The team is waiting on something they cannot provide themselves
+- Velocity is dropping and the cause is external
+- Sprint planning reveals tasks that cannot start until something external happens
+- A blocker has existed for more than 2 business days without resolution
+- The delivery lead needs to prepare an escalation
+- The team needs to communicate blockers to client stakeholders
+- A status report needs a clear "what's blocked and why" section
+- The team wants to identify dependencies before they become blockers (proactive scan)
+
+## Dependency Categories
+
+This skill covers ALL types of external dependencies, not just technical ones. The full taxonomy is in `references/dependency-taxonomy.md`, but the major categories are:
+
+### 1. Data and Information
+- Source data access (credentials, network path, permissions)
+- Sample or test data provision
+- Data dictionaries, schemas, or documentation
+- Data quality remediation by source owners
+- Ground truth / labeled data for evaluation
+- Production data access distinct from dev data
+- Data migration or extraction by source team
+
+### 2. Access and Credentials
+- Environment access (dev, staging, production)
+- Service account provisioning
+- API keys, tokens, or certificates
+- VPN or network access grants
+- Cloud subscription or resource group access
+- Repository or code access
+- Third-party system credentials
+- Privileged access for deployment
+
+### 3. Infrastructure and Environments
+- Environment provisioning (compute, storage, networking)
+- CI/CD pipeline setup or access
+- DNS, SSL, or domain configuration
+- Firewall rule changes
+- ExpressRoute / VPN tunnel establishment
+- Container registry or artifact repository access
+- Database provisioning
+- Message queue or event hub setup
+
+### 4. Security and Compliance
+- Security review completion
+- Penetration testing scheduling
+- Compliance sign-off (HIPAA, SOC 2, PCI, FedRAMP)
+- Privacy impact assessment (DPIA)
+- Data classification review
+- Vendor risk assessment for third-party services
+- Security architecture review board approval
+- Encryption key provisioning
+- Certificate issuance
+
+### 5. Identity and Access Management
+- App registration in identity provider
+- OAuth/OIDC configuration
+- Claims mapping
+- Group/role provisioning
+- Conditional access policy exceptions
+- Service principal creation
+- Managed identity setup
+- MFA enrollment for test accounts
+
+### 6. API and Integration
+- API gateway onboarding
+- API key or client certificate provisioning
+- OpenAPI spec availability
+- Sandbox environment access
+- Rate limit increase requests
+- API contract finalization
+- Integration testing environment availability
+- Webhook or callback URL registration
+
+### 7. People and Expertise
+- SME (Subject Matter Expert) availability for interviews or review
+- Business user availability for UAT
+- Architecture review board scheduling
+- Design authority approval
+- Executive sponsor decisions
+- Client product owner availability
+- End-user participation in testing
+- Training completion for team members
+
+### 8. Decisions and Approvals
+- Scope decisions from product owner
+- Budget approval for additional services or licenses
+- Go/no-go decisions from steering committee
+- Technology choice decisions
+- Vendor selection decisions
+- Change Advisory Board (CAB) approval
+- Release approval
+- Legal review of terms or contracts
+
+### 9. Legal and Procurement
+- License procurement (software, model API access, tools)
+- Contract execution (MSA, SOW amendments, DPA)
+- Legal review of AI-specific terms
+- IP assignment or licensing
+- Third-party vendor contracts
+- NDA execution
+- Data processing agreements
+- Model provider BAA (Business Associate Agreement)
+
+### 10. Vendor and Third-Party
+- Vendor support ticket resolution
+- Feature availability from platform provider
+- Vendor onboarding or enablement
+- Partner technical support
+- Open-source library fixes or releases
+- Cloud provider service availability in region
+- Marketplace listing approval
+- Vendor documentation or SDK updates
+
+### 11. Organizational and Process
+- Hiring or staffing for required roles
+- Training or certification completion
+- Change management activities (communications, training materials)
+- Organizational restructuring impacts
+- Policy creation or amendment
+- Standard operating procedure documentation
+- Stakeholder alignment across departments
+
+### 12. Client-Side Dependencies
+- Client team deliverables (content, data, feedback)
+- Client infrastructure readiness
+- Client testing and sign-off
+- Client communication to end users
+- Client change management execution
+- Client-side integration development
+- Client security team engagement
+
+## Core Analysis Approach
+
+### Step 1: Dependency Inventory
+
+For each identified dependency, capture:
+
+| Field | Description |
+|-------|-------------|
+| ID | Unique identifier (DEP-001) |
+| Description | What is needed |
+| Category | From the taxonomy above |
+| Owner | Who can provide it (person, team, org) |
+| Requestor | Who on the delivery team needs it |
+| Status | Not Requested / Requested / In Progress / Blocked / Resolved |
+| Date Requested | When the request was first made |
+| Date Needed | When the delivery team needs it to avoid blocking |
+| Days Waiting | Business days since request |
+| Impact if Delayed | What happens to delivery if this doesn't arrive on time |
+| Blocking | What specific work items are blocked |
+| Priority | Critical Path / High / Medium / Low |
+| Escalation Level | None / Team Lead / Director / VP / Executive |
+
+### Step 2: Critical Path Analysis
+
+Determine which dependencies are on the critical path:
+- Map dependencies to sprint items or work packages
+- Identify which blocked items have downstream dependents
+- Calculate the cascade effect (one blocked item may block 5 others)
+- Distinguish "blocks start" from "blocks completion" from "blocks deployment"
+
+### Step 3: Bottleneck Identification
+
+A bottleneck exists when:
+- Multiple work items depend on the same external party
+- A single dependency has been waiting longer than its SLA
+- The dependency has no clear owner or the owner is unresponsive
+- The approval process has unclear criteria or unknown duration
+- There is no workaround and no fallback
+
+### Step 4: Unblock Recommendations
+
+For each bottleneck, recommend one or more of:
+
+| Strategy | When to Use |
+|----------|-------------|
+| **Escalation** | Owner is unresponsive or SLA is breached |
+| **Parallelization** | Restructure work to avoid the blocked path temporarily |
+| **Stub/Mock** | Build against a contract/interface while waiting for the real thing |
+| **Decomposition** | Break the dependency into smaller parts, some of which may be unblocked |
+| **Alternative Path** | Use a different approach that avoids the dependency entirely |
+| **Advance Request** | Request future dependencies now before they become blockers |
+| **Direct Contact** | The request went to a queue; direct human contact may accelerate |
+| **Decision Forcing** | Frame the cost of delay to force a decision from stakeholders |
+| **Scope Adjustment** | Defer the blocked feature and deliver unblocked work first |
+| **Risk Acceptance** | Proceed with assumption and accept the risk of rework |
+
+### Step 5: Communication Artifacts
+
+Produce artifacts appropriate to the audience:
+- **Status report section** — For weekly client updates
+- **Escalation email** — For blocked items needing management attention
+- **Sprint planning input** — For what can and cannot be started
+- **Risk register entry** — For formal tracking
+- **Decision request** — For items needing stakeholder choice
+
+## Required Output
+
+Produce a structured report following `templates/dependency-bottleneck-report.md`:
+
+1. Executive Summary (what's stuck, what's at risk, what's needed)
+2. Dependency Inventory Table
+3. Critical Path Impact Map
+4. Bottleneck Analysis (the 3-5 most dangerous)
+5. Unblock Recommendations (prioritized by delivery impact)
+6. Escalation Recommendations (who, what, when)
+7. Advance Dependency Requests (get ahead of future blockers)
+8. Client Responsibilities Summary
+9. Decision Log (decisions needed to unblock)
+
+## Severity Classification
+
+| Level | Criteria |
+|-------|----------|
+| **Critical** | Blocks the critical path. Delivery date will slip if not resolved within 2 business days. |
+| **High** | Blocks significant work. Team members are idle or doing low-value work. Will become critical within a sprint. |
+| **Medium** | Blocks specific features or tasks. Can be worked around temporarily but workaround has cost. |
+| **Low** | Inconvenience or quality impact. Delivery can proceed but with technical debt or reduced scope. |
+| **Watch** | Not yet blocking but trending toward a block. Proactive attention needed. |
+
+## Escalation Framework
+
+| Condition | Recommended Action |
+|-----------|-------------------|
+| Waiting > 2 days, no acknowledgment | Direct follow-up to specific person |
+| Waiting > 5 days, acknowledged but no progress | Escalate to team lead / manager |
+| Waiting > 10 days, blocking critical path | Escalate to director level |
+| Waiting > 15 days, delivery date at risk | Escalate to VP / executive sponsor |
+| Multiple items blocked by same org/team | Pattern escalation — request process improvement |
+| Dependency owner is unknown | Discovery escalation — find the right person |
+
+## Proactive Detection Patterns
+
+Don't wait for things to block. Look for early warning signs:
+- Sprint items with unmet preconditions
+- Assumptions in the project plan that haven't been validated
+- Access requests that haven't been submitted yet
+- Approvals that have long SLAs not yet triggered
+- Client deliverables with no due date or owner
+- Vendors with no engagement timeline
+- Security or compliance reviews not yet requested
+- Environment requests not yet submitted
+
+## Reference Files
+
+- [references/dependency-taxonomy.md](references/dependency-taxonomy.md) — Full dependency taxonomy with examples and typical resolution times
+- [references/unblock-strategies.md](references/unblock-strategies.md) — Detailed unblock strategies with templates and examples
+- [references/escalation-patterns.md](references/escalation-patterns.md) — Escalation communication patterns and timing
+- [references/proactive-detection.md](references/proactive-detection.md) — Early warning signals and prevention patterns
+
+## Templates
+
+- [templates/dependency-bottleneck-report.md](templates/dependency-bottleneck-report.md) — Full analysis report
+- [templates/dependency-inventory.md](templates/dependency-inventory.md) — Inventory table format
+- [templates/escalation-email.md](templates/escalation-email.md) — Escalation communication template
+- [templates/client-dependency-summary.md](templates/client-dependency-summary.md) — Client-facing dependency summary
+- [templates/unblock-action-plan.md](templates/unblock-action-plan.md) — Prioritized unblock plan
+
+## Quality Bar
+
+- Every identified dependency must have a specific owner (not "the client" — name the team or role)
+- Impact statements must be concrete (not "could delay delivery" — state what is blocked and by how much)
+- Unblock recommendations must be actionable (not "escalate" — state to whom, with what message, asking for what)
+- The critical path must be explicit — not everything is critical
+- Proactive dependencies should be identified alongside current blockers
+- Communication artifacts should be ready to send, not require further editing

package/.github/skills/dependency-bottleneck-detector/evals/evals.json

@@ -0,0 +1,60 @@
+{
+  "skill": "dependency-bottleneck-detector",
+  "version": "1.0.0",
+  "eval_cases": [
+    {
+      "id": "eval-001",
+      "name": "Enterprise RAG Bot — Multi-Team Dependency Pile-Up",
+      "description": "A RAG chatbot project in a large financial services firm is stuck mid-sprint. The team needs API keys from a legacy gateway team, a security review that is 3 weeks overdue, client sample data that was promised 2 weeks ago, and a decision on PII handling from the legal team. The PM says 'everything is blocked' and wants a clear picture of what to do first.",
+      "input": "We're building a RAG-based internal knowledge bot for a financial services client. Sprint 3 started Monday and we're already stuck on multiple fronts:\n\n1. We need API keys for their Apigee gateway to connect to their document management system. We submitted the request 12 days ago through their ServiceNow portal. The Platform Ops team owns it. No response to our two follow-ups.\n\n2. Security review was submitted 5 weeks ago (they said SLA is 3 weeks). We got one round of questions back at week 2, answered within a day, and haven't heard back. Without security sign-off we can't deploy to their staging environment.\n\n3. Client was supposed to send us sample documents (200 representative PDFs) for testing the chunking and retrieval pipeline. They committed to this at kickoff 3 weeks ago. We've asked twice. The project sponsor says 'the content team is working on it.'\n\n4. Legal team needs to decide whether the bot can surface documents that contain employee PII or whether those need to be filtered. This affects our retrieval logic architecture. No one has raised it formally yet but we know it's coming.\n\n5. Our DevOps person who was going to set up the Azure OpenAI deployment is on paternity leave for 2 more weeks. No one else has the Terraform scripts or the subscription access.\n\nCan you analyze our dependency situation and tell us what to do?",
+      "assertions": [
+        "Output identifies at least 5 distinct dependencies",
+        "Output classifies each dependency by category (Integration, Security, Client, Legal/Decision, People)",
+        "Output assigns severity to each (Apigee and Security should be Critical or High)",
+        "Output provides specific escalation recommendations for the Apigee key (L2+ given 12 days)",
+        "Output recommends an unblock strategy for the DevOps single-point-of-failure (not just 'wait')",
+        "Output identifies the Legal/PII issue as a proactive detection opportunity (not yet formally raised)",
+        "Output prioritizes actions — not just a list but a sequenced plan",
+        "Output suggests parallel workarounds where possible (e.g., mock API for Apigee, synthetic data for client docs)",
+        "Output uses the dependency bottleneck report format or equivalent structure",
+        "Output includes client-facing communication recommendation for the sample data dependency"
+      ]
+    },
+    {
+      "id": "eval-002",
+      "name": "Copilot Extension — Procurement and Licensing Block",
+      "description": "A team building a Copilot extension for a manufacturing client is blocked by procurement processes: licenses haven't been purchased, a vendor contract isn't signed, and the client IT team refuses to grant admin consent for the Graph API permissions needed. The engagement manager asks for help structuring the situation.",
+      "input": "We're in week 4 of a 12-week Copilot extension build for a manufacturing client. We're supposed to be building integrations but we can't actually do anything:\n\n- The client hasn't purchased the Microsoft 365 Copilot licenses for their test users yet. Procurement says it's 'in approval' but they've been saying that for 3 weeks. Without licenses we can't test anything in their tenant.\n\n- We need admin consent for Graph API permissions (Mail.Read, Calendars.Read, Sites.Read.All). The client's IT security team says they need to do a 'vendor security assessment' before granting any Graph permissions to third-party code. They estimate 4-6 weeks for this assessment. We're already in week 4.\n\n- We planned to integrate with their SAP system through a middleware layer. The vendor (MuleSoft) contract renewal lapsed and they can't use the middleware until the contract is re-signed. Legal says 2-3 weeks.\n\n- Our team has 3 developers billing but they're essentially doing design work and documentation while waiting for these to clear. The client is asking why we're billing if we're blocked.\n\nWhat should we do? How do we structure this for the client steering committee next week?",
+      "assertions": [
+        "Output identifies procurement (licenses), security/auth (admin consent), vendor (MuleSoft), and client relationship as distinct dependency categories",
+        "Output assesses the admin consent + vendor assessment timeline against the 12-week engagement and flags the math doesn't work",
+        "Output recommends scope adjustment or timeline extension as a realistic option",
+        "Output suggests concrete parallel work that demonstrates value while blocked (local dev environment, mock integrations, design specs)",
+        "Output provides client-facing framing that is honest without being accusatory ('these are things we need from you')",
+        "Output recommends specific escalation for the license procurement (3 weeks in approval is overdue)",
+        "Output addresses the billing concern directly with a recommendation",
+        "Output structures the steering committee message clearly",
+        "Output identifies the vendor security assessment as the longest-pole dependency and sizes the risk",
+        "Output uses severity classification and recommends a specific unblock strategy for each item"
+      ]
+    },
+    {
+      "id": "eval-003",
+      "name": "Healthcare AI Agent — Regulatory and People Dependencies",
+      "description": "A healthcare AI agent project is facing non-technical dependencies: the compliance officer who must approve the data handling approach is unresponsive, the legal team hasn't finished the BAA amendment, the client's CISO wants a third-party pen test before UAT, and the only person who understands the EHR integration API is leaving the client org in 2 weeks.",
+      "input": "We're building an AI agent that helps clinical staff find relevant patient protocols. It connects to their Epic EHR system and uses Azure OpenAI for summarization. We're in the design-to-build transition and here's what's stalling us:\n\n1. The client's Chief Compliance Officer (CCO) needs to approve our data handling approach — specifically, what PHI we can process, how we handle it in transit and at rest, and our BAA coverage. We sent the data flow document 18 days ago. We've followed up three times. Her EA says she's in back-to-back meetings and will 'get to it when she can.' Without her sign-off, we cannot write a single line of code that touches patient data.\n\n2. Our legal team says the existing BAA needs an amendment to cover the AI processing use case. They sent the amendment to the client's legal team 10 days ago. No response. Our legal contact says this is normal ('legal timelines are what they are').\n\n3. The client's CISO has added a new requirement: third-party penetration test before UAT begins. This wasn't in the SOW. We haven't even identified a pen test vendor yet, and typical lead times are 3-4 weeks once engaged. UAT is supposed to start in 5 weeks.\n\n4. The client has exactly one person — Marcus — who understands the Epic FHIR API configuration in their environment. Marcus gave us two 30-minute sessions total. He just told us he's leaving the company in 2 weeks. After that, we have no way to debug integration issues or get new FHIR resource endpoints enabled.\n\n5. Three of our team members don't have VPN access to the client network yet. The request was submitted at engagement start (6 weeks ago). IT says they're 'backlogged.' We've been doing everything over screen share with the one team member who does have access.\n\nThis is a mess. Help me structure what's actually happening and what to do about it.",
+      "assertions": [
+        "Output identifies all 5 dependencies with appropriate categories (Decision/People, Legal, Security, People/Knowledge, Infrastructure)",
+        "Output classifies the CCO sign-off as Critical given 18 days and total code-blocking nature",
+        "Output identifies Marcus as a single-point-of-failure with urgent time pressure (2 weeks)",
+        "Output recommends immediate knowledge transfer session with Marcus before he leaves — this is the most time-sensitive action",
+        "Output flags the pen test as a scope change / new requirement and recommends SOW discussion",
+        "Output recognizes the VPN issue at 6 weeks as a systemic/pattern issue deserving escalation",
+        "Output provides a prioritized action plan (not just a list of problems)",
+        "Output recommends specific escalation approach for the CCO (L2+ given 18 days and total block)",
+        "Output distinguishes between dependencies the delivery team can influence vs. those requiring client executive intervention",
+        "Output suggests risk mitigation: what happens if CCO never responds in time, if Marcus leaves without transfer, if pen test delays UAT"
+      ]
+    }
+  ]
+}