Codex Project Intake
Goal
Turn a fresh or inherited repository into a clear working system with the right project docs, state files, risk notes, and next step, while minimizing token waste and dead ends.
When to use
Use this skill when you need to start a project from scratch, rescue an existing one, or re-establish control after the repo has drifted.
When not to use
Do not use this skill for a tiny isolated change when the relevant files are already obvious.
Inputs
AGENTS.md and any nested agent instructions.docs/CODEBASE_INDEX.md or the closest equivalent.docs/CODEX_STATE.md, docs/PLANS.md, and docs/DECISIONS.md if they exist.- The package manifest, entry points, and top-level folder scan.
docs/EFFICIENCY_SYSTEM.md and templates/project/EFFICIENCY_RUN.json for large or ambiguous work.
Workflow
- Detect the repo root and read project instructions before editing.
- Identify stack, package manager, major folders, and command surface.
- Decide whether the repo is a fresh bootstrap or an in-progress takeover.
- Create or update the project index, state, plan, and decision files.
- For new projects, establish the minimal operating scaffold and confirm the first safe task.
- For existing projects, map the current shape, identify drift, and choose the smallest useful recovery step.
- If the work is large or uncertain, run the efficiency benchmark workflow to compare baseline and treatment.
- Validate only what the change touches.
- Report what changed, what remains risky, and what to do next.
Quality bar
- The next action must be obvious after the intake pass.
- The repo should end with a durable state, not just a chat summary.
- The plan should be small enough to execute and specific enough to avoid wandering.
- The user should know whether the repo is ready to start work or needs recovery first.
Validation
- Run the narrowest useful validation for the files changed.
- Run benchmark comparison commands when efficiency claims are involved.
- Run secret scanning and artifact checks when instructions, templates, or examples changed.
Final response
Report the project type, current shape, next step, validation commands, and the main risks or unknowns.
1---2name: codex-project-intake3description: Use this when starting a new project or taking over an existing one and you need a repeatable bootstrap and recovery workflow.4---56# Codex Project Intake78## Goal910Turn a fresh or inherited repository into a clear working system with the right project docs, state files, risk notes, and next step, while minimizing token waste and dead ends.1112## When to use1314Use this skill when you need to start a project from scratch, rescue an existing one, or re-establish control after the repo has drifted.1516## When not to use1718Do not use this skill for a tiny isolated change when the relevant files are already obvious.1920## Inputs2122- `AGENTS.md` and any nested agent instructions.23- `docs/CODEBASE_INDEX.md` or the closest equivalent.24- `docs/CODEX_STATE.md`, `docs/PLANS.md`, and `docs/DECISIONS.md` if they exist.25- The package manifest, entry points, and top-level folder scan.26- `docs/EFFICIENCY_SYSTEM.md` and `templates/project/EFFICIENCY_RUN.json` for large or ambiguous work.2728## Workflow29301. Detect the repo root and read project instructions before editing.312. Identify stack, package manager, major folders, and command surface.323. Decide whether the repo is a fresh bootstrap or an in-progress takeover.334. Create or update the project index, state, plan, and decision files.345. For new projects, establish the minimal operating scaffold and confirm the first safe task.356. For existing projects, map the current shape, identify drift, and choose the smallest useful recovery step.367. If the work is large or uncertain, run the efficiency benchmark workflow to compare baseline and treatment.378. Validate only what the change touches.389. Report what changed, what remains risky, and what to do next.3940## Quality bar4142- The next action must be obvious after the intake pass.43- The repo should end with a durable state, not just a chat summary.44- The plan should be small enough to execute and specific enough to avoid wandering.45- The user should know whether the repo is ready to start work or needs recovery first.4647## Validation4849- Run the narrowest useful validation for the files changed.50- Run benchmark comparison commands when efficiency claims are involved.51- Run secret scanning and artifact checks when instructions, templates, or examples changed.5253## Final response5455Report the project type, current shape, next step, validation commands, and the main risks or unknowns.
YankielDBC2