feat(docs): add qwen-code skills, agents, and updated AGENTS.md (#3575)

- Add new skills: bugfix, feat-dev with structured workflows
- Update existing skills: docs-audit-and-refresh, docs-update-from-diff,
  e2e-testing, qwen-code-claw, structured-debugging, terminal-capture
- Update test-engineer agent with clearer constraints and formatting
- Update qc commands: bugfix, code-review, commit, create-issue, create-pr
- Reorganize .gitignore to keep qwen configs near top
- Expand AGENTS.md with development commands, feature/bugfix workflows,
  project directories table, and code review guidelines

Co-authored-by: 愚远 <zhenxing.tzx@alibaba-inc.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

.qwen/skills/docs-update-from-diff/SKILL.md

@@ -1,15 +1,22 @@
 ---
 name: docs-update-from-diff
-description: Review local code changes with git diff and update the official docs under docs/ to match. Use when the user asks to document current uncommitted work, sync docs with local changes, update docs after a feature or refactor, or when phrases like "git diff", "local changes", "update docs", or "official docs" appear.
+description: Review local code changes with git diff and update the official
+  docs under docs/ to match. Use when the user asks to document current
+  uncommitted work, sync docs with local changes, update docs after a feature or
+  refactor, or when phrases like "git diff", "local changes", "update docs", or
+  "official docs" appear.
 ---
 
 # Docs Update From Diff
 
 ## Overview
 
-Inspect local diffs, derive the documentation impact, and update only the repository's `docs/` pages. Treat the current code as the source of truth and keep changes scoped, specific, and navigable.
+Inspect local diffs, derive the documentation impact, and update only the
+repository's `docs/` pages. Treat the current code as the source of truth and
+keep changes scoped, specific, and navigable.
 
-Read [references/docs-surface.md](references/docs-surface.md) before editing if the affected feature does not map cleanly to an existing docs section.
+Read [references/docs-surface.md](references/docs-surface.md) before editing if
+the affected feature does not map cleanly to an existing docs section.
 
 ## Workflow
 
@@ -17,30 +24,38 @@ Read [references/docs-surface.md](references/docs-surface.md) before editing if
 
 Start from local Git state, not from assumptions.
 
-- Inspect `git status --short`, `git diff --stat`, and targeted `git diff` output.
-- Focus on non-doc changes first so the documentation delta is grounded in code.
-- Ignore `README.md` and other non-`docs/` content unless they help confirm intent.
+- Inspect `git status --short`, `git diff --stat`, and targeted `git diff`
+  output.
+- Focus on non-doc changes first so the documentation delta is grounded in
+  code.
+- Ignore `README.md` and other non-`docs/` content unless they help confirm
+  intent.
 
 ### 2. Derive the docs impact
 
-For every changed behavior, extract the user-facing or developer-facing facts that documentation must reflect.
+For every changed behavior, extract the user-facing or developer-facing facts
+that documentation must reflect.
 
 - New command, flag, config key, default, workflow, or limitation
 - Renamed behavior or removed behavior
 - Changed examples, paths, or setup steps
 - New feature that belongs in an existing page but is not mentioned yet
 
-Prefer updating an existing page over creating a new page. Create a new page only when the feature introduces a stable topic that would make an existing page harder to follow.
+Prefer updating an existing page over creating a new page. Create a new page
+only when the feature introduces a stable topic that would make an existing page
+harder to follow.
 
 ### 3. Find the right docs location
 
 Map each change to the smallest correct documentation surface:
 
 - End-user behavior: `docs/users/**`
-- Developer internals, SDKs, contributor workflow, tooling: `docs/developers/**`
+- Developer internals, SDKs, contributor workflow, tooling:
+  `docs/developers/**`
 - Shared landing or navigation changes: root `docs/**` and `_meta.ts`
 
-If you add a new page, update the nearest `_meta.ts` in the same docs section so the page is discoverable.
+If you add a new page, update the nearest `_meta.ts` in the same docs section so
+the page is discoverable.
 
 ### 4. Write the update
 
@@ -63,11 +78,17 @@ Verify that the updated docs cover the actual delta:
 
 ## Practical heuristics
 
-- If a change affects commands, also check quickstart, workflows, and feature pages for drift.
-- If a change affects configuration, also check `docs/users/configuration/settings.md`, feature pages, and auth/provider docs.
-- If a change affects tools or agent behavior, check both `docs/users/features/**` and `docs/developers/tools/**` when relevant.
-- If tests reveal expected behavior more clearly than implementation code, use tests to confirm wording.
+- If a change affects commands, also check quickstart, workflows, and feature
+  pages for drift.
+- If a change affects configuration, also check
+  `docs/users/configuration/settings.md`, feature pages, and auth/provider docs.
+- If a change affects tools or agent behavior, check both
+  `docs/users/features/**` and `docs/developers/tools/**` when relevant.
+- If tests reveal expected behavior more clearly than implementation code, use
+  tests to confirm wording.
 
 ## Deliverable
 
-Produce the docs edits under `docs/` that make the current local changes understandable to a reader who has not seen the diff. Keep the final summary short and identify which pages were updated.
+Produce the docs edits under `docs/` that make the current local changes
+understandable to a reader who has not seen the diff. Keep the final summary
+short and identify which pages were updated.

.qwen/skills/docs-update-from-diff/references/docs-surface.md

@@ -4,36 +4,39 @@ Use this file to choose the correct destination page under `docs/`.
 
 ## Primary sections
 
-- `docs/users/overview.md`, `quickstart.md`, `common-workflow.md`
-  Good for entry points, first-run guidance, and broad user workflows.
-- `docs/users/features/*.md`
-  Good for user-visible features such as skills, MCP, sandbox, sub-agents, commands, checkpointing, and approval modes.
-- `docs/users/configuration/*.md`
-  Good for settings, auth, model providers, themes, trusted folders, `.qwen` files, and similar configuration topics.
-- `docs/users/integration-*.md` and `docs/users/ide-integration/*.md`
-  Good for IDEs, GitHub Actions, and editor companion behavior.
-- `docs/users/extension/*.md`
-  Good for extension authoring and extension usage.
-- `docs/developers/*.md`
-  Good for architecture, contributing workflow, roadmaps, and SDK overviews.
-- `docs/developers/tools/*.md`
-  Good for tool behavior, tool contracts, and implementation-facing explanations.
-- `docs/developers/development/*.md`
-  Good for contributor setup, deployment, tests, telemetry, and automation details.
+- `docs/users/overview.md`, `quickstart.md`, `common-workflow.md` Good for
+  entry points, first-run guidance, and broad user workflows.
+- `docs/users/features/*.md` Good for user-visible features such as skills,
+  MCP, sandbox, sub-agents, commands, checkpointing, and approval modes.
+- `docs/users/configuration/*.md` Good for settings, auth, model providers,
+  themes, trusted folders, `.qwen` files, and similar configuration topics.
+- `docs/users/integration-*.md` and `docs/users/ide-integration/*.md` Good for
+  IDEs, GitHub Actions, and editor companion behavior.
+- `docs/users/extension/*.md` Good for extension authoring and extension usage.
+- `docs/developers/*.md` Good for architecture, contributing workflow,
+  roadmaps, and SDK overviews.
+- `docs/developers/tools/*.md` Good for tool behavior, tool contracts, and
+  implementation-facing explanations.
+- `docs/developers/development/*.md` Good for contributor setup, deployment,
+  tests, telemetry, and automation details.
 
 ## Navigation rules
 
 - Root navigation lives in `docs/_meta.ts`.
 - Section navigation lives in the nearest `_meta.ts`, for example:
-  - `docs/users/_meta.ts`
-  - `docs/users/features/_meta.ts`
-  - `docs/developers/_meta.ts`
-  - `docs/developers/tools/_meta.ts`
-- If you create a page and do not add it to the right `_meta.ts`, the docs will be incomplete even if the markdown exists.
+- `docs/users/_meta.ts`
+- `docs/users/features/_meta.ts`
+- `docs/developers/_meta.ts`
+- `docs/developers/tools/_meta.ts`
+- If you create a page and do not add it to the right `_meta.ts`, the docs will
+  be incomplete even if the markdown exists.
 
 ## Placement heuristics
 
 - Put the change where a reader would naturally look first.
-- Update multiple pages when a single feature appears in setup, reference, and workflow docs.
-- Prefer adjusting a nearby existing page instead of creating a top-level page for a small delta.
-- Avoid duplicating long explanations across pages; add one source page and update nearby pages with short pointers if needed.
+- Update multiple pages when a single feature appears in setup, reference, and
+  workflow docs.
+- Prefer adjusting a nearby existing page instead of creating a top-level page
+  for a small delta.
+- Avoid duplicating long explanations across pages; add one source page and
+  update nearby pages with short pointers if needed.