These are my mad programming skills for my llm friend named claude.
I use this script to create symlinks to my home .claude/skills so I can access these system-wide.
git clone git@github.com:sean-michael/skills.git ~/skills
~/skills/install.shIt's fully idempotent so re-running will add missing skills and not overwrite anything that I already have.
For example:
$ ./install.sh
up to date grafana-dashboards
linked python-docs
up to date ui-uxThe symlinks ensure that the skills are always up to date with whatever the local git dir has.
I've included skills for specific use cases borne from my experience developing platform infrastructure and DevOps automation tools.
Everyone wants them but nobody wants to make them! Some people do, I don't really because I lack creativity in this visual sense. I know what's definitely not good though and I've attempted to distill some best practices of design and operational function here.
The main goals are:
- provide a 5-second glance status check for an application
- never commit dashboards with broken queries
That's pretty much it. The LLM friend needs to be told that it should in fact validate that the queries it writes are actually possible to gather.
In a similar vein as the grafana dashboards I often struggle to articulate the first time what a 'good' design or intuitive ui-ux experience looks like to an LLM agent. I definitely know what doesn't look good and after reading some blogs and design articles and whatnot I started to put together some key facets that could be transcribed in a skill.
These are pretty basic right now like, every user interaction should have a response, use color theory and give icons and colors semantic meaning, green is good, yellow is warning, red is error, etc.
Sometimes I'll ask claude to write documentation for a codebase but this requires frequent updates as new features are added at the speed of whatever token rate anthropic is willing to give me.. so I figured we should probably act like adults and use mkdocstrings to make the code the source of truth.
The philosophy behind this skill is I don't want to bog-down the context of normal coding operations with a full trigger of the skill, instead I'll give some existing code and ask claude to create the docstrings. This way future claude sessions or agents will pickup on the patterns of docstrings in the context and intuitively continue it.
I also added some specifics on deploying with github pages using github actions. This is well documented online so I didn't feel the need to explicitly call out the implementation steps there.
This was born out of a necessity to instill some semblance of security best practice when creating web applications. Honestly anything that is exposed to the public internet should be considered 'production' in some sense so that it's treated with the respect it deserves to be properly secured. Even if the data behind it is inconsequential, I don't want to leave something to chance like forgetting I stored some personal info or left a backdoor open.
Claude already has a lot of training data on this topic but sometimes I have to specifically prompt it to surface the basics. The model is optimizing for a quick resolution of a request like "build me a fastapi application" and not exactly diving deep into rate limiting, auth models, token storage, etc.
The skill encodes the things Claude consistently skips without being told; IDOR ownership checks, httpOnly cookies, middleware-layer rate limiting, single-use hashed reset tokens, structured logging with request IDs. The goal is that invoking the skill is enough for Claude to pickup the vibe.
I really like Obsidian as a note taking and personal knowledge organization tool, but I am horrible at keeping it organized. I start off with good intentions and then slowly it gets derailed.
This skill is two things:
-
CLI integration — teaches Claude to use the official Obsidian CLI (shipped in v1.12.4) rather than reading and writing
.mdfiles directly. Going through the CLI means moves update internal links, creates apply templates, and frontmatter stays valid. The skill defers toobsidian helpfor command discovery so it stays current as the CLI evolves. -
PKM system — codifies a PARA-based vault structure (Projects, Areas, Resources, Archive) and conventions for how notes should be created, linked, and maintained over time. The goal is self-documenting work: decisions, tradeoffs, gotchas, and project history captured as things happen rather than reconstructed later.
The skill is intentionally vault-agnostic so it can be used anywhere. Vault-specific context (project names, folder paths, daily note template) gets provided at prompt time.
Developing applications for iOS was completely new territory for me, having never owned an iOS device until recently. I used claude code heavily to build out an MVP and learned a lot along the way of what methods work to close the feedback loop with the model and the product. I knew that if I was going to run something directly on my phone to test, it had better not crash from a missing library import!
The skill is built around a strict validation loop — TypeScript clean, expo-doctor clean, launched without crash on at least two simulator sizes, every screen screenshot-verified. The model isn't allowed to declare done until all of those pass. That single constraint prevents the most common failure mode: Claude writing code that looks fine in the editor but panics at runtime because a native module wasn't re-linked after install.
The other thing that took real trial and error to figure out was how to drive the simulator programmatically. xcrun simctl io booted tap does not exist, despite what the model will confidently tell you. The skill encodes the actual options: a globalThis.__navigateTo helper wired into the Metro debugger for navigation and state inspection, xcrun simctl io booted screenshot for visual verification, and physical mouse clicks as a last resort. This gives the agent a real feedback loop without needing me to pick up my phone for every change.
It also captures a handful of React Native / Expo footguns that Claude consistently stumbles over without being told: Supabase's SecureStore adapter and detectSessionInUrl: false requirement in RN (the web client config silently breaks auth on mobile), the --simulator vs --device flag distinction (using the wrong one triggers code signing prompts), and the native rebuild requirement whenever a native-code library is added. The stack is opinionated to move quickly and ship.
Have you ever wished that you could sit back at the end of a long day of vibe-coding and, vibe some more? Maybe vibe all night! Into the morning! That's what this skill does. It's inspired by my workflow I've been using lately and in an informal way where I plan and write a detailed spec and then have a roundtable session of claude code to plan, implement, and review.
There are three modes:
-
PLAN — interactive session where you brainstorm and Claude helps you decompose the work into a properly risk-tagged task list. The key insight here is that "done" has to be objectively verifiable. If you can't write a test or a command that proves the task is complete, it's not ready to run unattended.
-
RUN — headless execution loop. Agents work through the task list in dependency order, write a scratchpad per task, and produce a digest you can read when you're back. Compaction gates prevent the session from thrashing as context fills up.
-
AUDIT LOOP — spawns an auditor agent that reads your spec and scores the codebase against it across dimensions like auth, API completeness, test coverage, and production polish. Findings get converted into tasks, an executor implements them, and the loop repeats until the score hits your threshold or something gets too risky and requires a human in the loop.
The risk model allows tasks to be tagged safe, review, or risky, and risky tasks are hard-blocked by default. This operates under the assumption that there's a git repository backing the codebase for tracing and reverts. Anything touching live infrastructure — applying to a cluster, executing terraform — gets flagged as risky and won't run unless you specifically tell it to.
Usage:
# Night before — plan your work interactively
claude
> Night shift planning: add rate limiting to all auth endpoints,
write missing tests for the workflow service, scaffold the new
deployment unit reconciler
# Review the task list, then leave
# Next morning (or whenever) — run it
export CLAUDE_CODE_TASK_LIST_ID="devops-platform-api-nightshift-20260125"
claude --headless "Run the night shift. Read NIGHT_SHIFT_MANIFEST.yaml and follow the night-shift skill RUN mode."
# For the audit loop
claude --dangerously-skip-permissions --headless \
"Run night-shift audit loop. Read NIGHT_SHIFT_MANIFEST.yaml, follow night-shift skill AUDIT LOOP mode."