Pathlight·Playbook

Habits · 01: Skills and Commands

Skills and slash commands are the habits you invoke by name. Small, repeatable procedures you edit once and use forever. A workflow (next chapter) runs on its own; a skill runs when you call it. This chapter is the catalog: which to install first, which later, which only when a real need shows up. The discipline is restraint. Install the few you’ll use weekly, not the forty that exist.

Why habits come after Memory and Senses

A skill is only as good as the context it reads. /cold-email writes a generic email until your Codex has a voice.md and an icp.md. /meeting-cortex has nowhere to route a meeting until your files exist. Skills are the verbs; they need the nouns, Memory and Senses, to act on. That’s why Habits comes third.

Skills are also cheap to install and expensive to keep. The failure is never “I don’t have enough skills.” It’s “I installed thirty, use four, and the rest are rot.” Install the core set, then add one only after you’ve done the manual version enough times to know exactly what it should do.

Skill, command, workflow. Three words for related things: - A command is a slash-invocable procedure (/kb-ingest). You type it, it runs once, it stops. - A skill is the same idea with richer packaging: a folder with a SKILL.md, plus optional scripts and references, that Claude loads when it’s relevant. - A workflow (next chapter) runs without you invoking it. A cron (a scheduled clock) or a webhook (a trigger that fires when something happens) sets it off.

Skills are invoked; workflows are triggered.

The catalog

Grouped by which of the four parts of the OS each serves: Memory, Senses, Habits, Learning.

Layer Skill / Command What it does When you call it
Memory /kb-ingest Compiles a raw source into your knowledge base After a long input worth keeping
/vault-ingest Proposes a change-set to your files After input that might change something
/vault-apply Applies the items you ticked After you’ve reviewed a proposal
Senses /meeting-cortex Turns a recorded meeting into routed, filed notes After a call
/granola-sync Pulls Granola meeting notes into the right folder After a call (Granola path)
Habits /n8n-build Builds and ships an automation When automating a repeatable task
/n8n-fix Changes an automation you already run When one needs a tweak
/generate-proposal Drafts a proposal for service work When scoping a job
/cold-email Drafts a personal outreach email During outreach
Learning /vault-lint Audits your files for drift Weekly
/kb-lint Audits the knowledge base for stale or orphaned pages Weekly
/session-check End-of-session check that nothing’s lost Every session
/cc-sync Logs what you did this session As work wraps

The skills ship in the starter kit, the curated set, not the full menu. Every skill maps to a part of the OS and a clear trigger.

Installing a skill

Installing one is a copy, not a project. Drop the file into ~/.claude/skills/ (a skill folder) or ~/.claude/commands/ (a single command), then test it once on a real input. If it works, keep it; if not, the fix is in the file (next section).

The anatomy of a skill (so you can write your own)

Every command is a plain markdown file: frontmatter that names it, says what it does, and lists the tools it’s allowed to touch, then a prompt body. That structure is why skills are safe and repeatable.

---
name: my-skill
description: One line, what it does and when to use it. (This is how Claude
  decides whether the skill is relevant.)
argument-hint: "<what to pass it>"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*, date:*)
---

# My Skill

Target: **$ARGUMENTS**

## Hard rules
1. [The boundaries. What it must never touch. This is the safety.]

## Step 0: Load the contract
[What to read first so it acts on real context, not guesses.]

## Steps
1. [Concrete, ordered steps.]

## Report and stop
[What to output. No background work.]

Three things make a skill trustworthy: 1. allowed-tools scopes its power. A read-only skill can’t be handed write access. Least privilege, built in. 2. Hard rules state the boundaries. The meeting router writes proposals but never edits a settled decision. The rule lives in the file, not your head. 3. “Load the contract” makes it read before it writes. It starts by reading the file it operates against, so it acts on what’s true, not what it assumed.

Install order (from zero)

Each step earns the next:

  1. Get knowledge in, keep it clean. /kb-ingest, /kb-lint.
  2. The confirm gate. /vault-ingest, /vault-apply: propose a change to your files, then confirm it.
  3. Capture and routing. /meeting-cortex, the highest-leverage single skill (chapter 03).
  4. One domain skill. /n8n-build if you’re automating, /generate-proposal if you’re selling. Add only what your work asks for.
  5. Rituals last. /session-check, /cc-sync, once you have something worth checking.

Install a skill the week you’ll first use it, not before. A skill installed ahead of need is the rot a later cleanup has to find.

Pitfalls (the “if X, then Y” guide)

Situation What to do
You want to install all forty skills that exist Don’t. Install the eight core ones. Each extra skill is upkeep. Add the rest only when a real task asks.
Not sure if something is a skill or a workflow If you decide when it runs, it’s a skill. If a clock or an event decides, it’s a workflow (next chapter).
A skill’s output is generic and doesn’t sound like you The skill isn’t the problem, its context is. Check that voice.md and icp.md exist and the skill reads them in its “load the contract” step.
You keep doing a task by hand that feels repetitive Do it by hand three times first, then codify. A skill written before you understand the task is a guess you’ll rewrite.
Two skills overlap Merge or retire one. Two places for the same logic is exactly the drift to avoid.
A skill has broad allowed-tools “just in case” Tighten it. A read-only audit skill with write access is one bad prompt from damage.
You installed a skill and never run it Retire it. Installed-but-unused is the number that matters.

Maya’s version

Maya runs an online store and a small service business, plus a content channel, and she doesn’t code. Her skills library is small on purpose:

Skill Why she keeps it
/kb-ingest Pulls a long supplier email or a saved article into her knowledge base.
/vault-ingest, /vault-apply Proposes a change to her files, then applies only what she ticks. Nothing changes without her say-so.
/meeting-cortex Every service call files itself as a note she can search later.
/generate-proposal Drafts a proposal for her service work in her own voice.
/vault-lint, /kb-lint, /session-check Her weekly and end-of-session checks that nothing’s gone stale or lost.

Two things worth copying. First, a library can grow, but the weekly-used set stays small: Maya keeps a few more for the odd occasion, yet the ones that fire every week are the handful above. The gap between “installed” and “used” is what to watch, not the total. Second, every skill has a home under the part of the OS it serves, so a new one inherits a place instead of piling into a drawer. She adds a skill when a task asks, and retires one she stopped running.

You’ve got it when

The first five make the layer live. The last is the maturity marker.

/cc-skills-sync re-syncs your skills list from the real ~/.claude registry after you add, remove, or rewire one.

Next chapter

→ 02-workflow-templates.md. The patterns that run without being invoked: automations set off by a clock or an event, with the LLM as the logic inside specific steps.