Appendix B. Qwen Code Compatibility

The second volume describes production processes around Qwen Code. Some of these processes are built into Qwen Code, while others need to be implemented in the project as user commands, skills, hooks, MCP servers, or regular scripts. This appendix defines the boundary so that the reader does not mistake a designed process for a standard CLI command.

Canonical Scale

The second volume uses three maturity levels. This is not a quality assessment of the idea, but a boundary of expectations from the reader.

The mapping to the four layers is as follows: built-in Qwen Code capabilities belong to Standard; user commands and project scripts belong to Recommendation; external orchestrator belongs to Frontier. If an example uses Kubernetes, Grafana, PagerDuty, or a separate file tribunal executor, this is the frontier layer of the teaching model, not a mandatory requirement for completing the volume.

Built-in Qwen Code Layer

Use these capabilities as-is:

• /plan — planning mode without edits and shell execution.
• /review — built-in code review with deterministic checks and parallel review agents.
• /skills — viewing and explicitly running skills.
• /memory, /remember, /forget — memory management and QWEN.md (/dream as an explicit consolidation command may appear in later versions; if it is not in your release, formalize consolidation as a user command).
• /mcp and qwen mcp add — connecting MCP servers.
• @path — adding a file or directory to context.
• !command — shell commands within an interactive session.
• qwen -p "..." — headless launch for CI, batch checks, and scripts.

User Commands

If you want commands like /specify, /tasks, /validate, /constitution or similar, create them explicitly:

.qwen/
  commands/
    sdd/
      specify.md
      tasks.md
      validate.md
      constitution.md

Then the commands will be invoked as /sdd:specify, /sdd:tasks, /sdd:validate, /sdd:constitution. Inside the Markdown file is a prompt with {{args}}, references to @specs/... and stop rules.

Similarly, /clarify is formalized: in the first volume this command was used as a requirements clarification step before planning, but it is not built into Qwen Code. In the second volume, create a project user command for the same scenario (for example, .qwen/commands/sdd/clarify.md), which is invoked as /sdd:clarify. Define the behavior and stop contract in the prompt so that the /clarify step from the first volume is reproduced without implicit assumptions.

Project Scripts

Checks that must be reproducible without a model should be formalized as regular scripts:

scripts/
  spec_ci/
    check_coverage.py
    validate_schema.py
  stress_mutator/
    mutate_specs.py
    fake_validator.py
    immunity_score.py
  tribunal/
    run_duel.py
    check_invariants.py

write_judgment.py
  budget/
    compile.py
    simulate.py
    inspect.py

Qwen Code can help write and run such scripts, but the green status should depend on the check code, not on the persuasiveness of the model's response.

Hooks

For guardrails, use official Qwen Code events: PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop, SubagentStop, Notification, PreCompact and others. In the second volume text, use exactly these names, not free variants like pretooluse. Check the exact list of events and configuration format against the current Qwen Code documentation (see links at the end of the appendix).

MCP and External APIs

Production APIs should not become unlimited shell commands. For Grafana, PagerDuty, Kubernetes, Jira, or internal APIs, it is better to make an MCP server with an allowlist of tools:

• read-only for triage and checks;
• separate write tools for safe actions;
• explicit confirmation and rollback conditions;
• prohibition on passing secrets in prompts, traces, and QWEN.md.

Second Volume Terms

| Verifier — votes | /review, separate Qwen session, sub-agent, or project script | | Implementor — votes | Qwen Code in default/auto-edit mode after an approved plan | | Safety — votes with veto on critical_risk | separate Qwen session with safety_review or project script checking blast radius and rollback conditions | | Coordinator — non-voting protocolist | human, CI task, or external orchestrator | | File tribunal | not a built-in command; combination of /review, scripts, reports, and rules in validation.md | | Spec gateway (Spec CI) | GitHub Actions or local scripts that may use qwen -p only as an auxiliary layer | | Budget keeper | external service or script; Qwen Code does not itself manage daily tier quota |

Reference Links

The applied volume README is kept as a short route map, so external sources are collected here.

• Qwen Code commands: https://qwenlm.github.io/qwen-code-docs/en/users/features/commands/
• Qwen Code headless mode: https://qwenlm.github.io/qwen-code-docs/en/users/features/headless/

• Qwen Code hooks: https://qwenlm.github.io/qwen-code-docs/en/users/features/hooks/
• Qwen Code skills: https://qwenlm.github.io/qwen-code-docs/en/users/features/skills/
• Qwen Code memory: https://qwenlm.github.io/qwen-code-docs/en/users/features/memory/
• Qwen Code MCP: https://qwenlm.github.io/qwen-code-docs/en/users/features/mcp/
• Qwen Code approval mode: https://qwenlm.github.io/qwen-code-docs/en/users/features/approval-mode/
• Qwen Code code review: https://qwenlm.github.io/qwen-code-docs/en/users/features/code-review/
• GitHub Spec Kit: https://github.com/github/spec-kit
• AWS Kiro documentation overview: https://aws.amazon.com/documentation-overview/kiro/
• OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Google SRE book: https://sre.google/sre-book/
• Goodhart's law: https://en.wikipedia.org/wiki/Goodhart%27s_law