home / skills / laurigates / claude-plugins / docs-decommission

This skill generates a comprehensive decommission documentation file with checklists, roles, timelines, and rollback procedures to streamline safe shutdowns.

npx playbooks add skill laurigates/claude-plugins --skill docs-decommission

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.4 KB
---
model: haiku
created: 2025-12-16
modified: 2025-12-16
reviewed: 2026-02-08
allowed-tools: Read, Write, Edit, Bash(find *), Bash(ls *), Grep, TodoWrite
argument-hint: <service-name>
description: Generate comprehensive service decommission documentation
name: docs-decommission
---

# Service Decommission Documentation Generator

Generate a comprehensive decommission checklist for ${1:-[SERVICE_NAME]} to be created at deployment time when all context is fresh.

## Your Task

Create a detailed decommission documentation file that includes:

### 1. Service Overview
- Document the service name, purpose, and deployment date
- List all environments (dev, staging, production)
- Note key stakeholders and team contacts
- Record repository and deployment locations

### 2. Infrastructure Resources Checklist
Create a checklist covering:
- [ ] Cloud resources (compute instances, containers, serverless functions)
- [ ] Storage resources (databases, object storage, file systems, volumes)
- [ ] Network resources (load balancers, DNS records, CDN configurations)
- [ ] Security resources (SSL certificates, API keys, service accounts, IAM roles)
- [ ] Monitoring and alerting (dashboards, alert rules, log aggregations)
- [ ] CI/CD pipelines and automation jobs
- [ ] Scheduled tasks and cron jobs

### 3. Data Management Checklist
- [ ] Identify all data stores and their locations
- [ ] Create data backup procedures and retention policies
- [ ] Document data migration or archival requirements
- [ ] Plan for data deletion in compliance with policies
- [ ] Verify backup completion and integrity
- [ ] Document legal/compliance data retention requirements

### 4. Access and Security Checklist
- [ ] Revoke service accounts and API credentials
- [ ] Remove IAM roles and permissions
- [ ] Rotate any shared secrets or keys
- [ ] Update security groups and firewall rules
- [ ] Remove OAuth applications and integrations
- [ ] Audit and remove user access
- [ ] Update password vaults and secret managers

### 5. DNS and Networking Checklist
- [ ] Document all DNS records (A, CNAME, TXT, MX, etc.)
- [ ] Plan DNS record removal or updates
- [ ] Update load balancer configurations
- [ ] Remove or update CDN configurations
- [ ] Document any hardcoded URLs or endpoints
- [ ] Notify dependent services of endpoint changes

### 6. Integration and Dependencies Checklist
- [ ] Identify all upstream services (services this one depends on)
- [ ] Identify all downstream services (services depending on this one)
- [ ] Document API contracts and integration points
- [ ] Notify dependent teams of decommission timeline
- [ ] Plan migration path for dependent services
- [ ] Update service discovery and registries

### 7. Monitoring and Observability Cleanup
- [ ] Remove monitoring dashboards
- [ ] Delete alert rules and notification channels
- [ ] Clean up log aggregation and retention
- [ ] Remove tracing and APM configurations
- [ ] Archive historical metrics if needed
- [ ] Update status pages and documentation

### 8. Documentation and Knowledge Transfer
- [ ] Archive technical documentation
- [ ] Update architecture diagrams
- [ ] Remove or archive runbooks and SOPs
- [ ] Update team wikis and knowledge bases
- [ ] Document lessons learned
- [ ] Archive incident reports and postmortems

### 9. Financial and Administrative
- [ ] Cancel subscriptions and recurring charges
- [ ] Remove cost allocation tags
- [ ] Update budget and capacity planning
- [ ] Archive invoices and billing records
- [ ] Transfer domain registrations if needed

### 10. Final Verification
- [ ] Verify all resources are deleted or archived
- [ ] Confirm no unexpected charges appear
- [ ] Validate dependent services are functioning
- [ ] Complete decommission sign-off with stakeholders
- [ ] Archive this decommission documentation

## Output Format

Create a markdown file named `DECOMMISSION-${1:-[SERVICE_NAME]}.md` with:
- Clear section headers
- Checkboxes for each action item
- Specific resource identifiers (not generic placeholders)
- Timeline and responsible parties for each major section
- Links to relevant documentation and tools
- Emergency rollback procedures

## Important Notes

- This documentation should be created **at deployment time** when context is fresh
- Include actual resource identifiers, not examples
- Keep it updated as the service evolves
- Store it in the service repository for easy access
- Review and update quarterly or after major changes

Overview

This skill generates a comprehensive decommission document for a service at deployment time, capturing resources, data, access, and operational steps. It produces a ready-to-store DECOMMISSION-[SERVICE_NAME].md with checklists, owners, timelines, and resource identifiers. The goal is to make decommission safe, auditable, and repeatable.

How this skill works

At creation time the skill inspects provided deployment context and prompts for concrete identifiers (compute IDs, database endpoints, DNS records, IAM principals). It then organizes findings into sections: infrastructure, data management, access/security, networking, integrations, observability, documentation, financials, and final verification. The output uses clear section headers, actionable checkboxes, assigned owners, timelines, links, and rollback procedures.

When to use it

  • Create the decommission document during initial deployment or major release
  • Before retiring a service or beginning a migration project
  • When onboarding a new owner or transferring service responsibility
  • During quarterly reviews or after significant architecture changes
  • Whenever service context and resource identifiers are still fresh

Best practices

  • Capture actual resource identifiers (instance IDs, DB hostnames, DNS entries) at creation time
  • Assign a responsible owner and a timeline to every major checklist item
  • Keep the document in the service repository and review quarterly
  • Include links to runbooks, dashboards, and billing pages for quick action
  • Document an emergency rollback plan and verify backups before deletion

Example use cases

  • Generate a DECOMMISSION file when launching a new microservice so retirement steps are already defined
  • Prepare a migration plan and decommission checklist when replacing an old database cluster
  • Document exact network and DNS changes required before removing a staging environment
  • Provide auditors with a traceable decommission plan including compliance and retention steps
  • Coordinate cross-team shutdown of a service by listing downstream dependencies and owners

FAQ

When should I update the decommission document?

Update it whenever you change resources, integrations, credentials, or after major releases; review quarterly.

What if I don't know every resource identifier at deployment?

Record what you know and mark unknowns as action items with owners and deadlines; complete identifiers during the first maintenance window.