Long read · · Claude Code · 14 min read
I found my hub’s admin key in an “always allow” list. These are the commands I use now.
Early in October I sat down to tidy up how I work with Claude Code, the AI coding assistant I’ve used to build Fred and most of what runs around him. I expected to delete a few old notes. The first thing I found was the master key to my house’s hub.
Not a door key. A digital one: an old access token with administrator rights to Home Assistant, the hub that runs the lights, the sensors and nearly everything else.
It was sitting in plain text in my list of “always allow” rules, the commands Claude Code may run without asking me first. A coding session had put it there, twice, inside commands it wanted to stop being asked about. It got there the boring way, which is how most of these things happen.
I revoked it, gave each program that needed access its own key, and cleared out the rules. The same session added a small safety hook and eight skills. A few days later, the hook learned to refuse any shell command with a secret typed into it.
That was the start of October. On October 28, the computer I build on has 28 personal skills, 13 hooks and five specialist helpers.
Most of them exist because something went wrong without them.
This is the reference I wish I’d had on day one: the commands and skills I actually reach for, sorted by the job you’re doing. Each card says what the command does in plain words, when to use it and what you’ll see. The built-in ones come from Anthropic’s documentation as it reads today. The ones marked as ours are described in general terms, and the safety pieces come from the Porchlight Starter, our free kit, so you can copy them straight off the card.
Four words first
Claude Code has four kinds of helper, and the names get mixed up, so here they are once.
- Command
- Something you type after a slash, like
/clear. Claude Code does it right away. - Skill
- A folder with a SKILL.md file inside: a description of when to use it, then the steps. You can run one by typing its name after a slash, and Claude picks it up on its own when your request matches the description. The custom commands people used to write now work as skills too.
- Hook
- A script that runs at a set moment, such as just before Claude runs a command. A hook can stop that command.
- Subagent
- A helper Claude hands a side task to. It works in its own context and reports back.
And one file: CLAUDE.md, the plain-text rules Claude reads at the start of every session. Most of what follows is about keeping that file honest and making Claude prove its work.
Your first hour
If you’re starting from nothing, this is the order I’d do it in. By the end, the assistant has rules, a seatbelt and the habit of proving its work.
-
Minute 0
Give it rules
Open your project folder in a terminal, type claude, then /init. You’ll get a CLAUDE.md with what Claude worked out about the project.
/init/init -
Minute 10
Write down the rules you’d otherwise repeat
Open /memory and add three lines: read the real thing before changing it, prove it worked, and never put a secret in a command. Our kit’s CLAUDE.md is a longer version you can borrow from the card below.
/memory/memory -
Minute 20
Put the seatbelt on
Copy the safety hook from the kit into .claude/hooks/, and its settings into .claude/settings.json. Start a new session and type /hooks. It should be listed under PreToolUse, the moment before every tool call.
/hooks/hooks -
Minute 30
Plan before it touches anything
Ask for one small change with /plan in front of it. Read the plan. Approve it with the option that lets you review each edit.
/plan/plan -
Minute 45
Check the work
Look at /diff before you accept anything. Then ask it to verify: what success looks like, the evidence, and a verdict.
/diff/diff -
Minute 55
Leave a note and start clean
Write the handoff, then /clear before the next task. Tomorrow, /resume or the note picks it up.
/clear/clear
The reference, by job
Thirty-four cards in seven jobs. Filter by job or search for a word. Every copy button copies something you can paste: the command itself, the kit’s settings, or, for our own skills, a template to start yours.
All 34 commands and skills
01Start
Set up a project so every session begins with the same rules.
/init
Writes a starter CLAUDE.md, the file of rules Claude reads at the start of every session in this project.
- When
- The first time you open Claude Code in a project.
- You’ll see
- A new CLAUDE.md describing your project, ready for you to edit.
/init/memory
Opens your CLAUDE.md files to edit, and turns Claude’s own automatic notes (auto memory) on or off.
- When
- Right after a mistake you never want to see twice. Write the rule down once.
- You’ll see
- Your instruction files, and the notes Claude has kept for itself.
/memory/doctor
A setup checkup. It finds installation, settings and CLAUDE.md problems and proposes fixes, which Claude applies after you confirm.
- When
- When something about Claude Code itself seems off.
- You’ll see
- The problems it found and the fix it suggests for each.
/doctor/model
Switches the AI model and saves it as your default for new sessions.
- When
- A big plan deserves the strongest model. Renaming a file doesn’t.
- You’ll see
- A list of models. On models that support it, the arrow keys set how much effort it spends.
/model02Plan
Think first, edit later.
/plan fix the login bug
Starts plan mode. Claude reads and explores, then writes a plan, but doesn’t edit your files. Shift+Tab cycles into plan mode too.
- When
- Before any change that touches more than one file.
- You’ll see
- A written plan, then a choice: approve and let it edit, approve and review each edit, or keep planning.
/plan /context
Shows what’s filling Claude’s working memory, the context window, as a colored grid, with suggestions.
- When
- When answers start getting vague late in a long session.
- You’ll see
- A grid of what’s using the space and what you could trim.
/context/btw what does this flag do?
Asks a side question about the session without adding it to the conversation.
- When
- A quick question that shouldn’t pull the task off course.
- You’ll see
- An answer that doesn’t become part of the history.
/btw /engineering-plan
Our planning skill. It sorts a change by risk, lists everything it touches, and writes the tests and acceptance checks before any code.
- When
- Before anything that touches more than one system.
- You’ll see
- A plan with a risk level and a list of what “done” means, before a single file changes.
---
name: engineering-plan
description: Plan a change before building it. Sort it by risk, list everything it touches, and write the tests and acceptance checks first. Use before any change that touches more than one file or system.
---
1.
2.
3.
03Build
Point it at the right thing and keep the session lean.
@README.md
Typing @ starts file path autocomplete, so you can point Claude at the exact file you mean.
- When
- When “the config file” could mean three different files.
- You’ll see
- Matching paths as you type.
@! git status
An exclamation mark at the start runs a shell command yourself. The output goes into the session and Claude responds to it.
- When
- When you want Claude to see exactly what you see.
- You’ll see
- The command’s output in the session, then Claude’s reading of it.
! git status/compact keep the test results
Summarizes the conversation so far to free up room. You can say what the summary should keep.
- When
- When /context shows the window filling up in the middle of a task.
- You’ll see
- A shorter conversation that carries on.
/compact /clear
Starts a new conversation with empty context. Your CLAUDE.md rules still load.
- When
- Between unrelated tasks.
- You’ll see
- A fresh session. /resume brings the old one back.
/clear/tag-before-change
Our checkpoint skill. It snapshots the configuration of whatever is about to change, so there’s a known-good point to go back to.
- When
- Before any change to a system the house depends on.
- You’ll see
- A named checkpoint, recorded before the first edit.
---
name: tag-before-change
description: Take a checkpoint before changing a live system, so there is a known-good point to return to. Use before any change you might need to undo.
---
1.
2.
3.
04Check
Done means proven, not said.
/diff
Shows what changed in your working tree, including Claude’s edits so far.
- When
- Before you say yes to anything.
- You’ll see
- The changes, file by file.
/diff/code-review
Reviews the current changes, a branch or a pull request for correctness bugs. Add --fix to apply what it finds. /review does the same.
- When
- Before you commit something that matters.
- You’ll see
- A list of findings you can apply with --fix.
/code-review/security-review
Checks the changes on your branch for security problems such as injection, login flaws and exposed data.
- When
- Anything that handles logins, keys or input from outside.
- You’ll see
- The risks it found in your changes. It compares against a remote named origin, so it needs one.
/security-review/verify
Builds your app, runs it and watches the result, rather than trusting tests or type checks alone.
- When
- When “the tests pass” isn’t the same as “it works.”
- You’ll see
- What it ran and what it saw happen.
/verify/verify-change
Our verification skill. It restates what success looks like, checks each point on the real system and reports PASS or FAIL with evidence.
- When
- At the end of any change, or whenever you’d ask “did it work?”
- You’ll see
- Criteria, evidence and a verdict instead of “Done!”
---
name: verify-change
description: Prove a change worked before calling it done. Restate the success criteria, check each one against the real system, review the diff, and report PASS/FAIL with evidence. Use at the end of any change, or when asked "did it work?", "verify" or "double-check".
argument-hint: "[what was changed]"
---
/engineering-review
Our pre-merge gate. The project’s own checks run first, then reviewers that didn’t write the code each look at one angle.
- When
- Before merging anything that will run in the house.
- You’ll see
- PASS, FAIL or PARTIAL, with a file and line for each finding.
---
name: engineering-review
description: Gate a branch before it merges. Run the project's checks first, then ask reviewers that did not write the code to look at one angle each. Report PASS, FAIL or PARTIAL with file and line.
---
1.
2.
3.
05Remember
What one session learns, the next one should know.
CLAUDE.md
Plain-text rules Claude reads at the start of every session. ~/.claude/CLAUDE.md covers all your projects; ./CLAUDE.md covers this one.
- When
- Any rule you’d otherwise repeat in every session.
- You’ll see
- Claude following the rule without being told. The copy button gives you two sections from our kit’s version.
## Prove it worked
- Plan as `step → verify: <observable result>`. Done means verified on the real system (tests, HTTP status, a read-back, a log line). Say what was and wasn't verified.
- For a bug: reproduce it, fix it, show the reproduction now passes. Leave a cheap check behind.
- "Done" from an agent is a claim, not evidence. Use the `verify-change` skill.
## Secrets
- Never put a token, password or key in a chat, permission rule, saved command, note or memory. Read it at run time from your password manager or the one file that holds it.
- If a secret leaks, rotate it. Deleting the line is not enough.
/resume
Opens a picker of earlier conversations, or resumes one by its name.
- When
- Picking up yesterday’s work where it stopped.
- You’ll see
- A list of past sessions to choose from.
/resume/rewind
Rolls the code and the conversation back to an earlier checkpoint, or summarizes from a message you choose. /undo and /checkpoint do the same, and Esc twice on an empty prompt opens it.
- When
- When the last few steps went the wrong way.
- You’ll see
- A menu of checkpoints to return to.
/rewind/session-handoff
Our handoff skill. It checks git and the live system, then writes a note a fresh session can trust.
- When
- Before you stop for the day, or before the context fills up.
- You’ll see
- A handoff note in notes/handoffs/.
---
name: session-handoff
description: Write a verified end-of-session handoff so a fresh session, another agent or a person can resume safely. Use when ending a significant session, before the context fills up, before handing work over, or when asked to "wrap up" or "save where we are".
argument-hint: "[topic]"
---
/vault-note
Our shared-notebook skill. It searches before it writes, updates a note instead of adding a near-copy, and won’t overwrite a note that changed since it was read.
- When
- Anything someone should be able to find next month.
- You’ll see
- One updated note, not a pile of new ones.
---
name: vault-note
description: Read and write the shared notebook. Search before writing, update an existing note instead of adding a near-copy, and refuse to overwrite a note that changed since you read it.
---
1.
2.
3.
06Stay safe
Decide what it may do alone before it decides for you.
claude --permission-mode plan
Starts a session in a permission mode. Manual asks before most actions. acceptEdits lets file edits through. plan only reads and explores. auto runs with background safety checks.
- When
- Match the mode to the job. Plan for exploring, Manual for anything that touches a live system.
- You’ll see
- The current mode in the mode indicator. Shift+Tab cycles through them.
claude --permission-mode plan/permissions
Your allow, ask and deny rules in one place, by scope, where you can add or remove them.
- When
- Read it every week or so. It’s where the key was.
- You’ll see
- Every rule you’ve said yes to.
/permissions/hooks
Shows your hooks: scripts that run at set moments, such as just before Claude uses a tool, and can stop that tool.
- When
- After installing a safety hook, to confirm it’s there.
- You’ll see
- Your hook configuration.
/hooks.claude/hooks/careful.py
Our safety hook. Before every shell command and file write it refuses wiping a disk, asks before force-pushes and recursive deletes, and refuses a secret, such as a key or token, typed into a command.
- When
- Day one, before you approve anything.
- You’ll see
- A [careful] prompt before anything risky happens. The copy button gives you the settings that switch it on.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Write|Edit|MultiEdit|NotebookEdit",
"hooks": [
{
"type": "command",
"command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/careful.py\"",
"timeout": 5
}
]
}
]
}
}
/secret-sync
Our secrets skill. It moves a key between the password manager and a config file by script and compares by fingerprint, so nobody pastes a secret by hand.
- When
- Any time a key, token or password has to move.
- You’ll see
- A match or a mismatch, shown as a fingerprint, never the secret itself.
---
name: secret-sync
description: Move a password, key or token between the password manager and a config file by script. Compare by hash, never print the value, never paste it by hand.
---
1.
2.
3.
07Automate
Repeat the boring parts, on purpose.
/loop 10m check the build
Runs a prompt again and again while the session stays open. Leave out the interval and Claude paces itself.
- When
- Keeping an eye on something that takes a while.
- You’ll see
- The same check repeating in the session.
/loop 10m /schedule
Creates, lists or runs scheduled tasks that run in the cloud. Claude walks you through the setup in conversation.
- When
- Jobs that should run on a timetable, not when you remember.
- You’ll see
- A short conversation, then the task in your list.
/scheduleclaude -p "summarize today's changes"
Runs Claude once, without the interactive screen, so a script can call it.
- When
- Wiring Claude into your own scripts.
- You’ll see
- The answer printed in your terminal.
claude -p "summarize today's changes"/fewer-permission-prompts
Scans your past sessions for read-only commands you approve over and over, and adds an allowlist for them to the project’s settings.
- When
- When you’re tired of approving the same safe command. It’s the careful answer to “don’t ask again.”
- You’ll see
- A prioritized list of read-only rules added to .claude/settings.json.
/fewer-permission-prompts/release-loop
Our release loop, under a plainer name here. A script, not an agent, runs every step a script can decide: the checks, the merge, deploy readiness and the check afterwards.
- When
- Shipping code the house runs on.
- You’ll see
- One screen with what’s ready, what’s blocked and why.
---
name: release-loop
description: Run the change-and-release loop. Let a script decide every step a script can: checks, merges, deploy readiness and verification. Use agents only for judgment.
---
1.
2.
3.
The one-page version
Everything above on a single sheet. Print it and keep it by the keyboard.
| Type | Job | What it does |
|---|---|---|
/init | Start | Write a starter CLAUDE.md |
/memory | Start | Edit the rules; auto memory on or off |
/doctor | Start | Check the setup, fix what’s wrong |
/model | Start | Switch the model |
/plan | Plan | Plan before editing (or Shift+Tab) |
/context | Plan | See what fills the context window |
/btw | Plan | Ask a side question |
/engineering-plan | Plan | Our skill: plan by risk, tests first |
@ | Build | Point at a file |
! git status | Build | Run a command yourself, share the output |
/compact | Build | Summarize to free up room |
/clear | Build | Start fresh between tasks |
/tag-before-change | Build | Our skill: checkpoint before a change |
/diff | Check | See what changed |
/code-review | Check | Review the diff for bugs |
/security-review | Check | Review the diff for security |
/verify | Check | Run the app and watch it work |
/verify-change | Check | Free kit: prove it before “done” |
/engineering-review | Check | Our skill: review by someone else |
CLAUDE.md | Remember | The rules file every session reads |
/resume | Remember | Go back to an earlier session |
/rewind | Remember | Roll back to a checkpoint (Esc Esc) |
/session-handoff | Remember | Free kit: a handoff the next session trusts |
/vault-note | Remember | Our skill: one shared notebook |
claude --permission-mode plan | Stay safe | Pick a permission mode (Shift+Tab) |
/permissions | Stay safe | Read every rule you’ve allowed |
/hooks | Stay safe | See your hooks |
.claude/hooks/careful.py | Stay safe | Free kit: the safety hook |
/secret-sync | Stay safe | Our skill: move secrets by script |
/loop 10m | Automate | Repeat a prompt while you work |
/schedule | Automate | Run a task on a timetable |
claude -p "summarize today's changes" | Automate | Run once from a script |
/fewer-permission-prompts | Automate | Allow safe, read-only commands in bulk |
/release-loop | Automate | Our skill: a script runs the release |
What I’d tell myself on day one
Most of these commands aren’t clever. /diff shows you what changed. /permissions shows you what you’ve already agreed to. The skill I lean on most is the one that makes Claude prove its work before it’s allowed to say done.
None of them would have stopped the key from landing in that list on their own.
Reading the list would have.
So here’s the challenge. Open /permissions today and read every rule out loud. Would you be comfortable with each one on a screen at the front of a room?