| 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 plugin -> feature-init skill", "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
Three paths:
- From
discuss — receives a feature_intake payload in context (park or promote outcome). No interview.
- Standalone — no payload; run the intake interview.
- 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; 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 Codex plan item per workflow step (the full
list up front, as a roadmap). After Step 6 creates the feature folder, show the
pipeline breadcrumb: run
${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
${PLUGIN_ROOT}/references/progress-indicator.md.
- Resolve — resolve the methodology root + manifest via
${PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md). Exit 2 (no manifest) → point to engineer plugin -> onboard skill.
- Gather intake — from-discuss: read the payload. Standalone: 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) 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. 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.
- 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. 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.
- 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.
- Allocate number — scan
features/ for max NNN, +1, 3-digit zero-padded. (Parallel runs may race — solo work won't hit it.) Onboarding intake exception: inherit the existing number — a feature migrated from a Speckit specs/NNN-slug/ keeps its NNN; do not renumber.
- Create —
features/NNN-<slug>/ with feature.md (per the Foundation Design feature.md schema), empty handoffs/, empty .build/. Add .build/ to .gitignore. Include branch: <name> in feature.md frontmatter — the slug for greenfield; the adopted branch for onboarding intake. This is read by ${PLUGIN_ROOT}/scripts/dae_branch.py at every later checkpoint's Step 0 to enforce branch hygiene. If a validation_method was provided in the intake, include it in the frontmatter too — downstream skills (plan, consistency-check) consume it. Do NOT create progress.md/acs.md/spec.md/plan.md/session-log.md — downstream skills produce those.
- Branch — auto-create
git checkout -b <slug> unless CHARTER.md declares a manual git policy. If the branch already exists (common in onboarding intake — the feature's work is already on a branch) → use it, don't recreate.
- LSP language note — if the feature touches a language not present in
manifest.validation.lsp.servers, surface a one-line note ("this feature is mostly Rust — no LSP server recorded for Rust; LSP-backed lookup will fall back to grep+AST"). Inform-only; never blocks. Skip if manifest.validation.lsp.servers is absent (the project hasn't done the LSP probe yet — onboard's gap-check will catch it).
- Tracker — upsert a
TrackedFeature via the driver per references/tracker.md (local = the dae_tracker_local.py no-op; notion = the connected Notion MCP); write the returned ref to feature.md tracker_ref.
- Handoff — emit a summary.
Handoff
Emit per ${PLUGIN_ROOT}/references/handoff-summary.md. checkpoint: 1.5; recommended_next: ready → "engineer plugin -> prime-context skill then engineer plugin -> discover-acs skill"; parked → "resume via engineer plugin -> discuss skill "; onboarding intake → "engineer plugin -> discover-acs skill (reverse-engineer mode)".
If folder + feature.md succeed but branch or tracker fails, emit status: interrupted noting what's incomplete.
References
