Claude Skills by skowalskidev

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...

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...

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 on...

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".

The ONE way to change the user's OWN PRIVATE Claude config (~/.claude — the instruction files Claude reads) — whether folding in a correction, adding a standing rule, OR creating/editing/removing a whole part (a new skill, a rule file, a reference catalog, a hook, a bin script, a connector manifest, settings wiring). A hard-blocking hook stops ad-hoc ~/.claude edits outside this flow, so route ANY config change through here. NOT the built-in /update-config, which edits settings.json hooks and...

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.

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.

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. It also OFFERS (opt-in) to delete the merged remote counterparts of th...

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). Callab...

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.

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 a...

Keep ONE living, source-of-truth plan file instead of re-writing or re-explaining the plan every time it changes. It updates only the SECTIONS a request touches (surgical edits, so the plan never drifts or needs re-reading whole), prepends a dated Changelog entry naming what changed, and shows you ONLY the changed section(s) in chat as the delta — so you read the change, not the whole document. It stays LOCKED in plan-mode: every new request, correction or idea folds back into the single plan...

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 f...

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 me...

Simon's full SHIP harness — drive a FINISHED PR or branch through the whole verify-and-ship sweep: assemble onto master, verify every ticket's acceptance criteria and the user + system journeys across the whole diff with a test per verdict, multi-model + security review, resolve every review thread, screenshot the UI, meet the Deploy-TLDR standard, then reconcile and hand back. The counterpart to /sk:work-full-detailed-workflow, which builds; this proves and lands what is already built. Apply...

Show Simon what a planned change will LOOK like, before it is built, as a shareable before/after mockup instead of a plan he has to read and imagine. The mockup is ONE self-contained HTML document whose entire state lives in an embedded JSON spec (a data island) and whose UI renders from it — so another Claude can rebuild it with zero loss. It is pixel-true to the real app: a compressed real screenshot of the target screen as the BEFORE, an HTML/CSS overlay sized from the real components' MEA...

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.

Hand back one glanceable end report when a piece of work is finished, then make sure the code actually does what we planned. Reports what the user goes through, what the system does under the hood in steps, and what changed on this branch against its base, cross-checking the two journeys and stating every mismatch. Then it finds the plan or ticket the work was validated against and judges whether the post-merge journeys still match the plan: every acceptance criterion gets an independent verd...

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 revie...

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 t...

Quickly screenshot the changed frontend surfaces for documentation — no bug-hunting, no waiting for anything you don't need. Figures out what changed (git diff), seeds the account into the state the change is meant to be seen in, drives each changed surface in a real debug browser with realistic example inputs, captures each — circling the change with a rounded-rectangle callout, and for a visual change a BEFORE/AFTER pair — hands them back (opened in Finder), and — opt-in, only with an open ...

Exhaustively test a finished diff or PR AUTONOMOUSLY — no human in the loop, safe to leave running overnight. Enumerates every feature the diff added (git diff + the plan's acceptance criteria + the Linear tickets), then holds each to TWO stages: Stage 1 traditional deterministic tests (unit/integration/e2e, happy path AND all edge cases, writing the missing ones), and Stage 2 Claude-as-judge reasoning (reads the real inputs/outputs + trajectory, judges against the feature's intent + acceptan...

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 lo...

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...

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 k...

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 ...

Build a feature WITH Simon as an agile copilot loop, not waterfall. Each round builds the proposed interface in the real app with realistic SIMULATED data FIRST — no backend, it only has to look real — then walks him through it as a first-time user (previewable frontend) or shows the user-and-system journey in TLDR previewable form (backend), gets his feedback, and builds the backend for that slice ONLY after he confirms the UX and journey are right. Then it repeats, each loop showing what's ...

Work out whether a proposed piece of work should be built at all, before any of it is. Takes a ticket, a feature request, a plan or a rough idea; reasons from first principles to the outcome it is really for; splits it into separately-decidable parts; and gives each part an evidence-backed verdict — build, build-but-changed, refuted, already-done, defer, or a decision only Simon can make. Researches to REFUTE rather than to agree: checks the codebase, real production data, the premises the ti...

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.

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 ma...

Two-level, hand-run parallelism that sits ON TOP OF /sk:work-superspeed, not in place of it. The OUTER layer is you: the orchestrator commits a clean START commit and writes ONE durable plan file split into fully self-contained paste-and-forget parts (each carries the whole shared context, its owned files, the git branch-off-START ritual, the repo setup steps, and a fixed report-back block), and you paste each part into its own separate Claude session. The INNER layer is superspeed: each sess...

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 wor...

Simon's live experiment harness — prove a feature or fix works by iterating against the REAL platform pipeline (real endpoints, real session/prod data, run in localhost as production would) BEFORE implementing it. User-driven loop: change only what's specified, show every asset + the exact payload and confirm before each billable/outward submit, read the real result, iterate to success, capture the working recipe, then tear down the scaffolding. Use for "let me test this before I build it", d...

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 ...

Spin ONE idea off into its own parallel Claude session as a throwaway branch, while THIS session keeps working — and DON'T merge it back on finish. For a spur-of-the-moment "what if" you want out of the way of the main work and may bin after a look: the orchestrator commits a clean START, hands you one paste-and-forget block for a new session, and polls a shared status file so you relay nothing. When the offshoot reports done it HOLDS — surfaces its branch and any screenshot/preview for you t...

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 t...

TODO — not built yet. The THIRD and outermost layer of the parallel stack: /sk:work-warpspeed sits ON TOP OF /sk:work-hyperspeed, which sits on top of /sk:work-superspeed. Where hyperspeed runs many hand-run sessions on ONE machine/account, warpspeed spreads a whole hyperspeed relay across MULTIPLE VMs/VPSs on DIFFERENT accounts/orgs — the only thing that actually breaks the per-org rate ceiling. Each machine runs its own hyperspeed (many sessions, each superspeeding its slice). Placeholder o...