jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/azure-devops-delivery-builder/README.md

@@ -0,0 +1,36 @@
+# Azure DevOps Delivery Builder
+
+This skill package helps agents turn Jump Start and AI Innovation Pod planning artifacts into Azure DevOps-ready execution work.
+
+## What Is Included
+
+- `SKILL.md`: Triggering guidance, workflow, quality bar, and output rules
+- `references/`: Azure DevOps process guidance, quality rules, AI backlog patterns, reporting guidance, and Pod alignment
+- `templates/`: Reusable work-item and CSV templates
+- `scripts/`: CLI utilities for JSON-to-CSV export and backlog validation
+- `examples/`: Worked example showing discovery-to-backlog conversion
+- `evals/`: Example prompts for validating the skill behavior
+
+## Best Use Cases
+
+- Convert workshop notes into Azure Boards backlog structure
+- Create agent-ready work items for Copilot-assisted delivery
+- Review backlog quality before sprint planning
+- Create Azure DevOps CSV imports and WIQL queries
+- Preserve source traceability from Jump Start through Pod implementation
+
+## Utility Scripts
+
+- Start from `./.github/skills/azure-devops-delivery-builder/templates/backlog-items-template.json` for JSON input shape.
+- `python ./.github/skills/azure-devops-delivery-builder/scripts/generate_azure_devops_csv.py backlog.json --output ado-import.csv`
+- `python ./.github/skills/azure-devops-delivery-builder/scripts/validate_azure_boards_backlog.py ado-import.csv`
+- `python ./.github/skills/azure-devops-delivery-builder/scripts/smoke_test_csv_tools.py`
+
+Smoke-test fixture input is provided at `./.github/skills/azure-devops-delivery-builder/examples/fixtures/backlog-items-smoke.json`.
+
+## Suggested Invocation Shapes
+
+- “Convert these discovery notes into Azure DevOps epics, features, stories, tasks, and spikes.”
+- “Review this Azure Boards backlog for readiness, missing dependencies, and oversized items.”
+- “Generate an Agile-process CSV import preview and the WIQL queries we need for MVP tracking.”
+- “Turn this AI use case PRD into agent-ready work items with citations, evaluation, and observability criteria.”

package/.github/skills/azure-devops-delivery-builder/SKILL.md

@@ -0,0 +1,197 @@
+---
+name: azure-devops-delivery-builder
+description: 'Use this skill when creating, reviewing, organizing, importing, or refining Azure DevOps work items from discovery notes, workshop outputs, PRDs, BRDs, SOWs, MVP scopes, POCs, transcripts, architecture documents, backlog ideas, or delivery plans. The skill produces Azure Boards-ready epics, features, user stories, product backlog items, tasks, bugs, spikes, acceptance criteria, dependencies, tags, priorities, estimates, area paths, iteration paths, WIQL queries, sprint-ready backlog slices, and CSV import files.'
+argument-hint: 'Provide the source material, Azure DevOps process template if known, team/project naming conventions, and whether you want backlog draft, CSV import, WIQL queries, review findings, or sprint planning outputs.'
+---
+
+# Azure DevOps Delivery Builder
+
+Convert rough planning, discovery, and delivery artifacts into Azure DevOps-ready work that is clear, testable, traceable, and usable by delivery teams and AI coding agents.
+
+This skill is the Azure DevOps bridge between Jump Start outputs and AI Innovation Pod execution. It should preserve business logic, expose dependencies, and avoid fake precision when the source material is still exploratory.
+
+## Use This Skill When
+
+- The user wants Azure Boards epics, features, stories, PBIs, tasks, bugs, or spikes.
+- The user wants to convert discovery notes, PRDs, BRDs, SOWs, MVP scopes, workshop notes, or architecture material into an Azure DevOps backlog.
+- The user wants Azure DevOps CSV imports, WIQL queries, sprint plans, or backlog-quality reviews.
+- The user wants work items tailored for GitHub Copilot, Cursor, Claude Code, Azure Repos, or Azure Pipelines delivery workflows.
+- The user wants a traceable path from Jump Start decisions to Pod execution.
+
+## Do Not Use This Skill When
+
+- The user only needs a high-level roadmap with no backlog detail. Use the phased-roadmap skill instead.
+- The user needs Jira or Confluence-native execution. Use the Atlassian backlog skills instead.
+- The user needs only proposal language, SOW text, or workshop summaries with no work-item output.
+
+## What This Skill Produces
+
+Depending on the ask, produce one or more of:
+
+- Epic and feature structure
+- User stories or PBIs with testable acceptance criteria
+- Tasks, bugs, and spikes
+- Dependency register and risk flags
+- Area Path and Iteration Path suggestions
+- Tagging and metadata standards
+- CSV import preview and final CSV-ready output
+- WIQL queries for planning and reporting
+- Sprint sequencing guidance
+- Backlog quality review findings
+- Definition of Ready and Definition of Done overlays
+- Source traceability matrix
+- Azure Repos and Azure Pipelines traceability guidance
+- Agent-ready implementation tickets with likely code areas, test expectations, and PR naming hints
+
+## Required Inputs
+
+- Source material: notes, transcript, PRD, BRD, SOW, scope, architecture, or direct instruction
+- Desired output: backlog draft, review, CSV import, queries, sprint slice, or report
+- Process template if known: Agile, Scrum, or CMMI
+- Delivery context if known: Jump Start, Ignition, Turbo, Overdrive, or non-Pod delivery
+- Naming constraints if known: project name, area paths, iteration names, tags, priority model
+
+If the source is incomplete, proceed with a labeled hypothesis-driven draft instead of pretending the gaps do not matter.
+
+## Core Workflow
+
+1. Identify the source material and the requested Azure DevOps output.
+2. Determine the process template or default to neutral work-item mapping.
+3. Extract the business outcome, capabilities, workflows, dependencies, risks, and unknowns.
+4. Decompose the work into epics, features, stories or PBIs, tasks, bugs, and spikes.
+5. Add acceptance criteria, test expectations, source traceability, and nonfunctional requirements.
+6. Add metadata: tags, priority, Area Path, Iteration Path, estimate hints, dependency markers.
+7. Present a reviewable markdown version before generating import CSV unless the user explicitly asks for CSV only.
+8. If asked, generate WIQL, reports, sprint slices, or backlog quality findings.
+
+## Process Template Rules
+
+Use the process template reference when needed: [process-templates.md](./references/process-templates.md)
+
+When the process template is unknown, map neutrally:
+
+- Major business outcome to Epic
+- Capability or capability slice to Feature
+- User-facing work to User Story or PBI
+- Technical implementation to Task
+- Research or uncertainty reduction to Spike
+- Defect or broken behavior to Bug
+
+Do not force every technical activity into user story format.
+
+## Work Item Rules
+
+Use the backlog decomposition reference when needed: [backlog-decomposition.md](./references/backlog-decomposition.md)
+
+- Use Epic for meaningful business outcomes, not team activity buckets.
+- Use Feature for capabilities that deliver a coherent slice of value.
+- Use Story or PBI for user-visible behavior or bounded outcome-oriented backlog units.
+- Use Task for technical implementation work, shared infrastructure, test harnesses, or pipeline setup.
+- Use Spike for unresolved questions that must produce a decision, recommendation, prototype, or estimate.
+- Use Bug only for broken or incorrect behavior, not vague cleanup work.
+
+## Acceptance Criteria And Quality Rules
+
+Use the quality reference when needed: [acceptance-criteria-and-quality.md](./references/acceptance-criteria-and-quality.md)
+
+- Acceptance criteria must be testable.
+- Prefer Given/When/Then structure for stories and PBIs.
+- Include edge cases, permission behavior, failure handling, and observability expectations where relevant.
+- Separate business outcome from implementation notes.
+- Mark missing dependencies, missing source evidence, or unresolved assumptions explicitly.
+
+## AI, RAG, And Agent Work Rules
+
+Use the AI patterns reference when needed: [ai-work-item-patterns.md](./references/ai-work-item-patterns.md)
+
+For AI, RAG, or agentic work items, include where relevant:
+
+- Source traceability and citation behavior
+- Permission filtering and ACL handling
+- Prompt, model, or tool version logging
+- Evaluation cases and golden-set updates
+- No-answer behavior
+- Human review or override path
+- Guardrails and policy checks
+- Token, latency, or cost observability
+
+## Jump Start And Pod Alignment
+
+Use [jumpstart-and-pod-alignment.md](./references/jumpstart-and-pod-alignment.md) when the backlog needs delivery posture, tier framing, or prototype-to-production sequencing.
+
+Rules:
+
+- Preserve the distinction between discovery outputs and build commitments.
+- Pull risky unknowns forward into spikes or early sprint work.
+- Reflect whether the backlog is Ignition-style discovery, Turbo-style MVP build, or Overdrive-style hardening and scale.
+- Do not imply production readiness unless the source material supports it.
+
+## Azure DevOps Metadata Rules
+
+Use [ado-traceability-and-pipelines.md](./references/ado-traceability-and-pipelines.md) when work must tie to repos, branches, builds, and releases.
+
+- Suggest Area Paths that map to real ownership boundaries.
+- Suggest Iteration Paths that reflect realistic sequencing.
+- Use tags to make reporting easier, not noisier.
+- Recommend AB# linking in branches, commits, and PR titles when Azure Repos is in play.
+- Add pipeline and environment tasks when build, test, deployment, approvals, or observability are missing.
+
+## WIQL And Reporting Rules
+
+Use [wiql-and-reporting.md](./references/wiql-and-reporting.md) when the user asks for queries, dashboards, or readiness reports.
+
+- Keep WIQL practical and directly tied to planning or reporting use cases.
+- Prefer queries that expose blocked work, MVP scope, AI-specific work, or refinement gaps.
+- Summaries should highlight what is ready, what is blocked, and what decisions remain.
+
+## Template Index
+
+Use these templates when drafting work items or exports:
+
+- [epic-template.md](./templates/epic-template.md)
+- [feature-template.md](./templates/feature-template.md)
+- [story-pbi-template.md](./templates/story-pbi-template.md)
+- [task-template.md](./templates/task-template.md)
+- [spike-template.md](./templates/spike-template.md)
+- [bug-template.md](./templates/bug-template.md)
+- [backlog-items-template.json](./templates/backlog-items-template.json)
+- [ado-import-template.csv](./templates/ado-import-template.csv)
+
+## Script Index
+
+Use these scripts when the user wants machine-usable backlog artifacts:
+
+- [generate_azure_devops_csv.py](./scripts/generate_azure_devops_csv.py): Convert structured JSON backlog items into Azure DevOps import CSV
+- [validate_azure_boards_backlog.py](./scripts/validate_azure_boards_backlog.py): Validate Azure Boards CSV files for missing columns and basic backlog quality issues
+
+## Example Index
+
+- [jumpstart-to-ado-backlog-example.md](./examples/jumpstart-to-ado-backlog-example.md)
+
+## Output Expectations
+
+Default output order:
+
+1. Summary of what the backlog or review is trying to achieve
+2. Confirmed facts, assumptions, and open questions when inputs are incomplete
+3. Structured backlog, review findings, CSV preview, WIQL, or sprint plan
+4. Dependencies, risks, and next-step recommendations
+
+## Quality Bar
+
+- Titles are specific and action-oriented.
+- Work items are small enough to estimate and test.
+- Acceptance criteria are testable.
+- Dependencies and security constraints are visible.
+- Source traceability is preserved.
+- AI work includes evaluation and observability, not just model behavior.
+- The backlog is useful to both humans and AI coding agents.
+
+## Common Pitfalls
+
+- Turning vague notes into overconfident implementation commitments
+- Mixing business value, technical tasks, and architecture decisions into one story
+- Skipping source traceability
+- Writing acceptance criteria that cannot be tested
+- Forgetting environment, IAM, integration, or data-access dependencies
+- Treating “production-ready” as implied without hardening, evaluation, and operational work

package/.github/skills/azure-devops-delivery-builder/evals/evals.json

@@ -0,0 +1,64 @@
+{
+  "skill_name": "azure-devops-delivery-builder",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Convert these Jump Start notes for an AI review queue into an Azure DevOps backlog with epics, features, stories, tasks, spikes, acceptance criteria, dependencies, and Area Path or Iteration Path suggestions.",
+      "expected_output": "Produces a structured Azure Boards backlog with clear hierarchy, testable acceptance criteria, dependency visibility, and delivery-ready metadata suggestions.",
+      "assertions": [
+        {
+          "name": "includes_hierarchy",
+          "type": "contains_concept",
+          "description": "Response contains backlog hierarchy such as epic, feature, and story or PBI."
+        },
+        {
+          "name": "includes_acceptance_criteria",
+          "type": "contains_concept",
+          "description": "Response includes testable acceptance criteria for at least one story-like item."
+        },
+        {
+          "name": "includes_dependencies",
+          "type": "contains_concept",
+          "description": "Response surfaces dependencies or unknowns rather than hiding them."
+        }
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Review this Azure DevOps backlog for sprint readiness, missing dependencies, non-testable acceptance criteria, and work items that are too broad for MVP delivery.",
+      "expected_output": "Produces a backlog quality review with concrete findings, severity, and recommendations tied to Azure DevOps readiness.",
+      "assertions": [
+        {
+          "name": "quality_findings_present",
+          "type": "contains_concept",
+          "description": "Response includes backlog-quality findings rather than only a rewritten backlog."
+        },
+        {
+          "name": "testability_checked",
+          "type": "contains_concept",
+          "description": "Response checks acceptance criteria for testability or readiness."
+        }
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Create Azure DevOps work items for a permission-aware RAG assistant and include AI-specific acceptance criteria, CSV import preview, and WIQL for tracking open AI work.",
+      "expected_output": "Produces AI-aware work items with permissions, citations, evaluation or observability expectations, plus CSV-oriented output and WIQL.",
+      "assertions": [
+        {
+          "name": "ai_controls_included",
+          "type": "contains_concept",
+          "description": "Response includes permission filtering, citations, evaluation, observability, or similar AI delivery controls."
+        },
+        {
+          "name": "wiql_included",
+          "type": "contains_concept",
+          "description": "Response includes at least one practical WIQL query."
+        }
+      ],
+      "files": []
+    }
+  ]
+}

package/.github/skills/azure-devops-delivery-builder/examples/fixtures/backlog-items-smoke.json

@@ -0,0 +1,35 @@
+{
+  "work_items": [
+    {
+      "work_item_type": "Feature",
+      "title": "RFQ Intake Automation",
+      "description": "Enable upload, validation, and processing of RFQ packages.",
+      "acceptance_criteria": [
+        "Given a supported RFQ file, when uploaded, then an intake record is created.",
+        "Given an invalid file, when submitted, then a clear validation error is returned."
+      ],
+      "priority": 1,
+      "tags": [
+        "ai-pod",
+        "mvp",
+        "backend"
+      ],
+      "area_path": "AI Pod\\Quote Acceleration",
+      "iteration_path": "AI Pod\\Sprint 1 - Foundation"
+    },
+    {
+      "work_item_type": "Spike",
+      "title": "Validate RFQ format support",
+      "description": "Validate parser and extraction constraints across top RFQ formats.",
+      "acceptance_criteria": "Produce a decision deliverable with recommended in-scope formats.",
+      "priority": 1,
+      "tags": [
+        "jumpstart",
+        "spike",
+        "needs-refinement"
+      ],
+      "area_path": "AI Pod\\Quote Acceleration",
+      "iteration_path": "AI Pod\\Sprint 0 - Discovery and Setup"
+    }
+  ]
+}

package/.github/skills/azure-devops-delivery-builder/examples/jumpstart-to-ado-backlog-example.md

@@ -0,0 +1,59 @@
+# Example: Jump Start Notes To Azure DevOps Backlog
+
+## Source Summary
+
+Source: Jump Start workshop notes for a quote acceleration use case.
+
+Confirmed signals:
+
+- Sales operations team loses time manually extracting RFQ data.
+- Users want upload, validation, extraction, review, and approval workflow.
+- The future solution will likely include AI-assisted extraction and review.
+- Access, source formats, and approval routing are not fully resolved.
+
+## Suggested Backlog Slice
+
+### Epic
+
+Quote Acceleration Platform
+
+### Feature
+
+RFQ Intake Automation
+
+### Story Or PBI
+
+Upload RFQ package and create intake record.
+
+Acceptance criteria:
+
+1. Given a supported RFQ file, when the user uploads it, then the system stores the file and creates an intake record.
+2. Given the file fails validation, when the user submits it, then the system returns a clear error message and does not create an intake record.
+3. Given upload succeeds, when extraction starts, then the intake status changes to `Processing`.
+
+### Technical Tasks
+
+- Create upload API endpoint and validation rules.
+- Create intake record schema and storage model.
+- Add upload telemetry and error logging.
+- Add PR build validation for upload API tests.
+
+### Spike
+
+Validate supported RFQ file formats and extraction constraints.
+
+Questions:
+
+- Which formats are in scope for MVP?
+- What file-size limits or OCR constraints exist?
+- Which edge cases require user review rather than automated extraction?
+
+## Metadata Suggestions
+
+- Area Path: `AI Pod\Quote Acceleration`
+- Iteration Path: `AI Pod\Sprint 0 - Discovery and Setup` for spike, `AI Pod\Sprint 1 - Foundation` for upload story
+- Tags: `ai-pod`, `jumpstart`, `mvp`, `frontend`, `backend`, `document-intelligence`
+
+## Traceability Note
+
+Derived from Jump Start workshop notes and user instruction. Do not mark production readiness until the backlog also includes auth, CI/CD, evaluation, observability, and release-readiness work.

package/.github/skills/azure-devops-delivery-builder/references/acceptance-criteria-and-quality.md

@@ -0,0 +1,54 @@
+# Acceptance Criteria And Backlog Quality
+
+Use this reference when writing or reviewing work items.
+
+## Acceptance Criteria Rules
+
+- Make criteria testable and observable.
+- Prefer Given/When/Then for story-like work.
+- Include failure handling, permissions, and edge cases when relevant.
+- Keep implementation notes separate from acceptance criteria.
+
+## Strong Criteria Pattern
+
+1. Happy path behavior
+2. Validation or failure path
+3. Permission or access behavior if applicable
+4. Logging, telemetry, or traceability behavior if applicable
+
+## Definition Of Ready
+
+A work item is ready when:
+
+- Business outcome is clear
+- Actor or owner is identified
+- Acceptance criteria are testable
+- Dependencies are visible
+- Required systems and data are named
+- Security and access assumptions are captured
+- Area Path and Iteration Path are assigned or proposed
+- Source traceability is preserved
+
+## Definition Of Done
+
+A work item is done when:
+
+- Acceptance criteria pass
+- Tests required by the slice are complete
+- Build or pipeline gates pass where applicable
+- Logging or observability is present for important behavior
+- Security requirements are satisfied
+- Documentation is updated when behavior or operations changed
+- Product or delivery owner acceptance is captured when applicable
+
+## Review Findings To Flag
+
+- Vague title
+- Missing business value
+- Missing acceptance criteria
+- Story too large or multi-purpose
+- Technical and user work mixed together
+- Missing dependency or access assumption
+- Missing Area Path or Iteration Path
+- Missing source traceability
+- Non-testable or subjective acceptance criteria

package/.github/skills/azure-devops-delivery-builder/references/ado-traceability-and-pipelines.md

@@ -0,0 +1,37 @@
+# Azure Repos, Pipelines, And Traceability
+
+Use this reference when work items must connect to implementation and release controls.
+
+## Traceability Rules
+
+Prefer these linking patterns when Azure Repos is used:
+
+- Branch name: `feature/1234-upload-rfq-package`
+- Commit message: `AB#1234 Add RFQ upload endpoint`
+- Pull request title: `AB#1234 Upload RFQ package`
+
+## Recommended PR And Branch Policies
+
+- Require linked work item
+- Require successful build
+- Require minimum reviewers
+- Require comment resolution
+- Require test pass
+- Require security scan where relevant
+- Require branch naming convention
+- Require PR template when team maturity supports it
+
+## Common Pipeline Backlog Items
+
+- Create build pipeline
+- Add test execution and result publishing
+- Add code coverage reporting
+- Add dependency and security scanning
+- Add deployment pipeline and environment approvals
+- Add infrastructure validation
+- Add deployment smoke checks
+- Add Application Insights or equivalent validation checks
+
+## When To Create Pipeline Work Items
+
+Create pipeline tasks or stories when the source implies delivery expectations but does not yet include the operational path to build, test, release, observe, or rollback the solution.

package/.github/skills/azure-devops-delivery-builder/references/ai-work-item-patterns.md

@@ -0,0 +1,43 @@
+# AI, RAG, And Agent Work Item Patterns
+
+Use this reference when the backlog covers LLM, RAG, or agentic systems.
+
+## Common AI Capability Areas
+
+- Document ingestion and normalization
+- Durable document identity and versioning
+- Embedding generation and storage
+- Retrieval and reranking
+- Citation rendering
+- Permission-aware retrieval
+- Prompt and tool orchestration
+- Human review and override
+- Evaluation data creation
+- Guardrail and prompt-injection testing
+- Observability, cost, and latency telemetry
+
+## AI Story Writing Rules
+
+- Do not rely on prompt text for access control.
+- Treat evaluation as a delivery artifact, not optional cleanup.
+- Include citation or source traceability if the experience claims grounded answers.
+- Include no-answer behavior if the system should abstain.
+- Include human escalation when the workflow affects sensitive decisions.
+
+## Example Story Skeleton
+
+As an authorized user, I want grounded answers from permitted content so that the system helps me without exposing restricted information.
+
+Acceptance criteria should cover:
+
+- Accessible-source answer path
+- Restricted-content exclusion path
+- No-answer path when no permitted evidence exists
+- Logged model, prompt, source, and user context where policy allows
+
+## Example Spike Questions
+
+- Can durable document IDs survive rename and move events?
+- Can ACLs be exported and refreshed reliably?
+- Where should permission filtering happen before model invocation?
+- What telemetry is needed for answer audits and cost analysis?

package/.github/skills/azure-devops-delivery-builder/references/backlog-decomposition.md

@@ -0,0 +1,47 @@
+# Backlog Decomposition Guide
+
+Use this reference when breaking rough material into Azure DevOps work.
+
+## Decomposition Goals
+
+- Preserve the business outcome behind the request
+- Separate user-facing behavior from technical enablers
+- Surface dependencies and unknowns instead of hiding them
+- Produce backlog slices that are estimable, testable, and sequenceable
+
+## Step-by-Step Decomposition
+
+1. Identify the business outcome.
+2. Split the outcome into capability areas.
+3. For each capability, separate user-visible behavior from platform, integration, security, data, and operational work.
+4. Convert unresolved questions into spikes.
+5. Add tasks for CI/CD, observability, security, and deployment when those are part of the delivery path.
+
+## Split Signals
+
+Split work items when they:
+
+- Span multiple systems or teams
+- Contain both discovery and implementation
+- Contain both user workflow and platform setup
+- Cannot be accepted by a single coherent set of criteria
+- Are too large for one sprint or a normal delivery chunk
+
+## Typical Work-Item Shapes
+
+- Epic: “Quote Acceleration Platform”
+- Feature: “RFQ Intake Automation”
+- Story or PBI: “Upload RFQ package and create intake record”
+- Task: “Create API endpoint for RFQ upload validation”
+- Spike: “Validate source-system ACL extraction strategy”
+- Bug: “Fix duplicate citation rendering in answer panel”
+
+## Common Dependency Types
+
+- Environment and tenant setup
+- Identity and access management
+- API or source-system access
+- Test data availability
+- Network and on-prem connectivity
+- Security review and approvals
+- Platform services such as search, storage, messaging, telemetry

package/.github/skills/azure-devops-delivery-builder/references/jumpstart-and-pod-alignment.md

@@ -0,0 +1,41 @@
+# Jump Start And AI Innovation Pod Alignment
+
+Use this reference when the backlog is derived from Jump Start or shaped for Pod delivery.
+
+## Positioning Rule
+
+This skill should turn Jump Start outputs into execution-ready Azure DevOps work without collapsing discovery into false implementation certainty.
+
+## Delivery Posture By Pod Tier
+
+- Ignition: advisory-heavy backlog, decision-support spikes, architecture validation, dependency discovery, feasibility slices
+- Turbo: MVP-oriented build backlog, integrated feature slices, early evaluation and user feedback, sprintable execution work
+- Overdrive: production hardening, release controls, governance, observability, environment readiness, multi-stream sequencing
+
+## Backlog Signals By Maturity
+
+### Discovery Or Post-Workshop
+
+- More spikes
+- More assumptions and dependency markers
+- Fewer low-level implementation tasks
+- Explicit architecture, data, and security questions
+
+### MVP Or Pilot Build
+
+- More end-to-end stories or PBIs
+- Technical enabler tasks for auth, data, APIs, CI/CD, telemetry
+- Demo-path acceptance criteria
+
+### Prototype To Production
+
+- Add deployment gates, rollback readiness, observability, evaluation refresh, security review, operational ownership, and support tasks
+- Do not label work “production-ready” unless hardening work exists in the backlog
+
+## Recommended Sequencing Pattern
+
+- Sprint 0: access, environment, data, architecture, and risk spikes
+- Sprint 1: app skeleton, auth, CI/CD baseline, core data flow
+- Sprint 2: first working workflow and integrations
+- Sprint 3: AI capabilities, citations, review queue, feedback path
+- Sprint 4: evaluation, observability, security hardening, demo and release readiness

package/.github/skills/azure-devops-delivery-builder/references/process-templates.md

@@ -0,0 +1,61 @@
+# Azure DevOps Process Templates
+
+Use this reference when the user names or implies an Azure DevOps process template.
+
+## Agile
+
+Hierarchy:
+
+- Epic
+- Feature
+- User Story
+- Task
+- Bug
+
+Use when the team prefers user-story language.
+
+## Scrum
+
+Hierarchy:
+
+- Epic
+- Feature
+- Product Backlog Item
+- Task
+- Bug
+
+Use when the team manages backlog and sprint work in Scrum terms.
+
+## CMMI
+
+Hierarchy:
+
+- Epic
+- Feature
+- Requirement
+- Task
+- Bug
+- Change Request
+- Risk
+- Issue
+
+Use when governance and formal control tracking are first-class requirements.
+
+## Neutral Mapping When Unknown
+
+| Concept | Agile | Scrum | CMMI |
+| --- | --- | --- | --- |
+| Major business outcome | Epic | Epic | Epic |
+| Capability | Feature | Feature | Feature |
+| User-facing work | User Story | Product Backlog Item | Requirement |
+| Implementation work | Task | Task | Task |
+| Defect | Bug | Bug | Bug |
+| Research unknown | Spike or Task tagged `spike` | Spike or Task tagged `spike` | Issue or Task tagged `spike` |
+
+## Selection Rule
+
+If the source does not specify Agile, Scrum, or CMMI:
+
+1. Ask if the user knows the process template.
+2. If not, produce neutral work items that can be remapped later.
+3. Avoid hard-coding “User Story” versus “PBI” unless the user or source makes that choice clear.