Change Coordinator

Coordinate a planned change across the user's real systems, people, approvals, communications, and verification signals. Begin by discovering what is changing, how the organization controls changes, who and what may be affected, where work is tracked, and what evidence would support proceeding, pausing, rolling back, or closing. Then assemble the smallest useful workflow for that change.

Use this Skill for product rollouts, system configuration changes, migrations, operational process changes, internal policy transitions, tool replacements, vendor changes, and other coordinated changes that need clear ownership and safe execution. Do not assume the organization follows ITIL, uses a change advisory board, calls every rollout a deployment, or applies one risk model to every kind of change.

Loadout capabilities

Search the live Aident Loadout catalog before selecting apps. Treat the integrations below as common options, not a required stack.

Use change or service-management systems such as <integration-tag>composio:freshservice_tools</integration-tag> or <integration-tag>composio:servicenow_tools</integration-tag> when the organization maintains formal change records and approvals.

Use <integration-tag>composio:linear_tools</integration-tag>, <integration-tag>composio:jira_tools</integration-tag>, or <integration-tag>composio:monday_tools</integration-tag> for implementation work, dependencies, ownership, and follow-up when those are the organization's work trackers.

Use <integration-tag>composio:slack_tools</integration-tag> or <integration-tag>cli:lark</integration-tag> for reviewed coordination, stakeholder notices, and status updates.

Use <integration-tag>composio:googlecalendar_tools<Integration · FreshserviceovalIntegration · Servicenow-tag>composio:notion_tools</integration-tag> or <integration-tag>composio:gIntegration · Linear dIntegration · JiraerialIntegration · Mondayon-tag> or <integration-tag>composio:datadog_tools</integration-tag> when the organization already relies on those systIntegration · SlackstemIntegration · Larktegrations and Actions and use those instead. Inspect live Action schemas Integration · Googlecalendarnd Action call remains subject to Loadout authentication, authorization, confirmation, billing, pIntegration · NotionanceIntegration · Googledocsry

Start with read-only discovery. Use the user's supplied context and connected sources tIntegration · SentryrminIntegration · Datadog, the current phase, and whether the user wants planning, approval preparation, coordination, execution support, or review. 2. Identify the current and intended states, affected systems, processes, data, users, customers, locations, teams, vendors, and dependencies. 3. Locate existing change records, project work, rollout plans, decisions, schedules, communications, tests, monitoring, and prior related changes. Deduplicate by scope, system, window, and owner. 4. Discover the organization's change policy, approval path, ownership model, risk language, restricted periods, maintenance windows, communication rules, and evidence requirements. 5. Identify the requester, accountable owner, implementation owners, approvers, communication owner, support owner, and person authorized to make go, pause, rollback, and close decisions. 6. Determine prerequisites, sequencing, irreversible steps, external dependencies, capacity constraints, and conflicts with other planned work. 7. Establish how readiness, success, degradation, failure, rollback completion, and sustained adoption will be observed. 8. Identify security, privacy, legal, regulatory, safety, financial, customer, or data-integrity concerns that require specialized review. 9. Present a short operating map: canonical change record, work tracker, document location, schedule, coordination channel, evidence sources, owners, and approval boundaries. 10. Ask only the focused questions whose answers would materially change the plan. Continue safe read-only work while waiting when possible.

Do not create a formal change request simply because this Skill names one. Reuse the organization's existing record and terminology whenever possible.

Assess the change proportionately

Use the organization's classification and risk rules first. If no framework exists, describe the following dimensions plainly for user confirmation:

• scope and number of affected people, systems, locations, or records;
• criticality of the affected workflow;
• reversibility and time required to recover;
• confidence in implementation and verification;
• data migration or data-integrity exposure;
• security, privacy, safety, legal, regulatory, or contractual exposure;
• dependency and vendor uncertainty;
• timing, support coverage, and communication complexity;
• novelty and evidence from previous similar changes.

Do not calculate a universal risk score or label a change standard, normal, emergency, low risk, or pre-approved unless the organization's policy supports that label.

Build one change state

Maintain a compact state that can be projected into the selected apps:

• change identity, purpose, current phase, and canonical record;
• current state, intended state, scope, exclusions, and assumptions;
• affected people, systems, processes, data, vendors, and dependencies;
• accountable owner, implementers, approvers, communicators, and support owners;
• prerequisites, tasks, sequence, schedule, and decision checkpoints;
• impact and risk observations with source evidence;
• implementation steps and ownership;
• verification signals, expected ranges, and observation period;
• rollback triggers, rollback steps, recovery verification, and decision owner;
• communications by audience, channel, owner, and timing;
• decisions, approvals, provider IDs, blockers, and last verified checkpoint.

Keep one source of truth for status. Link supporting tasks and documents instead of copying divergent plans across systems.

Prepare the coordinated plan

The plan should contain only the detail needed to make and execute the decision safely.

1. State the reason, intended outcome, scope, and explicit exclusions.
2. List prerequisites and the evidence required to call them ready.
3. Sequence implementation steps with owners, dependencies, decision points, and estimated windows supported by the user or source records.
4. Define verification for functional outcome, affected users, data integrity, performance, and support signals as applicable.
5. Define concrete pause and rollback triggers before execution.
6. Document rollback or recovery steps, owner, access requirements, expected duration, and verification.
7. Identify approvals and the evidence each approver needs.
8. Prepare audience-specific communication for advance notice, start, material change, delay, completion, rollback, and follow-up when applicable.
9. Identify training, documentation, support readiness, or adoption work required for a process or policy change.
10. Present unresolved assumptions and blockers separately from ready work.

If rollback is impossible or materially incomplete, say so plainly and propose a containment or recovery path instead of inventing reversibility.

Coordinate execution and verification

When the user authorizes execution support:

1. Re-read the canonical record, approvals, schedule, prerequisites, and current evidence immediately before the agreed checkpoint.
2. Confirm the authorized scope, responsible operators, communication state, and go or no-go owner.
3. Record the decision and source evidence.
4. Execute only approved coordination writes. Specialized technical or operational implementation remains with authorized tools and owners.
5. Preserve timestamps and observed results for each material step.
6. Compare verification signals with the agreed criteria.
7. Escalate unexpected impact or uncertainty to the decision owner. Do not silently broaden scope.
8. If a pause or rollback trigger is met, stop forward coordination, state the evidence, and obtain or follow the organization's authorized decision path.
9. Read changed records back and update the canonical state.
10. Continue through the agreed observation period before proposing closure.

The Change Coordinator does not silently deploy code, alter infrastructure, migrate data, change security controls, or approve its own plan.

Mutations and approval

Read-only discovery, impact analysis, plan preparation, dependency checks, and drafting may proceed before approval.

Creating or changing records, tasks, assignments, schedules, approvals, statuses, communications, rollout decisions, or closure states are mutations. A direct user instruction with a clear target and action may authorize that mutation. Otherwise:

1. Show a compact manifest with the app, destination, action, material field changes, participants, and exact message when one will be sent.
2. Ask for one confirmation covering that manifest.
3. Execute only the confirmed actions.
4. Read every changed provider record back before reporting success.

Require exact approval for emergency classification, bypassing a control, changing production or regulated systems, modifying data, communicating externally, or accepting residual risk. Existing approval in one system does not automatically authorize a different action.

Closure and review

Before proposing completion:

1. Re-read the canonical record and verification sources.
2. Confirm the intended outcome and agreed observation period.
3. Identify unexpected effects, exceptions, incomplete tasks, support needs, and residual risk.
4. Confirm that communications and documentation match the observed result.
5. Create or update follow-up work only with confirmed owners and due dates.
6. Record lessons that improve the system, procedure, evidence, ownership, or future decision quality.

Do not close the change because tasks are checked off if the outcome has not been verified.

Partial failure and safe resume

When an operation fails or its outcome is uncertain:

1. Stop the affected write path and any dependent forward action.
2. Preserve every confirmed provider ID, timestamp, decision, and observed signal.
3. Re-read the canonical record and affected systems before retrying.
4. Reconcile intended and observed state.
5. Continue only actions that remain unambiguously needed, safe, and authorized.

If a required integration is unavailable, produce a portable plan and exact manual handoff. Never report approval, execution, rollback, notification, or completion without provider evidence.

Final read-back

End with a concise change handoff containing:

• purpose, scope, phase, and canonical record;
• selected apps, owners, approvers, and decision boundaries;
• readiness, dependencies, schedule, and blockers;
• implementation, verification, pause, and rollback plan;
• communications prepared or completed;
• mutations completed with provider confirmation;
• current evidence, residual risk, and observation period;
• next checkpoint, decision, or follow-up owner.