Agent skill

Running Tests

by ZaxbyHub in ZaxbyHub/opencode-swarm

Safe test execution patterns for opencode-swarm. An agent skill from ZaxbyHub/opencode-swarm.

MITAuto-check passed

Install Running Tests

skills CLI
$ npx skills add ZaxbyHub/opencode-swarm --skill running-tests -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ZaxbyHub/opencode-swarm running-tests --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ZaxbyHub/opencode-swarm.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.opencode/skills/running-tests .claude/skills/running-tests && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
running-tests
GitHub stars
494
Token cost
~4k tokens
SKILL.md length
1,603 words
Files
1
Skills in repo
91
Repo updated
First seen
Licence
MIT

At a glance

Safe test execution patterns for opencode-swarm. An agent skill from ZaxbyHub/opencode-swarm.

  • SKILL.md covers Graph-first evidence contract, ⛔ The Scope Rule That Prevents…, Three-Layer Defense Against… and Decision Tree: test_runner…, plus 10 more sections
  • Calls bun, git and gh

What it does

Running Tests is an agent skill from ZaxbyHub/opencode-swarm. Safe test execution patterns for opencode-swarm. Covers when to use the testrunner tool vs shell bun commands, scope safety rules, per-file isolation loops (bash and PowerShell), pre-existing failure verification, CI log reading, and failure classification. Load this skill when you need to run tests — not when you need to write them (see writing-tests for authoring guidance).

Its SKILL.md is about 4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It works with Bash and PowerShell. The repository describes itself as: Architect-centric agentic swarm plugin for OpenCode. Hub-and-spoke orchestration with SME consultation, code generation, and QA review. The licence is MIT.

Example prompts

  • “/running-tests”

What it can do on your machine

Read from SKILL.md and the folder at commit b63a4bd. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bun
    • git
    • gh
    • npm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, gh and npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Running Tests loads about 4k tokens when it runs. Until then it costs about 98 tokens; SKILL.md has 1,603 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~98
When it runs · the whole SKILL.md, loaded when a task matches
~4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ZaxbyHub/opencode-swarm at commit b63a4bd, republished under its MIT licence (© ZaxbyHub). 1,603 words, ~4,040 tokens.

Download SKILL.mdSave it as .claude/skills/running-tests/SKILL.md (or your agent's skills folder).
name
running-tests
description
Safe test execution patterns for opencode-swarm. Covers when to use the test_runner tool vs shell bun commands, scope safety rules, per-file isolation loops (bash and PowerShell), pre-existing failure verification, CI log reading, and failure classification. Load this skill when you need to run tests — not when you need to write them (see writing-tests for authoring guidance).
audience
swarm-plugin

Running Tests for opencode-swarm

This skill is about executing tests safely. For writing tests, see writing-tests.

Graph-first evidence contract

Use repo_map test_pack only to discover focused candidate tests; Bun/shell output remains execution authority. Graph evidence is advisory only. If freshness is stale or inconclusive, confidence is low, source is missing, the language is unsupported/dynamic, the graph is absent, or the action fails, select tests from direct source, imports, and repository conventions.


⛔ The Scope Rule That Prevents Session Kills

convention discovery accepts one source file at a time (or explicit direct test files). graph and impact discovery accept a bounded normalized source array of up to MAX_SAFE_TEST_FILES = 50. Do not exceed that input cap or respond to scope_exceeded by widening to scope: 'all'.

The final unique resolved-test cap still binds for every discovery scope: when resolution produces more than 50 test files, test_runner returns scope_exceeded without executing them. Split a larger graph/impact selection into intentional bounded batches.


Three-Layer Defense Against Session Blocking

test_runner bounds source selection and resolved test execution before a session can fan out without limit:

Layer 1 — Scope-specific normalized-input guard

convention rejects more than one source file for convention discovery. graph and impact reject more than MAX_SAFE_TEST_FILES = 50 normalized source files before fan-out. Explicit direct test files remain allowed for convention scope.

Layer 2 — Advisory resolution estimate

For graph and impact, estimateFanOut(sourceFiles, workingDir) reads the cached impact map and reports a bounded, advisory count of unique candidate tests without spawning subprocesses. Resolution metadata preserves whether the estimate was advisory or unavailable and any cache status; it is not a substitute for the final cap.

Layer 3 — Bounded traversal + final unique-test check

Graph and impact traversal are bounded to the safe budget and report scope_exceeded when the budget is exceeded. After fallback, normalization, and deduplication, the final unique testFiles.length is compared with MAX_SAFE_TEST_FILES; an excess returns scope_exceeded before execution.

Result: When fan-out exceeds the safe threshold, the session gets outcome: 'scope_exceeded' instead of hanging.


Decision Tree: test_runner tool vs bun shell command

Do you need to run tests?
│
├─ Single test file, targeted validation
│   └─ Either works. Prefer shell: bun --smol test <file> --timeout 30000
│
├─ Multiple test files in the same directory (e.g. all agents tests)
│   └─ Shell only — per-file loop. These are explicit test files, not graph/impact sources.
│
├─ Find tests related to ONE OR MORE changed source files (up to 50 normalized files)
│   └─ test_runner is fine: { scope: 'graph', files: ['src/agents/coder.ts', 'src/tools/test-runner.ts'] }
│      (graph/impact input is bounded; final unique resolved-test cap still applies)
│
├─ Find tests related to MORE THAN 50 changed source files
│   └─ Split into intentional bounded graph/impact batches or use a shell loop.
│      Do not use scope:'all' as a fallback.
│
└─ Validate the entire repo (pre-push)
    └─ Shell only — 5-tier suite from commit-pr skill. Never test_runner scope:'all'.

Scope Safety Reference

ScopeWith files: [one]With files: [many]Notes
'convention'✅ Safe❌ Rejected for multiple source files (scope_exceeded)One source file for convention discovery; direct test file paths exempt
'graph'✅ Safe✅ Up to 50 normalized source files; >50 rejectedAdvisory estimate and bounded traversal; final unique resolved-test cap still applies
'impact'✅ Safe✅ Up to 50 normalized source files; >50 rejectedAdvisory estimate and bounded traversal; final unique resolved-test cap still applies
'all'❌ Never❌ NeverEnv-gated (SWARM_ALLOW_FULL_SUITE=1); CI mirror only

Rule of thumb: Pass one source file to convention; pass a normalized array of at most 50 source files to graph or impact. Use a shell loop or intentional batches when the source selection or final resolved test set exceeds 50.

For one named Go or CTest test, bypass file discovery with an exact native selector:

  • Go: { scope: "target", native_target: { framework: "go-test", name: "TestName[/Subtest]", path: "relative/package" } }
  • CTest: { scope: "target", native_target: { framework: "ctest", name: "ExactTestName", path: "relative/build-dir" } }

The target name is treated literally, the directory must stay within the project root, and the runner never falls back to a broader package or build-tree sweep.


Per-File Isolation Loops

CI runs agents/tools/services in per-file isolation (one bun --smol process per file). Reproduce this locally with the following loops.

bash (Linux / macOS)
bash
# Single directory — per-file isolation
for f in tests/unit/agents/*.test.ts; do
  bun --smol test "$f" --timeout 30000
done

# Multiple directories
for dir in tests/unit/tools tests/unit/services tests/unit/agents; do
  for f in "$dir"/*.test.ts; do
    bun --smol test "$f" --timeout 30000
  done
done

# Stop on first failure (useful for debugging)
for f in tests/unit/agents/*.test.ts; do
  bun --smol test "$f" --timeout 30000 || { echo "FAILED: $f"; break; }
done
PowerShell (Windows)
powershell
# Single directory — per-file isolation
Get-ChildItem tests/unit/agents/*.test.ts | ForEach-Object {
  bun --smol test $_.FullName --timeout 30000
}

# Multiple directories
@('tests/unit/tools', 'tests/unit/services', 'tests/unit/agents') | ForEach-Object {
  Get-ChildItem "$_/*.test.ts" | ForEach-Object {
    bun --smol test $_.FullName --timeout 30000
  }
}

# Capture output (avoids truncation on large output)
Get-ChildItem tests/unit/agents/*.test.ts | ForEach-Object {
  bun --smol test $_.FullName --timeout 30000
} | Out-File "$env:TEMP\test_out.txt"
Get-Content "$env:TEMP\test_out.txt" | Select-Object -Last 50

Common PowerShell pitfalls:

  • for f in ...; do — invalid, use Get-ChildItem | ForEach-Object
  • Select-String -Last N — invalid parameter, use Select-Object -Last N
  • 2>&1 2>&1 — duplicate redirection, causes parse error; use 2>&1 once
  • && — not supported in PowerShell 5.1; use ; if ($?) { cmd2 } instead
  • bun test --exec bash — fails on Windows hosts with ENOENT (bash is not available in standard PowerShell). Use bun test directly or a PowerShell-based loop instead.
  • After bun install --frozen-lockfile --force, non-elevated Windows shells can hit EPERM while reading refreshed node_modules entries. Treat that as a host permission/access issue: rerun the same focused Bun command with approved/elevated access before diagnosing it as a code or test failure.

Batch vs Per-File: Which Directories Need Isolation?

DirectoryModeReason
tests/unit/tools/Per-file loopHeavy mock.module usage; cache poisoning risk
tests/unit/services/Per-file loopSame
tests/unit/agents/Per-file loopSame
tests/unit/hooks/Per-file loopSame
tests/unit/cli/Batch OKFewer mock conflicts
tests/unit/commands/Batch OKFewer mock conflicts
tests/unit/config/Batch OKFewer mock conflicts
tests/integration/Batch OKIntegration fixtures, not mock-heavy
tests/security/Batch OKAdversarial inputs, no module mocks
tests/smoke/Batch OKBuilt-package tests

Truncated Output Recovery

When bun test output exceeds the bash tool's buffer, it is saved to a file with an ID like tool_dff778.... This ID format is not accepted by retrieve_summary (which only reads S1, S2 etc. format IDs). The output is effectively lost.

Prevention — pipe to a file explicitly:

powershell
# PowerShell
bun --smol test tests/unit/agents --timeout 60000 |
  Out-File "$env:TEMP\test_out.txt"
Get-Content "$env:TEMP\test_out.txt" | Select-Object -Last 50
bash
# bash
bun --smol test tests/unit/agents --timeout 60000 2>&1 | tee /tmp/test_out.txt
tail -50 /tmp/test_out.txt

To get a clean pass/fail summary only, filter immediately:

powershell
# PowerShell — show only summary lines
bun --smol test tests/unit/agents --timeout 60000 |
  Select-String "pass|fail|error" |
  Select-Object -Last 10
bash
# bash
bun --smol test tests/unit/agents --timeout 60000 2>&1 | grep -E "pass|fail|error" | tail -10

Verifying Pre-Existing Failures

Before documenting a failure as "pre-existing," prove it exists on main without affecting your working tree. Use a Git worktree — safer than git stash (stash can drop untracked files, fail on locked files on Windows, and leave you in an inconsistent state).

bash
# bash — create a throwaway checkout of main
git worktree add /tmp/repro-check origin/main
bun --smol test /tmp/repro-check/tests/unit/agents/architect-workflow-security.test.ts --timeout 30000
git worktree remove /tmp/repro-check
powershell
# PowerShell — same pattern (use Join-Path for robust separator handling)
git worktree add "$env:TEMP\repro-check" origin/main
$testPath = Join-Path "$env:TEMP\repro-check" "tests\unit\agents\architect-workflow-security.test.ts"
bun --smol test $testPath --timeout 30000
git worktree remove "$env:TEMP\repro-check"

Decision after checking:

  • Fails on main too → pre-existing. Document under ## Pre-existing failures in PR body. Continue.
  • Fails only on your branch → you introduced it. Fix before pushing.

⚠️ Check your own session history first. Before documenting anything as pre-existing, confirm you did not fix or update this test earlier in the current session. A test you fixed 20 messages ago is not pre-existing — listing it as such in the table or PR body is incorrect and will be caught in review.


Show full SKILL.md (701 more words)Show less

Placeholder Scans Without Diff Line Numbers

placeholder_scan is diff-aware: when you can supply added_lines (a map of workspace-relative file path → added line numbers from the task/PR diff), its verdict covers only the added lines, so a pre-existing TODO/FIXME on an unchanged line inside a changed file no longer fails the gate. When you CANNOT map a file's added lines (new/untracked file, no diff access) — or the computed added-line set is EMPTY — omit that file from added_lines entirely: the tool scans it unfiltered, fail-closed, and you manually cross-check that file's findings against the changed lines before treating a finding as introduced by the change. NEVER pass an empty line array for a file (an empty array suppresses every finding in it) and NEVER hand-enumerate guessed line numbers: a wrong added_lines map silently suppresses findings.


Failure Classification

Not all failures are equal. Before deciding what to do, classify the failure:

ClassDefinitionExampleWhat to do
Stale assertionTest checks for text/value that was deliberately removedexpect(prompt).toContain('CONSTRAINT: [what NOT to do]') — template removed in refactorUpdate the assertion to match current state
Soft regression indicatorTest checks a threshold the codebase has since exceededexpect(tokenCount).toBeLessThan(35000) — prompt grew past limitFix the threshold or reduce the prompt; do not just document and ignore
Genuine pre-existingFailure exists on main unrelated to any recent changeSee the quarantine ledgers (scripts/ci/quarantined-tests*.txt)Document in PR body; do not fix unless scoped
New regressionFailure introduced by your changesTests for prompt text you removed without updating testsFix before pushing

Stale assertions and soft regression indicators are actionable — they signal drift between tests and code. Genuine pre-existing failures are not your responsibility to fix in this PR, but they must be documented.


Reading CI Failure Logs

When a CI job fails, the GitHub Actions log shows the exact file:line of the failure. Do not guess — read the log.

bash
# Get the failing job URL from the PR
gh pr view <number> --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion=="FAILURE") | .detailsUrl'

# Fetch and search the log (if gh CLI available)
gh run view --log <run-id> | grep -E "FAIL|error" | head -20

Or open the detailsUrl directly in a browser / via WebFetch and search for:

  • (fail) — Bun test failure marker
  • error: — parse or runtime error
  • at <anonymous> — stack frame pointing to the test file and line

Once you have tests/unit/agents/some-file.test.ts:354, reproduce locally:

bash
bun --smol test tests/unit/agents/some-file.test.ts --timeout 30000

Quick Reference: Common Failures and Causes

SymptomLikely causeFix
scope_exceeded returned from test_runnerConvention received multiple source files, graph/impact received >50 normalized sources, or final resolution exceeded 50 unique testsSplit graph/impact inputs into bounded batches or reduce the source scope; never widen to scope:'all'
Session killed during test_runnerPre-fix: unbounded fan-out on multiple filesNow returns scope_exceeded instead — no more session kills
mock.module breaks unrelated testsMissing spread of real module exportsAdd ...realModule spread
Windows tests fail with EBUSYmock.restore() called while child process holds lockAdd test.skipIf(process.platform === 'win32')
Test output truncated, ID unreadableBash tool buffer exceededPipe to Out-File/tee explicitly
for f in ...; do parse errorBash syntax in PowerShellUse `Get-ChildItem
Select-String -Last N errorInvalid PowerShell parameterUse Select-Object -Last N
Token budget test failurePrompt grew past hardcoded thresholdTreat as soft regression; update threshold
CONSTRAINT assertion fails after refactorTest checks for removed format templateUpdate assertion to match current prompt
package-check CI failurepackage-check validates the npm tarball (npm pack + tarball contents) — a source/build/package-manifest problem, not generated-file driftdist/ is generated and NOT committed — do not stage it; run bun run build locally only when you need the bundle. There is no longer a committed-dist drift check.

Tree-sitter / WASM test timeouts

Tests that exercise tree-sitter (any test calling extractFileSymbols or loading a web-tree-sitter grammar) may take several seconds on first WASM module load. Depending on the code path, tree-sitter is reached via the dynamic symbol-graph import or the externalized runtime import; either way, the first Parser.init / grammar load in a process is slow.

  • Use --timeout 60000 (not 30000) for test files that load tree-sitter grammars.
  • If the test_engineer agent gets stuck (no output for extended time), run the test file directly via bash with a longer timeout (--timeout 120000) to determine whether it's a WASM first-load delay or a genuine code failure.
  • Classify the timeout before returning the test_engineer to the coder — a WASM-load timeout is infrastructure, not a code bug.
  • Each test process loads WASM independently (no cross-process cache), so every file's first grammar load is slow.

© ZaxbyHub, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .opencode/skills/running-tests of ZaxbyHub/opencode-swarm.

Open the folder on GitHubat commit b63a4bd

Compare with similar skills

Running Tests next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Running Tests compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Running Tests this skillZaxbyHub/opencode-swarm494—~4kAutomated safety check: PassMIT
Hf Cloud Sagemaker Iam Preflightwaybarrios/opencode-power-pack534—~1.6kAutomated safety check: PassApache-2.0
Tbtoolsxuzhougeng/wispterm443—~2.3kAutomated safety check: PassMIT
Rtk Skillsopaco/deepwiki-rs3.1k—~1.4kAutomated safety check: PassMIT
Project KnowledgeJanDeDobbeleer/oh-my-posh24k—~564Automated safety check: PassMIT
Niubashunixwin/niubash163—~2.1kAutomated safety check: PassMIT

Similar skills

  • Hf Cloud Sagemaker Iam Preflight

    waybarrios/opencode-power-pack

    Verify or select a SageMaker execution role before creating models, endpoints, or training jobs.

    534 GitHub stars~1.6k tokensUpdated 5 days ago
    SecurityAuto-check passed
  • Tbtools

    xuzhougeng/wispterm

    A skill your agent uses when the user asks about TBtools, TBtools-II, TBtools RPC API, TBtools CLI, or bioinformatics operations available through TBtools such as sequence manipulation, BLAST…

    443 GitHub stars~2.3k tokensUpdated yesterday
    Research & ScienceAuto-check passed
  • Rtk Skill

    sopaco/deepwiki-rs

    A skill your agent uses when running shell commands that produce verbose output (git, test, build, lint, package managers, docker).

    3.1k GitHub stars~1.4k tokensUpdated 26 days ago
    DevOps & CloudAuto-check passed
  • Project Knowledge

    JanDeDobbeleer/oh-my-posh

    Verified, actionable gotchas for oh-my-posh. An agent skill from JanDeDobbeleer/oh-my-posh.

    24k GitHub stars~564 tokensUpdated today
    Testing & QAAuto-check passed
  • Niubash

    unixwin/niubash

    Run Windows tasks in Niubash, the GNU Bash-compatible Windows-native shell.

    163 GitHub stars~2.1k tokensUpdated today
    DevelopmentAuto-check passed
  • Peon-Ping Sound Toggle

    PeonPing/peon-ping

    Mutes or unmutes peon-ping sound notifications during an agent session with one command, and explains which settings the toggle also silences.

    5.1k GitHub stars~427 tokensUpdated 4 days ago
    Productivity & AutomationAuto-check passed

More from ZaxbyHub/opencode-swarm

All 91 skills in this repo
  • Codebase Review Swarm

    ZaxbyHub/opencode-swarm

    Runs an evidence-gated, quote-grounded audit of a codebase for security, QA, accessibility, performance and more, and writes a verified report without changing source files.

    496 GitHub stars~2.8k tokensUpdated today
    Auto-check passed
  • Issue Tracer

    ZaxbyHub/opencode-swarm

    Drives a bug report from validation and root-cause tracing through a critic-reviewed plan, an approved minimal fix and a PR-ready closure, never merging without recorded human approval.

    496 GitHub stars~4.4k tokensUpdated today
    Auto-check passed
  • Commit and PR Publishing for Codex

    ZaxbyHub/opencode-swarm

    Codex adapter for opencode-swarm that governs commits, pushes, draft PRs, PR body updates and CI closeout, deferring to the repo's canonical commit-pr protocol.

    496 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Durable Session State

    ZaxbyHub/opencode-swarm

    Keeps plans, decisions, evidence and reviewer verdicts in small files so long multi-phase tasks survive context compaction and session resumes.

    496 GitHub stars~896 tokensUpdated today
    Auto-check passed
  • Swarm PR Feedback Closer

    ZaxbyHub/opencode-swarm

    Ingests existing pull request feedback such as review comments and CI failures, verifies each claim, fixes confirmed issues and reports closure status for every item.

    496 GitHub stars~14k tokensUpdated today
    Auto-check passed
  • Swarm PR Subscribe

    ZaxbyHub/opencode-swarm

    Monitor a pull request after creation and act autonomously on pushed PR activity.

    496 GitHub stars~2.2k tokensUpdated today
    Auto-check passed

Works with

Questions about Running Tests

What does Running Tests do?

Safe test execution patterns for opencode-swarm. An agent skill from ZaxbyHub/opencode-swarm. Running Tests is an agent skill from ZaxbyHub/opencode-swarm. Safe test execution patterns for opencode-swarm.

How do I install Running Tests in Claude Code?

Run `npx skills add ZaxbyHub/opencode-swarm --skill running-tests -a claude-code`. Or copy the skill folder (.opencode/skills/running-tests in ZaxbyHub/opencode-swarm) into .claude/skills/running-tests in your project. Claude Code loads it when a task matches its description.

How do I install Running Tests in Codex?

Run `npx skills add ZaxbyHub/opencode-swarm --skill running-tests -a codex`. Or copy the skill folder (.opencode/skills/running-tests in ZaxbyHub/opencode-swarm) into .agents/skills/running-tests in your project. Codex loads it when a task matches its description.

Can I use Running Tests in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ZaxbyHub/opencode-swarm --skill running-tests -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/running-tests, .gemini/skills/running-tests, .github/skills/running-tests and .opencode/skills/running-tests in your project.

What does Running Tests need to run?

Going by SKILL.md and its folder, Running Tests needs the command-line tools its instructions call (bun, git, gh and npm).

Does Running Tests access the network?

SKILL.md contains no URLs. Its commands use git, gh and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Running Tests safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Running Tests use?

Running Tests is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Running Tests use?

About 4k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Running Tests?

Skills that share tags, products or a category with Running Tests: Hf Cloud Sagemaker Iam Preflight (waybarrios/opencode-power-pack, 534 stars), Tbtools (xuzhougeng/wispterm, 443 stars), Rtk Skill (sopaco/deepwiki-rs, 3.1k stars) and Project Knowledge (JanDeDobbeleer/oh-my-posh, 24k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Running Tests?

ZaxbyHub (a GitHub organization) maintains it in ZaxbyHub/opencode-swarm, which has 494 GitHub stars. The repository holds 91 skills in this directory. The repository was last updated on October 10, 2026.

Source: ZaxbyHub/opencode-swarm on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.