test-project
Skill1 starsChanged 3 months agoMITView on GitHub
Run and evaluate a project's tests, and create the suite when a repo has none. Owns the suite shape (smoke, behavior, performance), the run-tests.sh runner, and the report each flag writes. Use to run tests, prove a change actually works, analyze current behavior, write or restructure tests, or when clean-project or resolve-project needs a real test run.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-sourceSkill
- analyze-videoSkill
- archive-projectSkill
- clean-projectSkill
- code-standardsSkill
- global-heartbeatSkill
- map-projectSkill
- notes-heartbeatSkill
- researchSkill
- resolve-projectSkill
- sleepSkill
The file
Files
test-project
Prove the code does what the project needs, then show the output that proves it. Report the behavior observed and what it means for the project's goals, with the real output pasted.
Load code-standards first. Tests obey the same minimalism, and its One runnable check rule governs what a single change earns: one check, never a suite. This skill runs the full shape when the whole project is under review.
Scaffold when missing
No tests/run-tests.sh means build it before running anything:
tests/
├── smoke/ # in-process, one promise per case, runs in seconds
├── behavior/ # drives the real binary over its real protocol
├── performance/ # timings and determinism, wants the machine to itself
├── reports/ # DATE_smk.md, DATE_behave.md, DATE_perf.md
│ └──.logs/ # raw runner output, last run of each suite
└── run-tests.sh # --smk, --behave, --perfScaffold only what the repo can support today. A library with no binary gets smoke/ alone, and the runner exits non-zero on --behave with a clear message instead of passing empty. Priority sets the ceiling: P0 earns smoke/, P1-2 add behavior/, P3 adds performance/ and the edge cases hardening implies.
The three suites
Flags combine (--smk --behave) and always run in the order below.
| Suite | Flag | Content |
smoke/ | --smk | One promise per case, checked in process against the library. No child processes, no sleeps, no report of its own. A case belongs here if it can name what it checks and fail for that reason alone. |
behavior/ | --behave | Run tests, then cross-reference real behavior against the project and task goals by inspecting the output (visually or otherwise) at each major step/module. Include your own assessment of behavioral/project-goal alignment in the report, and cite output (text, figures, images, gifs, etc) and reasoning. |
performance/ | --perf | Timings and determinism, skipped by default so an ordinary test run never pays for it. Only run when relevant to a change since its last run, and use AskUserQuestion before running. Every row assumes an idle machine, so the report records the machine and its load. |
Reports
Each flag writes tests/reports/DATE_{smk,behave,perf}.md, prints it back with the tables lined up, and exits non-zero if anything broke. Raw runner output for the last run of each suite lands in tests/reports/.logs/.
Paste the real output in chat. A failing suite is a result about the repo, never a reason to stop and never something to summarize away.
The shape is fixed
Add cases inside the suite they belong to, add a module inside a suite when a file gets unwieldy, and leave the rest alone: no fourth suite, no second top-level test target, no per-case report files, no renamed flags or report suffixes. If a change genuinely needs the shape to move, say so and ask first.
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.