| name | maintenance |
| description | Production system maintenance orchestrator. Automates change acceptance → impact analysis → safe modification → test reinforcement → change record in 5 ITIL-based stages. Use this skill for bug fixes, feature changes, config updates, incident response, and hotfixes — always, without exception. |
| version | 1.0.0 |
| updated | "2026-03-16T00:00:00.000Z" |
Maintenance (Production Maintenance Orchestrator)
Purpose: Safely execute changes to a production system following a 5-stage ITIL-based workflow.
Automatically chains existing analysis skills (/impact, /deps, /coverage, /security-review, /changelog)
so the user does not need to run each one individually — the entire flow completes as a single operation.
Core Principle: Production code is involved, so every change must follow impact analysis → user confirmation → modification → verification in that exact order.
Absolute Prohibitions
- Do not modify code before completing the ASSESS stage
- Do not proceed without user confirmation when risk is HIGH or CRITICAL
- Do not move to the next file before running lint/type-check on the current one
- Do not skip the VERIFY stage
- Do not close the task without a change record (RECORD)
Prerequisites (auto-checked at skill start)
- Git repository: A
.git/ directory must exist. Halt if absent.
- TASKS.md: Not required (production maintenance targets existing code).
- Project type detection: Determine lint/test commands from package.json, pyproject.toml, Cargo.toml, etc.
5-Stage Workflow
/maintenance "request description"
│
▼
[Stage 1: ASSESS] Change classification + initial risk screening
│
▼
[Stage 2: ANALYZE] /impact + /deps + /architecture → impact report
│ ↓ HIGH/CRITICAL
│ User confirmation required
▼
[Stage 3: IMPLEMENT] git branch + incremental changes + per-file validation
│
▼
[Stage 4: VERIFY] Tests + /coverage + /security-review
│
▼
[Stage 5: RECORD] Change record + commit + rollback plan
Stage 1: ASSESS (Change Acceptance Decision)
Analyze the user request and classify the change.
Initial risk screening: Quickly determine risk from target file paths.
| Path Pattern | Risk Level | Reason |
|---|
**/payment/**, **/billing/** | CRITICAL | Financial logic |
**/auth/**, **/security/** | CRITICAL | Authentication/security |
migrations/**, **/schema* | HIGH | Data structure |
**/api/**, **/routes/** | HIGH | External interface |
src/**, lib/** | MEDIUM | General business logic |
config/**, *.env* | MEDIUM | Environment config |
docs/**, *.md | LOW | Documentation |
tests/** | LOW | Test code |
Gate: Emergency displays a warning banner then proceeds. Normal + HIGH/CRITICAL requires user confirmation before proceeding.
Stage 2: ANALYZE (Impact Analysis)
Call existing analysis skills in order and consolidate impact.
1. /impact <target file> → change impact + risk factors
2. /deps <target file> → dependency graph + circular reference check
3. /architecture → identify affected domains
Synthesize each skill's results into an impact report:
## Impact Report
| Item | Result |
|------|--------|
| Target files | 3 |
| Affected files | 12 |
| Affected domains | backend, api |
| Circular references | none |
| Risk level | HIGH |
### Risk Factors
- Core logic change in the payment domain
- Affects 3 API endpoints
Gate: If risk level is HIGH or CRITICAL, confirm with the user:
- Display impact summary
- Offer "Proceed / Reduce scope / Abort" choices
Stage 3: IMPLEMENT (Safe Modification)
Safely modify production code. All changes are made on a dedicated branch.
git checkout -b maintenance/{change-type}-{short-description}
Principles:
- Modify only one file at a time
- Validate immediately after each modification — do not move to the next file before validating
- If all files fail validation, halt and suggest manual correction to the user
Stage 4: VERIFY (Test Reinforcement)
Validate the quality of modified code.
1. Run existing tests → confirm all pass
2. /coverage <changed files> → check for coverage regression
3. /security-review --path <changed files> → check for security vulnerabilities
Validation verdict:
| Result | Verdict | Action |
|---|
| All tests pass + coverage maintained + security clean | PASS | Proceed to RECORD |
| Tests pass + coverage decreased | WARN | Show warning, user decides |
| Tests fail | FAIL | Show failure cause, suggest fix |
| CRITICAL security issue | BLOCK | Cannot proceed until security issue is resolved |
Stage 5: RECORD (Change History)
Systematically record the change history.
1. Update TASKS.md → mark fixed tasks as [x], add new tasks if created
2. Create Change Record → based on references/change-record-template.md
3. Write structured commit message
4. Present rollback plan
Commit message format:
{change-type}({domain}): {description}
Change-Type: {Standard|Normal|Emergency}
Risk-Level: {CRITICAL|HIGH|MEDIUM|LOW}
Impact: {affected domains}
Files: {count} modified
Rollback: git revert <hash>
Rollback plan: After the commit, provide the rollback command to the user.
Final Report
After all stages complete, output a summary report:
┌─────────────────────────────────────────────┐
│ Maintenance Complete Report │
├─────────────────────────────────────────────┤
│ Change Type: Bug Fix (Normal) │
│ Risk Level: MEDIUM │
│ │
│ ✅ ASSESS: Standard classification │
│ ✅ ANALYZE: 3 files, 2 domains affected │
│ ✅ IMPLEMENT: 3/3 files modified │
│ ✅ VERIFY: Tests pass, coverage maintained│
│ ✅ RECORD: CR-20260316-001 created │
│ │
│ Branch: maintenance/fix-payment-null-check │
│ Rollback: git revert abc1234 │
└─────────────────────────────────────────────┘
Skill Integration Table
| Stage | Called Skill | Purpose |
|---|
| ASSESS | (built-in logic) | Change classification + initial risk screening |
| ANALYZE | /impact, /deps, /architecture | Consolidated impact analysis |
| VERIFY | /coverage, /security-review | Quality + security validation |
| RECORD | /changelog (auto via hook) | Change history record |
Reference Documents
references/change-record-template.md — RFC-style change record template
Last Updated: 2026-03-16 (v1.0.0)
