| name | feat-dev |
| description | End-to-end workflow for implementing a non-trivial qwen-code feature. Covers requirements investigation, design, E2E test planning, baseline dry-run, implementation, verification, self-audit, code review, and iteration. |
Feature Development Workflow
Use this workflow when implementing a feature in qwen-code that needs design,
behavioral validation, or coordinated changes across multiple files. Each phase
produces a concrete artifact. Do not combine phases; the output of each phase
feeds the next.
Artifact Paths
Use these paths for planning artifacts:
docs/design/<feature>.md
.qwen/e2e-tests/<feature>.md
Phase 1: Investigate
Understand the requested behavior and the current qwen-code implementation.
Use a code exploration agent when available. Ask it to inspect the relevant
qwen-code areas for:
- Existing feature definitions: tools, parameters, schemas, commands, UI, or
config.
- Runtime wiring: spawning, lifecycle, state, permissions, hooks, and cleanup.
- Edge cases and error handling.
- Integration points and limitations.
In parallel, inspect docs, issues, tests, and nearby implementations that define
or constrain the expected behavior. If no exploration agent is available, do the
same investigation locally.
Output: mental model of current behavior, desired behavior, constraints, and key
file paths with line numbers.
Phase 2: Design Doc
Write a design doc covering:
- Problem statement and current state, including the behavior gap.
- Proposed changes by layer or component.
- Key design decisions and rationale.
- Files affected.
- Scope boundaries.
- Open questions.
Use prose, tables, and bullets. Avoid code snippets unless essential for a key
data structure. JSON config examples are acceptable.