# Feature Scaffold From Session

> Use when the user wants to turn one or more prior Codex sessions into a fresh feature workspace containing a targeted .codex control plane, AGENTS.md, and feature.md for a new planning cycle.

- Skill: `youguess21/feature-scaffold-from-session` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add youguess21/feature-scaffold-from-session`
- Raw SKILL.md: https://api.skillmd.com/api/skills/youguess21/feature-scaffold-from-session/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: YouGuess21 (https://skillmd.com/u/youguess21)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/youguess21/feature-scaffold-from-session

---


# Feature Scaffold From Session

This skill creates a new feature-workspace scaffold from prior Codex session history.

The intended output is a targeted planning control plane, that can transition to implementation and testing phases to become a finished automation framework. Aim is, in utopian scenario, with detailed feature.md and scaffold, the project can be automated end-to-end via iterative phases by codex within a planning prompt, implementation prompt loop, and validation prompt loop.

## Use This Skill When

- the user has already explored a feature in past Codex sessions
- the user wants a fresh directory that captures that work cleanly
- the user wants the initial phase only:
  - `.codex/`
  - `AGENTS.md`
  - `feature.md`

Do not generate later-phase files such as `design.md` as detailed design documentation, `tasks.md` as complete task breakdown, `testplan.md` as comprehensive test plan, or `progress_log.md` as progress log, these are to be generated by codex session later, and updated as needed.

## Required Inputs

- one or more session IDs
- target output directory

If the output directory is missing, ask for it.

## Workflow

1. Read the requested prior session or sessions.
2. Extract the feature goal, constraints, scope boundaries, terminology, relevant repos, and known risks.
3. Create a targeted workspace scaffold in the target directory.
4. Generate:
   - `AGENTS.md`
   - `context.md`
   - `feature.md`
   - `.codex/README.md`
   - `.codex/config.toml`
5. Generate `.codex/roles/` only if multiple distinct roles materially improve the workflow. Roles can be but are not limited to orchestrator/owner, context-mapper, designer, implemention_planner, tester, validator, critic all with feedback loops.
6. Generate `.codex/prompts/` only if multiple distinct prompts materially improve the workflow. Prompts can be but are not limited to planning, implementation, validation, etc, with explicit invocations for sub-agents. 
7. After you are done, HUMAN workflow should look like:
   - Review scaffold, and especially `feature.md`.
   - Start the planning phase in a codex session with this as working directory, project as a path argument instead in the prompt, by running the planning prompt, and then review the generate `design.md` , `tasks.md`, `testplan.md`, `progress_log.md`
   - Update `feature.md` as needed based on the planning phase outputs
   - Continue with implementation and testing phases

## Output Requirements

### `AGENTS.md`

Must define:

- the purpose of the folder
- which files to read first
- what later outputs are expected in future phases
- the workflow order
- scope expectations
- quality bar

### `context.md`

Must define:

- extracted context from the source sessions
- enough information along with `feature.md` so that human can start the planning phase in a codex session

### `feature.md`

Must define:

- summary
- required behavior
- constraints
- in-scope and out-of-scope items
- design expectations
- testing expectations
- expected deliverables for later phases

### `.codex/config.toml`

Keep it minimal and practical. It should describe:

- project name
- project root
- feature file location
- expected later outputs
- whether design should come before implementation

## Guardrails

- Preserve important technical constraints from the source sessions.
- Prefer explicit requirements over generic filler.
- Do not invent implementation certainty where the source sessions were still exploratory.
- Do not initialize git anywhere unless the user explicitly asks for that phase.
- Do not create a large framework. Create a clean starting workspace.

## Style

The scaffold should feel ready to use in another project:

- portable
- direct
- low ceremony
- concrete enough to guide the next Codex run