Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/dork-labs/dorkos/testgit clone --depth 1 https://github.com/dork-labs/dorkosWhat 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 | $0.00014 | $0.00872 |
| Opus 5 | $0.00007 | $0.00436 |
| Sonnet 5 | $0.00003 | $0.00174 |
| Haiku 4.5 | $0.00001 | $0.00087 |
Grade A, and why
test 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 2d 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 — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Failure Debugging
Debug and fix the failing test(s) described by $ARGUMENTS (a test file path, a test name pattern, or empty for the whole suite). Load the debugging-test-failures skill — it carries the methodology (read the failing test first, distinguish test bugs from implementation bugs, verify the fix would fail on wrong code). This command adds the project-specific ground truth below.
Running tests in this repo
pnpm vitest run <path-to-test-file> # ONE test file — fastest loop (~1-2s)
pnpm vitest run <path> -t "test name" # One test case within a file
pnpm vitest run apps/server/src/services # Positional filter — a directory or substring
pnpm test -- --run # Full suite via Turborepo (single run, no watch)
Gotchas:
- Never use bare
pnpm vitest runfor full runs — outside Turborepo it misses per-package env setup and falsely fails 2 tests in the dev environment. Full runs go throughpnpm test -- --run. If a failure only reproduces under bare vitest, suspect this before suspecting the code. - Vitest filters are positional (path or name substrings after
vitest run), plus-tfor test-name patterns.--testPathPatternis a Jest flag and is invalid here. - Snapshot updates:
pnpm vitest run <path> -u— only after confirming the change is intentional. - Stale
@dorkos/shareddist after a pull causes false-red type errors in tests — rebuild withpnpm --filter @dorkos/shared build.
Project testing patterns
Full conventions: .claude/rules/testing.md and contributing/ testing guide. The essentials:
- Tests live in
__tests__/alongside source; Vitest withvi.mock(). - Client component tests: need
/** @vitest-environment jsdom */, React Testing Library, and a mockTransportviaTransportProvider(createMockTransportfrom@dorkos/test-utils). Missing jsdom directive or missing Transport wrapper are the two most common setup failures. - Server route tests: use
FakeAgentRuntime+TestScenariofrom@dorkos/test-utils, never hand-rolled runtime mocks. If theAgentRuntimeinterface grew a method,FakeAgentRuntimetests fail to compile — that's intentional. - SSE integration tests: message POSTs are trigger-only 202s; collect frames from the durable stream with
collectDurableEvents(@dorkos/test-utils) and always passuntilfor live streams. - SDK-level scenarios: builders in
apps/server/src/services/runtimes/claude-code/__tests__/sdk-scenarios.ts— importable only insideservices/runtimes/claude-code/(ESLint SDK boundary).
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.
- 2d ago First seen · 49 lines · 14 tokens per session scan A 2323836c64d6
test is a command published in the GitHub repository dork-labs/dorkos (9 stars, last pushed 2d ago), licensed MIT. It adds 14 tokens to every session and 872 once invoked, about $0.0001 per session on Opus 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-31.
Other commands, from other repositories
fest-show
Show festival progression (in-progress tasks, roadmap, and dependency view).
swarm-planner
Generates a structured execution plan with dependency tracking using the Swarms-inspired planning methodology.
review-queue
Display and manage the human review queue for parallel autonomous operations.
feature
End-to-end authoring workflow for The Claude Code Bible — verify claims against the real tool, split chapters into path-disjoint slices, draft with parallel agents in this ONE checkout (never worktrees), fix TOC + cross-links, commit by path and merge. Reads intent from the prompt.
app-impact
Before merge, map every changed file to declared downstream consumers.
taskrunner-add
Add a task to the autonomous queue.