From codex-next
Assesses SDLC materials, specs, handoffs, issues, or direct-dev requests for readiness, revision need, or blockers before development proceeds.
How this skill is triggered — by the user, by Claude, or both
Slash command
/codex-next:sdlc-readiness-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this workflow to judge whether work is ready for the next delivery step.
Use this workflow to judge whether work is ready for the next delivery step.
This is a readiness check, not an enterprise approval board. It should make the next action clear:
ready-for-dev
ready-for-direct-dev
repo-onboarding-first
revise
change-control-needed
blocked
SDLC materials improve readiness, but they are not mandatory for every development task. Dev may continue without SDLC materials when the request is narrow, evidence is sufficient, risk is acceptable, and validation is clear.
Read available materials:
When no SDLC artifacts exist, inspect the issue/task evidence and decide whether direct dev is acceptable.
Classify the review target:
| Subject | Examples |
|---|---|
| requirements readiness | BRD, URS, PRD, scope baseline |
| software spec readiness | SRS, NFR, SPEC slices |
| handoff readiness | dev handoff, task cards, validation plan |
| traceability readiness | RTM or traceability seed |
| change readiness | change request, baseline update |
| direct-dev readiness | issue, bug report, user request, clear local task |
State the delivery profile and risk level if known.
Determine which source controls the work:
| Source | Status | Controls scope? | Notes |
|---|
Possible statuses:
draft
review-ready
baseline
change-pending
superseded
unknown
issue-only
repo-evidence-only
If sources conflict, do not choose silently. Report the conflict and recommend a resolution path.
A ready item must identify:
For direct-dev work, this may be expressed as:
Implement only the requested issue or observed failure.
Do not refactor unrelated architecture.
Do not change public behavior outside the stated path.
For SDLC-backed work, check:
| Area | Question |
|---|---|
| SRS | Are functional requirements numbered and testable? |
| NFR | Are quality constraints measurable or explicitly not applicable? |
| SPEC | Are UI/API/Data/Permission/Admin/Directory needs covered where relevant? |
| Handoff | Are task cards executable? |
| RTM | Can requirements trace to tasks and validation? |
| Change | Is baseline change controlled? |
For direct-dev work, check:
| Area | Question |
|---|---|
| issue clarity | Is the requested change understandable? |
| affected area | Is there a plausible repo area to inspect? |
| validation | Is there a smallest relevant check? |
| risk | Is risk acceptable without formal SDLC artifacts? |
| fallback | Can dev report blocker if repo evidence contradicts the request? |
Ready work must have at least one validation path.
Acceptable validation sources:
Do not require a full test plan for every direct-dev task. Require enough validation for the risk.
Use the appropriate traceability depth:
| Situation | Required traceability |
|---|---|
| direct-dev small task | source -> task -> validation seed |
| feature delivery | SRS/SPEC -> task -> validation |
| system delivery | source -> SRS/NFR/SPEC -> task -> test |
| program or compliance delivery | full RTM plus change and release evidence |
If traceability is absent but the task is safe for direct dev, mark it as an accepted direct-dev gap rather than blocking.
Use one verdict only:
| Verdict | Meaning |
|---|---|
ready-for-dev | SDLC-backed package is sufficient for dev execution |
ready-for-direct-dev | Formal SDLC materials are absent or unnecessary, but the task can proceed safely |
repo-onboarding-first | Dev can proceed after read-only repo mapping |
revise | Materials need revision before dev should start |
change-control-needed | Scope or baseline change requires change-control first |
blocked | Critical missing information or contradiction prevents safe execution |
Avoid vague results such as “mostly okay.”
The review must end with a concrete route:
Next skill:
Next agent:
Required artifact or task:
Risk if skipped:
Return a readiness review:
# SDLC Readiness Review: <Subject>
## 1. Review Subject
## 2. Source Authority
## 3. Scope and Non-scope Check
## 4. Completeness Check
## 5. Validation Check
## 6. Traceability Check
## 7. Risks and Gaps
## 8. Verdict
## 9. Next Action
Use this verdict block:
Verdict: ready-for-dev | ready-for-direct-dev | repo-onboarding-first | revise | change-control-needed | blocked
Reason:
Required before next step:
Can proceed without:
Must not skip:
Next agent / skill:
The Can proceed without line is important. It prevents the process from treating optional SDLC artifacts as mandatory blockers.
Before returning the verdict, check:
Route by verdict:
| Verdict | Route |
|---|---|
ready-for-dev | sdlc-dev-handoff-planning or dev implementation skill |
ready-for-direct-dev | dev skill such as dev-bugfix, dev-repo-onboarding, or dev-spec-driven-implementation |
repo-onboarding-first | dev-repo-onboarding |
revise | relevant authoring skill: sdlc-srs-workflow, sdlc-nfr-spec, sdlc-spec-slice-writer, sdlc-requirements-workflow |
change-control-needed | sdlc-change-control |
blocked | ask for required owner decision, missing input, or conflict resolution |
npx claudepluginhub blueskyxn/codex-is-all-you-need --plugin codex-nextConverts SDLC materials (SRS, NFR, HLD, LLD, ADRs, validation plans) into dev handoff packages and task cards for execution. Use when specifications need to become actionable implementation tasks.
Validates that work meets criteria before moving between SDLC phases. Implements gates for: Requirements → Design → Implementation → Testing → Deployment → Operations.
Provides DevOps review criteria for phase handoffs, deployment readiness, traceability, priority validation, and functional integration checks.