/feature-init

name: feature-init
description: Use when a new feature folder must be created for the DAE pipeline, or when discuss promotes/parks an idea. Triggers — "/engineer.feature-init", "create a feature", "start a new feature", "init a feature".

feature-init

Create a feature folder for the DAE pipeline — `feature.md` (the Ready contract), the folder, a branch, and a tracker entry. Checkpoint 1.5.

When to use

Five paths:

• **From `discuss`** — receives a `feature_intake` payload in context (park or promote outcome). No interview.
• **Standalone** — no payload; run the intake interview.
• **From a tracker capture** — promoting an untriaged row a human added directly to the tracker (no `Slug`; see *Tracker-as-intake* in `references/tracker.md`). Pre-fill intake from the row (its title → `title`/`outcome`, `Type`, any notes); confirm the rest. Reuse the row — don't create a new one (Step 9).
• **From a roadmap item** — promoting a strategic roadmap item (status `planned`) into a feature (typically from `next`'s ON THE ROADMAP bucket, or `discuss`). Pre-fill intake from the item (`title`, `area`, `notes`). Signalled by a `roadmap_ref` (the item `id`) passed in — carry it onto `feature.md` and mark the item in-progress (Step 9). See *the roadmap ↔ feature funnel* in `references/roadmap.md`.
• **Onboarding intake** — invoked by `onboard` (or directly) to formalize work that *already exists* in the codebase. The feature folder is reverse-engineered from an existing spec / branch / implementation. Enters at `status: in-progress` or `done`, not `ready`.

Detect from-discuss vs standalone by whether a `feature_intake` payload is present; a tracker capture is signalled by a slug-less `tracker_ref` passed in (typically from `next`); a roadmap promotion is signalled by a `roadmap_ref` (item id) passed in; onboarding intake is signalled by `onboard` (or an explicit "formalize existing feature" request).

**Not for:** brand-new ideas worth exploring first (`discuss`), or editing an existing feature (`feature-edit`).

Workflow

Before the steps below, create one TodoWrite todo per workflow step (the full list up front, as a roadmap). After Step 6 creates the feature folder, show the **pipeline breadcrumb**: run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_progress.py <feature-dir>` and present its output — for a just-initialized feature (no `progress.md` yet) it renders the pipeline ahead. The breadcrumb is advisory and never blocks. See `${CLAUDE_PLUGIN_ROOT}/references/progress-indicator.md`.

1. **Resolve** — resolve the methodology root + manifest via `${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py` (see `references/resolving.md`). Exit 2 (no manifest) → point to `/engineer.onboard`. 2. **Gather intake** — from-discuss: read the payload. From an `intent.md` (async originator, `${CLAUDE_PLUGIN_ROOT}/references/intent.md`): read it as the seed, synthesize the required fields from it, and confirm with the human before creating. Standalone: **first, project the path** (`${CLAUDE_PLUGIN_ROOT}/references/choice-points.md`) — read the idea, project size + clarity, and present the two funnel decisions as a **choice point** (recommend one, marked "(Recommended)", alternatives listed, `autonomy_level`-dialed default), not open questions: **(A) front half** — unclear/fuzzy/UX-heavy → recommend the **prototype-first path** (`${CLAUDE_PLUGIN_ROOT}/references/two-paths.md`): hand to `/engineer.prototype "<idea>"`, which iterates fast and converts to spec on convergence; shape known → spec-first. **(B) weight** — projected ~1-PR/low-risk → recommend **express (XS)** (`${CLAUDE_PLUGIN_ROOT}/references/express-lane.md`), else **full DAE**; charter-flagged path is never recommended express (safety wins). A `feature_intake`/handoff may already carry a projected `size` from `discuss` — use it, don't re-project. Only when the human takes the spec-first route, interview — required fields one per turn (`title`, `slug`, `outcome`, `source_links`, `status`, `autonomy_level` if `status` is `ready`/`in-progress`/`done`, `scope`), optional fields (`target`, `owner`, `area`, `relevant_adrs`, `tags`, `size`, `validation_method`, `assignee`) bundled at the end. **`validation_method`** is a one-line description of how this feature will be validated beyond the default (passing acceptance + unit + mutation); examples: "manual smoke in staging", "canary 5% prod for 24h, watch dashboard X", "feature flag `new_checkout`, internal users for 1 week". A high `autonomy_level` should be matched by an explicit non-default `validation_method`. **`assignee`** names who executes the next checkpoint — `human` | `local` | `cloud` (default `local`); it is orthogonal to `owner` (who is accountable). `cloud` requests cloud delegation, which the dispatch router still gates per-checkpoint via `dae_delegable.py` (see `references/handoff-dispatch.md`). Onboarding intake: reverse-engineer the fields from the existing spec / branch / commits; set `status` to `in-progress` or `done` per how complete the work is. 3. **Validate** — slug format (kebab-case, lowercase, ASCII, ≤50, leading letter); `autonomy_level` ∈ `manifest.autonomy.allowed_levels` and within path overrides; any `status` other than `parked` requires `autonomy_level`; `relevant_adrs` exist; `assignee` ∈ {`human`, `local`, `cloud`} if present. Slug collision: if existing feature is `parked` → offer promote-from-parked (flip status, keep handoffs); if `ready`/`in-progress` → redirect to `feature-edit`; if `done` → reject. 4. **Decomposition check** — if scope spans multiple competencies or sounds like several PRs, surface it; user proceeds as one feature or re-invokes per sub-feature with `parent_feature` set. 5. **Allocate number** — run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_feature_number.py <methodology_root>` and use the number it prints. Don't scan `features/` by hand — the script takes the max `NNN` across every git worktree (uncommitted folders included) and every local/remote branch, so num