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 (22)
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.
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".
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.
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.
ship-review
Unified pre-PR review — multi-model code review (gstack Claude + Codex everywhere; WORK adds pal Gemini + GPT-5, PERSONAL adds a pal-free personal-key Gemini pass; work/personal aware) plus a user-journey pass that walks the whole flow through in order as a first-time user, so a diff that reads fine but leaves a dead end, a missing empty/loading/error state, or a step nobody can reach is caught before it ships. 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.
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-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-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.
work-superspeed
Run a task across real parallel Claude sessions instead of in-session subagents, then reconcile in one warm session and log the run so it can be made faster next time. Cuts the work into slices with exclusive file ownership so no two slices do the same job, dispatches each as its own `claude -p` process, verifies every slice on disk, assembles and gates the result, and writes a waste analysis. Use for "run this in parallel", "fan this out", "split this across sessions", "superspeed", or any task that genuinely divides into 3-5 independent pieces. Not for work that does not divide.
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.
meta-cleanup-worktrees
Safely clean up DONE git worktrees 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, never force-deletes, and BLOCKS any worktree with a live session, uncommitted changes, unpushed commits, or an open/unmerged PR. 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", "tidy up my worktrees", "delete merged branches", "which sessions can I archive", or /sk:meta-cleanup-worktrees.
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 reads the task, routes it 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", "copilot this whole thing", or /sk:meta-dotclaude-copilot-start-here-for-any-task
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.
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-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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.