Appendix B. Compatibility with Qwen Code

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 custom commands, skills, hooks, MCP servers, or regular scripts. This appendix fixes the boundary so the reader does not mistake a designed process for a standard CLI command.

Canonical Scale

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

The relationship with the four layers is as follows: built-in Qwen Code capabilities belong to Standard; custom commands and project scripts belong to Recommendation; the external orchestrator belongs to Frontier. If an example uses Kubernetes, Grafana, PagerDuty, or a separate file arbitration executor, this is the frontier layer of the learning 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 explicit launching of 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 custom command).
• /mcp and qwen mcp add — connecting MCP servers.
• @path — adding a file or directory to the context.
• !command — shell commands inside an interactive session.
• qwen -p "..." — headless launch for CI, batch checks, and scripts.

Custom Commands

If you want /specify, /tasks, /validate, /constitution, or similar commands, 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. The Markdown file stores a prompt with {{args}}, references to @specs/..., and stop rules.

The same approach is used for /clarify: 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, for the same scenario, create a project custom command (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 the 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 the official Qwen Code events: PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop, SubagentStop, Notification, PreCompact, and others. In the text of the second volume, use exactly these names, not free variants like pretooluse. Check the exact list of events and the 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 unrestricted 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 verification;
• separate write tools for safe actions;
• explicit confirmation and rollback conditions;
• prohibition on transmitting secrets in prompts, traces, and QWEN.md.

Terms of the Second Volume

| Verifier — votes | /review, a 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 | a separate Qwen session with safety_review or a project script that checks blast radius and rollback conditions | | Coordinator — non-voting protocolist | a person, a CI task, or an external orchestrator | | File arbitration (tribunal) | not a built-in command; a 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 | an external service or script; Qwen Code itself does not manage the daily tier quota |

Reference Links

The README of the applied volume 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