From 8c05a076bb1a29700bdadc246f2bf7a93faff34c Mon Sep 17 00:00:00 2001 From: Magnus Hedemark Date: Sun, 2 Aug 2026 19:20:38 -0400 Subject: [PATCH] feat(production-excellence): add thin production-excellence bundle (#228) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the production-excellence bundle (#195) that composes cross-domain production evidence (readiness, migration, recovery, capacity/cost, incident-learning) into a launch or operational decision — go, no-go, defer, exception, or escalation — with an accountable owner and a post-launch learning path. - SKILL.md: thin umbrella with readiness routing table (5 primary production-domain routes + 7 supporting specialists), cross-domain entry evidence, gate/exception model, operational handoff, and post-launch learning paths routed to incident-learning and product-lifecycle-learning. - AGENTS.md: nested-skill loading behavior and harness compatibility. - README.md: human-facing with all five required sections. - references/discovery-brief.md: bounded comparison with 13 existing production and release skills (SRE, release, platform, security, data, QA, verification, lifecycle-learning, plus milestone skills). - references/evidence-packet.md: production evidence packet covering readiness, migration, recovery, capacity/cost, and incident-learning domains — for both new services and changes to existing systems. - references/gates.md: gate/exception model with go, no-go, defer, exception, escalation outcomes, each anchored to service ownership, risk, evidence, and verification. - references/handoff-record.md: operational handoff fields and post-launch learning path. - evals/evals.json: 5 integrated cases covering normal release, blocked launch (untested rollback), data migration, dependency outage, and cost/SLO conflict. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> --- .claude-plugin/marketplace.json | 9 + .codex-plugin/plugin.json | 1 + README.md | 3 + bundles/production-excellence/AGENTS.md | 28 +++ bundles/production-excellence/README.md | 48 +++++ bundles/production-excellence/SKILL.md | 178 ++++++++++++++++++ .../production-excellence/evals/evals.json | 74 ++++++++ .../references/discovery-brief.md | 84 +++++++++ .../references/evidence-packet.md | 110 +++++++++++ .../production-excellence/references/gates.md | 164 ++++++++++++++++ .../references/handoff-record.md | 115 +++++++++++ llms.txt | 1 + references/skill-triggers.md | 1 + 13 files changed, 816 insertions(+) create mode 100644 bundles/production-excellence/AGENTS.md create mode 100644 bundles/production-excellence/README.md create mode 100644 bundles/production-excellence/SKILL.md create mode 100644 bundles/production-excellence/evals/evals.json create mode 100644 bundles/production-excellence/references/discovery-brief.md create mode 100644 bundles/production-excellence/references/evidence-packet.md create mode 100644 bundles/production-excellence/references/gates.md create mode 100644 bundles/production-excellence/references/handoff-record.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 0995db5..660cb14 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -761,6 +761,15 @@ "strict": false, "description": "CPO methodology — product vision and strategy (North Star, product principles), competitive analysis and positioning, roadmap prioritization (RICE, Kano, OST), product-market fit frameworks (Sean Ellis test, retention curves), market sizing (TAM/SAM/SOM), platform strategy, product lifecycle management." }, + { + "name": "production-excellence", + "source": "./", + "skills": [ + "./production-excellence" + ], + "strict": false, + "description": "Route cross-domain production evidence (readiness, migration, recovery, capacity/cost, incident-learning) into a launch or operational decision — go, no-go, defer, exception, or escalation — with an accountable owner and a post-launch learning path. Compose production specialists without copying their runbooks. Do not use for incident command, release-pipeline mechanics, platform architecture, threat modeling, data-pipeline design, or any task owned end-to-end by a single specialist skill; do not use as a generic checklist detached from service ownership, risk, evidence, and verification." + }, { "name": "production-readiness", "source": "./", diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index c109330..d712c61 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -30,6 +30,7 @@ "./brand-designer", "./bundles/neckbeard", "./bundles/product-lifecycle", + "./bundles/production-excellence", "./bundles/research-and-vault", "./bundles/tailscale", "./bundles/workflow-architect", diff --git a/README.md b/README.md index 5a0868b..17e9283 100644 --- a/README.md +++ b/README.md @@ -356,6 +356,9 @@ Build and maintain outcome-based product roadmaps and portfolio views that seque CPO methodology — product vision and strategy (North Star, product principles), competitive analysis and positioning, roadmap prioritization (RICE, Kano, OST), product-market fit frameworks (Sean Ellis test, retention curves), market sizing (TAM/SAM/SOM), platform strategy, product lifecycle management. +### [production-excellence](bundles/production-excellence/SKILL.md) +Cross-domain production gate model — assembles readiness, migration, recovery, capacity/cost, and incident-learning evidence into a launch or operational decision (go/no-go/defer/exception/escalation) with an accountable owner and a post-launch learning path. Composes 12 specialist skills (production-readiness, migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, incident-learning, SRE, release, platform, security, data, QA, verification) without copying their runbooks. Ships 4 references (discovery brief, evidence packet, gate model, handoff record) and 5 integrated evals covering normal release, blocked launch, data migration, dependency outage, and cost/SLO conflict. + ### [production-readiness](production-readiness/SKILL.md) Assemble cross-domain production evidence into a risk-scaled launch decision. Defines three risk classes (Low/Standard/High) with proportional evidence requirements, an 11-category evidence checklist with named source or explicit gap for every category, and four launch-decision outcomes (Go/No-go/Defer/Exception) with accountable owners. Routes detailed technical checks to release-engineering, SRE, security, data, QA, platform, and implementation-planning. Ships 2 references (discovery brief, readiness record template) and 5 evals. diff --git a/bundles/production-excellence/AGENTS.md b/bundles/production-excellence/AGENTS.md new file mode 100644 index 0000000..fe5d98b --- /dev/null +++ b/bundles/production-excellence/AGENTS.md @@ -0,0 +1,28 @@ +# AGENTS.md — Production Excellence Bundle + +This bundle is a thin composition layer that assembles cross-domain production +evidence into a launch or operational decision. It is the discoverable entry +point; all routed skills are top-level catalog skills, not nested sub-skills. + +## Loading behavior + +- The umbrella `SKILL.md` is the single discoverable entry point. Harnesses that + respect Agent Skills progressive disclosure will discover this bundle through + its frontmatter (`name: production-excellence`). +- This bundle does not contain nested skills under a `skills/` directory. All + specialist skills are referenced via relative markdown links + (`../..//SKILL.md`) and are resolved by the harness from the catalog. +- When a production concern maps to a single specialist (e.g., a migration plan + is needed), load that specialist directly. Use this bundle when cross-domain + assembly and a gate decision are required. +- The bundle's reference files (`references/`) are loaded on demand per the + file map in `SKILL.md`. Do not load all references at activation time. + +## Harness notes + +- Compatible harnesses are guaranteed to see this bundle's `SKILL.md`. Nested + sub-skill auto-loading is not applicable (no nested skills exist). +- The bundle's routing table in `SKILL.md` uses relative links from the bundle + root (`bundles/production-excellence/`) to top-level skill directories + (`../..//SKILL.md`). Harnesses must resolve these relative to the + repository root. diff --git a/bundles/production-excellence/README.md b/bundles/production-excellence/README.md new file mode 100644 index 0000000..0456a49 --- /dev/null +++ b/bundles/production-excellence/README.md @@ -0,0 +1,48 @@ +# Production Excellence + +Assemble cross-domain production evidence into a defensible launch or operational decision — go, no-go, defer, exception, or escalation — with an accountable owner and a post-launch learning path. + +## Why Install This Skill + +When a service or change is heading to production, evidence is scattered across multiple domains: a readiness review in one place, a migration plan in another, recovery-exercise results somewhere else, a capacity model in a spreadsheet, and incident history in yet another tool. Without a single acceptance layer, teams either launch with invisible gaps or drown in coordination overhead. Production Excellence gives your agent that layer — a thin, structured gate model that reads evidence from every specialist domain and produces one of five clear, defensible outcomes with an accountable owner attached. + +After installing, your agent can run a production gate review for any change — from a low-risk docs update to a high-risk customer-facing launch with migration, recovery, and cost/SLO tradeoffs. The bundle composes the specialist catalog (production-readiness, migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, incident-learning, plus SRE, release, platform, security, data, and QA) without copying a single runbook. Post-launch, it routes outcomes into incident-learning and product-lifecycle-learning so production evidence flows back into decisions instead of being forgotten. + +## What You Get + +| Path | What it provides | +|---|---| +| `SKILL.md` | Thin umbrella entry point: readiness routing table for 5 production-domain routes and 7 supporting specialists, cross-domain entry evidence requirements, gate/exception model (go/no-go/defer/exception/escalation), operational handoff, and post-launch learning paths | +| `AGENTS.md` | Agent-specific loading notes: nested-skill behavior, harness compatibility, and progressive-disclosure guidance | +| `README.md` | This human-facing overview | +| `references/discovery-brief.md` | Bounded discovery brief comparing the bundle against 13 existing production and release skills (SRE, release, platform, security, data, QA, plus the 5 milestone production skills and verification/lifecycle-learning) | +| `references/evidence-packet.md` | Production evidence packet specification: entry-evidence requirements for readiness, migration, recovery, capacity/cost, and incident-learning domains — usable for both new services and changes to existing systems | +| `references/gates.md` | Full gate and exception model: go, no-go, defer, exception, and escalation outcomes, each with conditions, evidence requirements, risk-class applicability, and post-gate handoff rules | +| `references/handoff-record.md` | Operational handoff record template: service identification, gate outcome, evidence summary, gap register, post-launch learning paths (incident-learning and product-lifecycle-learning), and sign-off fields | +| `evals/evals.json` | Five integrated evaluation cases covering normal release, untested rollback, data migration, dependency outage, and cost/SLO conflict | + +## Quick Start + +1. Identify the service or change and its risk class (Low / Standard / High per production-readiness). +2. Gather entry evidence from each applicable domain using the evidence packet (`references/evidence-packet.md`). Every domain needs a named source or an explicit gap with an owner and due date. +3. Run the gate model (`references/gates.md`): evaluate the evidence against the five outcomes. Record the outcome with the accountable owner. +4. Populate the operational handoff record (`references/handoff-record.md`) — even for non-Go outcomes. +5. Route post-launch observations to incident-learning and product-lifecycle-learning per the handoff record's learning path. + +## Triggers + +- "Is this ready for production?" +- "Run a production gate review" +- "Assemble the production evidence packet" +- "We need a go/no-go decision for this launch" +- "Coordinate the production readiness review across teams" +- "What evidence is missing before we can launch?" +- "We have a migration, a recovery exercise, and a capacity model — are we clear to go?" +- "Route this launch outcome into our incident-learning process" +- A cross-team launch needs a single acceptance contract before proceeding +- A cost/SLO conflict needs a structured decision with accountable owners + +## Requirements + +- No runtime dependencies, API keys, or external services. +- The bundle routes to 12 specialist skills for detailed domain work; those skills must be present in the catalog for full routing capability (production-readiness, migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, incident-learning, site-reliability-engineering, release-engineering, platform-engineering, secure-software-engineering, data-engineering, qa-methodology, verification-methodology — all currently exist in the repository). diff --git a/bundles/production-excellence/SKILL.md b/bundles/production-excellence/SKILL.md new file mode 100644 index 0000000..a494b13 --- /dev/null +++ b/bundles/production-excellence/SKILL.md @@ -0,0 +1,178 @@ +--- +name: production-excellence +description: >- + Route cross-domain production evidence (readiness, migration, recovery, + capacity/cost, incident-learning) into a launch or operational decision — + go, no-go, defer, exception, or escalation — with an accountable owner + and a post-launch learning path. Compose production specialists without + copying their runbooks. Do not use for incident command, release-pipeline + mechanics, platform architecture, threat modeling, data-pipeline design, + or any task owned end-to-end by a single specialist skill; do not use + as a generic checklist detached from service ownership, risk, evidence, + and verification. +license: MIT +compatibility: Platform-agnostic methodology. No runtime dependencies, API keys, or external services required. +metadata: + tags: production-excellence, launch-decision, gate-model, evidence-packet, + operational-handoff, readiness-review, cross-domain, production-acceptance, + go-no-go, exception-escalation, post-launch-learning +--- + +# Production Excellence + +A thin composition bundle that assembles cross-domain production evidence into a +defensible launch or operational decision. It owns the **acceptance and handoff +layer** — the gate model that reads evidence from specialist skills and produces +go / no-go / defer / exception / escalation outcomes with accountable owners. +It does not own any specialist's runbook. + +## When to load this + +Load when: + +- A service or change is approaching a launch decision and evidence from multiple + production domains must be assembled. +- You need a structured gate model (go/no-go/defer/exception/escalation) with + conditions, evidence, and accountable owners. +- Cross-domain evidence (readiness, migration, recovery, capacity/cost, incident + history) must be combined into one operational handoff record. +- A launch or change needs a post-launch learning path routed to incident-learning + and product-lifecycle-learning. +- You are coordinating a production change across SRE, release, platform, security, + data, and QA specialists and need a single acceptance contract. + +## When not to use + +Do **not** load this bundle for: + +- **Incident command or SLO operations** — those are owned by + [site-reliability-engineering](../../site-reliability-engineering/SKILL.md). +- **Release-pipeline mechanics, versioning, or deployment strategies** — those are + owned by [release-engineering](../../release-engineering/SKILL.md). +- **Platform architecture or internal-developer-platform design** — those are + owned by [platform-engineering](../../platform-engineering/SKILL.md). +- **Threat modeling, security review procedure, or vulnerability assessment** — + those are owned by + [secure-software-engineering](../../secure-software-engineering/SKILL.md). +- **Data-pipeline design, ETL, or storage architecture** — those are owned by + [data-engineering](../../data-engineering/SKILL.md). +- **Test-strategy design, regression-suite management, or test-automation + framework design** — those are owned by + [qa-methodology](../../qa-methodology/SKILL.md). +- **A generic checklist detached from service ownership, risk, evidence, and + verification** — every gate in this bundle requires a named service owner, + assessed risk, verified evidence, and a declaration of the verification + boundary. A bare checklist is never a valid outcome. + +This bundle composes specialists. It never replaces them and never re-derives +their methods. If the task is wholly within one specialist's domain, load that +specialist directly. + +## Readiness routing table + +The bundle routes each production concern to the specialist that owns it. The +bundle itself owns only the acceptance and handoff layer — the cross-domain +assembly and the gate decision. + +### Primary production-domain routes + +| Domain | Specialist skill | What the specialist owns | What the bundle adds | +|---|---|---|---| +| **Production readiness** | [production-readiness](../../production-readiness/SKILL.md) | Risk-scaled evidence packet (11 categories), go/no-go/defer/exception launch decisions, accountable owners | Cross-domain assembly with migration, recovery, capacity/cost, and incident evidence; gate integration | +| **Migration** | [migration-engineering](../../migration-engineering/SKILL.md) | Expand/contract, compatibility windows, dual-running, backfills, reconciliation, cutover, recovery paths | Migration evidence as input to the gate model; handoff of migration verification to the operational record | +| **Resilience and recovery** | [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) | Failure modes, degradation choices, RTO/RPO, restore testing, DR, game days, failover, data integrity | Recovery evidence as a gate condition; exercise results feed the handoff record | +| **Capacity and cost** | [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) | Demand/capacity/scaling/utilization models, unit-cost connection to SLO decisions, cost-constrained scenarios | Capacity/cost evidence as a gate condition; SLO/cost tradeoff decisions feed the gate model | +| **Incident learning** | [incident-learning](../../incident-learning/SKILL.md) | Observed facts, causal hypotheses, contributing conditions, follow-up work mapping, verified closure | Pre-existing incident evidence as a gate condition; post-launch incidents routed back to incident-learning | + +### Supporting specialist routes + +| Domain | Specialist skill | When routed | +|---|---|---| +| **Reliability / SLOs** | [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | SLO/error-budget status required for gate entry; incident response for post-launch issues | +| **Release mechanics** | [release-engineering](../../release-engineering/SKILL.md) | Release plan, rollout/rollback strategy required for gate entry | +| **Platform** | [platform-engineering](../../platform-engineering/SKILL.md) | Service-catalog entry, paved-road status for new services | +| **Security** | [secure-software-engineering](../../secure-software-engineering/SKILL.md) | Security review evidence for trust-boundary changes | +| **Data** | [data-engineering](../../data-engineering/SKILL.md) | Data-quality and pipeline evidence for data-path changes | +| **QA** | [qa-methodology](../../qa-methodology/SKILL.md) | Verification evidence for all launches | +| **Verification** | [verification-methodology](../../verification-methodology/SKILL.md) | Boundary labeling and gap declaration for evidence assessment | + +## Cross-domain entry evidence + +Before the gate model runs, entry evidence must exist from every applicable +domain. The bundle does not gather this evidence — it requires it. The complete +evidence packet specification is in +[references/evidence-packet.md](references/evidence-packet.md). + +Summary: + +- Every evidence domain (readiness, migration, recovery, capacity/cost, + incident-learning) has a named source or an explicit gap with an owner and + due date. +- The packet is usable for **both new services and changes to existing systems** + — domains irrelevant to the change are explicitly marked "not applicable" + with a reason. +- Missing evidence is never silently omitted. Every gap is recorded. + +## Gate and exception model + +The gate model produces exactly one of five outcomes for every production change. +Full definitions, conditions, and evidence requirements are in +[references/gates.md](references/gates.md). + +| Outcome | Meaning | Key condition | +|---|---|---| +| **Go** | Authorized to proceed to production | All required evidence domains are sourced; no blocking gaps | +| **No-go** | Blocked; must not proceed | A required domain has a blocking gap, or an irreversible step has no verified recovery path | +| **Defer** | Postponed with explicit conditions | A non-blocking gap or dependency has a committed resolution date; re-evaluation is scheduled | +| **Exception** | Proceeds under an explicit waiver | A human authority (not the agent, not the service owner alone) approves a time-bounded, risk-bounded exception | +| **Escalation** | Decision escalated to a higher body | Irreconcilable gate conflict, trust-boundary security gap, cross-team authority gap, or regulatory boundary | + +Every outcome is anchored to **service ownership**, **risk**, **evidence**, and +**verification**. No gate passes on a bare checklist. Each outcome names the +accountable owner and records the evidence that supports it. + +## Operational handoff and post-launch learning + +After a gate outcome is reached, the operational handoff record +([references/handoff-record.md](references/handoff-record.md)) is populated. + +### Post-launch learning paths + +Launch outcomes and post-launch observations feed two learning routes: + +1. **Incident learning** — post-launch incidents (SLO degradations, unexpected + failures, capacity breaches) are routed to + [incident-learning](../../incident-learning/SKILL.md). The handoff record + provides the launch context; the incident-learning skill's verified-closure + requirement ensures follow-up items are tracked to completion. + +2. **Lifecycle learning** — expected outcomes recorded in the handoff (SLO + targets, capacity assumptions, cost projections) are routed to + [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) + for expected-vs-observed comparison at the handoff's review cadence. The + lifecycle-learning skill's continue/improve/harvest/pivot/pause/retire + decisions are informed by the gap between predicted and observed production + behavior. + +The handoff record is populated for every outcome — not only Go. No-go, Defer, +Exception, and Escalation each produce a handoff record with the blocking +condition, the follow-up path, and the accountable owner. + +## Loading and nested-skill behavior + +This bundle is the discoverable entry point. It does not contain nested +sub-skills under a `skills/` directory. All routed skills are top-level catalog +skills referenced via relative markdown links. Harnesses that support progressive +disclosure will discover this bundle through its `SKILL.md` frontmatter and load +the referenced specialists on trigger. + +See [AGENTS.md](AGENTS.md) for agent-specific loading notes. + +## File map + +| Path | Loaded when | +|---|---| +| [references/discovery-brief.md](references/discovery-brief.md) | Understanding the bundle's boundary against existing production and release skills | +| [references/evidence-packet.md](references/evidence-packet.md) | Assembling cross-domain evidence for a production decision | +| [references/gates.md](references/gates.md) | Running the gate model — go/no-go/defer/exception/escalation | +| [references/handoff-record.md](references/handoff-record.md) | Producing the operational handoff record and post-launch learning path | diff --git a/bundles/production-excellence/evals/evals.json b/bundles/production-excellence/evals/evals.json new file mode 100644 index 0000000..27f762d --- /dev/null +++ b/bundles/production-excellence/evals/evals.json @@ -0,0 +1,74 @@ +{ + "schema_version": 1, + "skill_name": "production-excellence", + "evals": [ + { + "id": "normal-release-safe-launch", + "prompt": "We are launching a new user-facing API service to production. The readiness review is complete with all 11 evidence categories sourced: ownership is assigned to the API platform team, SLOs are defined (99.9% availability, p99 latency < 200ms), security review passed, rollback plan uses blue-green deployment, capacity model shows 3x headroom at launch, restore test passed yesterday, and QA verification confirms all acceptance criteria pass at the integration boundary. The risk class is Standard. Run the production-excellence gate model and produce the operational handoff record.", + "expected_output": "The gate model produces a Go outcome. The operational handoff record includes the service name (API service), risk class (Standard), outcome (Go), the accountable service owner (API platform team lead), evidence summary for all domains (readiness, migration: none, resilience: restore test dated yesterday, capacity/cost: 3x headroom, incident learning: no prior incidents, security: passed, release: blue-green plan, QA: integration-boundary verification), no gaps, and post-launch learning paths routed to incident-learning and product-lifecycle-learning with a review cadence.", + "assertions": [ + "gate outcome is Go", + "all evidence domains are sourced with named references", + "no gaps exist in the evidence packet", + "operational handoff record names the service owner", + "post-launch learning paths reference incident-learning and product-lifecycle-learning", + "risk class is Standard" + ] + }, + { + "id": "blocked-launch-untested-rollback", + "prompt": "We are launching a database schema migration for our payment service — a High-risk change because it crosses a trust boundary and is irreversible without a verified rollback. The migration plan expands the schema with a new column, backfills data, and then drops the old column. The readiness review is otherwise complete (ownership, SLOs, security, QA all pass). However, the rollback procedure has never been tested — the team wrote a rollback script but has not run it against a production-like snapshot. The migration-engineering specialist confirms the step is irreversible without the tested rollback. Run the production-excellence gate model.", + "expected_output": "The gate model produces a No-go outcome. The blocking reason is: the rollback procedure has never been tested and the migration step is irreversible without it. The evidence packet records the gap in the migration domain (no tested rollback). The handoff record records the No-go with the gap owner (the migration team lead), the gap description (untested rollback for irreversible schema migration), and the condition for re-evaluation (successful rollback rehearsal against a production-like snapshot). The risk class (High) prohibits exceptions — no exception is offered without escalation.", + "assertions": [ + "gate outcome is No-go or blocked", + "blocking reason explicitly references untested rollback", + "evidence packet records the migration-domain gap", + "gap owner is named", + "no exception is granted for a High-risk irreversible migration without tested rollback", + "the handoff record is populated even for the No-go outcome", + "risk class High prevents exception without escalation" + ] + }, + { + "id": "data-migration-routes-to-migration-engineering", + "prompt": "We are migrating 200M customer records from an on-premises PostgreSQL database to a cloud-hosted database. The migration-engineering specialist has produced a plan: dual-write for 30 days, backfill the historical data with checksum verification, run reconciliation queries daily, and cut over with a 5-minute maintenance window. A rollback path exists: keep the on-premises database in read-only mode for 14 days post-cutover. The readiness review is complete, capacity model shows the cloud instance can handle 2x peak load, and QA has verified reconciliation correctness. The risk class is High. Run the production-excellence gate model and produce the operational handoff record.", + "expected_output": "The gate model produces a Go outcome because: the migration plan from migration-engineering includes dual-write, backfill, reconciliation, cutover, and a rollback path (14-day read-only window). The evidence packet references the migration-engineering artifacts explicitly. The handoff record captures the migration type (data migration), recovery path (rollback via 14-day read-only window), verification method (daily reconciliation queries + checksum), and cutover window (5 minutes). Post-launch learning routes to incident-learning for any reconciliation failures and to product-lifecycle-learning for expected-vs-observed data integrity comparison.", + "assertions": [ + "gate outcome is Go", + "migration domain evidence references migration-engineering artifacts", + "recovery path is explicit: 14-day read-only rollback window", + "cutover window is specified", + "reconciliation and checksum verification are cited", + "handoff record routes post-launch to incident-learning and product-lifecycle-learning", + "risk class is High but all evidence domains are sourced" + ] + }, + { + "id": "dependency-outage-routes-to-resilience", + "prompt": "We are launching a mobile notification service that depends on an upstream push-notification provider. The resilience-and-recovery assessment reveals that the upstream provider had a 45-minute outage last month affecting 30% of notifications, and the provider's SLA is 99.5% (below our service's 99.9% SLO target). The resilience specialist recommends a circuit-breaker with a fallback queue and a degraded-mode UX that shows 'delayed delivery' instead of silent failure. However, the circuit-breaker has not been exercised in a game day — the team has the code but has not run a dependency-failure simulation. All other domains are sourced. The risk class is Standard. Run the production-excellence gate model.", + "expected_output": "The gate model produces a Defer outcome (or No-go, depending on whether the untested circuit-breaker is considered a blocking gap for Standard risk). The resilience domain has a gap: the circuit-breaker has not been exercised. The evidence packet records this gap with the resilience owner and a due date for the game-day exercise. If Defer: the condition for re-evaluation is a successful dependency-failure simulation. If No-go: the blocking reason is that the upstream dependency's SLA (99.5%) conflicts with the service's SLO (99.9%) and the mitigation (circuit-breaker) has not been tested. In either case, the handoff record records the resilience gap explicitly and routes post-launch dependency monitoring to incident-learning.", + "assertions": [ + "gate outcome is Defer or No-go", + "resilience domain gap is explicitly recorded: untested circuit-breaker or dependency-failure simulation", + "upstream provider SLA vs service SLO conflict is cited", + "degraded-mode UX is referenced as part of the resilience plan", + "handoff record captures the gap with owner and resolution condition", + "post-launch learning references incident-learning for dependency monitoring" + ] + }, + { + "id": "cost-slo-conflict", + "prompt": "We are scaling our data-processing pipeline to handle 10x daily volume. The capacity-and-cost-engineering specialist has produced a model: at current unit cost, scaling to 10x would increase monthly infrastructure spend from $50K to $420K. The budget constraint is $300K/month. Two options exist: (A) scale to 8x within budget but relax the SLO from p99 < 500ms to p99 < 2s during peak hours, or (B) scale to 10x with a budget increase to $420K requiring VP approval. The SRE team confirms the SLO relaxation (option A) would still meet user expectations. The readiness review is otherwise complete, and the risk class is Standard. Run the production-excellence gate model to resolve this cost/SLO conflict.", + "expected_output": "The gate model identifies a cost/SLO conflict and produces either: (1) Go with option A (scale to 8x, relaxed SLO) if the SRE and capacity evidence supports it, recording the tradeoff decision with the accountable owner; or (2) Exception if option B is chosen and VP approval is granted for the budget increase; or (3) Escalation if the choice between A and B cannot be resolved at the service-owner level. In any outcome, the decision is explicitly anchored to: service ownership (who owns the cost/SLO tradeoff), risk (the risk of relaxing the SLO vs the risk of budget overrun), evidence (the capacity model with explicit assumptions, the SRE SLO assessment), and verification (how the scaled system's latency will be verified post-launch). The handoff record captures the capacity/cost domain evidence, the SLO decision, and routes post-launch cost and latency monitoring to product-lifecycle-learning for expected-vs-observed comparison.", + "assertions": [ + "cost/SLO conflict is explicitly identified", + "capacity-and-cost-engineering model is cited with unit cost and budget constraint", + "at least two options are compared with tradeoffs", + "the decision is anchored to service ownership, risk, evidence, and verification", + "handoff record captures the capacity/cost evidence and the SLO decision", + "post-launch learning routes to product-lifecycle-learning for expected-vs-observed comparison", + "outcome is Go, Exception, or Escalation — not No-go without exploring the tradeoff" + ] + } + ] +} diff --git a/bundles/production-excellence/references/discovery-brief.md b/bundles/production-excellence/references/discovery-brief.md new file mode 100644 index 0000000..9570413 --- /dev/null +++ b/bundles/production-excellence/references/discovery-brief.md @@ -0,0 +1,84 @@ +# Production-Excellence Bundle — Bounded Discovery Brief + +## Purpose + +This brief records the pre-implementation survey of existing production and release +skills in the `magnus919/agent-skills` repository. It establishes what the +production-excellence bundle owns, what it routes to, and what it must not duplicate. +It satisfies acceptance criterion "A bounded discovery brief compares the bundle with +existing production and release skills" (issue #195). + +## Surveyed skills + +Each skill below was inspected before the bundle was authored. For every skill the +conclusion is the same: it owns a deep specialist domain and does **not** own the +cross-domain acceptance and handoff layer that assembles evidence into a launch or +operational decision. + +| Skill | What it owns | What the bundle does NOT duplicate | +|---|---|---| +| [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | SLO definition, error budgets, incident response, operational recovery, capacity planning, toil reduction | Incident command, on-call procedures, SLO math, error-budget policy, toil automation | +| [release-engineering](../../release-engineering/SKILL.md) | Release pipelines, versioning, promotion, rollout, rollback mechanics, deployment strategies | CI/CD pipeline design, artifact promotion, canary/blue-green mechanics, release-please configuration | +| [platform-engineering](../../platform-engineering/SKILL.md) | Internal developer platforms, paved roads, service catalogs, infrastructure APIs, Golden Paths | Platform architecture, IDP design, service catalog implementation, infrastructure-as-code | +| [secure-software-engineering](../../secure-software-engineering/SKILL.md) | Threat modeling, secure design, security review, vulnerability assessment, trust boundaries | STRIDE/OWASP methodology, security-review procedure, threat-model facilitation | +| [data-engineering](../../data-engineering/SKILL.md) | Database operations, ETL/ELT pipelines, data quality, schema migration, storage infrastructure | Pipeline design, dbt patterns, SQL analytical patterns, storage architecture | +| [qa-methodology](../../qa-methodology/SKILL.md) | Test strategy, regression coverage, CI quality gates, verification planning, test-level taxonomy | Test-case design, regression-suite management, test-automation framework design | +| [verification-methodology](../../verification-methodology/SKILL.md) | Verification verdicts, boundary labeling, evidence standards, gap declaration | Verification-protocol design, evidence-boundary classification | +| [production-readiness](../../production-readiness/SKILL.md) | Risk-scaled evidence packet, go/no-go/defer/exception launch decisions with accountable owners | The 11-category evidence checklist, risk-class assignment, accountable-owner identification | +| [migration-engineering](../../migration-engineering/SKILL.md) | Safe cross-system migrations — expand/contract, compatibility windows, dual-running, backfills, reconciliation, cutover, deprecation, recovery paths | Migration-strategy design, compatibility-window management, cutover sequencing | +| [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) | Failure modes, degradation choices, RTO/RPO, restore testing, DR, game days, failover, data integrity, recovery communication | Game-day design, DR-runbook authoring, failover-procedure definition | +| [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) | Demand/capacity/scaling/utilization models, unit-cost connection to SLO decisions, cost-constrained scenario analysis | Capacity-model construction, cost-attribution accounting, quota/rate-limit engineering | +| [incident-learning](../../incident-learning/SKILL.md) | Observed facts, causal hypotheses, contributing conditions, follow-up work mapping, verified closure | Incident-analysis facilitation, causal-hypothesis testing, follow-up-ticket management | +| [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) | Expected-vs-observed outcome comparison, assumption/decision updates, continue/improve/harvest/pivot/pause/retire choices | Lifecycle-review facilitation, outcome-comparison analysis | + +## Boundary statement + +The production-excellence bundle owns the **acceptance and handoff layer**: + +- Assembling cross-domain evidence (readiness, migration, recovery, capacity/cost, + incident-learning) into a single production decision record. +- Running the gate model: go, no-go, defer, exception, escalation — each with + conditions, evidence, and accountable owners. +- Producing the operational handoff record for the team that will own the service + in production. +- Routing post-launch outcomes into incident-learning and product-lifecycle-learning + so that production evidence flows back into decisions. + +It does **not** own any specialist's runbook. It does not own incident command +(SRE), release pipeline mechanics (release-engineering), platform architecture +(platform-engineering), threat modeling (secure-software-engineering), data +pipeline design (data-engineering), or test-strategy design (qa-methodology). It +composes them — it never re-derives their methods. + +## What existing bundles do NOT cover + +The four pre-existing bundles were also surveyed: + +- **neckbeard** owns the issue-to-PR delivery journey (9-phase SDLC). It does not + own the production acceptance and handoff that happens after delivery. +- **workflow-architect** owns workflow discovery and skill-bundle generation. It + does not own production decision-making. +- **tailscale** owns the Headscale/Tailscale VPN ecosystem. It is domain-specific + networking, not production governance. +- **research-and-vault** owns the research-to-notes sequence. It is a knowledge + workflow, not a production workflow. + +None of them fill the gap this bundle fills: the cross-domain evidence assembly and +launch/operational decision layer that sits between delivery (neckbeard's phase 9) +and ongoing production operations. + +## Decision: bundle owns the acceptance layer, not the specialists' runbooks + +The production-excellence bundle is the thin composition layer that: + +1. Reads evidence from the five production-domain specialists (production-readiness, + migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, + incident-learning). +2. Reads applicable evidence from the existing production specialists (SRE, release, + platform, security, data, QA). +3. Assembles that evidence into a gate decision (go/no-go/defer/exception/escalation). +4. Produces an operational handoff record. +5. Routes post-launch learning back into incident-learning and product-lifecycle-learning. + +It is deliberately thin. It adds no new methodology beyond the acceptance and handoff +contract. Every specialist skill remains the authoritative source for its domain. diff --git a/bundles/production-excellence/references/evidence-packet.md b/bundles/production-excellence/references/evidence-packet.md new file mode 100644 index 0000000..bcc95a4 --- /dev/null +++ b/bundles/production-excellence/references/evidence-packet.md @@ -0,0 +1,110 @@ +# Production Evidence Packet + +The production evidence packet assembles cross-domain evidence into a single +decision-ready record. It is the shared input to the gate model +([gates.md](gates.md)) and feeds the operational handoff record +([handoff-record.md](handoff-record.md)). + +## Applicability + +This packet is used for **both**: + +- **New services** — a service that has never been in production. Every evidence + domain is assessed; domains that are not applicable are explicitly marked as such + with a reason (not silently omitted). +- **Changes to existing systems** — a feature, migration, or configuration change + to a service already in production. Only the domains affected by the change are + assessed; unaffected domains are marked "no change" with a reference to the + existing evidence. + +## Evidence domains + +### 1. Readiness + +| Field | Requirement | +|---|---| +| **Risk class** | Low / Standard / High per [production-readiness](../../production-readiness/SKILL.md) | +| **Evidence source** | Readiness record or explicit gap statement | +| **Owner** | Named accountable owner for the readiness assessment | +| **Decision** | Go / No-go / Defer / Exception from the readiness review | + +For a **change to an existing system**, cite the delta: what changed since the +last readiness review. + +### 2. Migration + +| Field | Requirement | +|---|---| +| **Migration type** | Schema / data / API / infrastructure / service (or "none") | +| **Evidence source** | Migration plan per [migration-engineering](../../migration-engineering/SKILL.md) | +| **Recovery path** | Rollback / roll-forward / restore / irreversible (explicit) | +| **Verification** | How migration correctness was verified (reconciliation, checksum, smoke) | + +For a **new service**, migrations may not apply; state "no migration — new service." + +### 3. Resilience and recovery + +| Field | Requirement | +|---|---| +| **Failure modes assessed** | Dependency outage, data corruption, zone/region loss, overload | +| **Evidence source** | Recovery exercise results per [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) | +| **RTO/RPO** | Stated targets (context-dependent, not universal) | +| **Degradation behavior** | What degrades and how (graceful degradation, not binary up/down) | +| **Recovery verified** | Date of last restore test, game-day, or failover exercise | + +For a **change to an existing system**, state whether the change introduces new +failure modes or alters existing ones. + +### 4. Capacity and cost + +| Field | Requirement | +|---|---| +| **Demand model** | Expected load, peak, growth rate | +| **Capacity model** | Scaling limits, quotas, rate limits | +| **Cost model** | Unit cost, budget constraint, cost attribution | +| **SLO interaction** | Any cost/SLO tradeoff decisions per [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) | +| **Assumptions** | Explicit: all demand/capacity/cost assumptions stated | + +### 5. Incident learning + +| Field | Requirement | +|---|---| +| **Pre-existing incidents** | Any incidents from this service or its dependencies relevant to this change | +| **Evidence source** | Incident records per [incident-learning](../../incident-learning/SKILL.md) | +| **Follow-up status** | Verified closure of prior incident follow-up items relevant to this change | +| **New risk register** | Risks identified during readiness that should feed incident-learning post-launch | + +For a **new service**, pre-existing incidents may not apply; state "no prior +incidents — new service." The new-risk register is always populated. + +## Cross-domain entry evidence + +Before a production decision can be made, the following must exist as **entry +evidence** (the bundle does not gather it; it requires it): + +| Evidence | Owned by | Required for | +|---|---|---| +| Readiness record with risk class and accountable owner | [production-readiness](../../production-readiness/SKILL.md) | All launches | +| Migration plan (when a migration is in scope) | [migration-engineering](../../migration-engineering/SKILL.md) | Migrations | +| Recovery exercise evidence (game-day, restore test) | [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) | High-risk launches | +| Capacity and cost model with explicit assumptions | [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) | SLO-bearing services | +| Incident-learning record for relevant prior incidents | [incident-learning](../../incident-learning/SKILL.md) | Changes to services with incident history | +| Security review evidence | [secure-software-engineering](../../secure-software-engineering/SKILL.md) | Trust-boundary changes | +| Release plan | [release-engineering](../../release-engineering/SKILL.md) | All launches | +| SLO / error-budget status | [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | SLO-bearing services | +| Platform/service-catalog entry | [platform-engineering](../../platform-engineering/SKILL.md) | New services | +| Data quality / pipeline evidence | [data-engineering](../../data-engineering/SKILL.md) | Data-path changes | +| QA verification evidence | [qa-methodology](../../qa-methodology/SKILL.md) | All launches | + +## Missing-evidence handling + +Any evidence domain without a named source is recorded as an **explicit gap**: + +- The gap is named (e.g., "no restore test performed"). +- An owner is assigned. +- A due date or condition is stated (e.g., "before next launch," "within 7 days post-launch"). +- The gap feeds the gate model: missing evidence in a required domain may produce + a no-go, defer, or exception outcome, depending on risk class and domain. + +A gap is never silently omitted. Every domain in the packet is either sourced or +gapped. diff --git a/bundles/production-excellence/references/gates.md b/bundles/production-excellence/references/gates.md new file mode 100644 index 0000000..3643b06 --- /dev/null +++ b/bundles/production-excellence/references/gates.md @@ -0,0 +1,164 @@ +# Gate and Exception Model + +The production-excellence gate model defines five discrete outcomes for every +production change. Each outcome requires specific conditions and evidence; +no outcome is reachable on a bare checklist. + +## Guiding principles + +- **Service ownership**: every gate decision names the service owner accountable + for the outcome. +- **Risk**: the risk class (Low / Standard / High per + [production-readiness](../../production-readiness/SKILL.md)) determines which + evidence domains are required and which gates are applicable. +- **Evidence**: no gate passes without evidence from the production evidence + packet ([evidence-packet.md](evidence-packet.md)). A missing-evidence gap is + acceptable only when the risk class permits it and the gap is explicitly + recorded with an owner and due date. +- **Verification**: evidence must be verified at the declared boundary (component, + integration, end-to-end, or production per + [verification-methodology](../../verification-methodology/SKILL.md)). An + unverified claim does not satisfy an evidence requirement. + +## Outcomes + +### Go + +**Meaning**: the change is authorized to proceed to production. + +**Conditions**: + +- All evidence domains required for the risk class are sourced (not gapped). +- The readiness decision from [production-readiness](../../production-readiness/SKILL.md) + is "Go." +- Migration evidence (if applicable) confirms a verified recovery path. +- Resilience evidence (if required by risk class) includes a recent exercise result. +- Capacity and cost model (if required) shows the change is within budget and + capacity constraints, with explicit assumptions. +- Incident-learning review (if applicable) confirms no unclosed follow-up items + relevant to this change. +- Security review (if trust-boundary change) is complete. +- Release plan is documented and approved. +- QA verification evidence is present. + +**Evidence required**: the complete production evidence packet with all domains +sourced or explicitly marked not-applicable. + +**Accountable owner**: the service owner, who signs off on the Go decision. + +### No-go + +**Meaning**: the change is blocked and must not proceed. + +**Conditions** (any one is sufficient): + +- A required evidence domain has a blocking gap (e.g., no restore test for a + High-risk launch, no security review for a trust-boundary change). +- The readiness decision is "No-go." +- A migration has no verified recovery path and the step is irreversible. +- An incident-learning review reveals an unclosed follow-up item that would be + exacerbated by this change. +- A cost/SLO conflict cannot be resolved (the change would violate an SLO, and + no budget increase or SLO relaxation is authorized). +- A dependency outage assessment shows the change would create an unacceptable + blast radius. + +**Evidence required**: the gap or condition that triggered the No-go, recorded +with the specific domain, the missing evidence, and the accountable owner who +can resolve it. + +**Accountable owner**: the service owner records the No-go; the owner of the +blocking gap is named as the resolver. + +### Defer + +**Meaning**: the change is postponed to a later date with explicit conditions +for re-evaluation. + +**Conditions**: + +- The change is not blocked permanently (it is not a No-go), but: + - A required evidence domain has a non-blocking gap with a committed due date. + - A dependency (e.g., an upstream service's readiness, a platform capability) + is not yet available but has a committed delivery date. + - A cost/SLO conflict requires a budget or SLO decision that is in progress + but not yet authorized. + - The risk window (e.g., a holiday freeze, a peak-traffic period) makes the + current timing unsuitable. + +**Evidence required**: the deferral reason, the condition for re-evaluation, the +committed date or trigger event, and the owner responsible for meeting the +condition. + +**Accountable owner**: the service owner records the Defer; the owner of the +deferral condition is named with the committed resolution date. + +### Exception + +**Meaning**: the change proceeds despite a gap, under an explicit waiver with +named approval authority. + +**Conditions**: + +- A required evidence domain has a gap that would normally produce a No-go, but: + - An explicit human authority (not the service owner, not the agent) approves + the exception. + - The exception is time-bounded (an expiration date or post-launch condition). + - The exception is risk-bounded (what specifically is waived, and what is not). + - The exception is recorded with the approving authority's name and the date + of approval. +- The exception does not waive security review for trust-boundary changes + (a hard constraint — see Escalation). + +**Evidence required**: the exception record with the waived domain, the +approving authority, the approval date, the expiration or post-launch +condition, and the accountable service owner. + +**Accountable owner**: the approving authority (the human who granted the +exception). The service owner records the exception and tracks the post-launch +condition. + +### Escalation + +**Meaning**: the decision cannot be made within the bundle's authority and must +be escalated to a higher decision body. + +**Conditions** (any one is sufficient): + +- A security review for a trust-boundary change cannot be completed and no + exception is authorized (security is a hard constraint — never waived without + a security authority). +- Two or more gate outcomes are in irreconcilable conflict (e.g., the readiness + review says Go but the capacity model shows an SLO violation with no + authorized budget increase). +- The service owner and the readiness reviewer disagree on the outcome and + neither has the authority to resolve the disagreement. +- A cross-team dependency blocks the change and the dependency owner is not + accountable to the service owner (organizational escalation). +- The change crosses a regulatory or compliance boundary and the bundle lacks + the domain expertise to assess it. + +**Evidence required**: the escalation record with the specific conflict or gap, +the parties involved, the decision body being escalated to, and the accountable +owner who initiated the escalation. + +**Accountable owner**: the initiator of the escalation (service owner or +readiness reviewer). The escalation itself names the target decision body. + +## Gate applicability by risk class + +| Outcome | Low risk | Standard risk | High risk | +|---|---|---|---| +| **Go** | Lightweight: readiness + release + QA evidence sufficient | All applicable domains sourced | All domains sourced; no gaps permitted | +| **No-go** | Blocking gap in any required domain | Blocking gap; irreversible migration without recovery; unresolved incident | Any gap in any domain; no exceptions for High risk without escalation | +| **Defer** | Non-blocking gap with due date | Dependency or timing constraint | Only timing constraints (e.g., freeze window); no evidence gaps deferrable | +| **Exception** | Service owner may self-approve with recorded rationale | Explicit human authority required; time-bounded | Escalation required (High-risk exceptions are escalated, not granted locally) | +| **Escalation** | Security hard-constraint, cross-team authority gap, regulatory boundary | Same as Low, plus irreconcilable gate conflict | Same as Standard; any High-risk exception is escalated | + +## Post-gate: operational handoff + +After a gate outcome is reached, the operational handoff record +([handoff-record.md](handoff-record.md)) is populated. For Go and Exception +outcomes, the handoff includes the launch evidence and the post-launch learning +path. For No-go, Defer, and Escalation outcomes, the handoff records the +blocking condition and the follow-up path. diff --git a/bundles/production-excellence/references/handoff-record.md b/bundles/production-excellence/references/handoff-record.md new file mode 100644 index 0000000..28f1fd7 --- /dev/null +++ b/bundles/production-excellence/references/handoff-record.md @@ -0,0 +1,115 @@ +# Operational Handoff Record + +The operational handoff record is the durable artifact that transfers a production +change from the launch decision to the team that will own it in production. It is +the final output of the production-excellence gate model +([gates.md](gates.md)) and the production evidence packet +([evidence-packet.md](evidence-packet.md)). + +## Handoff fields + +### Service and change identification + +| Field | Description | +|---|---| +| **Service name** | The service or system being launched or changed | +| **Change identifier** | Issue, ticket, or change-request ID | +| **Change description** | One-paragraph summary of what changed and why | +| **Risk class** | Low / Standard / High | +| **Service owner** | Named individual accountable for the service in production | +| **Launch coordinator** | Named individual who ran the readiness review and gate model | + +### Gate outcome + +| Field | Description | +|---|---| +| **Outcome** | Go / No-go / Defer / Exception / Escalation | +| **Outcome date** | Date the gate decision was reached | +| **Outcome authority** | Who approved the outcome (service owner, exception authority, escalation body) | +| **Conditions** | Any conditions attached to the outcome (deferral triggers, exception expiration, post-launch requirements) | + +### Evidence summary + +| Field | Description | +|---|---| +| **Readiness** | Risk class, accountable owner, decision summary — reference to readiness record | +| **Migration** | Migration type, recovery path, verification — reference to migration plan (or "none") | +| **Resilience** | Failure modes assessed, RTO/RPO, last exercise date — reference to recovery evidence | +| **Capacity/cost** | Demand model summary, budget constraint, SLO interaction — reference to capacity model | +| **Incident learning** | Relevant prior incidents, follow-up status — reference to incident records | +| **Security** | Review status, trust-boundary assessment — reference to security review (or "not applicable") | +| **Release** | Release plan summary — reference to release plan | +| **Platform** | Service-catalog entry, paved-road status — reference to platform entry | +| **Data** | Data-path assessment — reference to data-quality evidence | +| **QA** | Verification summary, boundary exercised — reference to QA evidence | + +### Gap register (for any missing evidence) + +| Field | Description | +|---|---| +| **Domain** | Which evidence domain has a gap | +| **Gap description** | What evidence is missing | +| **Owner** | Who is accountable for closing the gap | +| **Due date** | When the gap must be closed | +| **Risk of non-closure** | What happens if the gap is not closed by the due date | + +### Post-launch learning path + +| Field | Description | +|---|---| +| **Incident-learning route** | Whether launch outcomes and any post-launch incidents should feed [incident-learning](../../incident-learning/SKILL.md) | +| **Lifecycle-learning route** | Whether launch outcomes should feed [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) for expected-vs-observed comparison | +| **Review cadence** | When the service owner should revisit the handoff record (e.g., 7 days post-launch, 30 days post-launch) | +| **Escalation path** | Who to contact if post-launch issues exceed the service owner's authority | + +### Sign-off + +| Field | Description | +|---|---| +| **Service owner signature** | Name and date | +| **Launch coordinator signature** | Name and date | +| **Exception authority signature** | Name and date (only for Exception outcomes) | +| **Escalation body acknowledgement** | Name and date (only for Escalation outcomes) | + +## Post-launch learning: routing launch outcomes + +After launch, the handoff record feeds two learning paths: + +### Incident-learning route + +Post-launch incidents (degraded SLOs, unexpected failures, dependency outages, +capacity breaches) are routed to [incident-learning](../../incident-learning/SKILL.md) +with a reference to this handoff record. The incident-learning skill's verified-closure +requirement ensures that follow-up items traced to launch decisions are tracked to +completion. + +For a **Go** outcome: incidents are unexpected and trigger the standard +incident-learning flow. + +For an **Exception** outcome: incidents related to the waived domain are +expected to be elevated; the exception's post-launch condition defines the +threshold for re-escalation. + +### Lifecycle-learning route + +The expected outcomes recorded in the handoff (SLO targets, capacity assumptions, +cost projections, migration-success criteria) are routed to +[product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) for +expected-vs-observed comparison at the review cadence. The lifecycle-learning +skill's continue/improve/harvest/pivot/pause/retire decisions are informed by +the gap between what the handoff predicted and what production observed. + +## Handoff for non-Go outcomes + +The handoff record is populated even when the outcome is not Go: + +- **No-go**: the handoff records the blocking gap and routes it to the gap owner. + The record is retained as evidence of the decision and its rationale. +- **Defer**: the handoff records the deferral condition and the re-evaluation + trigger. At the trigger date, the service owner re-opens the gate model with + updated evidence. +- **Exception**: the handoff records the waiver and its post-launch condition. + The exception authority is named; the condition is tracked. +- **Escalation**: the handoff records the escalation target and the specific + conflict. The escalation body's decision (when reached) is recorded in a + follow-up handoff. diff --git a/llms.txt b/llms.txt index e798fc2..212ec6d 100644 --- a/llms.txt +++ b/llms.txt @@ -86,6 +86,7 @@ - [product-operations-and-governance](product-operations-and-governance/SKILL.md): Define and run product governance — recurring decision rights, intake, portfolio cadences, evidence standards, and cross-functional operating contracts. Covers six review cadences (intake, portfolio, roadmap, experiment, launch, lifecycle) with named accountable owners, minimum evidence standards per decision type, and escalation paths. Supports lightweight and high-assurance operating modes with configurable governance patterns. Use when designing a product governance model, resolving contested decisions, establishing evidence standards, recording exceptions and escalations, or building cross-functional operating contracts. Do NOT use for executive governance (capital allocation, org structure — route to chief-of-staff-methodology or strategy-frameworks), for technical delivery gates (CI/CD, release approval — route to release-engineering or spec-driven-development), or to impose a universal org chart. - [product-roadmapping-and-portfolio](product-roadmapping-and-portfolio/SKILL.md): Build and maintain outcome-based product roadmaps and portfolio views that sequence strategic bets by evidence, not dates. Covers Now/Next/Later views, strategic-bet management, capacity allocation, dependency and confidence mapping, scenario planning, continue/pause/kill/revisit criteria, stakeholder narratives, and roadmap review cadences. Use when building or reviewing a product roadmap, managing a portfolio of bets, or communicating strategic sequencing to stakeholders. Do NOT use for tactical prioritization mechanics (RICE, MoSCoW, Kano, OST — route to product-methodology or product-strategy), for project scheduling or Gantt charts, or for delivery-flow management (route to kanban-guru). - [product-strategy](product-strategy/SKILL.md): CPO methodology — product vision and strategy (North Star, product principles), competitive analysis and positioning, roadmap prioritization (RICE, Kano, OST), product-market fit frameworks (Sean Ellis test, retention curves), market sizing (TAM/SAM/SOM), platform strategy, product lifecycle management. +- [production-excellence](bundles/production-excellence/SKILL.md): Route cross-domain production evidence (readiness, migration, recovery, capacity/cost, incident-learning) into a launch or operational decision — go, no-go, defer, exception, or escalation — with an accountable owner and a post-launch learning path. Compose production specialists without copying their runbooks. Do not use for incident command, release-pipeline mechanics, platform architecture, threat modeling, data-pipeline design, or any task owned end-to-end by a single specialist skill; do not use as a generic checklist detached from service ownership, risk, evidence, and verification. - [production-readiness](production-readiness/SKILL.md): Define the minimum production evidence packet by risk class and produce go/no-go/defer/exception launch decisions with accountable owners. Cover ownership, user/business outcome, dependencies, SLOs, observability, support, security, data, rollback, capacity, and cost — every category with a named source or explicit missing-evidence outcome. Route detailed checks to existing specialist skills. Do not use for release pipeline mechanics (release-engineering) or incident response and SLO operations (site-reliability-engineering). - [programming-principles](programming-principles/SKILL.md): Distilled coding principles from 14 classic software books. - [pydanticai](pydanticai/SKILL.md): Build type-safe AI agents and graph-based workflows with PydanticAI and PydanticGraph. Agent creation, function tools, capabilities, dependency injection, structured output, streaming, multi-agent patterns, testing, evals, and graph state machines. Use whenever you are building agents, tool-using LLM workflows, or graph-based state machines in Python. diff --git a/references/skill-triggers.md b/references/skill-triggers.md index 938dcfc..3eadbeb 100644 --- a/references/skill-triggers.md +++ b/references/skill-triggers.md @@ -63,6 +63,7 @@ Each skill's `description` field is the canonical routing contract. This conveni | "product operations", "product governance", "operating model", "decision rights", "product council", "intake review", "portfolio review cadence", "launch review", "experiment review governance", "lifecycle review governance", "evidence standard product", "exception record", "escalation record", "product decision authority", "governance cadence", "product operating model", "lightweight governance", "high-assurance governance", "cross-functional operating contract" | [product-operations-and-governance](../product-operations-and-governance/SKILL.md) | | "product roadmap", "outcome roadmap", "Now/Next/Later", "strategic bet", "bet record", "portfolio roadmap", "roadmap review cadence", "continue/pause/kill criteria", "scenario planning roadmap", "dependency mapping portfolio", "portfolio capacity allocation", "roadmap stakeholder communication" | [product-roadmapping-and-portfolio](../product-roadmapping-and-portfolio/SKILL.md) | | "product UX", "product design", "interaction design", "information architecture", "task flow", "user flow", "state model", "recovery path", "interface contract", "UX handoff", "usability study plan" | [product-design-and-ux](../product-design-and-ux/SKILL.md) | +| "production excellence", "production gate", "launch decision gate", "go no-go defer exception", "production acceptance", "cross-domain evidence", "production evidence packet", "operational handoff", "post-launch learning", "production gate review", "gate model", "escalation decision", "production exception", "cost SLO conflict", "readiness gate", "migration gate review", "recovery evidence gate" | [production-excellence](../bundles/production-excellence/SKILL.md) | | "production readiness", "launch readiness", "ready to launch", "go no-go", "launch decision", "readiness review", "evidence packet", "launch evidence", "production evidence", "risk-scaled readiness", "readiness record", "launch review board", "missing evidence launch", "exception launch approval" | [production-readiness](../production-readiness/SKILL.md) | | "prioritize", "RICE", "MoSCoW", "opportunity solution tree", "decision log", "write a spec", "product spec", "PRD", "stakeholder communication", "executive brief", "feature prioritization", "backlog ranking", "release scope", "build vs buy", "product decision" | [product-methodology](../product-methodology/SKILL.md) | | "privacy engineering", "privacy requirements", "data lifecycle", "data-lifecycle record", "retention policy engineering", "deletion verification", "data residency", "consent engineering", "privacy acceptance criteria", "privacy change review", "data-flow map privacy", "PII lifecycle", "tenant isolation privacy", "privacy-by-design engineering", "agent trace privacy", "telemetry privacy", "data minimization engineering", "purpose limitation engineering" | [privacy-engineering](../privacy-engineering/SKILL.md) |