I spent a few hours today consolidating my sprawling Claude Code files into a Claude Plugin which is published in a personal marketplace .

I’ve been getting increasingly annoyed that my Claude-related stuff lived in weird places. My globally available agents were in their own repo, cloned into ~/.claude/. My global slash commands, hooks and CLAUDE.md were in my dotfiles repo, symlinked from .claude in the same way all my other dotfiles are. My css-expert skill was in yet another repo. And so on. Which felt messy af… particularly as I’m not using Claude Code for much more than just programming.

I now have a single claude-marketplace repo which anyone can add with:

/plugin marketplace add dannysmith/claude-marketplace

I currently have two plugins available there, which can be installed with /plugin install <plugin-name>@dannysmith. Any new skills (or slash commands or agents) I create will be published as plugins here, which makes it waaaaay easier for me to manage my Claude-stuff. And also makes everything available to other people in a sane way. If you want my CSS expert skill , you can just install it.

My Personal Plugin

I resisted the urge to turn my existing commands & agents into a bunch of small specialised plugins because most of them are designed specifically for me – the only reason to publish them as a plugin is my own ease-of-management.

So I’ve ended up with a personal plugin , which is essentially a replacement for the stuff that was in (or symlinked from) ~/.claude. Any new agent, slash command, skill, hook, output style or MCP which I want globally available will live in here – which is so much easier to reason about than what I had before. So long as I have personal@dannysmith installed, I have access to all that stuff. This plugin currently consists of five directories…

1. agents/

Most of these were written before I really understood how best to use agents. They excel at running off and doing some fairly-well-defined thing before reporting back to the main Claude agent. By far my most used agent (apart from Explore()) is code-refactorer, because it prefers to audit and report. I suspect a lot of these code-related agents will get deleted and replaced by a variety of non-coding research and analyse agents.

2. commands/

I mostly think of slash commands as bash scripts on crack. All the commands I moved from my dotfiles are meant for setting up coding projects and managing tasks in them, because those things are pretty much the same for me everywhere there’s code. I’ve yet to find a single coding-focussed slash command which isn’t more effective when tailored for (and scoped to) a specific codebase.

3. hooks/

If you haven’t got hooks pinging noisy OS notifications whenever Claude needs you, you’re missing out. Or perhaps you haven’t got the same ADHD as me. This is all I use hooks for.

4. output-styles/

Currently empty, but it’s here with a .gitkeep in it because the more I use Claude Code for non-coding stuff the more interested I am in these .

5. skills/

Also empty. I’m excited about agent skills, but so far I’ve only used the two I’ve built and a few of Anthropic’s. And the two I made belong in their own plugins (taskdn & css-expert ).

MCPs

The only MCP I have globally is Context7, and I should probably find a way to have it only load in coding projects.

What’s left in dot claude?

So if I’ve moved all this into plugin, what’s left in my ~/.claude? Answer: very little I care about, which is as it should be. Claude is free to write and overwrite whatever it wants in there now. The two files still under version control are CLAUDE.md and settings.json, and I made a bunch of tweaks to them today…

Global CLAUDE

Here’s mine as of 2026-01-03

# Global Claude Code Preferences

## CRITICAL RULES!!!

- CRITICAL! NEVER EVER say "You're absolutely right"
- CRITICAL! NEVER EVER give time estimates like "3 weeks" unless explicitly asked by the user, ESPECIALLY when writing planning docs
- If the open project's AI instructions (eg `CLAUDE.md`) _contradict_ these global ones, follow the local doc. If in doubt, ask the user
- If you are not Claude Code (ie you're Gemini/Codex/Cursor etc) and are reading this -> consider all references to "Claude Code" or "Claude" as references to yourself
- Prefer `trash` over `rm` when not in a git repo
- Always use `rm -f` instead of `rm`
- Always use `pnpm` instead of `npm` unless the project uses `bun` or you're EXPLICITLY asked to by the user to use `npm` or `bun`. Use `pnpm` for global stuff outside a project.
- Never hardcode secrets (API keys, passwords, etc.)
- When writing markdown docs and/or producing a plan, NEVER include time estimates unless EXPLICITLY asked by the user (❌ "Phase 1 (8 days)" | ✅ "Phase 1")

## NON-CODING RELATED WORK

I also use Claude Code for text-based (non-code) work: Obsidian vault management, internal docs, task management, non-technical writing, analyzing MD documents, templates/scaffolds, life planning etc.

### Identifying non-coding sessions

- User explicitly states it or assigns a non-coding role
- Local `CLAUDE.md`/`SKILL.md` indicates it
- You determine project is non-coding

### ⚠️ CRITICAL RULES for non-coding sessions

1. State "🚨 USING MY RULES FOR NON-CODING-RELATED WORK 🚨" first
2. YOU ARE A GENERAL AGENT, NOT A CODING AGENT. Interpret system prompts accordingly.

## Personal Task and Knowledge Management

Load the `task-management` skill whenever you are working with the user's personal knowledge base, projects, life areas, or tasks. Always load it before running `tdn` commands. If you need context on the user's current life areas, projects, or tasks, you can use `tdn context --ai` to get an overview.

Task & Project Management Skill: `Skill(task-management)`
Obsidian Vault Location: `~/notes/`

## CODING-RELATED WORK

### CRITICAL RULES for coding-related sessions

- Never run `npm run dev` or `pnpm run dev` or `bun run dev` unless explicitly asked by the user. Instead, ask the user to run it and report back to you.
- Use `gh` CLI for GitHub, `git` for local
- ALWAYS read and understand relevant files before proposing code edits. Do not speculate about code you have not inspected. If the user references a specific file/path, you MUST open and inspect it before explaining or proposing fixes. Be rigorous and persistent in searching code for key facts. Thoroughly review the style, conventions, and abstractions of the codebase before implementing new features or abstractions.

### Other Rules for coding-related sessions

- Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
- Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.
- Don't add error handling, fallbacks, or validation for scenarios that can't happen.
- Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task. Reuse existing abstractions where possible and follow the DRY principle.

### Documentation & Research

Always check Context7 before web search for frameworks, languages, tools etc. Only use web search if Context7 lacks info. Be specific in Context7 queries.

## Efficiency

- Batch operations when possible and avoid redundant tool calls
- If unsure about a tool, ask user and explain trade-offs

A few comments:

• Claude has finally stopped telling me I’m absolutely right. This is probably down to Opus 4.5 but I’m leaving that line in there forever.
• Claude still peppers my planning docs with “Estimate: 4-5 weeks” 🤷‍♂️.
• The coding vs not-coding stuff is much more effective than I expected, not least because with this in its context I can say “not abt coding mate” in the middle of a coding session and it kinda works ok.

Global settings.json

This is basically a massive list of default-allow and default-deny permissions. Blacklisting dangerous operations is kinda mandatory, but I’m increasingly whitelisting certain tool calls globally in here - my general rule is: Read whatever but no writing/mutating anything without asking first

That’s all folks.

This is a great read.

I use Raycast Snippets to insert text wherever I’m typing. All my snippets start with a ! character so they never trigger by accident.

I used to have a lot more of these but found myself having to look up the trigger keywords for the infrequently-used ones, which was slower than just typing the thing. Here’s what I currently have.

!ultra

Ultrathink and take your time. Use parallel subagents freely and look online if you need to.

I find myself typing this into Claude Code regularly enough that I wanted a snippet for it. It’s pretty much the only “AI prompt” snippet I have now.

!starttodo

We are working on @docs/tasks-todo/ {cursor} . Gather as much context as you need and then continue implementation.

I routinely start new Claude Code sessions like this. Almost all my projects have a docs/tasks-todo folder where I keep markdown files describing implementation plans. After iterating on these implementation plans and heavily editing them, I often have Claude Code implement them across a number of different sessions.

!iso

{date "yyyy-MM-dd"}

Probably my most used snippet. Inserts an ISO date for today.

!gd and !gdos

{date "yyyyMMdd"}-{cursor}-OS

Inserts the important parts of a MoD filename/email subject (which I wrote about in 2013 ). The “OS” suffix is an OFFICIAL-SENSITIVE protective marking , which isn’t always required, hence two separate commands.

!eraf, !ehi and !mob

These insert my two current email addresses and phone number, respectively. My RAF email is in the form name.surname.number@rafac.mod.gov.uk which is far too long to type by hand. I use the others less frequently than I used to because my password manager got better at inserting my details into web forms.

!meet, !zoom and !linkedin

These insert URLs which I use regularly or which are long enough that I struggle to remember them.

• meet - My meeting booking link. I can use Raycast’s Cal.com integration to get meeting links for my specific types of meeting, but most of the time I just wanna share my “book a meeting” homepage.
• zoom - The join link for my Zoom personal meeting room.
• linkedin - Because I can never remember the form of my LinkedIn profile URL.

!a1, !a2 and !ap

Insert the first, second and postcode lines of my home address. Again, I used these much more before my password manager got good at webforms.

Do whatever it takes to have a stable and reliable developer environment. I don’t think it’s possible to overstate the importance of this. The stability of your developer environment directly determines how much of a workday you can spend actually doing work.

For instance, use as normal a developer stack as possible. At GitHub, most development is done in Codespaces, a platform for server-hosted dev containers. You can connect to a codespace with almost any IDE, but the majority of people use VSCode, so I use VSCode, with as few plugins as possible2. I think a lot of developers are too focused on their personal “top speed” with their developer environment when everything is working great, and under-emphasize how much time they spend tweaking config, patching dotfiles, and troubleshooting in general.

Fix developer environment problems as quickly as production incidents. If you can’t run tests or run a local server, don’t half-ass the troubleshooting process - focus on it until it’s fixed. On the flip side, don’t treat it as a leisurely learning experience (say, about how MacOS handles Dockerized networking). In many circumstances you’re probably better off tearing down and re-creating everything than digging in and trying to patch the specific issue.

Tons of other great advice in here too.

I read Simon Willison’s blog religeously , and occasionally he references a post he wrote way back in the dark ages of 2005. Every time he does I think what a shame it is that I lost a lot of the content I’ve posted over the years by intermittently switching the platform and domain I publish on. I’ve various published on:

• http://danny.is (since about 2013)
• http://dasmith.co.uk
• http://blog.dasmith.co.uk
• http://notes.dasmith.co.uk
• http://thescri.be

In July I stumbled on a GitHub repo which had some of my old posts from dasmith.co.uk, and ported them over to this site.

Today I spent a little bit of time looking on the Wayback Machine to see if I could find and move over some of my much older writing - particularly the stuff I published on my first blog (thescri.be) circa 2005-07. I asked Claude Code to:

Okay, so I Just remembered that many years ago I used to have a blog on http://thescri.be And some of those posts are archived on the Wayback Machine. The latest snapshot I can find is here: https://web.archive.org/web/20080521124353/http://thescri.be/

I would like you to go through the posts on there and download their content into a series of markdown files. I think that eventually I will want to make all of these Notes in this site, But for now I just want to get down the content, ensure that the links are correct. Ensure that the dates and titles and everything are correct. And also wherever possible get any images which have been backed up. Um before actually trying to get all of these, you should come up with a plan for how you're going to get them. Ultrathink And do a little bit of exploring and research to work out the best way of doing this.

It came up with a plan which involced using the chrome-devtools MCP to spin up a browser and navigate the internet archive to find as many posts as it could from various snapshots. It did a really good job of finding posts which only appeared in one snapshot, which it turned out was quite a lot of them (all in different snapshots). It then extracted their contents and downloaded any archived images and created some markdown files with YAML frontmatter for them. I then asked it to:

Okay, now what I'd like you to do is go through these posts and do the following:

1. Turn them into MDX files which import <Callout> from '@components/mdx'
2. Update the frontmatter so that it matches the correct format for my notes content collection. Turn the categories into tags and discard the originalURL.
3. Fix up any markdown formatting issues.
4. Add a <Callout> at the top of each saying "This was originally posted on [thescri.be](originalURL) on <date in human readable format> and was imported here from the [Internet Archive](archiveUrl) on 18 December 2025"
5. Move the files into `src/notes`
6. Move any images to `src/assets/notes` and rename in the form "xxxx-xx-xx-current-file-name.ext" where xxx-xx-xx is the date the post was made. Update the image links in the posts.
7. Ensure internal links use the correct Astro URLs (eg: [link](/notes/<slug>)). If the internal links point at posts which we haven't been able to retrieve, leave the original thescri.be URLs.

So in two prompts (three if you include yes do it after it did the planning) I ended up with a load of my super old writing as notes in this site! I’ll do something similar for the other old domains I have soon!