AI Portfolio

How I work with AI.

Tools I’ve built for my own work, and projects I’ve worked through with clients using Claude Code and Codex.

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.

But 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.

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 now

Before 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 633121a records 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.

What they refuse to do

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, no scheduled runs, no committing 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.

A few of the skills

/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.

/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.

/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.

Some more skills

/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 surfaces what I've stopped paying attention to, written so that going quiet is never framed as a failure.

/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 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 gathers ideas flagged across months of work and ranks them by how often the material asked, rather than by how good they sound.

/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 adds structure and cross-references to raw text without altering a word of it.

/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.

/synthesis returns what's useful, what doesn't fit, and where the source and I actually disagree, on the theory that friction is more useful than agreement.

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.

How this works with clients

The tools above support my own work. These case studies follow projects I worked through with clients: what we 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 carries over

Regardless of the tool, room, or industry, these practices support my workflows across the board.

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.

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.

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.

Want something like this for your team?