project-checks
Skill17 starsChanged 51 days agoMITView on GitHub
Scaffold a Makefile with language-specific check targets (lint, vet, fmt, vuln, test). Auto-detects project languages from marker files. Use when user says project checks, scaffold checks, add make check, or /project-checks. Not for running checks (the advanced-review preflight does that).
- Installs packages
In this repository37 other files it gives its agents.
- adrSkill
- android-kotlinSkill
- apple-swiftSkill
- autoresearch-promptSkill
- blog-writerSkill
- cloud-infrastructureSkill
- commitSkill
- cover-imageSkill
- freezeSkill
- gemini-reviewSkill
- golangSkill
- harness-mechanicSkill
- harness-traceSkill
- humanizerSkill
- ios-debuggerSkill
- knowledge-syncSkill
- learning-docsSkill
- learning-loopSkill
- obsidianSkill
- orchestratorSkill
- plan-forgeSkill
- process-clippingsSkill
- project-analyzerSkill
- pr-reviewSkill
- pythonSkill
- railsSkill
- react-nextjsSkill
- refine-requirementsSkill
- releasing-softwareSkill
- rubySkill
- scoreSkill
- second-opinionSkill
- skill-forgeSkill
- source-controlSkill
- terraformSkill
- test-design-reviewerSkill
- verify-frontendSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 49
If a Makefile already exists:
- Distinctive: line 51
Ask the user before modifying
- Very specific: line 54
If no Makefile exists: generate it directly.
- Distinctive: line 60
Add to CI pipeline
- Distinctive: line 85
After the advanced-review preflight says "no make check target found"
≈ “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
ABOUTME: Scaffold Makefile with language-specific check targets
ABOUTME: Auto-detect, generate, ask before modifying existing Makefiles
Project Checks (Makefile Scaffolding)
Generates a Makefile with a check target that runs lint, vet, format
checks, vulnerability scanning, and tests specific to the project's
language(s). The result is committed to the repo and used by CI, pre-commit
hooks, and the advanced-review preflight gate.
Trigger
Activate when the user says: "project checks", "scaffold checks",
"add make check", or /project-checks.
Execution Flow
Step 1 - Detect languages
Scan the project root for marker files:
| Marker | Language |
go.mod | Go |
pyproject.toml or setup.py | Python |
package.json | JavaScript/TypeScript |
Gemfile | Ruby |
Cargo.toml | Rust |
Multiple languages can be detected (e.g., Go backend + Python scripts).
Step 2 - Generate Makefile
Load the template for each detected language from templates/<lang>.mk.
Combine into a single Makefile with:
checktarget that depends on all language-specific sub-targets- Sub-targets:
lint,vet,fmt-check,vuln,test - Each sub-target runs the appropriate tool for the language
Step 3 - Handle existing Makefile
If a Makefile already exists:
- Show the diff (what targets would be added)
- Ask the user before modifying
- Merge new targets without touching existing ones
If no Makefile exists: generate it directly.
Step 4 - Report
Show what was generated and suggest next steps:
make checkto run all checks- Add to CI pipeline
- The advanced-review preflight will auto-detect and use it
Language Templates
Each template defines the standard tooling for that language. Templates are
in templates/<lang>.mk and use Make variables for tool paths so users can
override them.
Advisory targets (Go)
templates/go.mk also ships two targets that are deliberately outside
check, run by hand when a review needs a number instead of an argument:
| Target | Tool | Purpose |
crap | crap4go | CC, coverage and CRAP per function, from the standard coverage profile. Evidence for a finding, not a gate: no threshold (see rules/quality-gates.md, Finding Contract) |
mutation | gremlins | make mutation PKG=./internal/foo. Surviving mutants are evidence of tautological tests. Slow (recompiles and reruns the suite per mutant), so never in check or the inner loop |
Both install their tool on demand via go install when it is missing.
When to Use
- New project that needs a standardized check target
- Existing project without a unified lint/test/vuln command
- After the advanced-review preflight says "no make check target found"
When NOT to Use
- Project already has a working
make checkor equivalent - CI-only checks that don't make sense locally
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.