New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Feature Development Workflow

by QwenLM in QwenLM/qwen-code

Phased workflow for non-trivial qwen-code features: investigate, design doc, E2E test plan, baseline dry-run, implement, verify, self-audit, review and iterate.

Apache-2.0Auto-check passedDevelopment

Install Feature Development Workflow

skills CLI
$ npx skills add QwenLM/qwen-code --skill feat-dev -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install QwenLM/qwen-code feat-dev --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/QwenLM/qwen-code.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.qwen/skills/feat-dev .claude/skills/feat-dev && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
feat-dev
GitHub stars
28k
Token cost
~1.2k tokens
SKILL.md length
653 words
Files
1
Skills in repo
41
Repo updated
First seen
Licence
Apache-2.0

At a glance

Phased workflow for non-trivial qwen-code features: investigate, design doc, E2E test plan, baseline dry-run, implement, verify, self-audit, review and iterate.

  • Works in 8 steps: Investigate → Design Doc → Test Plan → …
  • Implementing a qwen-code feature that touches several files
  • SKILL.md covers Artifact Paths, Phase 1: Investigate, Phase 2: Design Doc and Phase 3: Test Plan, plus 6 more sections
  • Calls npm and node

What it does

Each phase produces a concrete artifact and the phases are not merged. Investigation builds a mental model of current and desired behavior, constraints and key file paths, using a code exploration agent when available. The design doc covers the problem, proposed changes by component, key decisions, affected files, scope boundaries and open questions, and is saved under docs/design. The test plan uses the e2e-testing skill to choose test modes and groups tests by capability, with unique tmux session names and temp directories so groups can run in parallel.

A dry-run then validates the test plan against the baseline using the globally installed qwen CLI rather than the local build, with test-engineer agents handling independent groups when the runtime supports it. Because the feature does not exist yet, tests should fail or reveal the gap, and the plan is revised if commands or filters prove wrong. The description lists later phases of implementation, verification, self-audit, code review and iteration, which the excerpt does not show.

When your agent uses it

  • Implementing a qwen-code feature that touches several files
  • Writing a design doc before coding a feature
  • Planning E2E tests that can run in parallel groups
  • Validating a test plan against the baseline before implementing

Example prompts

  • “Run the feature workflow for adding a new parameter to the agent tool, starting with investigation.”
  • “Write the design doc for the session export feature under docs/design.”
  • “Draft the E2E test plan for the new command, grouped by capability, and dry-run it on the installed CLI.”
  • “Which test groups in the plan can run in parallel with separate test-engineer agents?”

Requirements

  • A checkout of the qwen-code repository
  • The globally installed `qwen` CLI for the dry-run

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Investigate
  2. Design Doc
  3. Test Plan
  4. Dry-Run
  5. Implement
  6. Verify
  7. Self-Audit and Code Review
  8. Wrap Up

What it can do on your machine

Read from SKILL.md and the folder at commit 4970bfa. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Feature Development Workflow loads about 1.2k tokens when it runs. Until then it costs about 57 tokens; SKILL.md has 653 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~57
When it runs · the whole SKILL.md, loaded when a task matches
~1.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from QwenLM/qwen-code at commit 4970bfa, republished under its Apache-2.0 licence (© QwenLM). 653 words, ~1,217 tokens.

Download SKILL.mdSave it as .claude/skills/feat-dev/SKILL.md (or your agent's skills folder).
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.

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:

  • Test groups by capability: parameter acceptance, core behavior, error handling, cleanup, and regressions.
  • Exact commands and expected behavior before and after implementation.
  • Unique tmux session names and temp dirs for independent groups.
  • Which groups can be run in parallel by separate test-engineer agents.

Output: test plan on disk.

Phase 4: Dry-Run

Validate the test plan against the current baseline using the globally installed qwen CLI, not the local build.

Spawn test-engineer agents for independent test groups when the runtime supports it. The feature is not implemented yet, so tests should either fail or show the gap. Iterate the test plan if the dry-run reveals broken commands, wrong filters, or false positives.

Output: confirmed-working test plan with accurate pre-implementation baseline.

Phase 5: Implement

Read the relevant source files before editing. Implement the changes described in the design doc and follow project conventions:

  • ESM and strict TypeScript.
  • Prettier formatting.
  • Collocated tests next to source.
  • No speculative abstractions beyond the design.

After implementation:

bash
npm run build
npm run typecheck
npm run bundle

Also run focused unit tests for changed files from the relevant package directory.

Output: local implementation that builds and passes focused tests.

Show full SKILL.md (242 more words)Show less

Phase 6: Verify

Run the full E2E test plan against the local build with node dist/cli.js. Spawn independent test-engineer agents when useful and available.

If tests fail, diagnose, fix, rebuild, re-bundle, and re-test until all groups pass.

Output: E2E results appended to the test plan.

Phase 7: Self-Audit and Code Review

First self-audit the full diff per the self-audit step in AGENTS.md's General workflow (open-ended passes plus presume-wrong verification, until two consecutive clean passes). If the audit changes source, return through Phases 5-6 before resuming it. Then run /review with a review task listing all changed files. Triage each comment before acting:

  • Valid: real bug or meaningful improvement. Fix it.
  • False positive: reviewer missed context. Skip it.
  • Overthinking: technically plausible but not worth the complexity. Skip it.

After fixes, re-run unit tests and a quick E2E sanity check.

Output: clean implementation with valid review findings addressed.

Phase 8: Wrap Up

Skip unless the user asks. Create the branch, commit with Conventional Commits, push, and create a draft PR using the project PR template. Post E2E results as a separate PR comment when applicable.

Iteration Rules

  • If Phase 6 fails, return to Phase 5 and then re-run Phase 6.
  • If Phase 7 finds valid issues, fix them, run a quick Phase 6 sanity check, and re-run the self-audit.
  • Do not loop more than 3 times between Phases 5-7 without asking the user.
  • If the test plan is inaccurate, update it and document why.

© QwenLM, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .qwen/skills/feat-dev of QwenLM/qwen-code.

Open the folder on GitHubat commit 4970bfa

Compare with similar skills

Feature Development Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Feature Development Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Feature Development Workflow this skillQwenLM/qwen-code28k—~1.2kAutomated safety check: PassApache-2.0
QAdutradotdev/quokka108—~1kAutomated safety check: PassMIT
Alefxberg-io/alef100—~1.7kAutomated safety check: PassMIT
Interactive Implementation Plannerjumppad-labs/jumppad263—~5.6kAutomated safety check: WarnMPL-2.0
Engineering Plan Reviewgarrytan/gstack136k—~13kAutomated safety check: NotesMIT
Drive MiMo CodeXiaomiMiMo/MiMo-Code14k—~3.9kAutomated safety check: PassMIT

Similar skills

  • QA

    dutradotdev/quokka

    Run quokka's real-device E2E layer (QA strategy layer 5): drive the real qk binary against connected iPhone/Android devices through tmux, apply deterministic verifiers, and write a report.

    108 GitHub stars~1k tokensUpdated 2 mo ago
    Testing & QAAuto-check passed

  • Alef

    xberg-io/alef

    Use Alef correctly for Rust-to-polyglot binding generation. An agent skill from xberg-io/alef.

    100 GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed

  • Interactive Implementation Planner

    jumppad-labs/jumppad

    Builds detailed implementation plans through interactive questions, parallel research agents and template files for context, research, plan and tasks, from an issue or a plan name.

    263 GitHub stars~5.6k tokensUpdated 5 days ago
    DevelopmentAuto-check: warnings

  • Engineering Plan Review

    garrytan/gstack

    Reviews an execution plan or design doc before coding, covering architecture, data flow, edge cases, test coverage and performance, one issue at a time.

    136k GitHub stars~13k tokensUpdated today
    DevelopmentAuto-check: notes

  • Drive MiMo Code

    XiaomiMiMo/MiMo-Code

    Lets one MiMoCode process drive another, headless with JSON events or interactively through tmux, to test behavior and visual regressions with parseable evidence.

    14k GitHub stars~3.9k tokensUpdated 4 days ago
    Testing & QAAuto-check passed

  • Senpi Agent QA Harness

    code-yeongyu/senpi

    Checks changes to the senpi coding agent by driving the real CLI from source in an isolated sandbox, over RPC, terminal UI, mock model and CLI smoke channels.

    470 GitHub stars~2.7k tokensUpdated today
    Testing & QAAuto-check: notes

More from QwenLM/qwen-code

All 41 skills in this repo

  • Agent Feature Reproduction

    QwenLM/qwen-code

    Reproduces a feature from Codex or Claude Code in Qwen Code by running the reference agent under capture, reading the traces, then implementing matching behavior.

    28k GitHub stars~1.5k tokensUpdated today
    Auto-check passed

  • Qwen Code E2E Testing

    QwenLM/qwen-code

    Guides end-to-end testing of the Qwen Code CLI in headless mode with real model calls, MCP test servers and inspection of raw API traffic.

    28k GitHub stars~2.1k tokensUpdated today
    Auto-check passed

  • Repo Hygiene Scan and Fix

    QwenLM/qwen-code

    Scheduled CI skill that scans a repository for small, certain docs, test and code hygiene issues and fixes them on one branch with a commit per finding.

    28k GitHub stars~1.7k tokensUpdated today
    Auto-check passed

  • Qwen Code Desktop Brand Builder

    QwenLM/qwen-code

    Builds a rebranded Qwen Code desktop package from the Tauri shell using only a brand id and a logo, with sensible derived defaults.

    28k GitHub stars~2.1k tokensUpdated today
    Auto-check passed

  • Qwen Code Memory Leak Debugger

    QwenLM/qwen-code

    Walks through capturing and comparing V8 heap snapshots to find memory leaks in the Qwen Code Node.js CLI, using tmux and the chrome-devtools CLI.

    28k GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • tmux Real User Testing

    QwenLM/qwen-code

    Drives Qwen Code in a real tmux session the way a user would and saves a readable step-by-step transcript of each screen for maintainers to review.

    28k GitHub stars~2.3k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Feature Development Workflow

What does Feature Development Workflow do?

Phased workflow for non-trivial qwen-code features: investigate, design doc, E2E test plan, baseline dry-run, implement, verify, self-audit, review and iterate. Each phase produces a concrete artifact and the phases are not merged. Investigation builds a mental model of current and desired behavior, constraints and key file paths, using a code exploration agent when available.

When should I use Feature Development Workflow?

Feature Development Workflow fits situations like: implementing a qwen-code feature that touches several files; writing a design doc before coding a feature; planning E2E tests that can run in parallel groups; validating a test plan against the baseline before implementing.

How do I install Feature Development Workflow in Claude Code?

Run `npx skills add QwenLM/qwen-code --skill feat-dev -a claude-code`. Or copy the skill folder (.qwen/skills/feat-dev in QwenLM/qwen-code) into .claude/skills/feat-dev in your project. Claude Code loads it when a task matches its description.

How do I install Feature Development Workflow in Codex?

Run `npx skills add QwenLM/qwen-code --skill feat-dev -a codex`. Or copy the skill folder (.qwen/skills/feat-dev in QwenLM/qwen-code) into .agents/skills/feat-dev in your project. Codex loads it when a task matches its description.

Can I use Feature Development Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add QwenLM/qwen-code --skill feat-dev -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/feat-dev, .gemini/skills/feat-dev, .github/skills/feat-dev and .opencode/skills/feat-dev in your project.

What does Feature Development Workflow need to run?

Going by SKILL.md and its folder, Feature Development Workflow needs the command-line tools its instructions call (npm and node). Our summary lists: A checkout of the qwen-code repository; The globally installed `qwen` CLI for the dry-run.

Does Feature Development Workflow access the network?

SKILL.md contains no URLs. Its commands use npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Feature Development Workflow safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Feature Development Workflow use?

Feature Development Workflow is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Feature Development Workflow use?

About 1.2k tokens (SKILL.md is roughly 4.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Feature Development Workflow?

Skills that share tags, products or a category with Feature Development Workflow: QA (dutradotdev/quokka, 108 stars), Alef (xberg-io/alef, 100 stars), Interactive Implementation Planner (jumppad-labs/jumppad, 263 stars) and Engineering Plan Review (garrytan/gstack, 136k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Feature Development Workflow?

QwenLM (a GitHub organization) maintains it in QwenLM/qwen-code, which has 28,337 GitHub stars. The repository holds 41 skills in this directory. The repository was last updated on October 7, 2026.

Source: QwenLM/qwen-code on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.