From codex-next
Manages baseline and scope changes, artifact updates, traceability impact, approvals, and handoff revisions in SDLC workflows.
How this skill is triggered — by the user, by Claude, or both
Slash command
/codex-next:sdlc-change-controlThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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 available materials:
If no formal baseline exists, state that this is not change control; route to the relevant authoring or dev skill.
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
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
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 |
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
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.
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.
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.
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.
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:
Before declaring change control complete, check:
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 |
npx claudepluginhub blueskyxn/codex-is-all-you-need --plugin codex-nextAuthors a Change Management (CHG) record to classify change level, route by source to the entry gate, assess cross-layer cascade impact, and register the change. Use when modifying an existing SDD artifact across any of the 8 layers.
Breaks requirement changes into ordered actionable tasks with Pharaoh workflow enforcement and dependency ordering for sphinx-needs projects.
Handles mid-track requirement changes by analyzing impact on spec, plan, HLD, LLD, and code before proposing amendments. Useful when scope shifts during active development.