<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

release-readiness

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Produce evidence for a release decision and a practical rollout/recovery plan, not a ceremonial checklist.

Required inputs

• Release scope, acceptance criteria, diff/version range, target environments, and owners.
• Test/build results, migrations, configuration/secrets, dependencies, and known risks.
• Deployment method, observability, rollout controls, compatibility window, and recovery capabilities.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. Reconcile shipped behavior with scope, acceptance criteria, non-goals, and public contract changes.
2. Verify tests/build/types and inspect security, privacy, dependency, configuration, and secret impact.
3. Review schema/data migrations, backfills, compatibility ordering, and rollback/forward recovery.
4. Confirm health signals, dashboards/alerts, support/operator notes, ownership, and incident triggers.
5. Define progressive rollout, smoke checks, decision thresholds, and explicit stop/recovery steps.
6. Classify blockers, accepted risks, and post-release verification with named evidence/owners.

Output contract

• Go/no-go recommendation with blockers first and evidence links/commands.
• Rollout, smoke-test, monitoring, and rollback/forward recovery sequence.
• Accepted risks, owners, communication needs, and post-release checks.

Guardrails

• Do not mark an item ready based on intention or an unrun command.
• Do not recommend rollback when schema/data changes make it unsafe; define forward recovery instead.
• Do not bury a release blocker among low-severity observations.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.