# Feat Dev

End-to-end workflow for implementing a non-trivial qwen-code feature.

- Repository: https://github.com/QwenLM/qwen-code (28858 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add QwenLM/qwen-code --skill feat-dev -g -a claude-code -y`
Codex: `npx skills add QwenLM/qwen-code --skill feat-dev -g -a codex -y`
Cursor: `npx skills add QwenLM/qwen-code --skill feat-dev -g -a cursor -y`
Gemini CLI: `npx skills add QwenLM/qwen-code --skill feat-dev -g -a gemini-cli -y`

## 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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

Output: design doc on disk.

## Phase 3: Test Plan

Use the `e2e-testing` skill to choose test modes. Then write an E2E test plan
covering:

The rest: https://github.com/QwenLM/qwen-code/blob/HEAD/.qwen/skills/feat-dev/SKILL.md