Skills

Package a repeated workflow into a slash command.

A skill is a markdown file describing a procedure. Invoke it with /name and its contents enter the conversation as instructions.

Creating one

Drop a .md file in either directory:

Location	Scope
~/.9p/skills/	every project
./.9p/skills/	this project (wins on name clash)

~/.9p/skills/review.md

---
name: review
description: Review staged changes before committing
---

Review what is currently staged (`git diff --cached`).

Check in order:
1. Correctness, logic errors, unhandled cases, wrong assumptions
2. Tests, is the new behaviour covered?
3. Conventions, does it match the surrounding code?

Report findings most-severe first as `file:line, problem`. Do not fix
anything unless I ask.

Then:

9p ❯ /review

Frontmatter is optional, without it the filename becomes the name and the description is empty.

Arguments

Anything after the name is passed through:

9p ❯ /review src/auth

Write the skill so that reads naturally: “Review what is staged. If an argument is given, restrict the review to that path.”

Why not just put it in 9P.md?

Because of context cost. 9P.md is loaded every session; a skill body enters context only when you invoke it. Ten skills cost nothing until used, ten workflows in 9P.md cost tokens on every single turn.

Rule of thumb: standing rules go in 9P.md, procedures go in skills.

Managing them

/skills           # reload from disk and list

Skills reload on /skills, so you can edit one in another window and pick up the change without restarting.

Ideas that work well

/ship

Run checks, write a commit message in your house style, open a PR with a filled-out template.

/debug

Reproduce, find root cause, fix, add a regression test, in that order, without skipping to the fix.

/onboard

Read the vault index and the codebase map, then summarise the current state of work. Good first command of the day.

/adr

Write a decision record into the vault’s decisions/ folder, linked from the relevant notes.