How I Use Qwen Code Slash Commands to Build Achu App

In this blog post, we will see how I use Qwen Code's slash commands and workflow strategies to build Achu my screenshot beautifier app without burning through tokens or losing context mid-session.

If you haven't heard of Achu, it's a desktop app built with Electron + React + TypeScript. It does screenshot beautification, Privacy Guard (offline OCR redaction), Auto-Vibe (palette-extracted backgrounds), and an AI Bug Agent with GitHub integration. It's a side project I'm genuinely proud of, and Qwen Code has become my go-to agentic coding CLI for it.

A developer shares their day-to-day workflow for using Qwen Code, an open-source agentic coding CLI, to build Achu, a desktop screenshot beautification app built with Electron, React, and TypeScript. The post covers how slash commands like /init, /plan, /compress, /remember, and /btw are used to manage context, reduce token costs, and maintain consistent output across sessions.

The core approach centers on spec-driven planning through iterative /plan sessions before any code is written, combined with parallel subagents for independent tasks and strict context hygiene using /compress and /clear. Additional practices include pointing the model at library source code instead of documentation and using /remember to persist architectural decisions across sessions.

This isn't a tutorial about what Qwen Code is. It's about how I actually use it day-to-day, the slash command tricks I rely on, and the discipline it takes to get real work done with an LLM in a terminal.

It all started with Google Antigravity, but the 5 hours reset and weekly limits is killing my productivity and thinking flow. I had to switch to more affordable and open source model where I chose Qwen.

Why Qwen Code?

I've tried Claude Code, Gemini CLI, and a bunch of others. Qwen Code is open source, has excellent subagent support, a rich slash command system, and Qwen Max is genuinely strong at reasoning through complex TypeScript and Electron internals.

My go-to model is Qwen Max. For lighter tasks like /recap or prompt suggestions I set a fast model with /model --fast qwen3-coder-flash to keep costs down.

The /init and Project Context Setup

The very first thing I do when I start on a new project or return to Achu after a few days is run:

/init

This analyzes the current directory and generates an initial context file essentially giving Qwen Code a map of the project. It picks up folder structure, key files, and creates a baseline understanding before I say a single word.

After /init, I manually add a few paragraphs about the project. I treat this like writing a team onboarding doc for a new developer. I tell Qwen what Achu is, what the current milestone is, what tech stack we're on, and what the known constraints are (like Electron IPC boundaries, the Upstash Redis integration, or the Gumroad-based monetization model).

This upfront investment saves enormous amounts of back-and-forth later.

Spec-Driven Planning with /plan

When I want to build a new feature, I don't just dump a vague request and hope for the best. I use /plan to switch Qwen Code into planning mode.

/plan Implement the Privacy Guard redaction pipeline

In plan mode, Qwen analyzes and thinks, but does not touch any files. This is key. It's the agentic equivalent of "think before you act."

What I actually do is run multiple turns in plan mode to iterate the spec. I think of a "spec" as the formal artifact that describes what should be built the interface contracts, the data flow, the error paths, the acceptance criteria. It's not a vague idea. It's something precise enough that a developer (or subagent) could implement it.

The loop looks like this:

1. /plan enter planning mode
2. Describe the feature in detail what it does, what it doesn't do, edge cases
3. Ask Qwen to propose an approach
4. Push back on anything that doesn't fit the architecture
5. Ask for the revised plan
6. Repeat 2-3 times until the spec is solid

The quality of implementation is almost entirely determined by the quality of the spec. This multi-turn refinement before a single line of code is written is the most valuable habit I've developed using any agentic coding tool.

By default, Qwen will ask followup questions. But it is always recommended to tell the model to ask questions.

Subagents for Async Work

Once the spec is locked in, I use subagents aggressively for any work that can happen independently.

Qwen Code's subagent system lets you define specialized agents as Markdown files in .qwen/agents/. Each agent has its own system prompt, tool allowlist, and model. You can call them explicitly or let Qwen delegate automatically.

For Achu, I have a few custom subagents:

• A testing subagent focused on Vitest and Electron testing patterns (more on this below)
• A code reviewer subagent that runs in plan mode and only reads files

The key power here is Fork Subagents when Qwen needs to run multiple things in parallel, it can implicitly fork. Forks inherit the parent context, run in the background, and share the prompt cache prefix. This means if I ask Qwen to "investigate the IPC handler for Privacy Guard, the Ollama integration, and the Upstash Redis voting flow simultaneously," it can fork three parallel agents without tripling my token costs.

I explicitly phrase tasks as:

"Run these three investigations in parallel using subagents and report back."

This keeps the main conversation focused and lets the grunt work happen concurrently.

A project-level subagent config lives at .qwen/agents/testing.md and looks like this:

---
name: testing
description: "Writes Vitest unit tests and Electron integration tests for Achu. Use PROACTIVELY for any test-related tasks."
approvalMode: auto-edit
tools:
  - read_file
  - write_file
  - read_many_files
  - run_shell_command
---

You are a testing specialist for an Electron + React + TypeScript app.
Follow Vitest conventions. Mock Electron IPC using vitest-mock-extended.
Always write both positive and negative test cases.

The phrase "Use PROACTIVELY" in the description is important it signals to the main model to delegate testing tasks here without being asked explicitly.

Context Hygiene: /summary, /compress, and /clear

This is where most people fail with long agentic sessions. They let the context grow unbounded until the model starts hallucinating, forgetting earlier instructions, or producing inconsistent output. I've learned to treat context like memory on a constrained machine.

My hygiene rules:

After a major chunk of work is done:

/summary

This generates a project summary from the conversation history. I save this externally and reference it when restarting sessions.

When the context window is getting full:

/compress

This replaces chat history with a compressed summary, freeing up tokens while preserving the semantic essence of what was discussed. Think of it as a lossy but practical checkpoint.

When Qwen starts steering away:

If the model starts going off-track giving answers that don't match the project constraints, suggesting patterns we've already ruled out, or just losing the thread. I don't argue. If it happens twice in a row, I clear:

/clear

Then I reload context from scratch using /init and a fresh description. Two drifts is my hard limit. The discipline here is resisting the urge to keep "fixing" a bad session. It's cheaper to restart clean.

Watching Context and Usage with /context and /stats

I watch these two commands constantly.

/context

Shows a breakdown of what's consuming the context window right now system prompt, conversation history, tool results. If I see tool results bloating the context, I know a /compress is coming.

/context detail

Shows per-item breakdown. Useful when one massive file read is eating 40% of the window.

/stats

Gives detailed session statistics tokens used, API calls, cost estimates. I check this before and after big operations. It's how I keep tabs on spend, especially on Qwen Max which isn't the cheapest model.

Keeping an eye on these is the agentic equivalent of watching memory usage in a production system. Ignore it and you'll pay for it.

Pointing to Source Directories Instead of Docs

This one is a significant productivity trick that I don't see talked about enough.

When Qwen needs to understand a third-party library, the default approach is to tell it to fetch the docs URL. The problem is that docs are often incomplete, outdated, or optimized for humans rather than LLMs.

What I do instead: I download the library source and point the conversation directly at it using @:

@./vendor/upstash-redis/src Tell me how the pipeline API works

Or with a deeper path:

@./node_modules/@electron/remote/src/main Explain the context bridge setup

Qwen reads the actual implementation. No guessing from docs. No hallucination about API signatures that changed in the last major version.

I keep a vendor/ folder in the project root where I clone or copy source for critical dependencies. This makes @ references stable and reproducible.

For Achu specifically, I've pointed Qwen at the Ollama TypeScript client source, the llava-phi3 model integration code, and parts of the Electron forge config. The answers I get are ground-truth accurate instead of approximately correct.

Persistent Memory with /remember and /dream

Some things should survive session boundaries. My preferences, key architectural decisions, constraints Qwen needs to always respect. I use /remember for these.

/remember Always use Electron's contextBridge for IPC. Never use remote module.
/remember Achu uses oklch color space. Do not suggest hex values without conversion.
/remember Free tier users get 3 exports per day. Pro users are unlimited.

These get persisted in Qwen's memory store and are injected into future sessions automatically.

/dream is the manual trigger for auto-memory consolidation. Qwen's auto-memory runs in the background, but if I want to force a consolidation pass after a long session to make sure the important discoveries from the current session get persisted I run:

/dream

Think of it as flushing the cache to disk before shutting down.

To review and manage what's been remembered, I use:

/memory

This opens the Memory Manager dialog where I can edit or delete entries. I audit this occasionally. Stale memories can be just as harmful as no memories.

The /btw Trick for Side Questions

This is my favourite quality-of-life command.

/btw What's the difference between contextBridge.invoke and contextBridge.exposeInMainWorld?

/btw sends a parallel API call with recent conversation context (up to the last 20 messages) and shows the response above the composer without touching the main conversation at all. The main session continues uninterrupted.

I use this constantly for:

• Quick clarifications while in the middle of implementation
• Checking a TypeScript type signature without derailing a planning session
• Double-checking a shell command before running it via !

The response doesn't become part of conversation history. It's a throwaway lookup. This is genuinely useful and I'm surprised more CLI tools don't have something like it.

Uncommon Commands Worth Knowing

Beyond the commands I use daily, here are a few from the docs that are genuinely underrated:

/restore

Restores files to their state before a tool execution. If a Qwen action made a mess, you can list recent tool executions with /restore and roll back a specific one with /restore <ID>. Think of it as a targeted undo for AI changes.

/loop

Runs a prompt on a recurring schedule:

/loop 5m check the build output and report any new warnings

I use this occasionally when I'm doing a long build and want Qwen to monitor for me while I do something else. It's a lightweight cron for conversational tasks.

/recap

Generates a one-line summary of where the session left off. If I step away for more than five minutes, Qwen auto-triggers this when I return:

? Implementing the Privacy Guard redaction pipeline. Next step: wire the OCR output into the bounding-box overlay renderer.

Incredibly useful for picking up after an interruption without scrolling through history.

/approval-mode auto-edit

Once I trust the current task scope, I switch to auto-edit to let Qwen make file changes without prompting me every time. I reserve yolo mode for throwaway branches only.

/directory

Adds multiple directories to the workspace context:

/dir add ./src,./tests,./electron

Useful when the feature spans multiple root-level directories that Qwen wouldn't automatically scope to.

My Qwen Code Workflow Summary

Here's the workflow I follow for every non-trivial feature in Achu:

1. Start clean /init + add project context manually
2. Spec first use /plan in multiple turns until the spec is solid
3. Delegate async tasks use subagents for parallel investigations and implementation
4. Monitor context /context detail regularly, /compress proactively
5. Log source truth point @ at source directories, not docs
6. Remember decisions /remember for anything that should persist
7. Quick questions /btw without breaking flow
8. Clear if it drifts two steering-away moments is my hard limit for /clear
9. End of session /dream to consolidate memory, /summary to save the state

This isn't magic. It's discipline. The LLM doesn't make you disciplined you have to bring that yourself. But when you apply this workflow consistently, the output quality is noticeably better than freeform chatting with an AI.

If you're building something with Qwen Code, try the spec-first approach. The twenty minutes you spend in /plan mode iterating the spec will save you three hours of correcting implementation drift.

Happy Agentic Coding, Testing, Shipping, Learning, whatever :) !

What's your biggest challenge with agentic coding workflows staying in context, or getting the model to follow architectural constraints? Let me know in the comments.