skowalskidev
UserSimon's personal Claude Code config: rules, hooks, guards, and skills, structured as a reusable template you fork and make your own.
Categories
Indexed Skills (30)
claude-config-self-development-research
Research whether Simon's Claude config, his sk/sk-work skills, the third-party packs and the tools they depend on have fallen behind current community-validated practice — then propose the worthwhile changes for approval. Audits ~/.claude against primary sources and high-adoption repos, checks installed packs and CLI deps for drift and deprecation, and separately surfaces proven workflow practices he is not using yet. Use for "what am I missing", "is my Claude setup current", "research better ways to do this", "audit my config against best practice", or on a quarterly refresh. Proposes only; never applies a change without his yes.
maintenance-code-optimize-app
Simon's web performance + Lighthouse audit harness — run Lighthouse yourself via the debug Chrome (never ask Simon to paste JSON), measure on a PRODUCTION build (never next dev), and apply the verified fixes for media payload, image optimization, lazy-loading, CSP, and accessibility audits. Use for any "make it faster", "run Lighthouse", "audit performance", "the page is slow", or Core Web Vitals task.
ship-review
Unified pre-PR review using independent subscription-backed code review passes and a user-journey pass. Inherit the current chat's provider for every reviewer; never use API-billed reviewers. Find dead ends, missing states and unreachable steps before shipping. Use for "code review", "review my changes", "walk the whole flow", "walk through this as a user", "pre-ship UX pass". Judges work that EXISTS; whether it should be built at all is /sk:work-does-this-make-sense-to-build.
test-copilot
Test a feature WITH Simon rather than for him. Claude exhausts every machine-checkable thing first (build, types, tests, seeded states, its own browser pass), instruments the code with reason-coded logs and a correlation id BEFORE starting, then boots and identity-verifies its own dev server and paces Simon through the real user journey ONE step at a time while watching the logs live — so his eyes catch the UX gaps automated tests structurally cannot see, and Claude diagnoses each from the logs and fixes it. Use for "co-pilot test this", "let's test this together", "walk me through testing X", "my tests pass but the app is broken", or before shipping anything a human will click through.
work-full-detailed-workflow
Simon's full detailed working harness — plan-first with tickets, verify foundation assumptions empirically before building, tests-first as a tree, parallel sub-agents with tracked progress, observability, UX standards, scope discipline, PR/deploy hygiene. Apply to any substantive or multi-step task (feature, integration, refactor, or adopting someone else's work). Thin index — it points to the shared reference catalogs in ~/.claude/references/ that hold the detail.
work-superspeed
Run a task across real parallel Claude or Astra sessions, then reconcile in one warm session and log the run. Inherit the current chat's provider for the entire workflow. Cut exclusive file-ownership slices, dispatch each through `claude -p` or `codex -p`, verify on disk, assemble and gate the result, and analyse waste. Use for "run this in parallel", "fan this out", "split this across sessions", "full Astra workers", "superspeed", or any task that genuinely divides into 3-5 independent pieces. Not for work that does not divide.
meta-cleanup-worktrees
Safely clean up DONE git worktrees, their plan dashboards, and branches for this repo — remove only the ones that are provably finished (merged into master, clean, idle, and never the current or main checkout) and tell you which Conductor/Claude sessions you can archive. It lists and CONFIRMS before it deletes anything, stops only a dashboard viewer whose runtime receipt proves it belongs to that worktree, never force-deletes, and BLOCKS any worktree with another live session, uncommitted changes, unpushed commits, or an open/unmerged PR. It also OFFERS (opt-in) to delete the merged remote counterparts of the branches it removes — your OWN branches only, by tip author. Reuses bin/port-registry.sh + bin/kill-orphan-workers.sh for live-session detection and points to rules/process.md + references/dev-server-hygiene.md for the teardown rules. Use for "clean up merged worktrees", "remove done worktrees and branches", "delete finished dashboards", "tidy up my worktrees", "delete merged branches", "which sessions c
meta-dotclaude-copilot-start-here-for-any-task
The single skill to call for ANY task with this dotclaude config, so Simon never has to remember which skill fits. It finds or creates the session's one plan-backed dashboard, returns its link on request, routes the task to the right skills via references/skill-stack.md (verifying each is installed), presents the plan, and drives the whole job to a verified finish — keeping an always-visible progress bar (overall + nested sub-progress), applying each skill at its stage, and gracefully RESUMING the main thread after a tangent (a mid-task fix, a discovered todo). Callable at any stage; it re-reads the tracker and continues where the plan left off. Reuses references/skill-stack.md (the map), the task-intake gate, and rules/process.md (a tangent is a queued task; track every task to completion); it owns the single entry point, the progress bar, verifying skill names, and the resume. Use for "start here", "what should I use for this", "run this the right way", "just handle this", "which skills for this task", "cop
ship-verify-with-prod-data
Before shipping a change to a data-facing surface — a dashboard, a report, a total, a count, a funnel, a chart, any figure whose job is to reflect stored data correctly — prove it renders correctly and will NOT regress against REAL production data, across EVERY prod account with recent data, not one. Reads prod READ-ONLY through the provisioned path, enumerates every account/tenant/entity the surface serves, recomputes what each figure would show under the new code, and confirms they cross-verify to one source. Distinguishes a real code bug from a deploy/data-skew (prod written by the old code) or legacy residue (stale records the current writer no longer produces, dated to prove it), supplies a backfill or recompute the user runs on prod, and proves that backfill first on a seedable dev account. Use for "verify against prod data", "check it works for all accounts with real data", "make sure this won't regress on production", "look at recent data from all accounts", "does this add up across accounts", or befo
work-humanize-copy-side-by-side
Reword an interface's copy in your OWN voice through a two-pane side-by-side tool, then write the humanized text back into the source. Point it at a React/TSX interface (e.g. the landing page); it extracts every user-facing copy string, captures the real rendered screen 1:1 as an on-the-left reference, and builds ONE self-contained HTML file where the LEFT pane is the real screenshot with numbered anchors and the RIGHT pane is editable fields seeded with the original copy, each numbered to match its spot on the left and hover-paired to it. You reword only the fields you want and leave the rest; on hand-back it writes every string back into the .tsx/.ts files it came from. Because untouched fields still hold the original, apply is a safe blanket overwrite (no diffing) and every write is verified present in source afterward. Reuses the data-island and loss-free hand-back mechanics of /sk:ship-mockup-before-after; seeds voice guidance from rules/copy-quality.md but never auto-rewrites, you write the words. Use f
claude-config-self-optimize-analysis-after-run
Read the logs a run left behind and propose the specific changes that would make the next run faster, cheaper or less wasteful. Built for /sk:work-superspeed run directories (idle capacity, slice imbalance, ownership leaks, cache misses, rework, dead slices) but works on any run that left timing and token logs. Proposes only; never edits. Use for "why was that slow", "analyse the run", "optimise this", "what did we waste", "self optimise", or as the last step after any parallel run. Judges one run's execution; /sk:claude-config-self-development-research audits the whole config against outside practice.
claude-config-sync
Commit + push changes to Simon's ~/.claude config repo (his config source of truth — a private GitHub repo) SAFELY. Review the diff, NEVER commit secrets, write a conventional commit, push, confirm in sync. Use whenever ~/.claude has uncommitted config changes (the SessionStart hook flags them), right after editing any config under ~/.claude (CLAUDE.md, a hook, an sk/sk-work skill, settings.json), or when Simon says "sync my config" / "commit my config".
meta-report-standup-weekly
Write the short spoken standup report Simon reads aloud at the monday morning meeting. Gathers the window mechanically from git commits, GitHub PRs and Linear tickets, collapses them into outcomes, and emits punchy Last week / Today / Next bullets. Use for "standup report", "write my standup", "monday morning standup", "what did I do last week", or the weekly summary of work done.
plan-research
Answer a research question with a corroborated, ranked, cited TLDR instead of a single-source guess, for any topic or project. Decomposes the question into sub-questions, fans out parallel agents that search the web AND the codebase and production data, then adversarially verifies every load-bearing claim (attempt to refute it, require a second independent non-conflicted source, discount sources by their stake). Ranks the surviving options best-to-worst for the actual use case, corrects the asker where the evidence says so, and hands back a human TLDR with links, never word-vomit. Tracks tasks and sub-tasks as they arise, sends research questions to spin-off agents and reserves real decisions for the user, and self-improves at the end. Use for "research X", "deep dive on X", "what is the best or most popular way to X", "compare these options", "is this claim true", "corroborate this", "what do people actually do for X", or before a decision that turns on facts you do not already hold.
setup-connectors
Guided co-pilot to set up, health-check ("doctor"), add, or extend the connectors/credentials for the CURRENT project (Firebase, Linear, Stripe, Twilio, AWS, pal, …). Does everything it can automatically, then hands Simon numbered steps for the rest and waits. Use when connectors aren't working ("can't access Firebase/Stripe/Linear", "not enough permissions"), when first setting up a machine/project, when adding a new connector, to enable a one-off prod write, or to audit the existing setup for insecure credential handling (world-readable key files, a secret inside a repo, a CLI profile defaulting to the wrong work/personal account) and fix it. Reads the per-project manifest in ~/.claude/connectors/<project>.json; the deep spec is references/connectors-setup.md.
ship-pr
Simon's PR-authoring standard — every PR body STARTS with a human-readable Deploy TLDR (imperative, do-only numbered steps covering cross-repo order, build prerequisites, deploy commands, and the post-deploy smoke). Apply whenever creating a PR or finalizing one for review, in any repo.
ship-resolve-pr-comments
Work through every open review comment on a PR — read each one, judge whether it's valid (verifying against the code and researching online when the claim is checkable), fix only the valid ones, then reply to the thread author, resolve the thread, and commit each fix on its own. Invalid comments get a reasoned reply and are resolved too. When all threads are handled it pushes, swaps the review label back to pending, and re-requests review. Use for "resolve the PR comments", "address the review feedback", "handle the reviewer's comments", "reply to and resolve the threads", or after a reviewer leaves comments on a PR.
test-eyeball
Drive the changed frontend HARD in a real debug browser — fuzz edge inputs, hunt and FIX bugs, loop until a clean pass — on top of /sk:ship-screenshot-changes, which it REUSES for the capture (debug-browser login, port lane, figuring out what changed, seeding the state, screenshotting each surface with realistic inputs, the hand-back, and the opt-in GitHub-native PR post). Use for "go eyeball / QA / check my UI change in the browser". For a quick screenshot pass with no bug-hunt, use /sk:ship-screenshot-changes directly.
work-isolate-environment
Give this session its own lane of local dev ports, so two or more stacks can run at once instead of fighting over :3000. Allocates a stable slot per worktree, wires each service through the env knob it already reads, sweeps whatever a dead session left behind, and tears down clean. Use for "isolate my environment", "give this session its own ports", "run two stacks at once", "EADDRINUSE", "AxiosError Network Error", or when a second dev server will not boot. Works in any repo, personal or work, containerised or not.
work-preview-on-phone
Put this project's running dev server on Simon's phone over Tailscale, with login working, in any repo. Serves the local port to the tailnet only, adds the host to the dev server's cross-origin allowlist, mints a dev-only API credential when a referrer-locked key blocks auth, and tears the share down after. Use for "preview this on my phone", "test on mobile", "open this on my iPhone", "serve this over Tailscale", "check the mobile layout on a real device", or when a phone shows the page but nothing is clickable. Tailscale only, on purpose — it is tailnet-private, unlike a public tunnel.
claude-config-metrics-self-analysis
Run self analysis on Simon's dotclaude config from real usage metrics — surface the underused and silently dead parts, show which parts of my config are dead or barely used and the inputs that should reach them, and judge whether each low-usage part is warranted or a broken trigger to fix. Reads the dotclaude store (per-part usage, error and denial rates, recency, run backlog), scores every part two-axis (reachable × used), and proposes a trigger FIX so a dead part gets used — never a removal by default. Use for "run config self analysis", "surface underused config parts", "which parts of my config are dead", "config metrics", "what config is not being used", "analyse my config usage", "self optimise the config from metrics", or /sk:claude-config-metrics-self-analysis.
ship-preview-eyeball-with-prod-data
Show actual production account data in the changed app running locally before deployment, visually verify the affected screens, and leave a working local URL for review. Use for "preview locally with production data", "show real prod accounts on localhost", "eyeball production data before deploy", or "leave a local preview with real account data". Keep the source export read-only, isolate the preview runtime from production, and report source dates and any replay clock.
work-gauntlet-loop
Maintain every session's gauntlet record and continue all requested work to verified completion, including requirements added mid-conversation. Use for "gauntlet loop", "don't forget any requests", "keep going after tangents", "independent judge", or "live progress dashboard". Reuse the one living plan and its unfinished queue. Configure Ralph or independent judgement when requested; otherwise use current-session execution without an options interview. Resume a handed-off gauntlet from a pasted dashboard link with its recorded options.
work-ralph-loop
Run a Ralph loop to complete unfinished plan items with one fresh worker per item and no loose ends. Use for "ralph loop", "fresh worker per task", or "finish every plan item". Works alone or as the execution engine selected by Gauntlet. Reuse the permanent plan and live dashboard, verify each outcome, persist learnings, and resume from a checkpoint without losing evidence.
ship-check-merge-readiness
Check that a PR (and its stack + every open PR it needs/influences) will merge onto CURRENT master and work together as one assembled end state — rebase onto up-to-date master, close every in-scope gap so it lands harmoniously, and for anything owned by ANOTHER PR/person, keep it in that owner's scope (a ticket + a comment + an explicit BLOCKING line in this PR's Deploy TLDR) rather than doing it unilaterally. Use for "is this ready to merge", "make these land together with master", "check merge readiness", "assemble the open PRs", "is it ready to ship to prod as-is", or before flipping a stacked PR to ready.
work-checkpoint-wrap-up-safe-to-reboot-resume
Checkpoint all in-flight work so a computer RESTART (which wipes /tmp) and a later resume lose nothing — everything resume-critical moved out of /tmp and session memory into durable homes (pushed git branches, the Linear ticket, the .context plan), background agents/monitors/servers stopped cleanly, and a single RESUME BRIEF written that says exactly where to pick up. Use when stopping for the day, resuming later (e.g. Monday), about to reboot or shut down, or handing a long task across a break. Triggers "I'm done for today", "resuming Monday/later", "I'll restart my computer", "wrap up so it's safe to reboot", "checkpoint this so I can resume", or the explicit /sk:work-checkpoint-wrap-up-safe-to-reboot-resume.
work-consolidate-supersede-branches-prs
Consolidate several branches (and their PRs, if any) plus the latest base into ONE new branch that supersedes them all — merge each onto the others so every branch's changes propagate BOTH ways, reverse-merge the current base the same way, resolve every conflict for behaviour, build any additional asks on top, and hand it back as a superseding draft PR (or a bare branch) that closes the originals. Never touches master/the base; leaves the new PR draft. Use for "consolidate these branches/PRs into one", "supersede
maintenance-code-cleanup-repo
Full file-by-file repo cleanup — dead code, duplicated rules, doc drift, and organization — run as an audit → adversarial-verify → fix → re-verify loop that keeps the build and tests green throughout. Use for "clean up the repo", "clean up the codebase", "find dead code", "make this DRY", "the README is out of date", "reorganize this repo", or any request to remove rot without breaking behaviour. Also use before a big refactor, so the refactor starts from a repo with no dead weight in it.
work-ask-reply-in-full-before-after-artifact
When Simon is lost on what a reply means, or is weighing several options to decide among, answer with an INTERACTIVE decision ARTIFACT instead of chat prose: a plain-English explainer plus a BEFORE and AFTER preview and a verdict per option, grouped into sections. Every card and section is SELECTABLE with a COMMENT box, and Simon can PICK the items he wants and hand back exactly what he selected and commented (a copy-paste block, or a submit button when the runtime allows). Use for "I don't know what you're talking about", "explain this so I can decide", "give me the before/after", "make it selectable", or an explicit /sk:work-ask-reply-in-full-before-after-artifact.
work-ask-reply-tldr
Reply in bare-metal TLDR from now on — only what needs Simon's decision or attention, nothing he didn't ask for, no recap, no paragraphs — and keep doing it until he says otherwise. Works in ANY situation, not tied to a task. Use for "reply in tldr from now on", "just the answer, no paragraphs", "stop the paragraphs, give me clear-cut answers", "only tell me what needs my decision", "bare metal", or any time he wants terse decision-only replies.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.