jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/crafting-effective-readmes/using-references.md

@@ -0,0 +1,35 @@
+# Using References
+
+Templates are your primary tool for writing READMEs. References provide depth - use them to refine your understanding or handle edge cases.
+
+**Tip:** Don't load all references at once. Pick the one most relevant to your situation.
+
+---
+
+### art-of-readme.md
+`references/art-of-readme.md`
+
+**Why:** The philosophy behind great READMEs - understanding how readers actually scan and evaluate projects
+**What:** Cognitive funneling (broad → specific), brevity as a feature, README as the "one-stop shop" that keeps users out of source code
+
+---
+
+### make-a-readme.md
+`references/make-a-readme.md`
+
+**Why:** Practical, section-by-section guidance for what to include
+**What:** Walks through each common section (Name, Description, Installation, Usage, etc.) with concrete suggestions. Good reminder: "too long is better than too short"
+
+---
+
+### standard-readme-spec.md
+`references/standard-readme-spec.md`
+
+**Why:** Formal specification when consistency or compliance matters
+**What:** Required vs optional sections, exact ordering, formatting rules. Useful for OSS projects wanting a standardized format.
+
+Examples:
+- `references/standard-readme-example-minimal.md` - Bare minimum compliant README
+- `references/standard-readme-example-maximal.md` - Full-featured with badges, ToC, all optional sections
+
+

package/.github/skills/current-state-process-miner/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: current-state-process-miner
+description: Reconstruct the as-is workflow for a business process from interview notes, screen recordings, narrated demos, ticket data, SOP docs, or transcripts and produce a BPMN-style map with actors, systems, decisions, exceptions, hand-offs, cycle times, and pain points. Use this whenever the user needs a current-state process map, an as-is workflow diagram, a swim-lane view, BPMN output, a mined process from messy artifacts, or a baseline to compare against a future-state AI-augmented workflow, even when the user asks for it as "map this process," "document how it works today," or "show me the workflow before we automate."
+argument-hint: Paste interview notes, transcripts, ticket samples, SOP excerpts, narrated screen-recording transcripts, and the process or department in scope.
+---
+
+# Current-State Process Miner
+
+## Positioning
+
+Use this skill to reconstruct the actual as-is workflow from messy, multi-source artifacts before any AI Innovation Pod or Jump Start design work. The output is a credible baseline for scoping, automation candidate selection, and future-state design — not a polished re-engineering map.
+
+Bias toward what really happens, including workarounds, shadow tools, and exception paths, rather than the SOP as written.
+
+## When To Use This
+
+- The user needs an as-is workflow, current-state map, swim lane diagram, or BPMN-style view of how a process runs today.
+- Inputs are messy: interview notes, transcripts, screen recording narrations, ticket exports, SOP fragments, or seller observations.
+- The team needs a baseline before designing a future-state AI workflow, picking automation candidates, or scoping a Pod build.
+
+## When Not To Use This Alone
+
+- Do not use this when the user already has a clean BPMN and just needs the future-state design. Use `../solution-architecture-patterns/SKILL.md` or `../phased-roadmap/SKILL.md`.
+- Do not use this for pure business-rule extraction; pair with `../business-logic-extractor/SKILL.md`.
+- Do not use this to score AI fit on a list of use cases; use `../use-case-prioritization/SKILL.md`.
+
+## Required Inputs
+
+Start with what the user has. Common inputs:
+
+- process or department in scope and the trigger event,
+- interview notes or call transcripts with role labels,
+- screen recording narrations or click-by-click notes,
+- ticket samples (Jira, ServiceNow, Salesforce cases) with status transitions,
+- SOPs, runbooks, or training docs,
+- known pain points, escalations, or exception cases.
+
+If inputs are partial, produce a hypothesis-driven map with explicit `Confirmed`, `Inferred`, and `Unknown` labels on each step.
+
+## Working Rules
+
+1. Capture the process as it actually runs, not the SOP-ideal. Note workarounds explicitly.
+2. Separate happy path from exception paths, but keep both visible.
+3. Tag every step with: actor (role), system, input, output, decision, cycle time (if known), and pain.
+4. Do not invent metrics. If cycle time is unknown, mark it `unknown` rather than guess.
+5. Surface candidates for AI augmentation, automation, or removal — but keep them in a separate section, not embedded in the as-is map.
+6. Distinguish role-level actors (e.g., "Underwriter II") from named individuals.
+
+## Workflow
+
+1. Frame the process. Identify trigger, end state, scope boundaries, and out-of-scope adjacent processes.
+2. Normalize inputs using the artifact triage in [references/process-mining-workflow.md](./references/process-mining-workflow.md).
+3. Extract steps in canonical form using the step schema (actor / action / system / decision / output / pain / cycle time).
+4. Group steps into phases and lanes (one lane per actor or system, depending on which view the user needs).
+5. Render the map using [templates/as-is-process-map-template.md](./templates/as-is-process-map-template.md), including a Mermaid `flowchart` block for BPMN-style output.
+6. Surface the pain register, exception catalog, and AI-fit candidate list as separate sections.
+7. Close with explicit unknowns and the next interviews or data pulls needed to close them.
+
+## Output Mode
+
+Default to the As-Is Process Map artifact:
+
+- Executive summary (3-5 bullets, what runs and where it hurts).
+- Scope and trigger.
+- Actors and systems table.
+- Phase-by-phase step table.
+- Mermaid swim-lane / BPMN-style diagram.
+- Exception and rework catalog.
+- Pain register with severity and frequency.
+- AI-fit and automation candidates (clearly labeled hypothesis).
+- Confirmed vs. inferred vs. unknown legend.
+- Next-step interviews and data asks.
+
+## Style
+
+- Plain, observational language. No hype.
+- Prefer "the underwriter copies the policy number into the email" over "the underwriter performs data extraction."
+- Quantify only where evidence exists.

package/.github/skills/current-state-process-miner/evals/evals.json

@@ -0,0 +1,42 @@
+{
+  "skill_name": "current-state-process-miner",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I have ~20 pages of interview notes and a 45-min screen recording transcript from claims adjusters at a mid-market P&C carrier, plus a small Jira export of FNOL tickets from last quarter. The Pod wants an as-is map of the FNOL-to-first-touch process before we scope an AI triage prototype. The notes mention adjusters copy-pasting policy numbers into a separate fraud lookup tool that isn't in the SOP. Reconstruct the as-is workflow with role lanes, exception paths, and AI-fit candidates.",
+      "expected_output": "A current-state process map with phase-by-phase steps including the unofficial fraud lookup, a Mermaid swim-lane diagram, exception catalog, pain register, and clearly-labeled AI-fit candidates with confidence labels.",
+      "files": [],
+      "assertions": [
+        {"text": "Output includes a Mermaid flowchart with at least two role lanes"},
+        {"text": "Workaround (fraud lookup tool not in SOP) is captured explicitly as a step or note"},
+        {"text": "Steps use the canonical schema (actor, system, action, decision, cycle time, pain)"},
+        {"text": "AI-fit candidates are in a separate section labeled as hypothesis, not embedded in the as-is map"},
+        {"text": "Confirmed / Inferred / Unknown labels appear on at least some steps"},
+        {"text": "Exception paths are catalogued separately from happy path"}
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Map the as-is invoice approval process at a manufacturing client based on these 5 SME interview snippets. We don't have ticket data or recordings — just the interviews. The CFO told us they want to AI-augment this in Q3. Produce the map even though inputs are partial.",
+      "expected_output": "A hypothesis-heavy as-is map with explicit Unknown labels and a concrete list of follow-up data asks before scoping.",
+      "files": [],
+      "assertions": [
+        {"text": "Multiple steps are labeled Inferred or Unknown rather than presented as confirmed"},
+        {"text": "A 'next-step interviews and data asks' section is present and concrete"},
+        {"text": "The output does not invent cycle times"},
+        {"text": "Output flags that the SOP and reality may diverge and recommends validation"}
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We just ran a Jump Start workshop on broker onboarding at a wholesaler. I have the workshop transcript, three SOPs, and emails between ops and IT. Produce an as-is map I can use as the baseline for a future-state design next sprint.",
+      "expected_output": "An as-is map using role lanes, with a clear AI-fit candidate section that is explicitly NOT a future-state design.",
+      "files": [],
+      "assertions": [
+        {"text": "The output is an as-is map and does not present a future-state design"},
+        {"text": "The AI-fit section is labeled hypothesis and is separate from the as-is map"},
+        {"text": "The output names the trigger event and end state of the process"}
+      ]
+    }
+  ]
+}

package/.github/skills/current-state-process-miner/references/process-mining-workflow.md

@@ -0,0 +1,73 @@
+# Process Mining Workflow
+
+How to reconstruct an honest as-is workflow from messy multi-source artifacts.
+
+## Artifact triage
+
+| Artifact | What it gives you | Watch out for |
+|---|---|---|
+| Interview notes / transcripts | Roles, exceptions, why steps exist | Self-reported steps are often the SOP, not reality |
+| Screen recordings (narrated) | Real click-by-click behavior, system names, copy-paste paths | Narration may skip "obvious" steps |
+| Ticket exports (Jira, ServiceNow, Salesforce) | Volumes, status transitions, cycle times, escalations | Status transitions may be lazy; check timestamps |
+| SOPs and runbooks | Idealized happy path | Often outdated; treat as hypothesis |
+| Email / Teams chat samples | Hand-offs, exceptions, parking lots | Privacy — redact before reuse |
+| Spreadsheets / shared trackers | Shadow systems, real source of truth | Often missing from architecture diagrams |
+
+## Step schema
+
+Capture every step in this canonical form:
+
+```
+- step_id
+- phase
+- actor (role)
+- system
+- action (verb-noun)
+- input
+- output
+- decision? (Y/N) and branches
+- cycle_time (or unknown)
+- frequency (or unknown)
+- pain_signal (or none)
+- evidence_source
+- confidence (Confirmed / Inferred / Unknown)
+```
+
+## Lane choice
+
+- Default to **role lanes** for human-heavy processes.
+- Use **system lanes** when integration risk dominates.
+- Use **dual lanes** (role + system) only for executive-readable summary views; do not maintain dual lanes as the source.
+
+## Exception handling
+
+Keep exceptions in a separate catalog with:
+- trigger,
+- frequency (rough),
+- detour path,
+- whether the SOP acknowledges it,
+- pain it causes,
+- whether it is a candidate for AI augmentation or for elimination.
+
+## AI-fit heuristics (for the candidate list, not the as-is map)
+
+A step is a strong AI-fit candidate when:
+- it is high-frequency and human-only,
+- it requires reading or summarizing unstructured content,
+- it follows soft rules with judgment,
+- it has a quality / cycle-time pain signal,
+- the data needed is reachable.
+
+A step is a weak candidate when:
+- it requires high-stakes judgment with poor feedback signal,
+- the data is not reachable or is highly sensitive,
+- the volume is too low to justify build,
+- the underlying SOP or rules are themselves unclear (fix the process first).
+
+## Common traps
+
+- Treating the SOP as truth.
+- Drawing the diagram first and forcing steps into it.
+- Hiding rework loops to keep the picture clean.
+- Combining "happy path" and "exception" in one swim lane and losing the exception signal.
+- Inventing cycle times. If unknown, say unknown.

package/.github/skills/current-state-process-miner/templates/as-is-process-map-template.md

@@ -0,0 +1,81 @@
+# As-Is Process Map: <Process Name>
+
+**Owner:** <name>
+**Date:** <YYYY-MM-DD>
+**Sources:** <interviews / recordings / tickets / SOPs>
+**Confidence legend:** Confirmed / Inferred / Unknown
+
+## Executive summary
+
+- Trigger: <what starts this process>
+- End state: <what marks done>
+- Volume: <per day/week/month, or unknown>
+- Headline pain: <top 1-3 pain signals>
+- AI-fit posture (hypothesis): <where AI looks promising; flag as hypothesis>
+
+## Scope
+
+- In scope: <bounded process>
+- Out of scope: <adjacent processes deliberately excluded>
+- Trigger event: <event that initiates>
+- End event: <event that closes>
+
+## Actors and systems
+
+| Actor (role) | Responsibility | System(s) used |
+|---|---|---|
+| | | |
+
+## Phase-by-phase steps
+
+### Phase 1: <name>
+
+| # | Actor | Action | System | Input | Output | Decision | Cycle time | Pain | Confidence |
+|---|---|---|---|---|---|---|---|---|---|
+| 1.1 | | | | | | | | | |
+
+(Repeat for each phase.)
+
+## Swim-lane / BPMN diagram
+
+```mermaid
+flowchart LR
+    %% Replace with actual lanes and steps
+    subgraph Lane_Actor1["Actor 1"]
+        A1[1.1 Action] --> A2[1.2 Action]
+    end
+    subgraph Lane_Actor2["Actor 2"]
+        B1[2.1 Action]
+    end
+    A2 --> B1
+    B1 -->|exception| EX[Exception path]
+```
+
+## Exception and rework catalog
+
+| Exception | Trigger | Frequency | Detour path | SOP acknowledges? | Pain | Candidate? |
+|---|---|---|---|---|---|---|
+| | | | | | | |
+
+## Pain register
+
+| Pain | Where (step) | Severity | Frequency | Evidence |
+|---|---|---|---|---|
+| | | | | |
+
+## AI-fit and automation candidates (hypothesis)
+
+| Step | Candidate type | Why it fits | Data needed | Risk |
+|---|---|---|---|---|
+| | augment / automate / eliminate | | | |
+
+## Confirmed vs. inferred vs. unknown
+
+- Confirmed: <items>
+- Inferred: <items>
+- Unknown — needs validation: <items>
+
+## Next-step interviews and data asks
+
+- <role> — <questions to validate>
+- <data pull> — <fields, time window, owner>

package/.github/skills/data-readiness-assessor/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: data-readiness-assessor
+description: 'Score data sources for AI-fitness across availability, quality, lineage, sensitivity, and refresh cadence so a Jump Start or AI Innovation Pod team can decide whether the data path is workable, conditional, or blocking. Use this whenever the user is sizing a RAG, agent, copilot, classification, or analytics build and needs a defensible read on whether the data is good enough to commit to a use case, an MVP boundary, or a Pod tier — even when the request is phrased as "is the data ready", "can we build this", "what is the data risk", or "what will we have to clean up first".'
+argument-hint: 'Provide the candidate use case, the data sources in scope, and any known access, quality, governance, or refresh constraints.'
+---
+
+# Data Readiness Assessor
+
+## Positioning
+
+Use this skill to turn vague "the data is messy" or "we have a data lake" statements into a per-source, per-dimension readiness view that the Pod, the seller, and the client sponsor can defend. The goal is not a data quality audit. The goal is to expose, before scoping is locked, where the data path is workable, where it needs hardening, and where it will block delivery.
+
+A good output should let the team answer three questions:
+
+1. Can we build the proposed use case on this data, as is, in the next motion?
+2. What must change for the data to be usable — and who owns that change?
+3. Where does data risk drive scope, sequencing, or pricing decisions?
+
+## When To Use This
+
+- Sizing a Jump Start, Pod MVP, RAG build, agent, copilot, or classification model and the team needs a fast read on data fitness.
+- Discovery has produced a list of candidate sources but no one has scored them.
+- A client claims the data is ready and the team needs an evidence-grounded second opinion.
+- A scope or SOW is being drafted and data assumptions need to be made explicit before commitments are written.
+- Use-case prioritization is stalled because data risk is not differentiated across candidates.
+
+## When Not To Use This
+
+- Do not use this for a full enterprise data governance or master data management assessment. Route to a dedicated data engagement.
+- Do not use this as a substitute for `business-logic-extractor` when the underlying workflow rules are still unclear — you cannot score data fitness against a use case that is not defined.
+- Do not use this to validate model accuracy claims. Model evaluation belongs in eval design.
+
+## Required Inputs
+
+- Candidate use case in one or two sentences, including the decision, output, or workflow the AI will support.
+- A list of data sources in scope, even if rough. For each source, capture what is known about: where it lives, who owns it, how it is accessed, how fresh it is, and what sensitivity class it carries.
+- Any known constraints: access blockers, regulatory overlays (PII, PHI, PCI, IP, regulated industry), residency rules, retention rules, or refresh windows.
+- Time horizon for the next motion (Jump Start window, MVP window, pilot window). Readiness is always scored against a delivery horizon, not in the abstract.
+
+If any of the above is missing, draft the assessment with hypotheses clearly labeled and list the gaps the team must close before the read is reliable.
+
+## The Five Dimensions
+
+Score every source on all five. A source can be perfectly available and still block the use case if its sensitivity class makes it unusable in the proposed environment, or if its refresh cadence is wrong for the decision the AI is supporting.
+
+1. **Availability** — Can the Pod actually get to the data inside the delivery window? Covers system access, API or export path, auth pattern, network reachability, environment (prod, non-prod, sandbox), and whether legal or procurement gating is in the path.
+2. **Quality** — Is the data fit for the decision the AI will make? Covers completeness, accuracy, consistency, structure, deduplication, language and format normalization, and whether ground truth exists for evaluation.
+3. **Lineage** — Do we know where the data came from, how it was transformed, and whether we can trust it as a source of record? Covers documented sources, transformation visibility, ownership, change-control posture, and whether a downstream copy is the right thing to use vs. the system of record.
+4. **Sensitivity** — What handling rules attach to this data? Covers regulated classes (PII, PHI, PCI, financial, IP, export-controlled, union or HR sensitive), residency, retention, allowable processors, and whether the data can leave the source environment at all.
+5. **Refresh cadence** — Does the freshness of the data match the decision the AI is supporting? Covers update frequency at source, propagation delay to the layer the AI will use, staleness tolerance for the decision, and whether near real-time or event-driven access is required.
+
+See [references/scoring-rubric.md](./references/scoring-rubric.md) for the score bands, dimension-specific cues, and the convention for confidence flags.
+
+## Workflow
+
+1. **Anchor on the use case.** Restate the decision or output the AI will produce, in one or two sentences. Readiness is meaningless without it.
+2. **Inventory the sources.** Use [templates/data-source-inventory.md](./templates/data-source-inventory.md) to capture each source. Include sources the team may want to exclude — making the exclusion explicit is part of the deliverable.
+3. **Score each source on the five dimensions.** Use the rubric in `references/scoring-rubric.md`. Cite the evidence for each score in one short clause; if the score is from inference rather than evidence, mark confidence as `inferred` so the team knows where the read is soft.
+4. **Flag sensitivity-driven constraints.** Use [references/sensitivity-classification.md](./references/sensitivity-classification.md) to surface the handling rules that drive architecture, environment, and contract choices. Sensitivity is not an aggregate score — a single high-sensitivity source can constrain the whole solution.
+5. **Roll up to a per-source verdict.** For each source, mark it `Ready`, `Conditional`, or `Blocking` against the use case and the delivery window. Conditional sources must name the condition and the owner.
+6. **Roll up to a use-case verdict.** Translate the per-source picture into a use-case-level read: `Buildable`, `Buildable with remediation`, or `Not buildable in this window`. Connect the verdict back to scope, sequencing, or tier implications for the engagement.
+7. **State assumptions and the next validation step.** Name what the team is assuming, what the client must confirm, and what artifact or conversation closes the biggest unknown.
+
+## Output Structure
+
+Use this exact structure so the artifact is easy to review across sales, architecture, and delivery:
+
+1. Use case in scope (one or two sentences, plus the delivery window).
+2. Sources in scope (table from the inventory template, with verdict per source).
+3. Dimension scores and evidence (short narrative per source, or a compact table with one-line evidence per dimension).
+4. Sensitivity and handling constraints (cross-cutting; call out anything that drives environment, residency, or contract decisions).
+5. Use-case readiness verdict (`Buildable`, `Buildable with remediation`, or `Not buildable in this window`) with the reasoning.
+6. Conditions, owners, and sequencing (what must change, who owns it, when it must close).
+7. Assumptions, unknowns, and recommended next step.
+
+A worked output is in [examples/example-claims-rag-readiness.md](./examples/example-claims-rag-readiness.md).
+
+## Evidence And Boundary Discipline
+
+- Score from evidence where possible. When you score from inference, mark it. A confident-looking score with no basis is worse than a labeled hypothesis.
+- Distinguish data the client says is ready from data the team has actually seen. The two are routinely different.
+- Keep the assessment scoped to the use case in front of you. A source that is unfit for one use case may be fine for another; readiness is relative.
+- Sensitivity findings can override a high score on every other dimension. Do not average sensitivity into a single number — surface it as a constraint.
+
+## Common Pitfalls
+
+### Pitfall 1: Averaging Sensitivity Into A Single Score
+
+Bad: averaging a `3` on availability with a `1` on sensitivity to call a source "moderate."
+
+Better: keep sensitivity as a constraint that gates environment and contract choices. A `1` on sensitivity often means the data path is unusable in the proposed environment regardless of every other dimension.
+
+### Pitfall 2: Scoring Without A Use Case
+
+Bad: assessing a data lake "in general."
+
+Better: score each source against the specific decision or output the AI will produce. Same data, different use case, different verdict.
+
+### Pitfall 3: Confusing The System Of Record With A Convenient Copy
+
+Bad: scoring a downstream BI extract because it is easier to access.
+
+Better: name the system of record and any intermediate copy explicitly. Decide which layer is the right source for the AI flow and capture the lineage risk if a copy is used.
+
+### Pitfall 4: Treating Refresh Cadence As One Number
+
+Bad: marking a source "daily" without checking what the AI decision actually needs.
+
+Better: score refresh against the decision tolerance. A nightly batch may be fine for a monthly forecast and unacceptable for a same-day service-recovery agent.
+
+### Pitfall 5: Hiding Blocking Findings To Keep The Deal Alive
+
+Bad: softening a `Blocking` verdict into `Conditional` because the opportunity is commercially attractive.
+
+Better: state the block plainly and recommend a smaller, safer motion (Jump Start, data-readiness sprint, or sequenced MVP) that respects the finding.
+
+## Quality Bar
+
+- Every score has a one-clause evidence statement and a confidence flag.
+- Every `Conditional` source names the condition and the owner.
+- The use-case verdict ties cleanly to scope, sequencing, or tier implications for the engagement.
+- The artifact is short enough for a sponsor to read in a single sitting and concrete enough for the Pod to act on.
+
+## Related Skills
+
+- `business-logic-extractor` — run first if the workflow rules are still unclear.
+- `discovery-depth-scorecard` — use to check whether discovery produced enough data evidence to make this assessment reliable.
+- `qualification-scorecard` — use the readiness verdict as input to the data and integration readiness dimension.
+- `risk-assumption-register` — escalate `Blocking` and high-impact `Conditional` findings into the engagement risk register.
+- `solution-architecture-patterns` — use the readiness verdict to choose RAG, fine-tuning, or workflow-automation patterns realistically.

package/.github/skills/data-readiness-assessor/evals/evals.json

@@ -0,0 +1,37 @@
+{
+  "skill_name": "data-readiness-assessor",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Use the attached discovery notes to produce a data readiness assessment for the field service copilot use case. Score each source on availability, quality, lineage, sensitivity, and refresh cadence. Surface the cross-cutting handling constraints, give a use-case verdict for the 6-week Jump Start window, and list conditions, owners, and sequencing the Pod will need.",
+      "expected_output": "A per-source readiness assessment with dimension scores, evidence, and confidence flags; a cross-cutting sensitivity/handling section; a use-case verdict; and a conditions/owners/sequencing table.",
+      "files": [
+        "evals/files/data-readiness-fieldservice-copilot.md"
+      ],
+      "expectations": [
+        "The output scores every source on all five dimensions (availability, quality, lineage, sensitivity, refresh cadence) and includes a confidence flag (evidence, attested, or inferred) on each score.",
+        "The output marks the curated senior-tech spreadsheet as a Conditional or Blocking source on lineage and availability, citing the single-owner risk, the email-based access path, and the lack of documented governance.",
+        "The output flags the SAP live API path as a Conditional or Blocking availability finding because the 6-week procurement cycle does not fit the 6-week Jump Start window, and recommends using the existing nightly Snowflake extract or sequencing live API access into a follow-on motion.",
+        "The output names parts pricing in SAP, customer addresses in ServiceNow, or warranty terms in Salesforce as confidential or sensitive content that drives environment, logging, or contract decisions.",
+        "The output gives a use-case verdict of Buildable with remediation (or Not buildable in this window if justified) and ties the verdict back to scope, sequencing, or tier implications such as narrowing the prototype to rooftop units, deferring live SAP integration, or capturing the curated spreadsheet as institutional-knowledge before the senior tech retires.",
+        "The output names at least one next validation step that closes the largest unknown, such as sampling ServiceNow resolution notes, inspecting the curated spreadsheet, or auditing OEM manual coverage and duplicates."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Use the attached discovery notes to produce a data readiness assessment for the permit triage agent. Score every source, surface the cross-cutting constraints that drive environment, residency, and contract choices, and give a clear verdict for the 12-week pilot window. If the verdict is Not buildable in this window, recommend the next motion the agency could responsibly run instead.",
+      "expected_output": "A per-source readiness assessment for a regulated public-sector use case, with a clear verdict that respects the AI governance board, residency, and cross-agency data-sharing constraints.",
+      "files": [
+        "evals/files/data-readiness-public-sector-permit-triage.md"
+      ],
+      "expectations": [
+        "The output scores every source on all five dimensions with confidence flags.",
+        "The output marks the state critical-infrastructure designations source as Blocking (or Conditional with a renegotiation owner) because the existing data-sharing agreement does not permit automated processing and renegotiation does not fit the 12-week window.",
+        "The output names cross-cutting constraints that drive architecture and contract choices, including state-approved cloud region (AWS GovCloud or Azure Government), the AI governance board review requirement, public records (FOIA-equivalent) implications for generated content, and the procurement constraint that no new MSA can clear in the window.",
+        "The output identifies PII, attorney-client content in historical completeness letters, and critical-infrastructure designations as sensitivity findings that bind the solution, and treats sensitivity as a constraint rather than averaging it into a single score.",
+        "The output gives a use-case verdict that fits the constraints, either Buildable with remediation under a HITL pilot scope that excludes automated use of the critical-infrastructure data, or Not buildable in this window with a recommended smaller motion such as a non-decision-making drafting assistant, a discovery-only motion, or sequencing the data-sharing renegotiation before pilot expansion.",
+        "The output recommends a concrete next validation step, such as a working session with the AI governance board liaison, a sample inspection of historical letters, or a written confirmation of the Azure Government environment readiness."
+      ]
+    }
+  ]
+}

package/.github/skills/data-readiness-assessor/evals/files/data-readiness-fieldservice-copilot.md

@@ -0,0 +1,40 @@
+# Data Readiness Input — Field Service Copilot (Mid-Market HVAC Distributor)
+
+## Client And Use Case
+
+Mid-market HVAC distributor (~$600M revenue, US-only operations) wants a field-service technician copilot. When a technician opens a service ticket on their tablet, the copilot should suggest likely root causes, the relevant troubleshooting steps, and the parts most often used to resolve the issue.
+
+Sponsor: VP of Field Service. Co-sponsor: CIO. The CFO is interested but has not committed budget beyond a discovery motion.
+
+Delivery window asked for: 6-week Jump Start, ending in a working prototype on a single product line (rooftop units).
+
+## Sources Discussed In Discovery
+
+1. **ServiceNow ITSM (service tickets, work orders, resolution notes).** System of record for field service. Roughly 220k tickets per year, free-text resolution notes from technicians. Owner: Field Service Ops. Access: REST API, OAuth. Non-prod environment exists. Contains customer site addresses and technician names.
+
+2. **OEM technical manuals (PDF library on a corporate file share).** Hundreds of manuals from a dozen OEMs, mixed quality — some are scanned, some are native PDF, multiple revisions stored side by side without a clean current-version index. Owner: Product Management. Access: SMB file share, no API today. Internal sensitivity only.
+
+3. **Parts master and inventory (SAP S/4HANA).** Source of record for parts, part substitutions, and live inventory by warehouse. Owner: Supply Chain IT. Access: an existing nightly extract to a Snowflake reporting layer; live SAP API access exists but requires a 6-week procurement cycle for a new integration. Contains pricing data treated as confidential business.
+
+3. **Historical resolution outcomes spreadsheet (curated by a senior tech).** A senior tech maintains an Excel file of "real" root causes for the top 200 issues, hand-curated over five years. Owner: that one senior tech. Access: shared via email. Quality is reportedly excellent but undocumented.
+
+5. **Customer warranty and contract terms (held by Sales Ops in Salesforce).** Determines whether a part or labor charge is billable. Owner: Sales Ops. Access: Salesforce API, but the warranty fields are inconsistent — entered free-text in some accounts.
+
+## Known Constraints
+
+- US-only operations and US data residency required by client policy. No EU or APAC processing.
+- Client security has approved Azure OpenAI in US regions for prior pilots. No external SaaS LLMs have been approved.
+- The CFO will not approve the Jump Start unless the prototype includes a credible parts-suggestion path, not just troubleshooting text.
+- The senior tech who maintains the curated spreadsheet is retiring in nine months. Field Service Ops sees this skill as institutional-knowledge capture.
+
+## What The Client Has Asserted Vs. What The Team Has Seen
+
+- The client says "ServiceNow data is clean." The team has not yet seen a sample.
+- The client says "we have all the OEM manuals." The team has seen the file share and confirmed many duplicates and at least one OEM whose manuals are missing.
+- The client says "SAP integration is easy." The team has confirmed the nightly extract to Snowflake but has not validated whether live API access is feasible inside the 6-week window.
+- The team has not yet seen the curated spreadsheet at all.
+- Warranty data quality is not yet validated.
+
+## Ask
+
+Produce a data readiness assessment for the field service copilot use case, scoring each source on availability, quality, lineage, sensitivity, and refresh cadence. Surface the constraints that drive architecture and contract decisions. Give a use-case verdict and the conditions, owners, and sequencing the Pod will need to defend the 6-week window.

package/.github/skills/data-readiness-assessor/evals/files/data-readiness-public-sector-permit-triage.md

@@ -0,0 +1,40 @@
+# Data Readiness Input — Public-Sector Permit Triage Agent
+
+## Client And Use Case
+
+State-level permitting agency. Wants an internal-facing agent that triages incoming construction permit applications: classifies the application type, flags missing documentation, routes to the right reviewer queue, and drafts an initial completeness letter for staff to send back to the applicant.
+
+Sponsor: Agency Deputy Director. Co-sponsor: Director of IT. The agency's procurement officer is involved from day one because the agency is bound by the state's IT procurement and AI usage rules.
+
+Delivery window asked for: 12-week pilot in a single permit category (commercial alterations) with three trained reviewers using the agent in parallel with the current process.
+
+## Sources Discussed In Discovery
+
+1. **Permit application packets (PDF uploads via the agency portal).** Mix of applicant-completed forms, architect drawings, structural calculations, and supporting letters. Average packet is 40–120 pages. Many are scanned at low resolution. Contains applicant PII and, in some cases, building floor plans considered sensitive by the state's critical-infrastructure office. Owner: Permitting Operations. Access: existing document management system with a documented API and a non-prod environment.
+
+2. **Permit application metadata (the agency's permitting system database).** Structured fields: application ID, type, submission date, applicant, parcel ID, current status, assigned reviewer. Owner: Permitting Operations IT. Access: read-only API to a reporting replica. Updated near real-time.
+
+3. **Internal review checklists and policy guidance (SharePoint).** The "what counts as complete" rules. Maintained by senior reviewers. Quality varies by permit type — commercial alterations is well-documented; some other categories are not. Owner: Permitting Operations. Access: SharePoint Online via Graph API. Internal sensitivity only.
+
+4. **Historical completeness letters (sent letters, stored in the document management system).** Several years of prior letters that staff sent back to applicants. Useful as drafting examples. Contains applicant PII and in some cases attorney-client correspondence. Owner: Permitting Operations.
+
+5. **State critical-infrastructure designations (a separate state office's database).** Tells whether a parcel is on or near a critical-infrastructure asset, which changes the review path. Owner: a different state agency. Access: cross-agency data-sharing agreement exists for human review but not for automated processing. Updated quarterly.
+
+## Known Constraints
+
+- State law requires that any AI system used in regulatory decision-making be reviewed by the state's AI governance board before production use. The board meets monthly. Pilot use behind a human reviewer is allowed under an existing administrative order, but the board review is required before scope expands beyond pilot.
+- All processing must occur in a state-approved cloud region. The state's standard cloud is AWS GovCloud; an Azure Government enrollment exists but has not been used by this agency before.
+- The state has a public records (FOIA-equivalent) regime. Anything the agent generates may be subject to disclosure.
+- Critical-infrastructure designations cannot be exported into a vendor environment under the current data-sharing agreement; a renegotiation would take six months minimum.
+- The procurement officer has signaled that any solution requiring a new MSA will not clear in the 12-week window. The agency has an existing MSA with a major systems integrator and an existing Azure Government enterprise agreement.
+
+## What The Client Has Asserted Vs. What The Team Has Seen
+
+- The agency says the permit packets are "mostly digital." The team has confirmed this for new submissions but has not validated quality for the historical corpus.
+- The agency says the SharePoint policy guidance is "current." The team has not yet sampled to confirm.
+- The agency says the critical-infrastructure data is "available to us." The team has confirmed this is true for staff-mediated lookup but is not yet confirmed for an automated agent path.
+- Historical completeness letters: not yet sampled.
+
+## Ask
+
+Produce a data readiness assessment for the permit triage agent. Score each source on the five dimensions, surface the constraints that drive environment, residency, and contract choices, and give a clear use-case verdict for the 12-week pilot window. If the verdict is `Not buildable in this window`, recommend the next motion the agency could responsibly run instead.