0xmortuex
UserA curated pack of 16 Claude Code skills for the unglamorous work that ships software - ship-it, readme-forge, security-sweep, git-rescue, devlog, and more. Each one researched first: only problems no prominent existing skill solves. No 40-skill kitchen sink.
Categories
Indexed Skills (19)
atomic-io
Find and fix non-atomic writes to local state files — config, checkpoints, caches, lockfiles — that leave a truncated or corrupted file on disk after a crash, `kill -9`, OOM-kill, power loss, or full disk. Use when the user reports a config/state file that came back empty or unparseable after a crash or forced restart, when reviewing or writing any code that opens a path in write mode (`open(path, 'w')`, `json.dump`, `yaml.safe_dump`, `pickle.dump`, `torch.save`, `.write_text()`) to persist application state a process reads back later, or when the user asks "how do I save this safely" / "make this crash-safe" / "atomic write". Covers the temp-file-fsync-rename fix, directory fsync, single-writer locking, validate-on-read recovery, and Windows-specific EPERM/antivirus-lock retries on rename.
backfill-pilot
Write or review a production data backfill/repair safely — the one-off script that updates millions of live rows to fix bad data, populate a new column, or migrate a format. Use whenever the user needs to "backfill", "fix the data in prod", "migrate existing rows", "run a one-off script against the database", or shows an UPDATE/DELETE meant to touch a large or live table. These scripts are written once, run once, and have no test suite — which is exactly why they destroy data more often than any other kind of code.
changelog
Turn git history since the last release into a human-readable changelog or release notes, grouped by type of change and written for the people who use the software, not the people who wrote it. Use this whenever the user is cutting a release, asks for release notes, a changelog, "what changed since the last version", wants to update CHANGELOG.md, or is tagging a version. Also use when someone needs to summarize a range of commits into something a user or stakeholder would read.
clock-sweep
Audit code for datetime and timezone correctness — naive/aware mixing, local-time storage, DST-unsafe arithmetic, server-timezone assumptions, date-vs-instant confusion. Use when the user reports a time-related bug ("times are off by an hour/a day", "wrong date for some users", "broke after DST"), stores or schedules anything time-based, or asks "handle timezones properly". Also use proactively when you see `datetime.now()`, `new Date()` without a zone, or epoch±86400 arithmetic in code you're already touching. Time bugs are silent — the code runs and returns plausible values for the wrong moment — so audit systematically, never spot-fix.
codebase-tour
Orient someone in an unfamiliar codebase — the entry points, the architecture, the request/data flow, and where you'd go to make a given change — by reading the actual code and mapping it, not by summarizing the file tree. Use this whenever the user is new to a repo, asks "how does this work", "where do I start", "walk me through this codebase", "how is this organized", "where would I add X", or has just cloned/inherited a project and needs to get productive. Also use when onboarding to a large or undocumented codebase.
devlog
Turn today's REAL coding activity into a short dev-diary entry and commit it to a journal repo. Use when the user says "devlog", "write today's entry", "log today", "update my diary/journal", or wraps up a session with "note down what we did today". Also handles "devlog week", "weekly rollup", or "summarize this week", which distills the week's already-written daily entries into one summary instead of re-reading git history. Grounded in actual git history and past entries — never invented; if nothing happened, it writes nothing. Great for learning-in-public, TIL streaks, and future-you archaeology ("when did I fix that and why?").
env-detective
Diagnose "works on my machine" divergence — a test/build that passes locally but fails in CI (or on a teammate's machine, or in Docker, or in prod) with the SAME code. Use whenever the user says "passes locally but fails in CI", "works for me but not for them", "only fails in Docker/on the server", "green here, red there", or shows a CI failure they can't reproduce. The bug is in the DIFFERENCE between the two environments, and this skill finds it by diffing environments systematically instead of rereading the code for the fifth time.
erasure-guard
Audit whether a "delete my account" / erasure feature actually removes a user's data everywhere it's copied, not just the primary table an ORM cascade covers. Maps every destination data reaches — replicas, caches, search indices, materialized views, analytics pipelines, third-party processors, warehouse snapshots, backups — checks whether deletion calls into each one, and classifies each as must-hard-delete, acceptable-to-anonymize (retained financial/audit records), or acceptable-"beyond use" until cycle-out (backups). Distinct from `tombstone` (unused code, not an active deletion feature), `secret-spill` (credentials, not user data), `stale-guard` (general cache correctness), and GDPR/DSAR compliance packs (consent workflow, not this completeness check). Use when adding/reviewing a deletion endpoint, when a new data store might not be wired into it, or when asked "does deleting a user delete everything", "GDPR erasure audit", "right to be forgotten", or "where does user data still live after deletion".
git-rescue
Recover work that looks lost in git — after a bad `reset --hard`, a botched rebase or merge, a commit on the wrong branch, a deleted branch, a lost stash, commits orphaned in detached HEAD, or a force-push that overwrote history. Use this the moment the user says anything like "I lost my changes", "my commits are gone", "I reset and now it's empty", "the rebase destroyed everything", "I committed to main by accident", or "someone force-pushed over my work". Also use it BEFORE running any recovery command the user suggests themselves — panicked users propose destructive fixes.
import-guard
Review a user-facing bulk import feature (CSV/XLSX/JSON upload, "import contacts", "bulk create from a spreadsheet") for the three failure modes that make bulk import untrustworthy — a single bad row aborting or corrupting the whole batch, the response lying about what actually landed (silently skipped rows counted as success), and re-uploading the same file creating duplicates instead of upserting cleanly. Distinct from `backfill-pilot` (an engineer's internal ops script against a live prod table) and `job-warden` (queue/cron idempotency) — this is a customer-facing upload endpoint ingesting untrusted, messy user files. Use when adding or reviewing a bulk/CSV/spreadsheet import feature, when asked "does this import handle bad rows right", "what happens if the upload fails halfway", or "will re-uploading duplicate everything".
migration-guard
Review a database schema migration for production hazards BEFORE it deploys — table locks that freeze traffic, data loss, deploy-order breakage, and irreversible steps. Use whenever the user writes or shows a migration (SQL, Alembic, Django, Rails, Prisma, Drizzle, Laravel…) and is about to ship it, or asks "is this migration safe", "will this lock the table", "can I run this on prod". Trigger on any ALTER TABLE / CREATE INDEX / column drop or type change headed for a database with real data — even if the user only asks you to "write a migration", guard your own output too.
portability-audit
Audit a codebase for Windows/POSIX portability hazards and fix them — hardcoded path separators, CRLF/LF assumptions, shelling out to POSIX-only commands, reserved Windows filenames, case-sensitivity collisions, exec-bit and signal differences. Use when the user says "make this work on Windows/Linux/Mac", "a Windows user reported it's broken", "cross-platform", "why does this fail on Windows", or before publishing a CLI/dev tool to an audience that includes both platforms. Also use proactively when you notice platform-specific code in a project that claims to be cross-platform.
readme-forge
Write or overhaul a project's README by reading the actual codebase — the real entry points, dependencies, scripts, and config — not by guessing from the project name. Use this whenever the user asks to create, write, improve, rewrite, or "make a proper" README, wants better documentation for a repo, is preparing a project to be public or shared, or says their README is thin/outdated/embarrassing. Also use when someone wants their GitHub project to look more professional or get more attention, since the README is the first thing visitors judge.
rollout-guard
Review a mobile app release, staged rollout, or forced-update decision for failure modes specific to shipping through an app store, not a backend deploy. Checks for a defined rollout halt threshold (crash-free rate, ANR rate) instead of "eyeball it," that incident response doesn't assume App Store/Play Store review turnaround is a hotfix SLA, that a forced (blocking) upgrade is reserved for genuinely critical cases rather than a default nudge, and that the backend tolerates old client versions nobody can force to update. Use for a mobile release plan, a staged/phased rollout, "should this be a forced update," an app-store hotfix under time pressure, minimum-supported-version/version-gating logic, or a kill-switch/remote-config flag standing in for a client fix. Distinct from skew-check (backend mixed-version windows in minutes) and ship-it (deploy checklists) — this is the client-binary distribution tail, in weeks to years, plus the review clock neither accounts for.
security-sweep
Review the working changes (or a named set of files) for real, exploitable security problems — injection, authz gaps, secret leaks, unsafe deserialization, SSRF, path traversal, and the like — and report only findings you can justify with a concrete attack path. Use this whenever the user asks for a security review, a "security check", wants to know if a change is safe to ship, is touching auth/crypto/file-uploads/user-input/database queries, or says things like "any vulnerabilities here", "is this exploitable", "audit this endpoint". Also use before shipping code that handles untrusted input or secrets.
ship-it
Run the repo's own checks (tests, linter, type-checker, build), fix what breaks, then write a clean conventional-commit message and a review-ready summary of the diff. Use this whenever the user is about to commit, push, open a PR, or says "ship it", "commit this", "is this ready", "clean this up before I push", or otherwise signals they want work finalized — even if they don't name the individual steps. Also use it when someone asks you to verify a change is safe to land.
skew-check
Review a change for mixed-version deploy hazards — the window during every rolling/canary deploy when OLD and NEW code run at the same time against shared state. Use before deploying changes that touch queue/event message shapes, cache or session serialization, RPC/API payloads between your own services, feature-flag payloads, or anything persisted that another version will read. Trigger on "is this safe to roll out", "will this break during deploy", canary/rolling-deploy prep, and proactively when a diff renames or retypes a field that crosses a process boundary.
stale-guard
Review caches and derived data for CORRECTNESS — completeness of invalidation, key scoping, and drift between a source of truth and its copies (Redis/memcached entries, memoization, denormalized columns, materialized views, search indexes, CDN caches). Use when the user reports staleness symptoms ("users see old data", "it shows the wrong user's data", "search doesn't match the database", "works after a refresh/logout"), adds or modifies caching, or asks "is this caching correct". Performance skills add caches; this one proves the existing ones can't serve wrong data.
tombstone
Prove — with production evidence, not just a repo-wide grep — that an externally-reachable API endpoint, database column/table, exported package function, or infrequent scheduled job is actually unused before deleting it. Use when the user asks "can I delete this endpoint/column/table", "is this still used", "nobody calls this anymore, right?", or is about to remove code reachable from outside this repo (other services, mobile clients on old app versions, third-party webhooks, BI tools querying the DB directly, quarterly/monthly batch jobs). Static dead-code tools (knip, ts-prune, vulture, depcheck, plain grep) only prove "no reference inside this repo" — this skill covers the gap between that and "actually unused," and is not a static-analysis tool itself.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.