Claude Skills by everywan-dev

Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.

Build a throwaway build-a-throwaway-prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Use when deciding whether a table, a file, or a service can be deleted because it looks unused. Measure real access, rename before deleting, and check the units of every counter.

Use before pulling someone else's code, skills, prompts or configuration into your project, and before publishing anything that contains them. Turns "it was on GitHub" into an obligation you can actually meet.

Use when deciding how much review a change needs, and of what kind. What the change touches decides the level — not how big it looks, not how confident you feel.

Use when something did not happen and nothing complained — no error, no alert, an empty log, a change with no effect. Teaches how to read absence as a symptom and where silence gets manufactured.

Use when a change is about to touch a running system. Backup, dry run, rollback and per-node verification, in that order.

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Use when checking whether curated knowledge is still fresh, reading freshness verdicts, or investigating why a unit shows drifted or unknown. Triggers on requests like "check freshness", "run the probes", "is this knowledge still current", "why does kb-0002 say unknown", or "read the knowledge index".

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Use when recording a new piece of curated knowledge -- a finding, a decision, a measured fact worth keeping and later re-checking for freshness. Triggers on requests like "record this as knowledge", "write a knowledge unit for X", "capture this finding with evidence", or "add this to curated knowledge". Do not use for a quick personal or project preference; that belongs to the keep-agent-memory-accurate skill instead.

Use when editing a configuration file a running process is reading. Unique anchor, keep the inode, validate before applying, verify every node.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Generate an interactive bash generate-a-setup-wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.

Use when a claim needs a second opinion that does not share your blind spots. How to ask a different model, what to send it, and how to settle a disagreement.

Implement a piece of work based on a spec or set of tickets.

Use when entering a system you did not build. The reading order that gets you oriented without breaking anything, and the false negatives that will fool you on the way.

Use when recording or updating a persistent agent-memory fact -- a user preference, a project fact, feedback, or a reference note the harness should remember across sessions. Triggers on requests like "remember that I prefer X", "note this project fact", "update this memory", or "this preference changed". Do not use for curated knowledge with evidence and freshness tracking; that belongs to document-with-evidence.

Use before committing configuration, when a secret has already been committed, or when adding a secret scanner. Covers why rotation beats scrubbing and why most scanners get switched off.

Use before shipping something that runs repeatedly — a job, a query, an agent loop, a pipeline. Estimates the recurring cost of a change while it is still cheap to change, and decides where spending less is safe.

Use before claiming a web change works. Reading HTML and CSS is not seeing the page — render it, in every theme, and look.

Use after an incident, or before shipping something whose failure would be invisible. Decides what to log, measure and alert on so the next failure announces itself instead of being discovered by a customer.

Use when documenting a system or auditing what is already documented. Records the edge of what is known, so that silence stops reading as "nothing there".

Use before exposing something, after inheriting a system you did not build, or when a security review says "looks fine". Finds who can reach what, the authorisation gaps scanners never report, and what not to put in the findings list.

Use when you do not know which skill fits the situation you are in. A router over every skill in this collection, grouped by what you are actually about to do.

Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.

Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

Use when you need to resolve an in-progress git merge/rebase conflict.

Use when a plan is written and about to be built. Reviews it from four deliberately different angles, because the objection that kills a plan is rarely the one its author was watching for.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".

Use when you are about to approve, merge or ship code an agent or another person wrote and you do not fully understand. Turns "it looks right and the tests pass" into a review that could have rejected it.

Use when something is failing and you are about to change code or config to fix it. Blocks the fix until you can say why it happens, and shows how to hunt a cause instead of confirming a guess.

Use before starting any change, to decide how much validation it needs and which model and effort to spend on it. Answers "is this a one-review change or a three-review change?" without arguing about it.

Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.

Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

Use when a project wants to adopt the validated-memory method -- bootstrapping curated knowledge and agent memory for the first time, wiring the harness's persistent memory to this project, or verifying an adoption is set up correctly. Triggers on requests like "adopt validated-memory here", "set up curated knowledge for this project", "bootstrap the memory layer", or "wire the harness memory symlink".

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

Use when a curated-knowledge unit turns out to be wrong, outdated, or replaced by better evidence. Triggers on requests like "correct kb-0003", "update this finding, it changed", "this knowledge unit is no longer true", or "supersede X with Y". Never use this to justify editing a unit's frontmatter or body in place.

Use when something that worked yesterday stopped working and you changed nothing, or before upgrading a dependency, runtime or platform. Also covers not doing this to your own consumers.

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Teach the user a new skill or concept, within this workspace.

Move issues and external PRs through a state machine of triage-issues-and-prs roles, categorise, verify, grill if needed, and write agent-ready briefs.

Turn a decision you can't fully answer into a questionnaire for someone else to fill in.

Use when writing or trusting anything that decides pass/fail — a test, a linter, a scanner, a health check, a monitor. Makes the checker prove it can fail before you believe a green result.

Use when about to report something as done, working or fixed. Turns "it looks right" into a check that could have failed.

Use when work has to survive a break in continuity — end of a session, end of a day, passing a task to someone else. Writes the handoff that carries the evidence and names what was never checked.

Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.