---
name: codex-rdlc-wizard
description: Install or update Codex RDLC 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 RDLC files repaired.
---

# Codex RDLC Wizard

This skill wraps the bundled `install.sh` and `setup.sh` scripts in this repository.

Use it for:
- installing baseline Codex RDLC 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="xhigh"'` 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="xhigh"' <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 `\$rdlc` 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 RDLC entrypoint: `\$rdlc`. `/rdlc` is historical shorthand for the missing slash-command idea, not an invocation command.
   For setup/update bootstrap work, recommend the `maximum` profile via `--model-profile maximum` as the safer default. For routine work after bootstrap, point users back to the `mixed` profile via `--model-profile mixed` for the better speed / lower latency / lower token path with `xhigh` review.
   This repo always stays on `maximum` (`gpt-5.5` at `xhigh` throughout); when maintaining `codex-rdlc-wizard` itself, do not switch wizard-repo work to `mixed`, mini-only, or lower-reasoning profiles because the work is unusually meta.
   Interactive `setup` should ask for the profile when the user does not pass `--yes` or `--model-profile`, and it should recommend `maximum` as the bootstrap 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-rdlc-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.