dev-feature

Use a scoped workflow: clarify only decisions that change the implementation, present a compact plan listing changes and tests, then implement directly. Reuse existing project utilities and avoid adding abstractions that serve only one caller.

Use dev-feature when the change spans multiple areas like API, storage, and tests and benefits from a short plan. Downgrade to dev-feature-lite when the behavior and implementation path are obvious and need no plan or user decision.

Escalate to dev-debug when the root cause is unknown, and to dev-problem-solving when multiple viable architectures exist or the user asks how something should be designed. State the escalation reason in one line.

Ask at most 3 questions in one batch, each with a recommended answer the user can approve with one word. Skip questions about facts findable in the codebase, existing conventions, or defaults with obvious answers.

Stop and tell the user before cutting scope. Never commit TODO stubs, placeholders, or unimplemented paths without explicit approval, and list any approved leftovers under Deferred in the final report.

No. Files outside the repo root given as samples or references are read-only inputs. Copy what you need into the project and adapt the copy; editing anything outside the repo requires explicit user confirmation.