4. Skills and slash commands — what repetition is worth collapsing into one line
Tools that compress repeated mind operations into a single-word call. Five promotion criteria, the split between skills, slash commands, and functions, design principles, and what to keep out.
This is part 4 of the Alice Way series. Parts 2 Persona design and 3 Memory system covered where mind gets inscribed and where it gets held. This post covers the next layer — how to compress the repeated motions of mind into a single line.
0. A skill condenses repeated mind motion into one line
There are two kinds of content in an operator's mind. One kind is "what do I need to decide right now." The other is "what procedure do I unwind that decision through." The first changes every time. The second is often the same.
If the same procedure repeats every day and you are explaining it to the collaborator with the same words every day, that procedure has already congealed into a mind pattern. A congealed motion deserves a one-line name.
Skills and slash commands are that name. They condense a recurring mind motion into a single-word invocation. Names exist so the same procedure does not have to be unrolled in language every time.
This post is a collection of criteria for which repetitions deserve that name, and how to design those names.
The "skill" mechanism itself is borrowed from Anthropic Claude Code's Skill system. This post is a record of how that mechanism is used, not an invention of it.
1. Promotion criteria — which repetitions become skills
Not every daily procedure should become a skill. Only the ones that pass all five of these get a one-line name.
1.1 Has it repeated at least twice?
Once is a coincidence. Twice is a pattern. The same procedure has to have run at least twice to qualify.
This criterion is the simplest but the most often violated. It blocks the impulse "I'll probably do this a lot, let me make a skill ahead of time." Future repetition is a guess; past repetition is a fact. Promote on fact only.
1.2 Are start and end clearly defined?
A skill needs unambiguous start and end conditions. "Enter a project," "close out a session," "build after linting" — these have clear edges. "Write code" does not, in either direction, and does not become a skill.
Without clear edges, the collaborator does not know where to stop after the call. A skill with a fuzzy end gets manually halted by the operator every time.
1.3 Is the invocation moment decidable?
Invocation comes in two flavors. Operator-conscious (slash commands) or system-driven (hooks — next post). Either way, the moment of invocation has to be decidable.
"It depends on the moment" is not a skill. That puts judgment back on the collaborator each time, and that judgment itself demands fresh mind.
1.4 Does it take the same input (or only simple args)?
The input has to be simple. Either no arguments, or one or two short arguments. Many arguments turn filling them in into a new procedure of its own — the savings disappear.
| Good skill arg | Bad skill arg |
|---|---|
None (/session-end) | 5+ options |
One short identifier (/start vsub) | Long free text |
A clear enum (/loop 5m) | "Tell me how to handle this" |
1.5 Can the result be consistently verified?
After running, the skill should let the collaborator self-verify the result. Signals like "success," "failure," "precondition missing" need to be clear.
A skill whose results cannot be verified means the operator has to manually check every time. Half the benefit evaporates there.
2. Skills · slash commands · functions — separating roles
All three reduce repetition, but they play different roles.
| Tool | Caller | Context-aware | Right fit |
|---|---|---|---|
| Function / plain code | The collaborator itself | None (pure input→output) | Deterministic compute, transforms, file processing |
| Slash command | Operator-explicit | Session-aware | Procedures the operator's intent starts (/start, /session-end) |
| Hook | System on event | Event-aware | Things-not-to-forget, auto-fired (next post) |
A skill is the shared procedure definition that both slash commands and hooks can invoke. The same /verify procedure can be typed by the operator or auto-fired by a hook right before a "done" report. Both paths point at the same skill.
If this split is not clean, either every automation becomes a function and the collaborator's context-awareness goes unused, or everything becomes a slash command and the operator has to invoke each one manually.
3. Skills in actual rotation — the accumulated effect
A subset of the skills I invoke every day.
3.1 /start <project> — enter a project
Enter the named project, auto-load README.md · CLAUDE.md · HANDOFF.md · PLAN.md, then report current git state and prior-session handoff in one view. Stop and wait for the operator's next instruction.
Without this skill, every entry requires the operator to unroll "go to that folder, read the README, read the HANDOFF, check git status, show me the last commit message." Condensed into one word.
3.2 /session-end — close the session
Write the work log, update HANDOFF.md (the next-session handoff the system auto-loads), commit, push — all in one motion. No more spelling out "summarize today into history.md, write what the next session needs into HANDOFF, commit, push."
3.3 /verify — the verification loop
After code changes, runs lint · build · test · security checks · diff review automatically. A "done" report cannot go out until it passes. Covered in detail later in the series.
3.4 /council — four-perspective parallel analysis
For genuinely ambiguous decisions, runs architect · skeptic · pragmatist · critic perspectives in parallel and synthesizes the results. This pattern is adapted from Andrej Karpathy's multi-perspective critique approach to LLM reasoning.
3.5 The accumulated effect
Each of these is not a great invention on its own. But when about 30 one-line names are getting invoked daily, the time the operator spends unrolling procedures into language almost disappears. The operator's mind only has to focus on "what do I need to decide right now"; the names handle "how do I unroll the decision."
4. Design principles — what I hold to when building a skill
What I converged on for skill design.
4.1 Idempotent
Calling with the same args twice should yield the same result, or at least not break. A non-idempotent skill makes the operator think "is it safe to call this right now?" every time. That is fresh mind tax.
4.2 Fail-fast
If preconditions are not met, the skill stops on line one with a clear message. "This directory is not a git repo. Run git init and try again." Half-executed skills in an intermediate state are the most dangerous.
4.3 Short output
When the skill ends, the output should be short. "OK: pushed 3 files," one line. Detailed logs only on demand, behind an option. Long output forces the collaborator to summarize every time and the operator to re-read.
4.4 Declare side effects
If the skill changes external state — writes files, makes network calls, pushes — that fact is declared at the top of the skill definition. "This skill pushes to origin." The operator should know that before calling.
4.5 Single responsibility
A skill does one thing. Do not slip "and also install dependencies" into /start. That is a separate skill. When single responsibility breaks, the name stops describing the action.
5. When skills accumulate — the network effect
A single skill's value is time saved. But when 30 skills accumulate, something larger happens. Skills start calling each other.
For example:
/session-endinternally calls/verify— unverified changes do not get pushed/startauto-refreshes the memory index/councilproposes invoking/btw(decision-queue processing) after a decision
When each skill can call others through a well-defined interface, the operator's mind operates at a larger unit. A single "close out today's work" decision unrolls into 7 or 8 skill calls internally. The operator does not have to be aware of those 7 or 8.
That is the real value of an accumulated skill set. Time saved is a side effect; mind being able to operate at a larger unit is the essence.
6. What not to skillify — traps
The flip side of the promotion criteria. The following lose money as skills.
6.1 Procedures likely to run only once
"This migration runs once, let me write a script." That should not become a skill. One-off procedures just run once and disappear. As a skill they become maintenance, and six months later you are trying to remember what they were.
6.2 Things with heavy context dependence
"Review this code" cannot be a skill because every invocation needs different context. If you take context as arguments, you end up spelling it out every time, and the benefit evaporates.
6.3 Outsourcing the mind itself
"Tell me what I should decide" is not a skill. That outsources the operator's mind, and then the operator stops being the owner of the decision.
A skill assists the operator's mind; it does not replace it.
6.4 Procedures that change too often
A skill, once defined, should stand for days. Procedures that change weekly do not get congealed. If you congeal them, they break next week.
7. Evolution pattern — how skills get polished
The natural life cycle I have observed for a skill.
- Repetition spotted: same procedure spelled out twice or more → candidate
- Manual write-up: list the steps in a README or note → followable by hand
- Skillify: once the steps are stable, condense into a slash command or skill definition
- In-flight polish: edge cases found in real use get fixed
- External-callable: clean up the interface so other skills can call it
- Promote or demote: heavily used → add an auto-fire trigger in the persona (next post on hooks) / unused → demote external or delete
Skills that do not go through this cycle do not last. They are easy to make and hard to maintain, so natural selection is required.
8. Compressed into one principle
The core of skill and slash command design collapses into one sentence.
"Only give a one-line name to the recurring mind motions. Spell out everything else."
When this holds, the skill set becomes an accelerator for the operator's mind. When it breaks — skills made too early, or too complex — they become an overhead the operator has to think about every time.
The next post covers the other half that pairs with skills — hooks and automation, i.e. procedures the system auto-fires without the operator having to invoke them.