AI tooling · Claude CodePersonal project

Custom Claude Skills

A skill is a reusable instruction set an assistant loads on demand.

I wrote five by hand, one at a time, each because something kept going wrong. The one I lead with edits a live production database and will not write a single row until a person reads the diff and says yes. It is running further down this page with made-up data, so you can work the gate yourself.

Try the approval gate Browse all five

skills written by hand, one problem each

of them running right here, no sign-up, made-up data

rows written without a human saying yes

Try it: the approval gate

This is the idea I care most about, so here it is running in your browser. No account, no sign-up, made-up data.

What you are looking at. Ridgeline Foods is a made-up company. Its staff portal decides which tools each person can open, and it keeps that in a database. Someone asks for a change. The skill works out exactly what the change takes, shows you the before and after, and tells you how many people it hits. Then it stops.

Nothing gets written until you click Approve. That is the whole point.

The directory right now

Three people. Watch this panel: it only ever changes after you approve something.

1. Ask for a change

Pick a change above and the skill will stage it here.

Runs entirely in this page. No network calls, no database, no real people.

The library

Five skills. Each one is about fifteen seconds to understand. Open the expander if you want the mechanics.

staged-db-admin

Running on this page

Edits a live production database, and cannot write a single row until a person has read the diff and approved it.

An assistant with database access is one confident mistake away from locking the wrong person out of every tool they use. Most setups that let AI run SQL fail the same three ways: they guess at record ids, they write changes the app's own audit log never sees, or they fire one unfiltered UPDATE and take out a table.

What it actually does

Reads current state first, and validates every key and id against the live schema before it stages anything. It never guesses an id.
Renders the change as a before and after diff, and states the blast radius out loud (how many people this hits) before it asks.
Stops. Approve, reject, or edit. "Edit" sends it back to restage, and a batch of ten changes still gets one diff and one approval.
On approve, it writes the same audit row the app's own admin screen writes, so a change made by the skill is indistinguishable from one made by clicking around in the UI.
DROP, TRUNCATE, and any DELETE or UPDATE without a filter are hard forbidden. It will not stage them at all.
Covers the real jobs: onboard a person, offboard a person, change a role, grant or revoke a tool for an entire role, fix a tool's link, and archive a tool instead of deleting it.
Offboarding always surfaces the same caveat: removing the portal is not the same as closing their accounts in the other systems.

You configure it before first use: your Postgres project and database, how the assistant runs SQL, your app's admin and audit paths, and whether accounts have to be on a specific email domain.

Work the gate yourself ↑ Four asks, one of them the kind it refuses outright.

The demo above is the behaviour, staging and refusals included, against a made-up company.

handover

Public

Writes the shift-change note at the end of a session, so the next one does not start from zero.

The gap between sessions is where context dies. You come back the next morning and the reasoning, the dead ends, and the half-finished state are all gone, so you rebuild them from memory or repeat the same mistakes.

What actually lands in the file

What you were trying to do and where things started.
Work completed, with the file paths and the commands that ran.
What worked, and separately what did not work and why. The failed-attempts section is usually the most valuable part, because it stops the next session repeating them.
Key decisions, each with the reasoning, the alternatives considered, and the tradeoff accepted.
Lessons and gotchas: the surprises, the edge cases, the config quirks.
An honest current state, split into working, incomplete, broken, and open questions.
A prioritized next-steps list with the blockers named, plus a map of the files that matter going forward.
The repetitive manual work it noticed during the session, with suggested automations ranked by frequency times time saved.

git clone https://github.com/flexscalex/claude-handover-skill.git
cp -R claude-handover-skill/handover ~/.claude/skills/

View the repo → Then say "generate a handover" at the end of a session.

process-call

Files a meeting recording where it belongs, then reads the transcript and writes it up like a colleague who was on the call.

The recording lands in a folder and nothing ever happens to it. A week later nobody remembers what was agreed, and nobody is going to scrub an hour of video to find out.

What it actually does

Lists your recent recordings over rclone and asks which one you want.
Works out whether the call was internal, with an existing client, or with a prospect, and moves the whole recording folder to the matching place on your shared drive. It creates the folder if the company is new.
It asks before it moves anything.
Then it reads the transcript and writes a real analysis: a summary with an honest read on how the call went, the relationship stage and sentiment, decisions made, action items split by side with owners, opportunities, risks, recommended follow-ups, and the quotes worth keeping verbatim.

Needs rclone configured for your drives. The skill file has a setup section for remote names and folder paths, and a warning about folder names with trailing spaces that will cost you twenty minutes if nobody tells you.

Runs on your own machine against your own drive. The only thing it needs is rclone already configured.

conversation-archaeologist

Reads every past session at once and comes back with a ranked list of what I should automate.

One session only shows you today. The patterns that actually cost you time only appear across hundreds of them, and nobody is going to sit down and read hundreds of them.

What it actually does

Reads the whole conversation history and builds a working profile: what you actually work on, which projects finish and which stall, the approaches that keep succeeding, the ones that keep failing, and your recurring time sinks.
Picks up how you make decisions, how you give corrections, and what consistently frustrates you, so the next session does not have to relearn it.
The headline output is a ranked list of automation opportunities. Each one is scored by how often it comes up, the estimated time cost, the rough return, and how hard it would be to build, so the highest-leverage thing floats to the top.
Writes it all out as a user manual you can keep and hand to a new session.

Reads the session history already sitting on your own machine. Nothing gets uploaded anywhere.

network-icp

Configurable

Turns your own LinkedIn connections export into a ranked list of who is worth talking to, and will not draft a single message until you have read that list and said go.

Everybody knows their network is full of leads and almost nobody mines it, because by hand it means looking up several hundred companies one at a time.

Point an assistant at it instead and the usual result is a few hundred CRM calls and a pile of enrichment credits spent to find out most of them were already in the pipeline.

What it actually does

Parses the export, pulls out every unique company, and classifies each one against your customer profile before it looks at anyone's job title.
Pulls your whole CRM once and matches the company names locally, instead of querying company by company. A 500-connection export usually costs two CRM calls, not hundreds.
Spends enrichment credits only on the companies your CRM could not already identify. If you know them, you do not pay to learn about them again. Both output files report how many API calls actually got used, so you can check the claim.
Hands back a brief that splits the network into direct prospects, referral partners, and noise, plus a CSV you can work off. Existing customers, open deals, and known partners get flagged rather than pitched.
Says so when a company name match is ambiguous, instead of guessing.
Phase 1 is analysis only. It will not write outreach until a person has read the list and explicitly approved it. Same gate as the database skill above, different blast radius: a bad list does not just waste an afternoon, it costs you relationships you already had. Even after approval it only drafts. You send.
The export is a file full of real people's names and employers, so exports and generated output are kept out of version control by default.

One YAML block at the top of the skill file is the only thing you edit: who you sell to, your target segments, the size band, industries to include and exclude, hard disqualifiers, decision-maker titles, the sentence that separates a referral partner from a prospect, and which CRM and enrichment tools to call.

It ships with a worked example filled in for a made-up freight company so you can see the shape before you write your own.

HubSpot and Apollo are what it was built against, and neither is required. Any CRM with a bulk search endpoint and any enrichment provider that takes a company name both work. Swap two names in the config. The two rules that matter survive any swap: pull once and match locally, enrich only what you could not already identify.

Why this set, together

Three of them are about memory. Look across everything and tell me what to automate. Keep a session's context from leaking away. Keep a meeting from evaporating the moment it ends.

Two of them are about restraint. Stage the change, show the diff, name who it hits, and wait for a person. The database one and the network one stop at the same place, because that is where being wrong gets expensive. One writes rows, the other writes to real people. Same gate, different blast radius.

For an implementation role, the second group is the real signal. The job is not prompting a model well. It is designing the scaffolding around the model so the work compounds and so the model cannot quietly do damage. I build that scaffolding for myself, which is the same muscle I would bring to building it for a team.

Happy to walk through any of them.