Agent Toolkit

MCP servers, plugins, skills, and patterns I actually use with Claude Code

I run Claude Code most of the day, across a dozen projects and from my phone. This is the short list of what’s stuck. Everything here is something I use, not something I’ve only read about. Filter by MCP Server, Plugin, or Skill, or jump to the patterns.

Tools

Patterns

Most of what makes agents useful isn’t a tool. It’s habits around the tools. These came from things breaking.

Name every session, and keep a manifest

Launch each session with an explicit name and session ID (claude --name <name> --session-id <uuid>), and append a row to a plain TSV: timestamp, ID, name, working directory. A small wrapper script can then list what’s running, kill a session by name, or resume one that ended days ago, without digging through ~/.claude/projects for the right transcript.

Make sessions reachable from your phone

Start long-running sessions with --remote-control so you can check in and steer from anywhere. Two things silently break this:

• The folder-trust dialog. A session waiting at “Do you trust this folder?” never registers for remote control. Pre-trust the directory before launching. If several launches can run at once, serialize writes to ~/.claude.json: two racing writes once wiped the trust settings for every project.
• The large-session resume prompt. Resuming a big or old session asks whether to resume from a summary or in full, and that prompt blocks remote control. Run /compact headlessly first, then resume. The session is small enough that the prompt never appears.

Back up transcripts additively

Session transcripts can disappear. I lost three multi-day sessions in one afternoon. A scheduled job copies ~/.claude/projects and ~/.claude/file-history every 30 minutes, without mirroring or purging, so a file deleted from the live folder survives in the backup. Only an age-based retention rule ever deletes anything. To restore, copy the .jsonl back and run claude --resume <id>.

Enforce with hooks, not prompts

A sentence in a system prompt is advice; a PreToolUse hook is a guarantee. Anything that leaves the machine, like email, posts, or deploys, gets a hook that checks the tool call and exits with code 2 to block it. My email hook allows sends only to an allowlist and logs every reply. This is what makes running in bypassPermissions mode reasonable.

Give agents a memory, and let it consolidate overnight

A fresh session knows nothing about you. Keep canonical facts (who you are, current priorities, how you like to work) in a markdown knowledge base with git history. Have every session read a few core pages first, and write back what it learned at the end. A nightly job turns recent transcripts into plain-text digests and runs a consolidation pass, so lessons from today’s sessions are in the brain tomorrow. See GBrain.

Turn what agents make into apps on a private shelf

When a session produces something I’ll come back to, I ask for it as a small interactive app, not a chat reply that scrolls away. That covers a technical course for work, a brief from a discussion, a playbook, or a draft I’m writing. Each one gets its own auth-gated private URL and a card on a private hub page, grouped by topic. There are about forty so far.

The routine stays cheap because every app has the same shape:

• No build step. Each app is static files: React through htm and ES modules from a CDN, a shared sign-in gate, and one file per chapter. An agent can write it, and I can read the diff.
• Verify before shipping. Syntax-check every module as ESM (a CommonJS check passes things that break in the browser), then render every chapter in a headless browser. Behind a sign-in gate, one broken chapter just shows a blank page, and nobody files a bug about it.
• Commit to deploy. The session registers the new app on the hub and commits; CI deploys it. Nothing gets copied around by hand.
• Treat the gate as a door, not a vault. A client-side sign-in keeps casual visitors out, but the private URL is what actually keeps the apps hidden. Anything truly sensitive belongs somewhere with server-side auth.

Split scheduled routines so each fits its time limit

I dogfood each library I maintain nightly with cloud-scheduled Claude Code routines: a clean-room install from PyPI, using only the docs, filing a GitHub issue for each gap. One routine covering all six libraries kept timing out, because a scheduled run has a wall-clock limit. Six small routines, staggered across an hour, fit easily. Plan around the time limit, not the token budget.

Don’t let the author grade its own work

An agent reviewing its own draft is anchored to it. Use separate agents with separate prompts: one drafts, an independent one critiques; one proposes an idea, others each try to kill it on a single axis (already solved, too rare, infeasible, won’t be adopted). The ideas that survive are worth a human’s time. pm-system is built on this.

Launch interactive sessions in their own terminal

On Windows, starting claude through an inline powershell -Command re-parses the quoting. Long prompts get cut to their first word. Open a new terminal instead (wt.exe -d <folder> ...) and run the launcher script there.

---

Using something I should know about?

Tell me