Skip to content
cccskills
FreePublished on GitHub

prd-v08-release-planning

Define release criteria, deployment environments, and rollback strategies during PRD v0.8 Deployment & Ops. Triggers on requests to plan releases, define deployment criteria, or when user asks "how do we deploy?", "release criteria", "deployment plan", "rollback strategy", "go-live checklist". Outputs DEP- entries with deployment steps and release criteria.

The English summary is being prepared. Showing the original description.

See how to install

Files included (5)

  • SKILL.md12.0 KB
  • assets/dep-template.md11.8 KB
  • references/deployment-strategies.md16.5 KB
  • references/examples.md16.8 KB
  • references/rollback-procedures.md18.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Release Planning

Position in workflow: v0.7 Implementation Loop → v0.8 Release Planning → v0.8 Runbook Creation

Execution Mode

Default is standard. See .claude/rules/08-skill-execution-modes.md for selection logic.

ModeWhat this skill produces
quickStaging→prod only; 3–5 release criteria; one rollback trigger
standardDev/staging/preview/prod environments; full criteria checklist; multiple rollback triggers; post-deploy validation
deepFull environments + IaC review + canary/blue-green strategy + risk-weighted criteria + post-mortem hooks

Consumes

This skill requires prior work from v0.7 Implementation Loop and v0.6-v0.9:

  • EPIC-* completed entries (from v0.7 Implementation Loop) — Finished work packages define what's being released; must have State=Complete, all TEST- passing
  • TEST-* test entries (from v0.7 Test Planning) — All TEST- must pass in staging before release criteria can be met
  • API-* endpoint contracts (referenced in EPIC Context & IDs) — Define SLA and performance baselines for release criteria
  • ENV-* environment specifications (from v0.6 Environment Setup) — Local/CI/CD/production configurations inform DEP- entries for each environment
  • ARC-* architecture decisions (from v0.6 Architecture Design) — System structure (monolith, microservices, deployment topology) drives environment setup
  • TECH-* technology stack (from v0.5 Technical Stack Selection) — Technology choices inform infrastructure requirements and deployment tooling
  • RISK-* high-priority entries (from v0.5 Risk Discovery) — High RISK- must be mitigated or explicitly accepted before release
  • KPI-* metrics (from v0.3 and v0.9) — Target KPI values inform monitoring baselines and rollback thresholds

This skill assumes v0.7 Implementation is complete with all EPIC- entries marked Complete and all TEST- passing.

Produces

This skill creates/updates:

  • DEP-* entries (deployment specifications, environment/criteria/rollback/validation types) — Release readiness checklist with environment configs, go/no-go criteria, rollback triggers and thresholds, post-deploy validation steps
  • Release readiness checklist — Pre-deploy validation matrix showing which DEP- criteria must be met before release proceeds
  • Rollback decision tree — Mapping of DEP- rollback triggers to execution procedures and escalation paths (feeds v0.8 Runbook Creation)

All DEP- entries are operational contracts, not confidence-based. They are:

  • Environment-specific (each environment from staging to production has defined configuration)
  • Verifiable (each criterion has a concrete check or metric threshold)
  • Enforceable (release stops if DEP- criteria not met)
  • Traceable (each DEP- links to EPIC-, TEST-, API-, KPI- that validate it)

Example DEP- entries:

DEP-001: Production Environment Configuration
Type: Environment
Stage: Pre-deploy

Description: AWS production environment setup for application
Name: production
Infrastructure: AWS us-east-1, ECS Fargate, RDS PostgreSQL
Configuration:
  - NODE_ENV=production
  - LOG_LEVEL=info
  - RATE_LIMIT=100/min
  - METRICS_COLLECTION=enabled
Secrets: AWS Secrets Manager, rotated monthly
Access: DevOps team (deploy), On-call (read-only access)

Linked IDs: ARC-001 (monolith structure), TECH-005 (AWS)

---

DEP-002: All Tests Pass in Staging
Type: Criteria
Stage: Pre-deploy

Description: Complete test suite must pass in staging environment before production release
Requirement: All TEST- entries pass with >95% success rate, including smoke tests and E2E tests
Verification: CI/CD pipeline reports green; test report generated and reviewed
Blocker: Yes — Release cannot proceed if this fails
Owner: QA Lead

Linked IDs: TEST-001 to TEST-050 (from EPIC-01 through EPIC-07)

---

DEP-003: Error Rate Rollback Trigger
Type: Rollback
Stage: Post-deploy

Description: Automatic rollback if error rate exceeds baseline post-deployment
Trigger: 5xx error rate exceeds pre-deployment baseline
Threshold: >2% of requests for 5 minutes (currently 0.5% baseline from MON-001)
Procedure:
  1. Alert on-call engineer (PagerDuty)
  2. Pause traffic to new version
  3. Revert to pre-deploy git tag
  4. Investigate root cause
Notification: #incidents Slack, PagerDuty, Engineering Lead

Linked IDs: MON-001 (error rate metric), RUN-002 (rollback procedure), API-001–020 (endpoints affected)

---

DEP-004: Post-Deployment Smoke Tests
Type: Validation
Stage: Post-deploy

Description: Automated smoke tests to verify critical user journeys work post-deployment
Check: All critical UJ- (UJ-000, UJ-001, UJ-005, UJ-010) complete successfully
Method: Automated (tests/e2e/smoke.spec.ts) + manual spot-check
Success Criteria: All journeys complete <2 seconds, no auth failures, data persists
Escalation: If smoke tests fail, execute DEP-003 rollback and investigate

Linked IDs: UJ-000/001/005/010 (critical journeys), TEST-050 (E2E suite)

Core Concept: Release as Contract

A release is not "code that works locally." It is a contract between development and operations—a formal handoff that includes everything needed to deploy, validate, and recover.

Release Components

ComponentPurposeOutput
Deployment EnvironmentWhere code runsDEP- (environment config)
Release CriteriaWhat must be true to deployDEP- (checklist)
Rollback TriggersWhen to revertDEP- (conditions)
Validation StepsHow to verify successDEP- (post-deploy checks)

Execution

  1. Inventory completed EPICs

    • Which EPIC- entries are "Complete"?
    • What API-, DBT-, FEA- are included in this release?
  2. Define deployment environments

    • Staging, Production, Preview
    • Environment-specific configurations
    • Secrets management approach
  3. Establish release criteria

    • All TEST- pass in staging
    • Performance baselines met (from MON-)
    • No critical RISK- blockers
    • Security review complete
  4. Define rollback triggers

    • Error rate thresholds
    • Latency thresholds
    • User-reported critical issues
    • Data integrity concerns
  5. Document validation steps

    • Post-deployment smoke tests
    • Key journey verification (UJ-)
    • Metric baseline confirmation
  6. Create DEP- entries with full traceability

DEP- Output Template

DEP-XXX: [Deployment Item Title]
Type: [Environment | Criteria | Rollback | Validation | Step]
Stage: [Pre-deploy | Deploy | Post-deploy | Rollback]

Description: [What this deployment item covers]

For Environment Type:
  Name: [staging | production | preview]
  Infrastructure: [Cloud provider, region, resources]
  Configuration: [Environment-specific settings]
  Secrets: [How secrets are managed]
  Access: [Who can deploy, who can access]

For Criteria Type:
  Requirement: [What must be true]
  Verification: [How to check this]
  Blocker: [Yes | No] — Does failure block deploy?
  Owner: [Who verifies]

For Rollback Type:
  Trigger: [What condition initiates rollback]
  Threshold: [Specific metric or condition]
  Procedure: [How to execute rollback]
  Notification: [Who to alert]

For Validation Type:
  Check: [What to verify post-deploy]
  Method: [Manual | Automated | Both]
  Success Criteria: [Expected result]
  Escalation: [What if validation fails]

Linked IDs: [EPIC-XXX, API-XXX, TEST-XXX related]

Example DEP- entries:

DEP-001: Production Environment Configuration
Type: Environment
Stage: Pre-deploy

Description: AWS production environment setup for main application

Name: production
Infrastructure: AWS us-east-1, ECS Fargate, RDS PostgreSQL
Configuration:
  - NODE_ENV=production
  - LOG_LEVEL=info
  - RATE_LIMIT=100/min
Secrets: AWS Secrets Manager, rotated monthly
Access: DevOps team (deploy), On-call (read-only)

Linked IDs: ARC-001, TECH-005
DEP-002: All Tests Pass in Staging
Type: Criteria
Stage: Pre-deploy

Description: Complete test suite must pass in staging environment

Requirement: All TEST- entries pass with >95% success rate
Verification: CI/CD pipeline green status, test report review
Blocker: Yes
Owner: QA Lead

Linked IDs: TEST-001 to TEST-050
DEP-003: Error Rate Rollback Trigger
Type: Rollback
Stage: Post-deploy

Description: Automatic rollback if error rate exceeds threshold

Trigger: 5xx error rate exceeds baseline
Threshold: >2% of requests for 5 minutes
Procedure:
  1. Alert on-call engineer
  2. Pause traffic to new version (if canary)
  3. Revert to previous known-good version
  4. Investigate root cause
Notification: #incidents Slack, PagerDuty

Linked IDs: MON-001, RUN-005

Environment Progression

StageEnvironmentPurposeGate
1DevelopmentEngineer testingTests pass locally
2StagingIntegration testingAll TEST- pass
3PreviewStakeholder reviewSign-off from PM
4ProductionLive usersAll DEP- criteria met

Release Criteria Categories

CategoryExamplesPriority
FunctionalTests pass, features workMust-have
PerformanceLatency <200ms, throughput >100rpsMust-have
SecurityNo critical vulns, secrets rotatedMust-have
OperationalRunbooks ready, monitoring activeShould-have
DocumentationRelease notes, API docs updatedShould-have

Rollback Strategy Patterns

PatternWhen to UseComplexity
Blue-GreenNeed instant rollback, can afford 2x infraMedium
CanaryGradual rollout, catch issues earlyHigh
RollingZero-downtime, standard approachLow
Feature FlagsDecouple deploy from releaseMedium

Anti-Patterns

PatternSignalFix
Deploy and prayNo validation steps definedAdd DEP- validation entries
Manual everythingNo automation, error-proneAutomate repeatable steps
No rollback plan"We'll figure it out"Define triggers and procedures upfront
Environment driftStaging doesn't match productionInfrastructure as code, sync configs
Missing criteria"It works on my machine"Formal DEP- criteria checklist
Unclear ownershipNo one knows who approvesAssign owner to each DEP-

Quality Gates

Before proceeding to Runbook Creation:

  • All deployment environments documented (DEP- Environment type)
  • Release criteria defined with clear blockers (DEP- Criteria type)
  • Rollback triggers specified with thresholds (DEP- Rollback type)
  • Post-deploy validation steps defined (DEP- Validation type)
  • Each DEP- entry has an owner
  • Criteria trace back to EPIC-, TEST-, API- IDs

Downstream Connections

ConsumerWhat It UsesExample
Runbook CreationDEP- rollback procedures become runbook inputsDEP-003 → RUN-005
Monitoring SetupDEP- thresholds inform alertingDEP-003 (2% error) → MON-001
v0.9 GTM StrategyRelease readiness gates launchAll DEP- met → GTM-001
EPIC- Future ReleasesDEP- becomes template for next releaseDEP-001 reused

Detailed References

  • Environment configuration examples: See references/environment-examples.md
  • DEP- entry template: See assets/dep-template.md
  • Rollback procedure guide: See references/rollback-guide.md

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Validates gate criteria before PRD lifecycle advancement by delegating to the readiness scoring pipeline (scripts/readiness.py). Returns a graduated PASS / WARN / BLOCK verdict with top blockers and their causal chain. Triggers before advancing from v0.X to v0.Y or explicit `/ghm-gate-check`.

The English summary is being prepared. Showing the original description.

mattgierhart/PRD-driven-context-engineering181Updated Aug 31, 2026

Extracts durable insights from temp/ files to SoT during EPIC Phase E. Triggers at EPIC completion or explicit `/ghm-harvest` invocation. Outputs new SoT entries and archive manifest.

The English summary is being prepared. Showing the original description.

mattgierhart/PRD-driven-context-engineering181Updated Aug 31, 2026

Validates and registers new SoT IDs with cross-reference integrity. Triggers when creating BR-XXX, UJ-XXX, API-XXX, or CFD-XXX entries. Outputs formatted SoT entry with validated cross-references.

The English summary is being prepared. Showing the original description.

mattgierhart/PRD-driven-context-engineering181Updated Aug 31, 2026

Install the PRD-Driven Context Engineering methodology into a fresh OR existing repository — the subscription-native alternative to forking the whole repo. Runs an interactive wizard that seeds the framework (.claude/ hooks, skills, agents, rules, scripts) without clobbering product content. Triggers on "install the methodology", "adopt this into my repo", "self-install", "set up PRD lifecycle here", "onboard existing project". Outputs an installed framework + a verification report.

The English summary is being prepared. Showing the original description.

mattgierhart/PRD-driven-context-engineering181Updated Aug 31, 2026

Creates new Source of Truth (SoT) files when existing templates don't fit your needs. Triggers on requests to create a new SoT file, add a new artifact type, or when user says "I need to track [X] but there's no SoT for it", "create SoT", "new source of truth". Outputs a properly structured SoT.*.md file with ID prefix, frontmatter, and update protocol.

The English summary is being prepared. Showing the original description.

mattgierhart/PRD-driven-context-engineering181Updated Aug 31, 2026

Synchronizes README.md Command Center with current project state. Triggers on gate changes, EPIC status changes, or explicit `/ghm-status-sync` invocation. Outputs updated README.md dashboard with current lifecycle stage, blockers, and metrics.

The English summary is being prepared. Showing the original description.

mattgierhart/PRD-driven-context-engineering181Updated Aug 31, 2026

See all skills by mattgierhart

Report a problem with this skill