development-premortem

name	development-premortem
description	Explicit-only skill for development and engineering premortems. Use this skill only when the user explicitly invokes "$development-premortem", "use development-premortem", "run a development premortem", "development-premortem this", "premortem this architecture", "premortem this migration", "premortem this deploy", "premortem this technical plan", "haz un development-premortem", "premortem técnico", or "premortem de desarrollo". Stress-test technical work before build, merge, rollout, migration, architecture change, integration, deployment, or infrastructure change by assuming it failed in production and working backward. Do NOT trigger on normal code review, debugging help, architecture brainstorming, "what are the edge cases?", "will this scale?", "what could break?", or ordinary technical discussion unless the user explicitly asks for development-premortem.
license	MIT
metadata	{"version":"0.1.0"}

Development Premortem

A development premortem assumes a technical plan has already failed in production or in real operation. Work backward from the failure to expose architectural blind spots, unsafe assumptions, missing rollback paths, silent data risks, and concrete changes that make the plan safer to build or deploy.

This skill is explicit-only. If the user asks for normal code review, debugging, brainstorming, edge cases, or scalability feedback without explicitly invoking this skill, do not use it.

When To Use

Use only when the user explicitly asks for a development premortem with one of the trigger phrases in the description.

Good development premortem targets:

• Architecture decisions and platform bets
• Migrations, refactors, rewrites, and schema changes
• Deployments, releases, and rollout plans
• External API, vendor, payment, ERP, auth, or data integrations
• Infrastructure, scaling, queue, cache, or reliability changes
• Security-sensitive workflows
• Technical plans where failure could harm users, data, revenue, or team velocity

Do not use for:

• Normal code review or PR feedback
• Debugging a current bug
• Architecture brainstorming where the user wants options
• Generic edge-case analysis
• Product, pricing, launch, or go-to-market risk; use product-premortem only if explicitly requested

Context Threshold

Before running the premortem, gather only the minimum context needed. Scan the current conversation, referenced files, diffs, docs, or architecture notes first. If one of these is missing and cannot be inferred, ask one focused question at a time:

1. What is changing? Feature, architecture, migration, integration, deploy, refactor, schema, or infrastructure.
2. Where will it run? Runtime, service, app, environment, data store, queue, vendor, or client surface.
3. What depends on it? Users, services, jobs, downstream systems, data consumers, deploy pipeline, support team.
4. What does success mean? Reliability, correctness, latency, migration completion, compatibility, cost, security, or developer velocity.
5. What constraints matter? Deadline, legacy behavior, rollback limits, data volume, compliance, team capacity, dependencies, or uptime requirements.

If the user has provided enough context, proceed immediately and state any assumptions.

Workflow

Step 1: Set The Frame

State the frame explicitly and choose a practical time horizon:

It's [time horizon] after launch/deploy/migration. This technical plan failed in production. Users, data, systems, revenue, operations, or developer velocity were harmed. We're looking back to understand how it failed.

Use these defaults:

• Deploy or release: days to 2 weeks
• Migration or integration: 1-3 months
• Architecture or platform decision: 6-12 months

Step 2: Generate Technical Failure Reasons

Generate every genuine failure reason that fits this specific technical plan. Do not force a fixed count. Some plans have 4 real failure modes; others have 9.

Each failure reason must be:

• Specific to the system and change being discussed
• Grounded in the provided context, files, diffs, or constraints
• A real threat to users, data, uptime, correctness, security, cost, or maintainability
• Stated in 1-2 direct sentences

Use these technical lenses as prompts, not headings unless they help:

• Architecture boundaries and coupling
• Data integrity, schema compatibility, and migration order
• Deployment, rollout, rollback, and feature flags
• Observability, alerting, tracing, and silent failure
• Performance, concurrency, load, and resource limits
• Security, auth, permissions, secrets, and compliance
• External dependencies, vendor behavior, and rate limits
• Backward compatibility across clients, APIs, jobs, and events
• Operational ownership, runbooks, support, and on-call impact
• Developer workflow, maintainability, testing burden, and future changes
• Edge cases, degraded states, retries, idempotency, and partial failure

Step 3: Deepen The Important Failures

For each major failure reason, produce a short technical deep dive:

### [Failure Reason]

**Failure story:** [2-3 paragraphs explaining how this failure played out in production or real operation.]
**Underlying assumption:** [The hidden technical assumption that made this failure possible.]
**Early warning signs:** [1-2 observable signals in logs, metrics, tests, support, data, deploys, or developer workflow.]
**Blast radius:** [Users, systems, data, operations, cost, or team velocity affected.]

If multi-agent delegation is available and the change is high risk, run independent reviewers in parallel by technical lens: architecture, data integrity, release/rollback, observability/operations, security, and performance. Otherwise perform the same review inline while keeping each lens independent.

Step 4: Synthesize

Produce the synthesis first; this is the product of the premortem:

# Development Premortem: [Technical Plan]

## Synthesis

**Most likely technical failure:** [The failure most probable given the plan.]

**Most dangerous technical failure:** [The failure with the largest blast radius.]

**Silent failure risk:** [The failure most likely to happen without immediate alerts.]

**Point of no return:** [The action after which rollback becomes expensive, unsafe, or impossible.]

**Hidden technical assumption:** [The assumption most likely to be wrong or untested.]

**Single most important revision:** [The one concrete technical change that would most improve the plan.]

## Revised Technical Plan

1. [Concrete technical change mapped to a failure mode.]
2. [Concrete technical change mapped to a failure mode.]
3. [Concrete technical change mapped to a failure mode.]

## Pre-Merge / Pre-Deploy Checklist

- [ ] [Specific test, migration dry run, review, flag, monitor, or rollout guard.]
- [ ] [Specific test, migration dry run, review, flag, monitor, or rollout guard.]
- [ ] [Specific test, migration dry run, review, flag, monitor, or rollout guard.]

## Monitoring And Rollback Requirements

**Required signals:** [Metrics, logs, traces, dashboards, alerts, data checks.]

**Rollback path:** [How to reverse, pause, disable, or isolate the change.]

**Stop condition:** [Concrete threshold that halts rollout or triggers rollback.]

## Failure Analysis

[Failure deep dives.]

## Assumptions

- [Assumption made because the user did not provide enough detail.]

Artifact Mode

Default to Markdown suitable for an RFC, ADR, rollout plan, ticket, or PR comment. Generate an HTML report or transcript only if the user explicitly asks for a report, artifact, file, or saved transcript.

When artifact mode is requested:

• Save development-premortem-report-[timestamp].html
• Save development-premortem-transcript-[timestamp].md
• Keep the HTML self-contained with inline CSS
• Put the synthesis at the top
• Include one scannable card per failure reason

Quality Bar

• Do not turn this into generic code review.
• Do not pad with theoretical edge cases that cannot plausibly matter.
• Do not say "add monitoring"; name the exact signal, threshold, dashboard, or alert.
• Do not say "make rollback easier"; name the rollback mechanism and stop condition.
• Prefer concrete changes the team can make before merge, deploy, migration, or rollout.
• Keep the tone direct, technical, and grounded in the user's actual system.