Update an existing SOP to reflect changes in tools, processes, or best practices
Updates existing Standard Operating Procedures to reflect changes in tools, processes, or best practices.
/plugin marketplace add TheBushidoCollective/han/plugin install hashi-gitlab@hanhashi-agent-sop:update-sop - Update an existing Standard Operating Procedure
/update-sop
This command guides users through updating existing Standard Operating Procedures (SOPs) to reflect changes in tools, processes, or best practices. It handles version bumping, changelog management, migration guides, and ensures consistency across related SOPs.
You are helping the user update an existing Standard Operating Procedure (SOP) to keep it current and accurate.
Guide the user through updating an SOP by:
Identify the SOP to update:
Read the current SOP:
Determine update type:
Update version and changelog:
# {SOP Title}
**Version**: {new_version}
**Last Updated**: {YYYY-MM-DD}
**Changes**: {brief summary of changes}
## Changelog
### v{new_version} ({date})
- {change 1 with detail}
- {change 2 with detail}
- {change 3 with detail}
*Reason: {why these changes were made}*
### v{previous_version} ({previous_date})
- {previous changes}
Make the updates:
Ensure consistency:
Major (X.0.0): Breaking changes
Minor (x.X.0): New features, non-breaking
Patch (x.x.X): Bug fixes, clarifications
After making changes, verify:
## Changelog
### v1.2.0 (2025-12-05)
- Updated Node.js requirement from v16 to v18
- Updated npm commands to use new syntax
- Added troubleshooting for Node v18 breaking changes
*Reason: Node.js v16 reached end-of-life*
## Prerequisites
### Required Tools
- Node.js (v18 or higher) <!-- Changed from v16 -->
- npm (v9 or higher) <!-- Changed from v8 -->
## Changelog
### v1.1.0 (2025-12-05)
- Added error handling for connection timeout scenarios
- Included retry logic in deployment steps
*Reason: Production incident #1234 - timeout during deployment*
## Error Handling
### Error: Connection Timeout During Deployment
**Symptoms**: Deployment hangs, connection to server times out
**Cause**: Network issues, server overload, or firewall blocking
**Resolution**:
1. Check network connectivity to deployment target
2. Verify server is responsive: `ping {server}`
3. Retry deployment with increased timeout: `--timeout 300`
4. If persistent, check firewall rules and server logs
## Changelog
### v2.0.0 (2025-12-05)
- Added canary deployment step (BREAKING)
- Restructured rollout process for gradual release
- Added monitoring validation between stages
*Reason: Reduce risk of production outages from bad deployments*
## Steps
1. Deploy to canary (10% of traffic)
- Update canary deployment
- Route 10% traffic to new version
- **NEW**: Monitor error rates for 10 minutes
- **Validation**: Error rate < 1%, latency within 10% of baseline
2. Deploy to production (remaining 90%)
- If canary successful, proceed
- If canary fails, rollback automatically
[... rest of steps ...]
For breaking changes (major version), include migration guide:
## Migration from v{old_major}.x
### Breaking Changes
1. **{Change Name}**
- **Old Behavior**: {what it was before}
- **New Behavior**: {what it is now}
- **Action Required**: {what users must do}
2. **{Another Change}**
- **Old Behavior**: {previous approach}
- **New Behavior**: {new approach}
- **Action Required**: {migration steps}
### Migration Steps
1. {Step to prepare for migration}
2. {Step to perform migration}
3. {Step to verify migration}
### Backward Compatibility
- {What remains compatible}
- {What breaks compatibility}
- {How long old version will be supported}
Test the updated SOP:
Communicate changes:
Update related documentation:
Commit changes:
git add {sop-file}.sop.md
git commit -m "feat(sop): update {sop-name} to v{version} - {summary}"
User: "Update the deployment SOP to use the new CI/CD pipeline"
Response: