Skill v1.0.1
LLM-judged scan95/100+1 new
version: "1.0.1" 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
Three paths:
- From `discuss` — receives a
feature_intakepayload 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 atstatus: in-progressordone, notready.
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 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.
- Resolve — resolve the methodology root + manifest via
${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py(seereferences/resolving.md). Exit 2 (no manifest) → point to/engineer.onboard. - Gather intake — from-discuss: read the payload. Standalone: interview — required fields one per turn (
title,slug,outcome,source_links,status,autonomy_levelifstatusisready/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 flagnew_checkout, internal users for 1 week". A highautonomy_levelshould be matched by an explicit non-defaultvalidation_method. `assignee` names who executes the next checkpoint —human|local|cloud(defaultlocal); it is orthogonal toowner(who is accountable).cloudrequests cloud delegation, which the dispatch router still gates per-checkpoint viadae_delegable.py(seereferences/handoff-dispatch.md). Onboarding intake: reverse-engineer the fields from the existing spec / branch / commits; setstatustoin-progressordoneper how complete the work is. - Validate — slug format (kebab-case, lowercase, ASCII, ≤50, leading letter);
autonomy_level∈manifest.autonomy.allowed_levelsand within path overrides; anystatusother thanparkedrequiresautonomy_level;relevant_adrsexist;assignee∈ {human,local,cloud} if present. Slug collision: if existing feature isparked→ offer promote-from-parked (flip status, keep handoffs); ifready/in-progress→ redirect tofeature-edit; ifdone→ 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_featureset. - Allocate number — scan
features/for maxNNN, +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 Speckitspecs/NNN-slug/keeps itsNNN; do not renumber. - Create —
features/NNN-<slug>/withfeature.md(per the Foundation Design feature.md schema), emptyhandoffs/, empty.build/. Add.build/to.gitignore. Includebranch: <name>infeature.mdfrontmatter — the slug for greenfield; the adopted branch for onboarding intake. This is read by${CLAUDE_PLUGIN_ROOT}/scripts/dae_branch.pyat every later checkpoint's Step 0 to enforce branch hygiene. If avalidation_methodwas provided in the intake, include it in the frontmatter too — downstream skills (plan,consistency-check) consume it. Do NOT createprogress.md/acs.md/spec.md/plan.md/session-log.md— downstream skills produce those. - Branch — auto-create
git checkout -b <slug>unlessCHARTER.mddeclares 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 ifmanifest.validation.lsp.serversis absent (the project hasn't done the LSP probe yet —onboard's gap-check will catch it). - Tracker — upsert a
TrackedFeaturevia the driver perreferences/tracker.md(local= thedae_tracker_local.pyno-op;notion= the connected Notion MCP); write the returned ref tofeature.mdtracker_ref. - Handoff — emit a summary.
Handoff
Emit per ${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md. checkpoint: 1.5; recommended_next: ready → "/engineer.prime-context then /engineer.discover-acs"; parked → "resume via /engineer.discuss <slug>"; onboarding intake → "/engineer.discover-acs (reverse-engineer mode)".
If folder + feature.md succeed but branch or tracker fails, emit status: interrupted noting what's incomplete.
References
- Foundation Design — feature.md schema, storage layout, naming
- Discuss & Upstream Funnel — the
feature_intakecontract from discuss references/tracker.md— the tracker drivers (local + Notion)