jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/bottom-up-estimation/references/estimation-methodology.md

@@ -0,0 +1,132 @@
+# Estimation Methodology Reference
+
+Use this reference when drafting the actual estimate logic.
+
+## Standard sequence
+
+1. Define scope boundaries.
+2. Break the work into packages.
+3. Estimate low, likely, and high effort.
+4. Apply complexity logic.
+5. Add non-build effort.
+6. Translate to delivery capacity.
+7. Present a ROM range with assumptions.
+
+## Size bands
+
+| Size | Effort Range | Typical Use |
+| --- | ---: | --- |
+| XS | 1 to 2 days | Simple configuration or known task |
+| S | 3 to 5 days | Standard screen, small API, minor integration |
+| M | 1 to 2 weeks | Multi-step workflow or moderate business logic |
+| L | 3 to 5 weeks | Complex integration or new service |
+| XL | 6 to 10 plus weeks | High uncertainty or cross-system work |
+
+## Complexity drivers
+
+| Driver | Low | Medium | High |
+| --- | --- | --- | --- |
+| Requirements clarity | Well-defined | Some ambiguity | Discovery still needed |
+| Data readiness | Clean and accessible | Some mapping needed | Unknown or poor quality |
+| Integration complexity | Modern APIs | Mixed interfaces | Legacy or fragile systems |
+| Security and compliance | Standard controls | Audit requirements | Regulated or high-risk workload |
+| UX complexity | Internal pilot | Multi-role workflow | Broader external or NFR-heavy use |
+| Dependency risk | Team-controlled | Shared ownership | Client or vendor bottlenecks |
+
+## Non-build add-ons
+
+| Category | Typical Add-On |
+| --- | ---: |
+| Project management | 10% to 15% |
+| Architecture oversight | 5% to 10% |
+| QA and validation | 20% to 30% |
+| DevOps and deployment | 10% to 20% |
+| Security and governance | 5% to 15% |
+| Client review and UAT support | 10% to 20% |
+| Contingency | 15% to 35% |
+
+## ROM framing guidance
+
+- Prefer ranges over a single value.
+- Explain what makes the range wide or narrow.
+- Name the top estimate movers explicitly.
+- State which assumptions would tighten the estimate next.# Estimation Methodology Reference
+
+Use this reference when building a bottom-up estimate package.
+
+## Standard reasoning sequence
+
+1. Define scope boundary.
+2. Identify delivery shape and ownership.
+3. Break the work into work packages.
+4. Estimate low, likely, and high effort.
+5. Apply complexity drivers.
+6. Add non-build effort.
+7. Add contingency.
+8. Convert effort into timeline.
+9. Present a ROM range with estimate movers.
+
+## Scope boundary guidance
+
+Every estimate should state included and excluded work at the deliverable level. Broad labels such as "frontend" or "AI" are not enough without a boundary describing what is and is not included.
+
+## Work-package guidance
+
+Typical work-package families:
+
+- discovery and backlog shaping
+- architecture and solution design
+- experience or workflow design
+- application build
+- data and retrieval
+- AI workflow and evaluation
+- integrations
+- QA and validation
+- delivery engineering
+- governance, enablement, and handoff
+
+## Three-point estimate guidance
+
+Use low, likely, and high estimates for each package.
+
+- Low: requirements are clear and access is ready.
+- Likely: reasonable working assumption.
+- High: drag appears from ambiguity, access, rework, or reviews.
+
+## Complexity guidance
+
+Key complexity drivers:
+
+- requirements clarity
+- data readiness
+- integration difficulty
+- governance burden
+- UX or workflow complexity
+- AI uncertainty
+- dependency risk
+
+Suggested multiplier guidance:
+
+| Complexity | Multiplier |
+| --- | ---: |
+| Low | 1.0x |
+| Medium | 1.25x to 1.5x |
+| High | 1.75x to 2.5x |
+
+## Non-build effort guidance
+
+Add these categories directly when relevant:
+
+- project management
+- architecture oversight
+- QA and evaluation
+- delivery engineering and deployment
+- governance and security review support
+- UAT support
+- contingency
+
+## ROM framing guidance
+
+Treat the result as a range, not a fixed bid, unless the user explicitly asks for a single-number conversion.
+
+State what would move the estimate up or down after discovery.

package/.github/skills/bottom-up-estimation/references/output-package-guide.md

@@ -0,0 +1,45 @@
+# Output Package Guide
+
+Use this structure for substantial bottom-up estimate responses.
+
+## Required sections
+
+1. Estimate framing
+2. Scope boundaries
+3. Delivery shape and ownership assumptions
+4. Work-package estimate table
+5. AI-accelerated versus dependency-bound work
+6. Non-build effort and contingency
+7. Capacity and timeline
+8. ROM range
+9. Estimate movers and next discovery questions
+10. Proposal-ready narrative
+
+## Tone guidance
+
+Keep the output direct and commercially usable.
+
+- Avoid false precision.
+- Separate facts from assumptions.
+- Name the main dependencies clearly.
+- Use ranges rather than single-point certainty.
+- Keep comparison to a regular team optional and concise.
+
+## Reusable file guidance
+
+When writing files, prefer:
+
+- `response.md` for the narrative package
+- `estimation-worksheet.csv` for the work-package table
+
+The worksheet should contain at least:
+
+- workstream
+- work package
+- acceleration type
+- low estimate
+- likely estimate
+- high estimate
+- complexity notes
+- dependency notes
+- owner notes

package/.github/skills/bottom-up-estimation/references/pod-tier-mapping.md

@@ -0,0 +1,30 @@
+# Pod Tier Mapping
+
+Use this reference when the user wants the estimate translated into AI Innovation Pod motion guidance.
+
+## Default tier anchors
+
+- Ignition: 25 Innovation Units
+- Turbo: 60 Innovation Units
+- Overdrive: 140 Innovation Units
+
+## Mapping intent
+
+The mapping is not a strict formula. Use it to explain which delivery motion best fits the estimate shape, ambiguity level, and dependency burden.
+
+## Heuristic guidance
+
+| Signal | Typical Motion |
+| --- | --- |
+| Narrow MVP, bounded scope, limited integrations, fast validation need | Ignition |
+| Moderate workflow set, some integrations, meaningful build and evaluation work | Turbo |
+| Broad scope, multiple workstreams, higher governance or handoff burden | Overdrive |
+| Scope materially exceeds focused Pod capacity or requires adjacent enterprise teams from the start | Broader delivery motion or blended team |
+
+## Communication guidance
+
+When mapping to a tier, explain:
+
+1. why the current estimate fits that motion
+2. what assumptions keep it in that tier
+3. what would push it into a heavier motion or a broader delivery model

package/.github/skills/bottom-up-estimation/references/pricing-conversion-guide.md

@@ -0,0 +1,27 @@
+# Pricing Conversion Guide
+
+Use this reference only when the user asks to translate effort into a commercial range.
+
+## Core rule
+
+Do not present pricing conversion as objective certainty. State the pricing assumptions explicitly.
+
+## Recommended conversion steps
+
+1. Start from the effort range, not from a target price.
+2. Identify the assumed Pod shape and duration.
+3. Apply the commercial logic relevant to the current proposal model.
+4. State what is included in the commercial range and what is excluded.
+5. Note whether contingency is already embedded in the effort range, priced separately, or handled as a commercial buffer.
+
+## Pricing language guidance
+
+Use wording like this:
+
+> The commercial range below is derived from the estimated effort and current delivery assumptions. It is not a fixed commitment. The range will tighten after scope, data readiness, integration ownership, and governance requirements are confirmed.
+
+## Guardrails
+
+- Do not hide uncertainty by collapsing low, likely, and high effort into one price without explanation.
+- Do not convert to price if the user only asked for effort.
+- If pricing assumptions are missing, say what was assumed.

package/.github/skills/bottom-up-estimation/templates/estimate-package-template.md

@@ -0,0 +1,117 @@
+# [Estimate Title]
+
+## Estimate Framing
+
+- Estimate type: [ROM / proposal input / scoping estimate / comparison]
+- Intended decision: [What decision this estimate supports]
+- Confidence level: [Low / Medium / Higher]
+
+## Scope Boundaries
+
+| Area | Included | Excluded |
+| --- | --- | --- |
+| [Area] | [Included scope] | [Excluded scope] |
+
+## Work Breakdown
+
+| Work Package | Description | Delivery Type |
+| --- | --- | --- |
+| [Package] | [What it covers] | [AI-accelerated / mixed / dependency-bound] |
+
+## Estimate Table
+
+| Work Package | Low | Likely | High | Notes |
+| --- | ---: | ---: | ---: | --- |
+| [Package] | [Days] | [Days] | [Days] | [Assumption or risk] |
+
+## Complexity And Contingency
+
+- Main complexity drivers: [List]
+- Contingency rationale: [Explain]
+
+## Capacity And Timeline Signal
+
+- Suggested Pod shape: [Roles and allocations]
+- Estimated effort: [Total range]
+- Timeline signal: [Range]
+
+## ROM Range And Estimate Movers
+
+- ROM range: [Effort or commercial range]
+- Main movers up: [List]
+- Main movers down: [List]
+
+## Recommendation
+
+[State whether the work fits a focused Pod, co-delivery, or broader enterprise motion.]# Estimate Framing
+
+- Business objective:
+- Delivery stage:
+- Delivery shape:
+- Confidence level:
+
+## Scope Boundaries
+
+| Area | Included | Excluded |
+| --- | --- | --- |
+| | | |
+
+## Delivery Shape And Ownership Assumptions
+
+- Pod-owned work:
+- Shared or client-owned work:
+- Handoff expectations:
+
+## Work-Package Estimate Table
+
+| Workstream | Work Package | Acceleration Type | Low | Likely | High | Notes |
+| --- | --- | --- | ---: | ---: | ---: | --- |
+| | | | | | | |
+
+## AI Acceleration Assessment
+
+### AI-Accelerated Work
+
+-
+
+### Dependency-Bound Work
+
+-
+
+## Non-Build Effort And Contingency
+
+| Category | Add-On | Rationale |
+| --- | ---: | --- |
+| | | |
+
+## Capacity And Timeline
+
+- Assumed team or Pod shape:
+- Total likely effort:
+- Implied timeline:
+
+## ROM Range
+
+- Low:
+- Likely:
+- High:
+
+## Commercial Translation
+
+- Pricing requested: [Yes / No]
+- Pricing assumptions:
+- Commercial range:
+
+## Pod Tier Mapping
+
+- Recommended motion:
+- Why this fits:
+- What could change the recommendation:
+
+## Estimate Movers And Next Discovery Questions
+
+-
+
+## Proposal-Ready Narrative
+
+>

package/.github/skills/bottom-up-estimation/templates/estimation-worksheet-template.csv

@@ -0,0 +1,16 @@
+Work Package,Description,Delivery Type,Low Days,Likely Days,High Days,Complexity Driver,Dependency Risk,Notes
+Discovery synthesis,"Convert discovery notes into scoped backlog and estimate assumptions",AI-accelerated,4,6,10,Requirements clarity,Medium,"Assumes workshop notes are already available"
+Architecture blueprint,"Define solution shape, integration boundaries, and delivery pattern",Mixed,5,8,12,Integration complexity,Medium,"Increase if security review is still open"
+Workflow UI,"Build pilot screens and user workflow states",AI-accelerated,8,12,18,UX complexity,Medium,"Assumes MVP-only UI"
+Integration adapter,"Connect to target system or service",Dependency-bound,10,18,30,Integration complexity,High,"Increase if API access is not yet approved"
+Evaluation harness,"Create representative test set and scoring approach",AI-accelerated,6,10,16,AI uncertainty,Medium,"Increase if SME review cycles are slow"Workstream,Work Package,Acceleration Type,Low Estimate Days,Likely Estimate Days,High Estimate Days,Complexity Notes,Dependency Notes,Owner Notes
+Discovery,Requirements synthesis,AI-accelerated,,,,,,
+Architecture,Solution blueprint,Mixed,,,,,,
+Experience,Workflow design,AI-accelerated,,,,,,
+Application,Service and UI implementation,AI-accelerated,,,,,,
+Data,Source preparation and retrieval design,Mixed,,,,,,
+AI Workflow,Prompt and evaluation setup,AI-accelerated,,,,,,
+Integration,Enterprise system adapter,Dependency-bound,,,,,,
+QA,Validation and defect remediation,Mixed,,,,,,
+Delivery Engineering,CI and deployment flow,Mixed,,,,,,
+Governance,Approval and handoff support,Dependency-bound,,,,,,

package/.github/skills/business-logic-extractor/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: business-logic-extractor
+description: 'Extract the workflow rules, validations, approvals, triggers, exceptions, and integration logic that must be surfaced before Jump Start scoping, PRD writing, or solution design. Use this whenever the user needs the actual business logic made explicit instead of buried in notes or transcripts.'
+argument-hint: 'Paste requirements, notes, a transcript, or a process description.'
+---
+
+# Business Logic Extractor
+
+## Positioning
+
+Use this skill to make hidden workflow and rule complexity visible early in a Jump Start or Pod motion. It should surface the logic that must be understood before the team commits to architecture, sizing, automation design, or agent behavior.
+
+## When To Use This
+
+- Discovery content describes a process but not the rules.
+- The team needs to identify automation logic or decision points.
+- A solution design or PRD needs concrete business rules.
+- Workshop notes describe a target workflow, but approvals, exceptions, or calculations are still vague.
+
+## Typical Need Shapes
+
+- "Pull the real workflow rules out of these Jump Start notes before we write a proposal."
+- "Turn this Pod pilot description into explicit approval, fallback, and human-review logic."
+- "Extract the business rules that will govern routing, prioritization, or agent behavior."
+
+## When Not To Use This
+
+- Do not use it as the only architecture skill. Use `solution-architecture-patterns` after the rules are extracted.
+
+## Required Inputs
+
+- Process notes, requirements, transcript excerpts, or current-state description.
+
+## Evidence And Boundary Discipline
+
+Label each rule as confirmed, inferred, or unknown when the source is uneven. Do not invent validations, approval paths, or system behavior to make the process feel complete. If a rule could change scope, effort, compliance, or acceptance, surface it as a design-critical item.
+
+## Workflow
+
+1. Identify actors, triggers, inputs, outputs, and workflow stages.
+2. Extract validations, decision points, calculations, and exceptions.
+3. Note approvals, escalation paths, handoffs, and dependencies.
+4. Separate confirmed logic from assumptions, policy constraints, or open questions.
+5. Group the rules into a usable structure for design, backlog, or PRD work.
+
+## Output Structure
+
+1. Workflow summary
+2. Core actors and triggers
+3. Business rules and validations
+4. Exceptions, escalations, and human review points
+5. Data or integration dependencies
+6. Assumptions and missing logic
+
+## Reference Files
+
+- Use [logic-pattern.md](./references/logic-pattern.md) for the default extraction format plus Jump Start and AI Innovation Pod rule-table examples.
+- Use [../../../05-reference/the-jumpstart-workshops.md](../../../05-reference/the-jumpstart-workshops.md) when the logic comes from workshop material.
+- Use [../../../05-reference/prototype-to-Production.md](../../../05-reference/prototype-to-Production.md) when the rules need to support a production path.
+
+## Common Pitfalls
+
+### Pitfall 1: Summarizing Process Instead Of Extracting Rules
+
+Bad: describing the workflow in prose without decisions, validations, triggers, or exceptions.
+
+Better: produce explicit rule statements that can feed architecture, PRD, backlog, or acceptance criteria.
+
+### Pitfall 2: Missing Exceptions
+
+Bad: only documenting happy-path behavior.
+
+Better: call out escalations, rejected states, fallback steps, manual review points, and unresolved edge cases.
+
+## Quality Bar
+
+- Favor explicit rules over narrative summary.
+- Show where logic is assumed rather than confirmed.
+- Make the output reusable in design, prioritization, or PRD work.

package/.github/skills/business-logic-extractor/evals/evals.json

@@ -0,0 +1,33 @@
+{
+  "skill_name": "business-logic-extractor",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Extract the business logic from the attached intake workflow notes for a Jump Start or AI Innovation Pod intake process. Organize the result into actors, triggers, inputs, rules, exceptions, outputs, and dependencies.",
+      "expected_output": "A structured rule breakdown of the intake workflow that a design team could use for scoping or PRD work.",
+      "files": [
+        "evals/files/intake-workflow-notes.md"
+      ],
+      "expectations": [
+        "The output identifies actors, trigger, required inputs, and outputs.",
+        "The output captures the completeness validation and approval or routing thresholds.",
+        "The output includes the draft-save and reopen-for-correction exceptions.",
+        "The output surfaces dependencies such as Teams, Planner, or security review support."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Turn the attached process narrative into explicit business logic for implementation review. Favor rules, validations, and state transitions over chronological summary, and label inferred logic clearly when needed.",
+      "expected_output": "A rule-oriented summary of the process narrative with validations, exceptions, and dependencies called out explicitly.",
+      "files": [
+        "evals/files/process-narrative.md"
+      ],
+      "expectations": [
+        "The output converts the narrative into explicit rules rather than a paragraph recap.",
+        "The output captures the security review requirement for customer PII and the owner requirement for cross-functional requests.",
+        "The output identifies the bounce-back, draft-save, or resubmission paths.",
+        "The output distinguishes confirmed rules from inferred logic where the source is ambiguous."
+      ]
+    }
+  ]
+}

package/.github/skills/business-logic-extractor/evals/files/intake-workflow-notes.md

@@ -0,0 +1,30 @@
+# Intake Workflow Notes
+
+- Actors:
+  - requester
+  - intake coordinator
+  - regional approver for requests over $25,000
+- Trigger:
+  - new AI use case intake form submitted through Teams
+- Required inputs:
+  - business unit
+  - use case summary
+  - data sources
+  - requested outcome
+  - sponsor name
+- Validation rules:
+  - form cannot move to triage if sponsor name or data sources are blank
+  - if regulated data is involved, security review flag must be set to yes or no
+- Routing rules:
+  - standard requests go to the weekly triage queue
+  - requests over $25,000 or with cross-business-unit impact require regional approver review
+- Exceptions:
+  - internal team members can save as draft before all fields are complete
+  - intake coordinator can reopen rejected forms for correction
+- Outputs:
+  - triage ticket created in Planner
+  - confirmation message sent to requester
+- Dependencies:
+  - Teams form availability
+  - triage mailbox
+  - assigned security SME for regulated-data requests

package/.github/skills/business-logic-extractor/evals/files/process-narrative.md

@@ -0,0 +1,3 @@
+# Process Narrative
+
+Once a request comes in, the intake coordinator does a quick completeness check. If the sponsor is missing or the business outcome is unclear, the request is sent back for correction instead of moving to triage. If the use case touches customer PII, security review has to happen before a workshop can be scheduled. Small requests for a single team usually move into the weekly backlog, but cross-functional ideas cannot be scoped until each impacted team has named an owner. Internal teams that are still collecting details are allowed to save drafts without triggering triage. Rejected requests are not deleted; they stay open so the requester can correct the issue and resubmit.

package/.github/skills/business-logic-extractor/references/logic-pattern.md

@@ -0,0 +1,46 @@
+# Logic Pattern
+
+Use this pattern when Jump Start notes, workshop transcripts, pilot scoping inputs, or Pod delivery discussions describe a workflow but do not yet make the governing rules explicit.
+
+## Capture Order
+
+Extract business logic in this order:
+
+1. Actor
+2. Trigger
+3. Input
+4. Rule or validation
+5. Exception or fallback
+6. Output or downstream action
+7. Dependency or approval point
+
+## What Good Extraction Looks Like
+
+- Name the workflow boundary first: intake, triage, prioritization, approval, agent handoff, or delivery checkpoint.
+- Separate confirmed rules from inferred logic or open questions.
+- Include human review, approval, escalation, and compliance gates when they affect the workflow.
+- Call out systems, data owners, or client dependencies that would block Pod delivery or post-workshop follow-through.
+
+## Jump Start Example
+
+Use this shape when a Jump Start workshop is clarifying whether an opportunity is ready to move from discovery into scoped follow-on work.
+
+| Actor | Trigger | Input | Rule or validation | Exception or fallback | Output | Dependency |
+| --- | --- | --- | --- | --- | --- | --- |
+| Business sponsor | Workshop prioritization session | Candidate use cases, target outcomes, owner list | A use case cannot be recommended as the first follow-on if no business owner is named and no success measure is proposed. | If the use case has strong interest but missing ownership, keep it as a parked candidate rather than the primary recommendation. | Prioritized shortlist with one recommended first use case | Sponsor attendance, agreed decision criteria |
+| Solution lead | Architecture discussion | Data sources, integration notes, security constraints | Directional architecture can be drafted during Jump Start, but implementation commitments cannot be made until data access, system ownership, and security constraints are confirmed. | If data details are incomplete, label architecture as directional and capture validation items for the next phase. | Directional architecture guidance and validation list | Client system owner, security lead |
+| Facilitator | Workshop readout | Findings, risks, open questions | The final readout must distinguish confirmed requirements from assumptions so proposal or SOW language does not overstate readiness. | If the room cannot confirm a point, record it as an assumption or open question instead of a requirement. | Client-ready readout and follow-up actions | Notes capture, sponsor review |
+
+## AI Innovation Pod Example
+
+Use this shape when the team is defining the operating rules for a Pod pilot or MVP.
+
+| Actor | Trigger | Input | Rule or validation | Exception or fallback | Output | Dependency |
+| --- | --- | --- | --- | --- | --- | --- |
+| End user | Submit a request to the assistant | User question, uploaded document, workflow context | The assistant may answer only within the approved workflow and approved source set for the pilot. | If retrieval confidence is low or the request is outside scope, route to human review or return an approved fallback response. | Draft answer, recommendation, or routed case | Approved content corpus, retrieval service |
+| Reviewer or SME | Review generated output | Draft response, confidence signals, cited sources | Any external-facing or operationally material recommendation requires human review before release when the pilot is still in Ignition or Turbo scope. | Low-risk internal summaries may be auto-drafted but still logged for audit and tuning review. | Approved output or rejected draft with feedback | Named reviewer, review queue |
+| Product owner | Sprint review or checkpoint | Pilot metrics, defects, blocked dependencies | The Pod can continue building only if critical dependencies, acceptance measures, and client approvals remain on track. | If a dependency slips, resequence work or narrow scope rather than silently absorbing the delay. | Scope decision, backlog adjustment, or checkpoint recommendation | Client approvals, dependency tracker |
+
+## Prompting Reminder
+
+When details are inferred rather than stated, label them clearly as inferred, assumed, or not yet confirmed.

package/.github/skills/change-management-readiness/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: change-management-readiness
+description: Assess adoption risk for an AI Innovation Pod or Jump Start build across sponsorship strength, training load, role redesign, workflow disruption, union and legal sensitivity, communications readiness, incentive alignment, and middle-management buy-in, and produce an adoption-risk scorecard with mitigations. Use this whenever the user needs a change management readiness check, adoption risk assessment, OCM plan input, or a way to flag people-side risks that will sink an otherwise sound AI build, even when phrased as "will users actually use this," "what's the rollout risk," "do we need union sign-off," or "how do we get adoption."
+argument-hint: Paste the AI use case, target user population, sponsoring leader, known training and workflow impacts, and any union, legal, or HR sensitivities.
+---
+
+# Change Management Readiness
+
+## Positioning
+
+Use this skill to make adoption risk visible early — before a Pod ships a working prototype that nobody uses. The output should give sellers, Pod leads, and sponsors a defensible scorecard plus mitigations to fold into the engagement plan.
+
+Bias toward concrete people-side risks (sponsorship, role change, incentives, communications, union or legal) over generic "drive adoption" platitudes.
+
+## When To Use This
+
+- The user is scoping or shaping an AI build that will change how a workforce operates.
+- The team needs a defensible adoption risk view before SOW, kickoff, or steerco.
+- Phrased as "will they actually use it," "what's the people risk," "do we need HR or union sign-off," or "how do we land this."
+
+## When Not To Use This Alone
+
+- Do not use this for stakeholder mapping alone. Use `../proto-persona/SKILL.md`.
+- Do not use this for governance and policy. Use `../agent-governance/SKILL.md`.
+- Do not use this for facilitator-led adoption workshops. Pair with `../facilitation-guide-builder/SKILL.md`.
+
+## Required Inputs
+
+- AI use case and how it changes day-to-day work,
+- target user population (size, geography, roles, tenure mix),
+- sponsoring executive and middle managers in the path,
+- known training expectations,
+- union, works council, employment regulation, or HR sensitivities,
+- prior change history (recent reorgs, failed rollouts, layoffs),
+- incentives and performance metrics for affected roles.
+
+## Readiness Dimensions
+
+Score each dimension Red / Amber / Green with rationale and evidence:
+
+1. Executive sponsorship strength and visibility.
+2. Middle-management buy-in and incentive alignment.
+3. End-user motivation and pain alignment.
+4. Role redesign risk (does the AI change scope, identity, or headcount).
+5. Training load and learning-curve realism.
+6. Communications readiness (channels, narrative, cadence).
+7. Union, works council, employment-law, and HR sensitivity.
+8. Legal and regulatory adoption gates (e.g., disclosure, opt-out, audit).
+9. Tooling and access friction (devices, SSO, licensing).
+10. Change fatigue and recent-history posture.
+
+See [references/adoption-risk-rubric.md](./references/adoption-risk-rubric.md) for anchor descriptions and probing questions per dimension.
+
+## Workflow
+
+1. Confirm the user impact. Translate the AI build into a "before / after" view of one user's day.
+2. Score each dimension R / A / G using the rubric. Cite evidence; flag unknowns.
+3. Surface the top three adoption risks and their owners.
+4. Recommend mitigations per risk: sponsorship moves, communications, training format, incentive adjustments, legal pre-checks, opt-in vs. opt-out design.
+5. Identify go / no-go gates for rollout (e.g., "do not launch in EU sites without works council briefing").
+6. Produce the readiness artifact using [templates/change-readiness-scorecard-template.md](./templates/change-readiness-scorecard-template.md).
+
+## Output Mode
+
+Default artifact:
+
+- Executive summary (overall readiness verdict, top three risks).
+- Before / after view of an affected user's day.
+- Readiness scorecard table.
+- Top adoption risks and mitigations.
+- Stakeholder action register (sponsor, manager, HR, legal, union liaison).
+- Go / no-go gates for rollout.
+- Open questions and people the team must talk to.
+
+## Working Rules
+
+1. Never call adoption "low risk" without evidence of sponsorship, incentive alignment, and prior change capacity.
+2. Treat union, works council, and employment-law signals as veto-capable.
+3. Distinguish training load (learnable) from role identity threat (often not learnable).
+4. Be specific about who owns each mitigation and by when.