sushi-killersushi-killer/sushiAI/.agents/skills/sushiai-testing/SKILL.md

sushiai-testing

Skill2 starsChanged 26 days agoMITView on GitHub

Choose proportional proof for a sushiAI change - which npm scripts, targeted node --test suites, desktop smoke or manual steps a diff needs - and read the results honestly. Use before claiming any change works, when a check fails, or when briefing functional-qa.

In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- author-and-verify-extensionSkill
- autoreviewSkill
- cut-releaseSkill
- deslopSkill
- extension-manifest-changeSkill
- figma-to-codeSkill
- ship-prSkill
- sushiai-taskSkill
- sushiai-uiSkill
- ui-evidenceSkill

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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:
Run a single file with node --test tests/<name>.test.cjs.
line 26
Very specific:
Never verify through npx; use the npm script or ./node_modules/.bin/<tool>.
line 36
Distinctive:
When a test needs a private address as input, build it at runtime.
line 49
Distinctive:
Do not hide a failure with retries, longer timeouts, weaker assertions or a refreshed baseline.
line 52

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

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

sushiAI testing

Prove the changed contract with the smallest meaningful check, then run the required gate once. Broaden only for a new change, a failure or an open risk.

Select the proof

Change	Proof
Any code change (required gate before commit)	`npm run ci` - the checks the change needs (below), conventions, eslint, prettier, `git diff --check`
A Rust crate, inner loop	`node scripts/test-rust.mjs --affected` - only the test binaries the change can affect
Manifest, registry, routes, IPC surface	`npm run test:contracts`
Extension loading or surface state	`npm run test:extensions`
Layout, navigation, workspace or chat state	`npm run test:core`
`src/app`, `src/extensions` or `electron/`	`npm run build`, then `npm run test:desktop`, and `$ui-evidence` when a screen changed
Terminal rendering or unicode	`npm run test:terminal`, `npm run test:unicode`
Daemon sessions, reattach, restart	`npm run test:desktop` (strict daemon smoke)
Startup or render cost	`npm run perf`
Docs, skills or agent files only	`npm run check:conventions` and `git diff --check`

Run a single file with node --test tests/<name>.test.cjs.

npm run ci prints what it selected and why (scripts/ci-changes.mjs, the same selector as CI). Do not run a whole suite by hand on top of it; run CI_ALL=1 npm run ci only when the selection itself is in doubt.

Read results honestly

The exit code is the verdict. Record echo $? or redirect to a file and read it back; a wrapper has printed a success line for a run that exited 1.
Never verify through npx; use the npm script or ./node_modules/.bin/<tool>.
Tests are .cjs files importing .ts through Node's type stripping: nothing type-checks at test time, so an assertion must exercise behaviour. A test that only matches a string in the source proves nothing.
npm run test:desktop tests dist/; it refuses a dist older than src. Build first.
tsc covers only src/; electron/ and tests/ rely on ESLint.

Writing tests

A regression test fails on the original defect before the fix.
Synthetic data only: 192.0.2.0/24 addresses, invented hosts and names. CI rejects private network addresses in src, electron, tests, scripts. When a test needs a private address as input, build it at runtime.
Temporary trees go under os.tmpdir() and are removed; require fs, os, path inside the test that uses them.
Do not hide a failure with retries, longer timeouts, weaker assertions or a refreshed baseline.

When a check fails

Separate a product defect, a test defect and an environment problem before changing anything. Fix failures the diff caused. Report a proven unrelated failure with its evidence instead of widening the task.

Download now (ZIP)

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

What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free