codex-sdlc-wizard

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:

1. If the user wants the simplest install, run the bundled install.sh from this skill bundle against the current working repo.
2. 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.
3. Tell the user exactly which path you chose: install.sh for baseline enforcement, setup.sh for adaptive setup.
4. 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.
5. 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.
6. 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.
7. 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.