From agent-almanac
Manage change control for validated systems: triage, impact assessment, revalidation, approval workflows, and post-change verification. For upgrades, patches, config changes, or CAPA modifications.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agent-almanac:manage-change-controlThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Evaluate, approve, implement, and verify changes to validated computerized systems while maintaining their validated state.
Evaluate, approve, implement, and verify changes to validated computerized systems while maintaining their validated state.
# Change Request
## Document ID: CR-[SYS]-[YYYY]-[NNN]
### 1. Change Description
**Requestor:** [Name, Department]
**Date:** [YYYY-MM-DD]
**System:** [System name and version]
**Current State:** [Current configuration/version]
**Proposed State:** [Target configuration/version]
### 2. Justification
[Business, regulatory, or technical reason for the change]
### 3. Classification
| Type | Definition | Approval Path | Timeline |
|------|-----------|--------------|----------|
| **Emergency** | Urgent fix for safety, data integrity, or regulatory compliance | System owner + QA (retrospective CCB) | Implement immediately, document within 5 days |
| **Standard** | Planned change with potential impact on validated state | CCB approval before implementation | Per CCB schedule |
| **Minor** | Low-risk change with no impact on validated state | System owner approval | Documented before implementation |
**This change is classified as:** [Emergency / Standard / Minor]
**Rationale:** [Why this classification]
Expected: Change request has a unique ID, clear description, and justified classification. On failure: If classification is disputed, default to Standard and let the CCB adjudicate.
Evaluate the change against all dimensions of the validated state:
# Impact Assessment
## Change Request: CR-[SYS]-[YYYY]-[NNN]
### Impact Matrix
| Dimension | Affected? | Details | Risk |
|-----------|-----------|---------|------|
| Software configuration | Yes/No | [Specific parameters changing] | [H/M/L] |
| Source code | Yes/No | [Modules, functions, or scripts affected] | [H/M/L] |
| Database schema | Yes/No | [Tables, fields, constraints changing] | [H/M/L] |
| Infrastructure | Yes/No | [Servers, network, storage affected] | [H/M/L] |
| Interfaces | Yes/No | [Upstream/downstream system connections] | [H/M/L] |
| User access/roles | Yes/No | [Role changes, new access requirements] | [H/M/L] |
| SOPs/work instructions | Yes/No | [Procedures requiring update] | [H/M/L] |
| Training | Yes/No | [Users requiring retraining] | [H/M/L] |
| Data migration | Yes/No | [Data transformation or migration needed] | [H/M/L] |
| Audit trail | Yes/No | [Impact on audit trail continuity] | [H/M/L] |
### Regulatory Impact
- [ ] Change affects 21 CFR Part 11 controls
- [ ] Change affects EU Annex 11 controls
- [ ] Change affects data integrity (ALCOA+)
- [ ] Change requires regulatory notification
Expected: Every dimension is assessed with a clear yes/no and rationale. On failure: If impact cannot be determined without testing, classify the dimension as "Unknown — requires investigation" and mandate a sandbox evaluation before production change.
Based on the impact assessment, define what validation activities are needed:
# Revalidation Determination
| Revalidation Level | Criteria | Activities Required |
|--------------------|----------|-------------------|
| **Full revalidation** | Core functionality changed, new GAMP category, or major version upgrade | URS review, RA update, IQ, OQ, PQ, TM update, VSR |
| **Partial revalidation** | Specific functions affected, configuration changes | Targeted OQ for affected functions, TM update |
| **Documentation only** | No functional impact, administrative changes | Update validation documents, change log entry |
| **None** | No impact on validated state (e.g., cosmetic change) | Change log entry only |
### Determination for CR-[SYS]-[YYYY]-[NNN]
**Revalidation level:** [Full / Partial / Documentation only / None]
**Rationale:** [Specific reasoning based on impact assessment]
### Required Activities
| Activity | Owner | Deadline |
|----------|-------|----------|
| [e.g., Execute OQ test cases TC-OQ-015 through TC-OQ-022] | [Name] | [Date] |
| [e.g., Update traceability matrix for URS-007] | [Name] | [Date] |
| [e.g., Update SOP-LIMS-003 section 4.2] | [Name] | [Date] |
Expected: Revalidation scope is proportional to the change impact — no more, no less. On failure: If revalidation scope is contested, err on the side of more testing. Under-validation is a regulatory risk; over-validation is only a resource cost.
Route the change through the appropriate approval workflow:
# Change Approval
### Approval for: CR-[SYS]-[YYYY]-[NNN]
| Role | Name | Decision | Signature | Date |
|------|------|----------|-----------|------|
| System Owner | | Approve / Reject / Defer | | |
| QA Representative | | Approve / Reject / Defer | | |
| IT Representative | | Approve / Reject / Defer | | |
| Validation Lead | | Approve / Reject / Defer | | |
### Conditions (if any)
[Any conditions attached to the approval]
### Planned Implementation Window
- **Start:** [Date/Time]
- **End:** [Date/Time]
- **Rollback deadline:** [Point of no return]
Expected: All required approvers have signed before implementation begins (except emergency changes). On failure: For emergency changes, obtain verbal approval from system owner and QA, implement the change, and complete formal documentation within 5 business days.
Execute the change and perform post-change verification:
# Implementation Record
### Pre-Implementation
- [ ] Backup of current system state completed
- [ ] Rollback procedure documented and tested
- [ ] Affected users notified
- [ ] Test environment validated (if applicable)
### Implementation
- **Implemented by:** [Name]
- **Date/Time:** [YYYY-MM-DD HH:MM]
- **Steps performed:** [Detailed implementation steps]
- **Deviations from plan:** [None / Description]
### Post-Change Verification
| Verification | Result | Evidence |
|--------------|--------|----------|
| System accessible and functional | Pass/Fail | [Screenshot/log reference] |
| Changed functionality works as specified | Pass/Fail | [Test case reference] |
| Unchanged functionality unaffected (regression) | Pass/Fail | [Test case reference] |
| Audit trail continuity maintained | Pass/Fail | [Audit trail screenshot] |
| User access controls intact | Pass/Fail | [Access review reference] |
### Closure
- [ ] All verification activities completed successfully
- [ ] Validation documents updated per revalidation determination
- [ ] SOPs updated and effective
- [ ] Training completed for affected users
- [ ] Change record closed in change control system
Expected: Implementation matches the approved plan, and all verification activities pass. On failure: If verification fails, execute the rollback procedure immediately and document the failure as a deviation. Do not proceed without QA concurrence.
design-compliance-architecture — defines the governance framework including change control boardwrite-validation-documentation — create the revalidation documentation triggered by changesperform-csv-assessment — full CSV reassessment for major changes requiring full revalidationwrite-standard-operating-procedure — update SOPs affected by the changeinvestigate-capa-root-cause — when changes are triggered by CAPAsnpx claudepluginhub pjt222/agent-almanacAutomates the end-to-end change management pipeline: detects changes, classifies levels, drafts CHG records, traces cross-layer impact, and prepares gate approval. Works from diffs, incidents, prompts, or artifact edits.
Runs a Computer Systems Validation (CSV) assessment using GAMP 5 methodology for GxP environments. Covers URS creation, risk assessment, IQ/OQ/PQ planning, traceability matrix, and validation summary reporting.
Manages baseline and scope changes, artifact updates, traceability impact, approvals, and handoff revisions in SDLC workflows.