Skill to make you slow, but to go fast

Here's one skillsets I want to share.

kination / slow-slow-quick-quick

Skills for slo-mo, to go fast later.

slow-slow-quick-quick

A collection of AI assistant skills built around intentional friction. It slows down interactions to deepen user's understanding, form muscle memory, and produce work that reflects the user's genuine thinking rather than AI-generated output.

The name reflects the deliberate practice philosophy: go slow now to go fast later.

---

Skills

Skill	Trigger	What it does
slow-vibe-coding	Implementing a feature, writing a function, solving a coding problem	Refuses to write implementation code. Brainstorms patterns, presents at least two concrete approaches with trade-offs, provides comment-only skeletons, and guides you to write it yourself.
slow-vibe-sw-architect	System design, architecture decisions, technical choices	Refuses to give an immediate answer. Asks trade-off questions and failure scenarios until you arrive at a decision you own. Produces an ADR.
slow-dev-research	Technology selection, stack comparisons, engineering trade-off questions	Refuses to give a recommendation upfront. Surfaces research and real-world cases with sources, asks requirements questions one at a time, and

…

View on GitHub

LLMs change how fast software is being made. Tasks that used to take days now finishes in minutes. This speed creates a specific problem for the engineers who's in charge. It is remarkably easy to become a spectator in your own project.

I have felt this disconnection during recent work. When AI implements a feature, the growth of codebase is so fast, that sometimes human brain can barely keep up with. You are directing the work, but implementation details can bypass your understanding. You will feel that the work end up with a gap between what the system does and what you actually know about its inner workings.

Don't worry. It's not your fault, and it does not mean you are incompetent engineer. Strictly, in terms of the "speed" of software creation and problem solving, no human can even go close to current AI’s . That is how far AI has come today.

Make slowly, to go fast later.

True productivity follows a rhythm of "Slow, Slow, Quick, Quick."

This means alternating 'time to think' with implementation speed performance. Slowing down to analyze a design choice is not a waste of time. It is necessary investment. Building a clear mental model during the "slow" phases ensures the "quick" phases stay grounded. Without this balance, you just make shallow decisions that lead to huge technical debt.

This is the motivation for this skill.

Here's how to start for claude-code users:

$ /plugin marketplace add kination/slow-slow-quick-quick
$ /plugin install slow-engineering@slow-slow-quick-quick

(will make for other LLMs soon...)

Strategic Implementation with slow-vibe-coding

The slow-vibe-coding skill is one way to stay involved on coding. Typical assistants dump blocks of code, but this skill follows a strict protocol. AI is prohibited from writing implementation logic. It guides you through the problem and the patterns, then it stops.

The AI generates a skeleton of comments and a "pass" statement. Though they guide with well-made comments or making base code by your description, you will have change to involve in every output.

This builds muscle memory and maintains ownership. By the end, you have to explain details in review process. The AI becomes a high level director, not a code generator.

Architectural Integrity with slow-vibe-sw-architect

Design is usually the first thing lost when you move too fast. The slow-vibe-sw-architect skill enforces a pre-implementation step. It prohibits recommendations until you evaluate three tradeoffs and two failure scenarios. This forced delay explores scale, consistency, and complexity.

The result is a co-authored "Architecture Decision Record" (ADR). Documenting the "why" keeps the system coherent. It prevents AI from building something no human can debug.

So, here's the summary of these 2.

And one more, slow-dev-research

Technological decision often get made on familiarity, not fit. Result of selecting 'message queue' or 'database' under time pressure usually heads to choosing what team already knows. The research phase gets skipped because it feels like overhead. This is where a lot of technical debt originates.

Skill "slow-dev-research" adds friction before choices get made. The AI collects benchmarks, cases from real world, and known trade-offs with sources. After that it asks about your specific constraints one at a time. It can be expected traffic, team experience, consistency requirements, cost model. It refuses to give a recommendation until you have surfaced your own requirements.

The output is a research document with a trade-off map you fill out and a conclusion section you write yourself. It feeds directly into slow-vibe-sw-architect when a design decision follows.

Conclusion

These are the starting items of "slow" skills. I am planning more to cover the full lifecycle 'slowly', from research to verification.

Using LLMs is inevitable. I love coding, and still believe in the competitive edge of human-made code. But even so, AI is simply too fast and too productive to ignore.

But long term productivity requires more than raw generation. Working slow and deep at critical points will improve your understanding, to move quick later. Catching up may be impossible, but falling behind is not an option to remain as an engineer. Our mastery of the architecture must grow alongside the code it produces.