all-check
Skill0 starsChanged 2 months agoMITView on GitHub
Run every check the project has except e2e, scoped to the files of the current PR or branch, and report one line per check. Triggers — "/all-check", "run all the checks", "all checks except e2e", "check the PR files", «запусти все проверки», «прогони проверки по файлам PR».
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
Read scripts in package.json and sort them into the categories below.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
all-check
Goal: in one pass, run everything this project knows how to check except e2e, and report briefly — one line per check, findings limited to the files of the PR.
1. The PR files
- Base:
gh pr view --json baseRefName -q .baseRefName; with no PR, therelease/*branch the current one was cut from (git branch -r | grep release/), otherwisemain. - List:
git diff --name-only origin/<base>...HEADplus uncommitted work (git status --short). Save it to a file in the scratchpad and use that file from then on. - In zsh a variable is not word-split: pass the list as
${=FILES}or throughxargs.
2. Which checks
Read scripts in package.json and sort them into the categories below. Run everything that is
there and invent nothing: no script, no check.
| Category | Typical scripts | Scope |
| lint | lint:check, oxlint, eslint | PR files |
| format | format:check, oxfmt, prettier | PR files |
| types | tsc, typecheck | whole project |
| unit tests | test, vitest, jest | vitest run --changed origin/<base> (related tests); otherwise the PR's specs plus the specs of changed sources |
| mutation | mutate, stryker | --mutate 'a.ts,b.ts' as one comma-separated list of changed files that fall inside the config's mutate glob (usually services/stores/lib); always --force — the incremental cache lies when a file has only just gained a spec |
| build | build | whole project |
| duplication | jscpd, dup | whole project, filter the output by the base names of the PR files |
| architecture drift | drift, arch* | whole project, show the output in full (it is short) |
| dead code and exports | knip, dead* | whole project, filter by PR files, show the summary lines |
| React health | react-doctor | whole project, summary only |
Skip: anything matching e2e, playwright, staging, codegen, dev, deploy,
strip-comments, *:fix, *:write, openapi-ts, and mutate when no service files changed.
3. How to run them
- Light ones (lint, format, tsc) in a single call. Heavy ones (vitest, stryker, build, scanners) in parallel calls, but never alongside e2e: they starve each other on CPU.
- macOS has no
timeout; cap them with the tool's own timeout, 10 minutes for Stryker and build. - Stryker prints survivors for the whole incremental set: read only the table rows and the
[Survived]blocks for PR files. Put the full output in a scratchpad file and grep it. - A surviving mutant is a missing assertion, not a number. Leave equivalent ones and name them.
4. The report
A table: check → result → findings in PR files, one line each. On a separate line, findings that
predate the PR (confirm with git blame or a run on the base) — do not fix those silently.
Change nothing without asking, except formatting of files the PR already touches. If everything is
clean, say so in one sentence, no table.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.