Qwen Code

Qwen Code's /fork, /skills, and Cross-Project Memory: Fixing an Agent's Daily Friction

Qwen Code v0.18.0-preview adds /fork background agents that inherit full context, a searchable lockable /skills panel, and user-level cross-project memory in one weekly update.

Qwen Code's /fork, /skills, and Cross-Project Memory: Fixing an Agent's Daily Friction — article cover
On this page6 SECTIONS
  1. /fork: Long Tasks Move to the Background, Context Inherited Whole
  2. /skills: From Memorized Names to a Searchable, Lockable Panel
  3. Cross-Project Memory: Routing Lives in a Prompt, Not Hardcode
  4. Other Improvements Worth Noting
  5. Builder Recommendations
  6. Sources

Use a coding agent long enough and three frictions surface fast: the main conversation gets occupied by long tasks, skills pile up until nobody remembers them, and every repo switch resets your preferences to zero. Qwen Code’s weekly update from June 11 — v0.18.0-preview, merging 50+ PRs — addresses all three at once. The headline features are /fork background tasks, the /skills management panel, and user-level cross-project memory, with an interactive /stats panel, sleep prevention, and an experimental workflow tool around the edges.

/fork: Long Tasks Move to the Background, Context Inherited Whole

Type /fork <instruction> and a background agent starts immediately, inheriting your complete working state: system prompt, conversation history, tools, model settings, and the prompt cache. It receives not a summary of your task but your current context itself. The main conversation stays unblocked; when the fork finishes, a notification arrives through the background task panel and the results are written to a JSONL transcript for later review.

The split from /branch is worth keeping straight: branch copies the current conversation into a new session for exploring a different direction; fork dispatches a background worker inside the current session, suited to independently verifiable subtasks like “add tests for this module” or “investigate this error first.” Multiple forks run in parallel, bounded by concurrency limits, and empty instructions or missing config return explicit error messages instead of failing silently.

The trade-off sits at file boundaries. If forks modify the same set of files, the waiting time you saved can be spent entirely on resolving conflicts. Parallelism changes the cost of waiting, not the discipline of acceptance — the task boundary and completion criteria for each fork still need to be thought through in advance.

/skills: From Memorized Names to a Searchable, Lockable Panel

Using a skill used to mean remembering its name; disabling one meant hand-editing settings.json. The new /skills opens a picker dialog: every skill listed with its name, description, and source level, searchable by keyword, toggled with the Space key, with Enter filling the command into the input box for execution.

The governance detail lives in scope. Disabled state writes to the workspace-level skills.disabled setting and takes effect in the current session immediately: the <available_skills> list and slash completions sync in real time, with no restart. If a skill is disabled at the user level, the workspace panel shows [locked: User] and the project level cannot override it. For team environments, this turns “which capabilities are available” from a verbal agreement into a governable settings layer — upper levels lock, lower levels adjust, and the permission direction is unambiguous.

Cross-Project Memory: Routing Lives in a Prompt, Not Hardcode

The new user-level memory directory ~/.qwen/memories/ sits alongside the project-level .qwen/memories/, closing the “agent forgets everything on repo switch” gap. The key design is the routing: it reuses the existing four memory categories, with routing rules written into the memory extraction agent’s prompt rather than hardcoded — user-type entries (personal preferences) always go to user level, project-type entries (deadlines, events) always stay at project level, with zero new configuration. The two middle categories get sensible defaults: feedback-type entries default to user level unless they encode explicitly project-specific conventions, while reference-type entries default to project level unless they name company-wide resources.

Both scope indexes are rendered into the system prompt: user level first as background information, project level after with more specificity, forming a natural general-to-specific ordering. Even when the user-level MEMORY.md is empty, a placeholder is still rendered so the agent knows the directory exists and is writable. The toggle reuses the existing memory.enableManagedAutoMemory — again, no extra setup, and the pragmatic bonus is migration cost: categories, the toggle, and the rendering mechanism all reuse the existing design, so you upgrade and go with no new config file to learn.

The trade-offs deserve honesty: routing decided by a prompt is not a deterministic rule and will occasionally misclassify; user-level memory accumulates stale preferences over time and deserves periodic human review. But the line is drawn in the right place — personal style travels across repos, while repo-specific information never leaks into the next workspace.

Other Improvements Worth Noting

/stats becomes an interactive three-tab panel, with usage data written to ~/.qwen/usage_record.jsonl at session end and on /clear — token counts, costs, and cache hit rates gain a reviewable history for the first time. System sleep prevention is on by default (general.preventSystemSleep: true), implemented with caffeinate on macOS, systemd-inhibit on Linux, and SetThreadExecutionState on Windows — a hibernating machine no longer interrupts long tasks. Skills’ declared allowedTools are now auto-authorized, so running a skill like /review no longer triggers a chain of permission prompts.

The experimental Workflow tool (P1) is opt-in and off by default:

QWEN_CODE_ENABLE_WORKFLOWS=1

Enabled via that environment variable, the model can write JavaScript inside a node:vm sandbox to orchestrate multiple subagents. The direction is interesting, but the project labels it experimental — production environments should watch for now.

Builder Recommendations

Three things you can do today: hand independently verifiable subtasks to /fork and keep the main conversation for work that needs your judgment; use /skills to disable skills you never touch and shorten the agent’s available-command list; teach the agent your preferences in any one repo and let user-level memory carry them into the next project. Fold the memory content into routine maintenance as well: review ~/.qwen/memories/ every so often, delete stale preferences, and re-file entries that were routed to the wrong scope. The three features look scattered but share one thesis: the productivity bottleneck of agents is shifting from model capability to management friction, and time (fork), capability (skills), and context (memory) now each have a governance surface of their own.

Sources

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.

SHAREXEMAIL