sdlc-change-control

name	sdlc-change-control
description	Use only when the user explicitly invokes this skill to manage an approved or proposed baseline/scope change across artifacts, traceability, approvals, and handoff.
metadata	{"version":"1.0","updated":"2026-07-26"}

Change Control

Use this workflow when a requirement, baseline, scope, SRS, SPEC, NFR, handoff package, or traceability chain changes after it has been used for planning or development.

Change control protects the delivery contract:

what changed
why it changed
who owns the decision
what artifacts and tasks are affected
whether dev can continue

Not every code change needs formal change control. Direct-dev work may proceed without this skill when no SDLC baseline exists and the change is scoped to an issue, bugfix, or local task. Use change control when a prior agreement, source artifact, scope baseline, or implementation contract is affected.

Use when

• A scoped or baselined requirement changes.
• SRS, NFR, SPEC, RTM, dev handoff, or acceptance criteria must be updated after development planning starts.
• Dev reports a contradiction between artifacts and repository evidence.
• Scope expands, shrinks, or shifts across tasks or releases.
• A change affects release risk, compliance, security, privacy, data, permissions, API compatibility, or user-visible behavior.
• Multiple downstream artifacts or implementation tasks must be re-synchronized.

Do not use when

• No baseline or prior agreement exists and the user is still drafting requirements.
• A direct-dev bugfix or local task proceeds from a clear issue with no formal SDLC artifacts.
• The user asks for implementation, testing, review, or release publication.
• The change is only editorial and has no effect on scope, acceptance, downstream tasks, or traceability.
• The appropriate action is to write the missing artifact rather than record a change.

Inputs

Use available materials:

• original request or issue
• scope baseline
• BRD, URS, PRD
• SRS
• NFR
• SPEC slices
• dev handoff
• RTM
• readiness review
• implementation blocker report
• PR review finding
• release issue
• stakeholder decision
• repository evidence

If no formal baseline exists, state that this is not change control; route to the relevant authoring or dev skill.

Workflow

1. Determine whether change control applies

Ask:

Question	If yes
Was there a baseline, approved scope, SRS, SPEC, handoff, or task package?	change control may apply
Does the change affect requirement meaning, acceptance, validation, or release risk?	change control applies
Does the change only clarify wording without altering intent?	record as editorial update
Is this a direct-dev issue with no SDLC baseline?	route to dev or task handoff

Classify:

formal-change
editorial-update
implementation-blocker
scope-clarification
direct-dev-no-change-control

2. Capture change request metadata

Create a record:

Field	Required
Change ID	yes
Requested by	yes if known
Date	yes
Source artifact	yes when available
Current baseline	yes when available
Change type	yes
Reason	yes
Impact summary	yes
Decision owner	yes if known
Status	yes

Recommended status values:

proposed
accepted
rejected
deferred
needs-owner-decision
implemented
superseded

3. Classify change type

Use these types:

Type	Meaning
scope-addition	new behavior or requirement added
scope-removal	previous requirement removed
scope-shift	target behavior or user path changed
acceptance-change	validation or done criteria changed
nfr-change	performance, security, privacy, reliability, accessibility, compatibility, or operational requirement changed
spec-change	UI/API/Data/Permission/Admin/Directory/Release/etc. spec changed
implementation-blocker	repository evidence prevents implementation as written
release-risk-change	launch, rollback, migration, or support risk changed
editorial-update	wording changed without delivery impact

4. Assess impact

Assess impact across artifacts and execution.

Area	Impact
BRD / URS / PRD	business, user, product scope
SRS	functional or software requirement IDs
NFR	measurable quality constraints
SPEC	UI, API, data, permission, admin, directory, release, observability
Handoff	task cards, execution order, suggested agent, validation
RTM	source-to-task/test links
Dev work	changed files, in-progress tasks, PRs
Tests	planned, added, or invalidated tests
Release	rollout, rollback, support, documentation

Mark each item:

none
minor
material
blocking
unknown

5. Decide action

Choose one action:

Action	Meaning
accept-and-update	update affected artifacts and handoff
reject	keep baseline unchanged
defer	move change to future scope
split	separate into current and future changes
request-owner-decision	cannot decide from available evidence
route-to-dev-blocker	dev evidence blocks implementation; clarify or revise spec
direct-dev-no-control	change control is not needed

Do not silently accept scope expansion.

6. Update downstream map

If accepted, list required updates:

REQ IDs to update:
SPEC IDs to update:
NFR IDs to update:
Task cards to add/change/remove:
Validation to add/change/remove:
RTM rows to update:
Release notes / rollout notes to update:

If rejected or deferred, list what remains unchanged.

7. Preserve dev continuity

State whether dev can continue:

Dev status	Meaning
continue	change does not block current work
continue-with-limits	dev may continue unaffected tasks only
pause-affected-tasks	only affected tasks pause
pause-all	contradiction or scope change blocks all implementation
direct-dev	no formal baseline; dev can proceed from issue/task

This avoids unnecessary global stoppage.

8. Record traceability update

Every accepted material change should update traceability.

Add or update:

CHG-ID -> affected source IDs -> affected SRS/SPEC/NFR IDs -> affected TASK/TEST/PR/REL IDs

If traceability does not exist yet, create a traceability seed instead of blocking the change.

Output

Return or write a change record:

# Change Control Record: CHG-<ID>

## 1. Change Summary
## 2. Baseline or Source Artifact
## 3. Change Type
## 4. Reason
## 5. Impact Assessment
## 6. Decision
## 7. Required Artifact Updates
## 8. Dev Continuity
## 9. Traceability Update
## 10. Follow-up Actions

Use this decision block:

Decision: accept-and-update | reject | defer | split | request-owner-decision | route-to-dev-blocker | direct-dev-no-control
Reason:
Affected artifacts:
Affected dev tasks:
Dev continuity:
Traceability action:
Next skill / agent:

Validation

Before declaring change control complete, check:

• A baseline or source artifact was identified, or the record states why none exists.
• Change type is explicit.
• Impact assessment covers SRS, NFR, SPEC, Handoff, RTM, Dev, Tests, and Release when relevant.
• Decision is explicit and not hidden in prose.
• Accepted changes have downstream update actions.
• Rejected or deferred changes state what remains unchanged.
• Dev continuity is clear.
• Traceability is updated or explicitly seeded.
• Direct-dev tasks are not forced into formal change control when no baseline exists.

Boundaries

• Do not approve business decisions unless the user provides that decision.
• Do not edit code or execute implementation.
• Do not use change control for every direct-dev task.
• Do not turn editorial comments into formal scope changes.
• Do not accept scope expansion silently.
• Do not block unrelated dev tasks when only one task is affected.
• Do not rewrite all SDLC artifacts when only a targeted update is required.

Handoff

Route by decision:

Decision	Route
accept-and-update	update relevant authoring skill, then sdlc-requirements-traceability and sdlc-dev-handoff-planning
reject	return to current baseline and continue dev if ready
defer	record future scope and update RTM/deferred list
split	create current-scope and future-scope artifacts/tasks
request-owner-decision	ask for owner decision before dev continues affected tasks
route-to-dev-blocker	revise SRS/SPEC/handoff or route to repo evidence review
direct-dev-no-control	route to dev skill or direct task handoff