Borrowing it
Nothing to install: this file belongs to c9r-io/orchestrator. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/c9r-io/orchestrator/main/.claude/skills/align-tests/SKILL.mdgit clone --depth 1 https://github.com/c9r-io/orchestratorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/c9r-io/orchestrator/align-tests)<a href="https://agentmods.dev/skills/c9r-io/orchestrator/align-tests"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/align-tests/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/c9r-io/orchestrator/align-tests"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/align-tests.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00072 | $0.01199 |
| Opus 5.5 | $0.00029 | $0.00480 |
| Sonnet 5.5 | $0.00014 | $0.00240 |
| Haiku 4.5 | $0.00007 | $0.00120 |
Grade A, and why
align-tests scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Align Tests
Run a strict formatting + test-alignment workflow after major refactors.
In this repository, discover Rust workspace commands from Cargo.toml and frontend commands from gui/package.json. For other targets, derive commands from their own build files before running anything.
Workflow
- Scope the impacted areas.
- Inspect changed files with
git status --shortandgit diff --name-only. - Prioritize test suites by changed modules. Typical mapping:
- Backend (
core/or equivalent) → language-native unit/integration tests. - Frontend (
gui/) → JS/TS unit tests, Playwright, build, and type checks when relevant.
- Backend (
- If the project layout differs, discover module boundaries from the directory structure and build configs.
- Run formatters and fix code style.
- Auto-detect and run the appropriate formatter for each affected area:
- Rust:
cargo fmt --all— appliesrustfmtto the entire workspace. - TypeScript / JavaScript: inspect
gui/package.jsonfor a formatter or linter and use its declared scripts. Do not invent a formatter dependency. - Other languages: use whatever formatter the project already configures (
go fmt ./...,black .,mix format, etc.).
- Rust:
- After formatting, check
git diff --statto confirm what changed. - If formatting produces changes, continue with the rest of the workflow — these will be included in the final commit.
- Do not skip this step even if the refactor seems small; CI pipelines typically gate on formatting.
- Run unit tests first, then broaden.
- Backend (discover from project config):
- Rust: run a focused package test first, then
cargo test --workspacefrom the repository root. - Other languages: use the project's existing test command (
make test,go test ./..., etc.).
- Rust: run a focused package test first, then
- Frontend (discover from
gui/package.json):cd gui && npm test.- Use
npm run buildfor TypeScript/build drift andnpm run test:e2ewhen browser behavior is in scope.
- Analyze failures by root cause.
- Classify each failure:
- Refactor signature drift (function/argument/type changed).
- Behavior change (assertion no longer matches intended logic).
- Test fixture/mock drift (mocked dependency contract changed).
- Environment/order issues (state leakage, async timing).
- Prefer preserving intended product behavior; only update expectations when behavior change is intentional.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 99 lines · 72 tokens per session scan A 67db2082da7b
align-tests is a skill published in the GitHub repository c9r-io/orchestrator (21 stars, last pushed 1mo ago), licensed MIT. It adds 72 tokens to every session and 1,199 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
codew-release-qa-sweep
Use before claiming Codewhale release work is done: run the full gate sweep and list the manual QA targets.
cw-dogfood
Use when a Codewhale change needs proving in the real product, or when asked to build/install/dogfood the local binaries: stamped release build, atomic install, fresh-shell verification, and the manual QA that gates cannot cover.
cw-gates
Use before claiming any Codewhale change is done, green, or ready to land: the focused-to-broad verification ladder, the budget checks CI enforces, and the rules for what counts as a passing test.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
verification-before-completion
Use when about to claim work is complete, fixed, or passing, or before committing or creating PRs.
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.