April 2026

It also fixes font drift, overflow issues, border artifacts, and layout regressions that quietly ruin otherwise good work. Less patching after generation. Less CSS babysitting. Less rendering surprise. More range. Better paper for AI-native writing.

kami.tw93.fun/

This release also sharpens /write, adds Evaluation Mode to /think, compresses /health from 181 lines to 121 with every check intact, and rewrites all skill descriptions for better auto-routing across all 8 skills. I’ll attach the image below.

github.com/tw93/waza

Pake is the mom. She turns web apps into desktop apps and helps good products ship.

MiaoYan is the older brother. A native macOS Markdown editor for writing, thinking, and notes.

Waza is the older sister. A skill system that turns AI workflows into daily habits.

Kami is the younger sister. A design system that makes AI-written documents clear and beautiful.

Mole is the family pet. A Mac cleaning tool that digs out junk and keeps things tidy.

Which member did you meet first?

Meet the family: github.com/tw93

Another piece of good news: Mole Desktop has made obvious progress recently. It’s getting closer and closer.

github.com/tw93/mole

Of course, if you want to see the actual kami design system website, you can go here. kami.tw93.fun/index-en.html

Here’s what matters:

· mo clean now supports cleanup for AI coding agents, including Claude Code, Cursor, Windsurf, Cline, and Aider. It also respects your whitelist more consistently and adds cleanup for unavailable Xcode simulators.

· Scan speed is faster for common 50-500 item cleanup batches, thanks to a better path deduplication pipeline.

· mo optimize now starts almost instantly, with the old 6-second startup delay removed. Disk verify is also disabled by default to avoid unnecessary sudo prompts and slow checks.

· mo uninstall is safer by default. App removals now go through Trash first, with --permanent available when you really want direct deletion. A new --list flag also makes installed app inventory easier.

· mo analyze and mo purge are more stable on huge directory trees, with fixes for worker pool exhaustion, better throttling, and artifact age shown during selection.

There are also smaller fixes for stale Homebrew taps, Touch ID detection, launch daemon matching, deletion logging, CJK alignment, and a new mo analyse alias.

Swift is not a flashy release. It is mostly about faster scans, safer cleanup, fewer hangs, and better coverage for the tools developers actually use every day.

If Mole helps, I’d love your ideas on where to dig deeper for safe cleanup and more hidden junk.

Each line is a planet. Each planet is one of Mole's jobs, clean, uninstall, optimize, analyze, monitor. The Mac client has a small Easter egg that ties them all together.

One thing that really separates serious AI coding from shallow usage is how people use AI to work through problems that have stayed unresolved for a long time. The difference in debugging approach is usually very obvious. It is also one of the reasons experienced engineers can use AI to solve much more complex problems than people who do not have the same technical depth.

I kept running into the same pattern before. Claude Code would hit a problem and produce a patch. You would say it did not work, and it would offer another one. Four or five rounds later, new issues would appear. It was patching without ever diagnosing the real cause, which felt a lot like how junior engineers debugged before AI existed.

The core rule in /hunt is simple: until the AI can explain the root cause in one clear sentence, it is not allowed to touch the code. That sentence also has to be precise. It cannot be vague. It has to identify the cause in a concrete way.

I also built a “self-deception checklist” to stop the model from falling into common forms of self-justification. Each pattern has its own rule, and the gotchas section contains real cases. I keep updating and abstracting those examples from issues I have investigated over the past month.

The hypothesis validation stage also has real work attached to it. The model is expected to add new observation methods, such as logs, assertions, or a minimal failing test case. If the issue still remains after a fix, it should switch approaches quickly. Instead of trying endless patches, it should prepare a handoff that clearly states what was checked, which directions were investigated, and what is still unknown, so the user can decide how to proceed.

The output is structured as well: where the root cause is file:line, what changed file:line, what evidence shows the issue is fixed, and what the test results look like. The final status has only three valid outcomes: resolved, resolved with caveats, or blocked.

That is really what /hunt is trying to become: something closer to an experienced engineer. When a problem shows up, it does not guess. It slows down, finds the actual cause, diagnoses it clearly, and then solves it in one focused pass. In practice, that usually saves a lot of time.

And if you have better debugging methods, I would love to hear them, or see a PR. github.com/tw93/waza

The second is that I usually run Claude Code with alias c="claude --dangerously-skip-permissions". I would not recommend that to less technical users. I use it because I know what it is doing, and mostly because I am lazy.

Back to /think. How do you get the strongest model to produce better technical plans? It starts with the model itself. Models tend to avoid taking a position. I prefer engineers who can give a clear recommendation. So the first thing I do is require the model to have a point of view. It must state its recommendation, explain what evidence could overturn it, and avoid empty lines like “There are many ways to think about this.” Giving two or three options is fine, but it has to make a clear recommendation, and it must always include a minimal option.

But a plan is not done just because it sounds good. The second step is to make it argue against itself. Under what conditions would this plan fail? If those problems can be fixed, the fixes should be folded back into the plan and the revised version presented again. If the plan breaks under certain conditions, it has to say exactly where and why it fails. That way, by the time the plan reaches you, the tradeoffs are already visible.

I also go fairly deep on validating the premises before planning starts. First, it checks whether it is even looking at the right part of the codebase. I have seen models produce plans against the wrong path. Then it looks for older technical design docs to avoid reinventing work that already exists. After that, it searches GitHub to see whether similar problems have already been solved elsewhere. Only after those three steps does it start proposing solutions. That helps prevent the entire plan from being built on a bad assumption.

There is also complexity grading. If the work touches more than eight files or introduces a new service, the plan must explicitly call out the scale. If data flows across more than three components, it has to draw an ASCII diagram and look for cycles. API keys and third-party dependencies also have to be listed during the planning phase, so you do not waste time or end up with a plan that depends on shaky assumptions.

There is one more hard rule. The plan cannot contain things like TBD, TODO, “we can decide this later,” or vague phrases like “similar to step N.” That goes back to model behavior again. Once you leave that kind of escape hatch, execution tends to drift, skip work, or fill in the blanks poorly. I try not to leave the model any room to wiggle out of precision.

The output format is also strict: what we are doing, what we are not doing, which option was chosen and why, three to five decision factors, and a clear list of unknowns. /think does not write code. Execution only starts after the user approves the plan.

When I built this skill, I was really trying to capture how strong technical experts approach solution design: investigate first, form a clear recommendation, make decisions decisively, leave no loose ends, and improve the plan immediately when something invalidates it.

If you have better ideas for planning and solution design, feel free to contribute to Waza.
github.com/tw93/waza

What I find interesting is that it is less about chat and more about setting something up once and letting it keep working for you in the background. For recurring work like this, that model makes much more sense to me. Sharing a short video here as well to show the setup and result flow more clearly.
app.emergent.sh/landing/wingman

So /check was never designed as one giant all-in-one reviewer. It is a review orchestration system with clear division of responsibility. The main SKILL.md acts as the lead reviewer, handling review levels and process control. Under agents/, there are independent specialists such as a security reviewer and an architecture reviewer, each focused on its own domain. Which specialist gets involved is decided by an activation rule set, not the keyword matching approach many people use.

The review tiers are also intentional. For changes under 100 lines, it runs a fast review. For changes between 100 and 500 lines, it brings in specialists when needed. For changes above 500 lines, it activates the full review path and adds an adversarial testing round. That round looks for failure modes from four angles: broken assumptions, problems that appear only under combined failures, errors in cross-layer integration, and abuse or misuse scenarios.

Findings are then handled in four levels. Safe and obvious fixes can be applied directly. Issues that are mostly clear but still worth confirming are packaged for you to review. Cases that require judgment are escalated to you. Lower-priority observations are still surfaced, but /check does not interrupt you for every minor issue, and it does not overstep into changing behavioral logic on its own.

There is also one hard rule: if verification has not run, the task is not complete. /check includes a probing script that detects project types such as Cargo, TypeScript, and Python, then runs the appropriate validation flow. If it cannot detect the project type, it fails explicitly instead of pretending everything passed.

The result is something closer to an experienced technical reviewer: different strategies for different change sizes, explicit specialist involvement, and a stronger definition of what “done” actually means. I just tried to distill those engineering habits into a simple and reusable skill inside Waza.

And if you have better ideas for code review workflows, I’d love contributions to Waza. PRs are welcome.
github.com/tw93/waza

So I took the UI work I’ve made recently and had Claude Code study the way I prompt, refine, and correct design output. That became a base layer of design best practices and anti-patterns. On top of that, I pulled in the useful parts of Claude’s frontend design skill, which gave the whole thing a stronger foundation.

For more specific rules, I learned a lot from pbakaus/impeccable. It contributed many of the concrete constraints: banned font lists, color system guidance, theme direction, CSS anti-patterns, animation rules, and other details that help the model build a more reliable sense of visual taste.

I also borrowed part of the structure from getdesign, especially its simplified adaptation of Google Stitch’s nine-part scaffold. That gave /design a clearer knowledge framework instead of just a loose collection of tips.

The last piece is context. Before using this skill, I ask a few questions first: who the page is for, what aesthetic direction you want, what you want users to remember, what you definitely do not want, and what kind of micro-interactions should define the experience. Once Claude Code has that context along with /design, the results are usually much better, with far less iteration.

If you have strong design ideas, better rules, or useful references, feel free to contribute to Waza. PRs are welcome. Let’s build the most useful skill library for engineers together.
github.com/tw93/waza

A few things have worked well for us: keeping every SKILL.md short, splitting Write for exactly that reason, adding “not for” negative examples to reduce false activation, listing all skills in CLAUDE.md, and keeping descriptions under 1024 characters. These are small constraints, but they seem to improve activation quite a bit.

One issue we did find is that descriptions should be written in third person. The official docs call this out as important for routing, and it matches the examples they give. So instead of starting with imperative wording like “Use when…”, it is better to start with a capability statement first, then the trigger condition. For example: “Extracts text and tables from PDF files, fills forms, and merges documents. Use when working with PDF files or when the user mentions PDFs.” Small detail, real difference.

When Superpowers first came out, I installed it once and then removed it. It felt too heavy and wasn’t really for me. Quite a few people kept recommending it to me, like “Do you know Superpowers? If you’re not using it, you’re not really keeping up. It’s insanely good.” Later I found gstack, which was better, but still too much, and I still couldn’t get used to it. What I wanted was something simple and useful, while also being clear about what it was doing.

So I made Waza around my own habits. For me, installing this set is enough. I don’t need to keep messing with more skills. It has just the right amount, not more, not less. And when new iterations come later, I can keep improving it over time. These 8 skills correspond to what I think are the 8 abilities a good engineer should have in the AI era:

1. Thinking. AI writes code very fast, but if the direction is wrong, the faster it goes, the further off it gets. A good engineer questions the problem itself before starting, stress-tests the plan, and gets the architecture clear in their head before letting AI execute. /think turns that habit into something fixed.

2. Design. Building a product is not just about making the feature work. Things generated by AI can easily end up looking all the same. A good engineer should have taste and standards for what gets delivered, and the output should have a clear design direction. That is what /design is for.

3. Troubleshooting. When AI fixes bugs, it easily falls into a loop of “change something and try again.” A good engineer approaches problems systematically, finds the root cause first, and then fixes it properly in one go. I turned that habit into /hunt.

4. Checking. Code generated by AI needs human review even more. Before merging, review the diff first, automatically fix what can be fixed, group together the parts that need judgment, and validate with evidence instead of relying on gut feeling. That is /check.

5. Reading. Good engineers are used to reading primary sources instead of secondhand summaries. Turn a URL or PDF into clean Markdown and bring it directly into the workflow. That is what /read does.

6. Writing. No matter how strong your technical skills are, if you cannot explain things clearly, other people will not receive it. A good engineer can clearly communicate what they have learned and what they want to express to the right audience. /write helps you do that.

7. Learning. In the AI era, technology moves faster. Entering an unfamiliar field is not just about reading a few articles. It is about collecting, digesting, outlining, drafting, polishing, and publishing, using output to drive learning. /learn is that whole process.

8. Maintaining. A good engineer does not only focus on business code. The toolchain itself also needs regular checkups. When CLAUDE.md, rules, hooks, or MCP configurations start to feel off, running /health helps you quickly see where the problem is.

github.com/tw93/Kaku