| name | codex-sdlc-wizard |
| description | Install or update Codex SDLC enforcement in the current repository. Use when the user wants this wizard set up as Codex hooks/docs, wants adaptive setup, or needs the generated Codex SDLC files repaired. |
Codex SDLC Wizard
This skill wraps the bundled install.sh and setup.sh scripts in this repository.
Use it for:
- installing baseline Codex SDLC enforcement into the current repo
- running adaptive setup that scans the repo and generates docs
- reapplying or repairing the generated Codex hook/config files
Use the bundled scripts like this:
- If the user wants the simplest install, run the bundled
install.sh from this skill bundle against the current working repo.
- If the user wants repo-aware setup or regenerated docs, run the bundled
setup.sh --yes from this skill bundle against the current working repo.
- Tell the user exactly which path you chose:
install.sh for baseline enforcement, setup.sh for adaptive setup.
- After installation, tell the user to start a fresh Codex session so hooks and repo docs are loaded cleanly. Recommend plain
codex for the first live setup handoff unless the user explicitly chooses full-trust; recommend codex -m <model> -c 'model_reasoning_effort="high"' as the current explicit start mode after setup is complete and the guardrails are loaded. If a handoff was interrupted and Codex printed a resume id, recommend codex resume -m <model> -c 'model_reasoning_effort="high"' <session-id> for model-explicit continuation. Mention plain codex or codex resume <session-id> as the config-driven fallback for daily work. For yolo-style sessions, use the canonical full-trust flag --dangerously-bypass-approvals-and-sandbox; current Codex may accept --yolo as shorthand, but full-auto is not full-trust.
The fresh session should also pick up the repo-scoped \$sdlc skill under .agents/skills. Repo-scoped skill coverage is still a work in progress; additional workflow names should stay out of public handoff copy until their contracts are ready.
Canonical SDLC entrypoint: \$sdlc. /sdlc is historical shorthand for the missing slash-command idea, not an invocation command.
For install/setup/update and normal meaningful SDLC work, default to the maximum profile via --model-profile maximum. Sol high is the normal standing root driver, and the consumer default for agentic coding is Sol high. mixed is an experimental explicit opt-in that maps to gpt-5.6-terra at medium with a gpt-5.6-sol review whose reasoning must be explicitly overridden to high; it exists for measured speed, latency, or token-efficiency trials. Preserve an existing explicit selection, but do not recommend or select it automatically. Escalate security review, migrations, destructive operations, long-running research, or difficult coding to xhigh when high leaves unresolved risk. Use Terra or gpt-5.6-luna only for bounded low-risk support work with an explicit verification boundary, not as the normal SDLC driver.
Max is a single-task reasoning escalation; Ultra is a subagent-backed parallel-work escalation. Most tasks do not need Max or Ultra, and neither belongs in default wizard profiles.
This repo always stays on maximum (gpt-5.6-sol at xhigh throughout); when maintaining codex-sdlc-wizard itself, do not switch wizard-repo work to mixed, Terra, Luna, or lower-reasoning profiles because the work is unusually meta. This is a measured maintainer exception, not the consumer default.
Interactive setup should ask for the profile when the user does not pass --yes or --model-profile, and it should recommend maximum as the normal Sol-high default.
- For auth-heavy Windows / WAM / MFA flows, say plainly that the live sign-in remains user-owned, while Codex still owns command shape, checks, and the verify/resume path after the user completes sign-in.
- For update requests, explain the version boundary: update repairs repo artifacts using the package or skill version invoked; it does not self-update npm. To consume the newest npm release, use
npx codex-sdlc-wizard@latest update.
- For auth / license-sensitive repos, encourage a repo-local capability detector such as
doctor, check-capability, or Test-*Access.ps1 so Codex can start from one-command classification instead of raw provider commands.
Rules:
- Do not invent a second installer path when the bundled scripts already do the job.
- Prefer
install.sh unless the user asks for adaptive setup or the repo clearly needs generated docs.
- Preserve existing user files; the installer path is intentionally non-destructive.
- When debugging an install problem, inspect
.codex/config.toml, .codex/hooks.json, and AGENTS.md in the target repo first.
- Present auth boundaries as workflow ownership, not as refusal language.
- Treat account, license, tenant, and permission state as setup signals when a repo is capability-sensitive.
