The onboarding ships inside the tool. An intake interview on the first run, and something behind it anyone can ask a question of at any point. A new person can start without a walkthrough and stay unstuck without booking time with me. It handles the part where a tool gets shipped to a team and then nobody uses it.
As AI tools advance, the question of using these tools is much less about technical ability and much more about willingness.
I often start by speaking my thoughts aloud and asking what I might be missing. The conversation helps me work through an idea before I know exactly what I want to make, and I keep editing as it takes shape.
What carries over
Regardless of the tool, room, or industry, these practices support my workflows across the board.
The context lives in plain files you own. It stays in plain markdown rather than locked inside one platform's project or one person's account, so it follows whoever needs it and survives a change of model, of tool, or of employer.
Anything irreversible waits for a person. The approval steps depend on the task and the permission already given. A report can go into an agreed folder; sending it to someone or changing the source calls for its own permission.
The prompt carries the context, so you don't have to write one. The domain knowledge, the format rules, and the voice go into the tool. What comes back is ready to send rather than ready to rewrite, and nobody has to learn prompting first.
Reference that people actually open. Scattered documents become one page with search and filters, so the answer is findable in the moment someone needs it. It replaces the folder nobody opens with a page people keep in a tab.
Intentional automation design. While human-in-the-loop is how I begin and test any build, discernment is key. Knowing when a workflow needs approval checkpoints and when it doesn't is crucial to realizing the impact of AI adoption.
How this works
A few of the skills I use most, each with what it does and, for some, a recorded run you can look through.
/handoff
A long piece of work usually doesn't finish in one sitting. Handoff writes the note that lets the next session pick up without losing what this one learned: what got decided, what got ruled out and why, what's still open, and the one next thing to do. That can be a note I carry into another chat or a shared file that Claude Code and Codex both read. I use both, so the context needs to travel between them.
It checks its own claims against the files before it writes them down, because notes like this go stale and nobody notices until they've already acted on one. It also marks which lines are verified and which are just the last session's read, so an assumption can't get laundered into a fact three sessions later.
See /handoff at work
This website has a shared handoff that Claude Code and Codex can both read. Here's a recorded example from an update to its links, shortened for this walkthrough.
My request, excerpt
Make the links arrive somewhere specific.
I would love it if you could do all of that if you're able to understand where everything should be going, so that all of them are totally deliberate rather than just going to the general rooms.
Spoken aloud using Wispr Flow.
One example: the Wayspace album in Music should link to its lyrics in Writing.
See where that link goes nowBefore writing the note
Check what changed and what was decided.
- js/wayspace.js
- The 16 cross-room links have specific destinations. Album membership comes from the catalogue.
- wayspace/writing.html & css/wayspace.css
- Writing has album filters. Linked entries have room to clear the navigation at the top.
- CLAUDE.md & HANDOFF.md
- The shared instructions keep our decisions separate from the current checkpoint.
- Saved version & browser checks
- Save point
633121arecords the update. All 16 links were followed locally, and Writing showed 6 Feivel Speaks lyrics and 12 Wayspace lyrics.
September 12, 2026 checkpoint
A note the next session can pick up.
A shortened version of the project's handoff at that point. This records the local review stage of the update.
- What we're doing
- Finish the approved website audit changes and make the cross-room links precise.
- Verified at this checkpoint
- The link update is saved as 633121a. All 16 cross-room links reach their intended destinations in the local preview. Writing's album filters show 6 Feivel Speaks lyrics and 12 Wayspace lyrics.
- Settled with Jack
- Keep the existing public Production credits for credibility. Use explicit catalogue membership for the lyric filters. Publication needs Jack's go.
- Still open
- Jack is reviewing the case study and revised copy. Nothing from this update has been pushed or deployed. Hosting-specific checks need a deployment first.
- Next action
- Review the local changes with Jack before publishing.
- What travels with it
- CLAUDE.md, HANDOFF.md, js/wayspace.js, wayspace/writing.html, css/wayspace.css, and save point 633121a. Recheck the current files and Git state when you resume.
/synthesize and /graft
I like to consume as little as possible so I can practice as much as possible. I’ll watch or read just enough of something to see there’s value in it, and then I bring it to Claude and run one of these two skills over it as a filter, so we can act on what’s useful.
/synthesize reads a source for what it means to me: the core idea in one line, what checks out and what doesn’t, where it resonates with how I work, and where it rubs against it. The friction is often the most useful part. /graft asks a narrower question, which is what should change in my setup, if anything. It breaks the source into items, checks each one against what I already have, and gives it a verdict: already covered, borrow, install, or skip. Borrowing usually wins, so a good idea becomes a line in a skill I control instead of someone else’s tool running in every session.
Every verdict goes into a ledger, so nothing gets reviewed twice. Since October 11 it has logged 86 verdicts across 11 sources, and half of them are skips. Twelve borrowed ideas went into my setup.
One of those changes was to /synthesize itself. Below is the run where it happened.
See /graft at work
Here’s a recorded run from October 18, shortened for this walkthrough. I’d watched a few minutes of a video about learning with AI, and it made a confident case that most people do it wrong.
My request
Graft this video.
Could you /graft this video transcript please? (Recognizing that we already have graft and synthesis and mapmaker here so interesting to use graft on a video about these kinds of skills)
The video argues that you learn by producing (recalling, explaining back, attempting) instead of by reading, and lists ten roles AI can play in learning. Claude read the full transcript from YouTube’s captions.
Before any verdict
Six of the ten roles were already here.
- Interviewer
- Ask me questions before teaching me. Covered by the assumptions-first rule in my global instructions, question cards, and plan mode.
- Mapmaker
- Covered by a different job. His builds a curriculum for a subject you don’t know yet; mine maps a pile I already have.
- Checker
- Check my process, don’t rewrite it. Covered by /red-pen, which flags and never rewrites, and a second model as an outside reviewer.
- Diagnostician
- Find the one root mistake behind repeated ones. Covered by the “seen twice is a rule” habit in my editing loop.
- Sparring partner
- Covered by /readers, for talks.
- Clerk
- Organize my notes, add nothing. Covered by /obsidian-layer and the skills that deliver and gather notes.
Each “already covered” names what covers it, checked that day against the files.
The report, excerpt
What’s missing is the production side.
- Explainer, then redo it without help
- Borrow. My teaching lines were all the explainer role. One line in my global instructions: now and then, ask me to guess before explaining.
- Listener (explain it back in your own words)
- Borrow. /synthesize gets an optional “Say it back” step at the end.
- Socratic questioner
- Skip. It’s a prompting habit, so nothing in the setup changes.
- Examiner (quiz me, harder each time)
- Skip. Nothing in my setup is exam-style learning.
The short version: your setup already covers most of his ten roles. What it lacks is the production side: anything that asks you to say it back. Two small borrows would fill that gap.
Past the list, it pointed out that /graft, /synthesize and the map skill were all explainers too. Each hands me something to read, and none asks me to produce anything.
After I said yes
Consume little, practice much.
/synthesize now ends with an offer
Want to say it back? Talk through what you took from this, and I’ll tell you what you caught, what you missed, and what’s yours.
A new line in my global instructions
Now and then, before explaining a command or change, ask him to guess what it will do first. A guess is production, and production is what sticks; an explanation alone only feels like learning.
Written to Claude, so it calls me him. Both changes went in the same morning, each on its own yes, and both are logged in the ledger as acted on.
What I noticed afterward
I’ve barely even gone through much of the Claude Academy trainings, and I’ve done way more actual practice and learning
Spoken aloud using Wispr Flow.
Use /synthesize and /graft yourself, free on GitHub/fair-share
/fair-share checks AI-assisted work from both sides of a handoff: the person who received it and the person about to send it. Inbound pulls out the point, the asks, and the claims worth checking. Outbound traces weak output back to likely gaps in the prompt that made it, and returns a better prompt along with the diagnosis.
Testing it on my own draft led to a third direction, crossbound, for shared drafts still in progress. Read more about it in case studies →
/map-maker
When you have piles of material, whether files, pages, transcripts, a folder nobody has opened in a year, map-maker reads all of it and gives you one place to read it from, in whatever format you want: a web page, a Word doc, a PDF, a deck.
Every statement on the map carries a coordinate back to where it came from, precise enough to act on: a filename and a heading, a page number, a timestamp. So you read the consolidated view, hit something you want to be sure about, and go straight to the exact spot in the source.
Where a line pulls a few sources together and doesn't have one origin, it says so, so you can always tell what came from your material and what got added to connect it.
/ingest-transcript
Anyone publishing long recorded conversations runs into the same thing, which is that somebody has to get through a two hour transcript and decide what to cut before it ships. This reads the whole thing and hands back one timestamped report covering what has to come out because a speaker asked for it on the record, what's worth listening to again before deciding, the standout lines worth pulling as clips, and any passage where someone recited from a published text long enough to earn a quote card on screen.
It asks one question before it starts, which is what comes before this transcript in the finished file and how long that runs. Every time it reports is offset to match the editor's timeline instead of the transcript's. Without that, somebody does the arithmetic by hand for every entry, which is worse than getting no timestamps at all.
/save-points
I'm not a professional developer, and version control is one of the most useful things I've picked up. Most people never get near it, because the tooling assumes you already speak the language.
This skill makes the process simple and easy to understand, and the skill ensures that the save points resemble save states of a video game. It tells me what changed since last time in ordinary words, proposes a description, and commits when I say yes. Anything that could lose work gets explained in full before it runs, and it teaches me one small thing per session when there's a natural opening.
Case studies
The tools above support my own work. These case studies follow projects I worked through with clients, and two I built for myself: what was needed, what we tried, what changed, and how we checked it.
If you'd like to see what an audit conversation would start from, the readiness assessment is a few minutes' way to find out.
What they refuse to do
Most people I talk to that want to work with AI have the same worry about it. They're afraid of finding out afterward that something went out in their name that they never approved of, or wouldn't have been comfortable putting in front of other people.
The boundaries are curated to the task. Tools that read my notes can report what they find without changing the source. New material for my Obsidian vault goes into a folder called Compost, which I review myself. A save point changes Git history; a handoff can be a note in chat or an update to a project's existing handoff file. Each tool spells out where it can write and which actions need my approval.
Almost every one of these tools has a section in it titled "What this skill is not." These are lines from those sections, as written.
Findings are observations, not action items. A tool that walks through my notes reports what it sees and stops there. It doesn't hand me a task list I didn't ask for.
Never a guilt engine. One of these finds the parts of my archive I've stopped visiting. If a finding would land as "you neglected this," it gets reframed or dropped.
No hooks, scheduled runs, or commits behind my back. The tool that version-controls my writing never runs on its own. Every save point is taken on purpose.
It never invents something the material didn't ask for. The tool that proposes new notes can only propose what the sources already pointed at twice.
It never creates missing files, edits links, renames anything, or updates the registry. It reads, it reports, and any repair is a separate job I have to authorize.
The raw text is preserved exactly. Nothing is rewritten, summarized, or cleaned up. The annotation tool adds structure around my words and never touches the words.
More skills and resources
/sweep
/sweep walks a section of the archive and reports what it notices, with an explicit guard against drifting from noticing into telling me what to build.
/portal
/portal surfaces what I've stopped paying attention to, written so that going quiet is never framed as a failure.
/mycelium
/mycelium reads the wikilinks running through my notes: the connective tissue I use in Obsidian for writing, journaling, documentation, lyrics, and drawing themes and parallels across years of material. It never fixes a link itself, and it weighs the ones I made by hand more heavily than the ones an assistant added, so an assistant's habits can't masquerade as my own intent.
/orient
/orient finds where my written instructions have drifted from reality, and revises only the lines that actually drifted. Every sentence still true stays untouched, word for word.
/harvest
/harvest gathers ideas flagged across months of work and ranks them by how often the material asked, rather than by how good they sound.
/deliver
/deliver runs with a confirmation at every stage, which flags a file that looks miscategorized instead of silently reclassifying it, and never overwrites anything.
/obsidian-layer
/obsidian-layer adds structure and cross-references to raw text without altering a word of it.
/conversation-archiver
/conversation-archiver records both halves of a dialogue with an AI, and cross-references only my words, so the record has both of us in it and the connections through it are mine.
/trailhead
/trailhead saves a good idea for later as a prompt that stands on its own, onto the Overlook, a private page pinned in my Claude sidebar. Claude offers it once, when a session ends on a new idea, and never brings trailheads up at the start of a session. I go to the Overlook on purpose.
The verification tool
The verification tool holds the checks that catch what a browser hides: a stylesheet returning the wrong content type, an import that 404s without breaking the page, a phone-width test that was never actually testing a phone. This one came out of me pointing Claude Code at the last couple of months of my project history and asking what was worth building, based on the repetitive work we were doing.
Mods
A mod changes Claude Code itself. The two guards can only stop Claude and say why. Everything else waits for me to choose it.
The vault fence
The vault fence enforces the Compost rule in code, so it holds even when Claude forgets it. A write anywhere else in my vault is stopped and pointed to Compost, and only I can open the fence, for a few minutes at a time. It catches file edits and most shell commands, but not a script that writes files on its own.
The file guard
The file guard is for when I run two Claude sessions in the same project. If one is about to write over a file the other changed since it last looked, the guard stops it once, so it re-reads the file and merges instead of overwriting.
The tool belt
The tool belt is a row of buttons above where I type: save a trailhead, take a save point, write a handoff, ask Claude to explain what it just did.
The puzzle
Every new session starts with most of my mods asleep, and the puzzle offers the usual pieces, a pane to choose from, or none. The guards are always in. Everything else is opt-in so that I don't end up with a cluttered screen of mods in every session.
The value of curation
Knowing exactly who a tool is for, and what they need to use a tool on their own, is most of what makes enablement work.
When we build empathically, the tools become too convenient not to use, because we took the time to understand each use case carefully.
Tools that a team can use, or anyone who comes across them, are absolutely worth building, but they don't have to be generic. These tools work best when they keep their tailored DNA as placeholders, ready to adapt to the next person during an introductory onboarding step at first use.
I started by building tools around the way I work.
My interest in AI also connects to my spiritual practice. I explored that in Artificial Intelligence Meets Spirituality, a 48-minute video about creativity and working with AI.