Menu
Analyze phase. Turns scope.md and design.md into readiness.md with traceability, truths, build order, and scope-risk checks before BUILD.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Audit preferences.md stack choices against input docs for orthodox, idiomatic fit. Use before /expand when you want to validate that your technology choices match the problem domain.
Execute BUILD, ITERATE, or verify-fix work in small, test-first vertical slices. Use for multi-file implementation, failing tests, root-cause debugging, scope-creep risk, or when maintainability matters.
Build phase. Takes scope.md, design.md, and readiness.md and writes the actual code, tests, and deployment config in vertical slices.
Deploy phase. Push to the deployment target, verify it's live, write README and DELIVERY.md.
Design phase. Takes scope.md and produces design.md with architecture, directory structure, interfaces, integration details, and justified complexity exceptions.
Distill raw input materials into structured reference docs. Use when docs/input/ contains messy client briefs, API specs, meeting notes, or domain knowledge that needs structuring before EXPAND.
| name | analyze |
| description | Analyze phase. Turns scope.md and design.md into readiness.md with traceability, truths, build order, and scope-risk checks before BUILD. |
Custom agent: This workflow is normally driven by the
Lights Out SWE: Analyzecustom agent. Switch to that agent (or run from the main agent if the dropdown is unavailable) before executing the steps below.
Read scaffolding/scope.md and scaffolding/design.md. Produce scaffolding/readiness.md.
ANALYZE is the pre-BUILD admission gate. BUILD should start only after the plan is concrete enough that each AC-* has:
scaffolding/scope.md fullyscaffolding/design.md fullypreferences.md if it existsdocs/input/ materials when they materially affect acceptance criteria meaning, integrations, or constraintsscaffolding/readiness.md with these exact sections:# Readiness: [Project Name]
## Verdict
[READY / NOT READY]
## Truths
- [T-1] [Non-negotiable statement that must be true in the shipped system]
## Key Links
- [L-1] [AC-*] -> [design component or interface] -> [planned test or artifact] -> [runtime proof]
## Acceptance Criteria Coverage
| AC ID | Build Slice | Planned Test | Planned Runtime Proof | Notes |
| ----- | ----------- | ------------ | --------------------- | ----- |
## Scope Reduction Risks
- [Risk that could tempt BUILD to ship a shell, placeholder, or weakened behavior. If none, write "None."]
## Clarifications Needed
- [Question or bounded assumption that still matters for truthful delivery. If none, write "None."]
## Build Order
1. [AC-*] [Why it goes first]
## Complexity Exceptions
- [Justified exception carried forward from design.md, or "None."]
Run the post-analyze gate:
scaffolding/readiness.md existsVerdict of READYAC-* from scope.md appears in Acceptance Criteria CoverageAC-* has a planned test and planned runtime proofTruths and Clarifications Needed are separatedScope Reduction Risks is explicit (it may say None.)Build Order covers all AC-* itemsComplexity Exceptions is explicit (it may say None.)If any gate condition fails, fix it and recheck.
Log the result to scaffolding/log.md:
## ANALYZE — [timestamp]
- **Gate**: PASS (attempt N)
- **Evidence**: [which AC IDs were traced, what truths and risks were captured]
- **Changes**: scaffolding/readiness.md created
- **Retries**: [total gate attempts this phase]
- **Next**: BUILD
Git checkpoint:
git add -A && git commit -m "docs(analyze): prepare build readiness for [project]" -m "[summarize AC coverage, truths, and build order]\nGate: post-analyze PASS (attempt N)."
Auto-continue to BUILD (unless user specified stepped mode).
Scope Reduction Risks or Clarifications Needed.AC-*, the verdict is NOT READY until the scope is corrected.