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.
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 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.
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:
/plan
enter planning modeThe 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.
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:
plan
mode and only reads filesThe 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.
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.
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.
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.
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.
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:
!
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.
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.
Here's the workflow I follow for every non-trivial feature in Achu:
/init
- add project context manually
/plan
in multiple turns until the spec is solid/context detail
regularly, /compress
proactively@
at source directories, not docs/remember
for anything that should persist/btw
without breaking flow/clear
/dream
to consolidate memory, /summary
to save the stateThis 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.