New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

QA Test Plan

by elodin-sys in elodin-sys/elodin

Author, instantiate, and execute agentic QA test case plans for Elodin releases.

Apache-2.0Auto-check passedTesting & QA

Install QA Test Plan

skills CLI
$ npx skills add elodin-sys/elodin --skill qa-test-plan -a claude-code

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

GitHub CLI
$ gh skill install elodin-sys/elodin qa-test-plan --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/elodin-sys/elodin.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.cursor/skills/qa-test-plan .claude/skills/qa-test-plan && 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
qa-test-plan
GitHub stars
547
Token cost
~2.7k tokens
SKILL.md length
1,355 words
Files
11
Skills in repo
14
Repo updated
First seen
Licence
Apache-2.0

At a glance

Author, instantiate, and execute agentic QA test case plans for Elodin releases.

  • Works in 8 steps: One behavior per case. If a case… → Steps are exact commands, run from repo… → Commands must terminate. Beware: elodin… → …
  • The user asks to create a QA plan
  • SKILL.md covers Agent entry point, Authoring Test Cases, Instantiating a Plan for a… and Executing a Plan, plus 1 more section
  • Runs Python and Shell scripts from its folder; calls nix, git and uv

What it does

QA Test Plan is an agent skill from elodin-sys/elodin. Author, instantiate, and execute agentic QA test case plans for Elodin releases. Use when the user asks to create a QA plan, test case plan, or release test checklist, add or edit test cases, or run/execute a QA test plan for a release.

Its SKILL.md is about 2.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 13 other files (for example `elodin-db/serve_probe.py`, `elodin-db/test-plan.md` and `elodin-editor/capture.sh`).

It sits in Testing & QA, covering Test generation. The repository describes itself as: Elodin simulation and flight software monorepo. The licence is Apache-2.0.

When your agent uses it

  • The user asks to create a QA plan
  • Release test checklist
  • Edit test cases
  • Run/execute a QA test plan for a release

Example prompts

  • “/qa-test-plan”

Requirements

  • Python 3
  • A Bash shell

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. One behavior per case. If a case verifies two unrelated things, split it.
  2. Steps are exact commands, run from repo root inside the Nix shell (nix develop --command ...). Never write prose steps like "open the…
  3. Commands must terminate. Beware: elodin run and elodin editor keep serving the database even after the sim reaches max_ticks — they never…
  4. Pass criteria are objective: exit codes, specific output strings, file existence, row counts, screenshot contents. If a criterion can't be…
  5. Cases are independent. No case may rely on another case's side effects except through the declared Requires line. Use /tmp/qa-run// for…
  6. Deterministic where possible: fixed seeds, fixed tick counts, tolerance ranges for anything timing-dependent.
  7. Never pipe the command under test (cmd | tail reports the pipe's exit code, not cmd's). Redirect to a file in the artifacts directory and…
  8. Background processes must be managed inside one wrapper command: capture the PID, probe, kill by PID, and exit with the probe's code (see…

What it can do on your machine

Read from SKILL.md and the folder at commit 3bc1d99. 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

    Ships script files (Python and Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • nix
    • git
    • uv

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

  • Network

    No URLs in SKILL.md. Its commands use git and uv, 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

QA Test Plan loads about 2.7k tokens when it runs. Until then it costs about 62 tokens; SKILL.md has 1,355 words of instructions outside code blocks.

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

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 elodin-sys/elodin at commit 3bc1d99, republished under its Apache-2.0 licence (© elodin-sys). 1,355 words, ~2,734 tokens.

Download SKILL.mdSave it as .claude/skills/qa-test-plan/SKILL.md (or your agent's skills folder). This skill also uses 10 other files; get the full folder from GitHub.
name
qa-test-plan
description
Author, instantiate, and execute agentic QA test case plans for Elodin releases. Use when the user asks to create a QA plan, test case plan, or release test checklist, add or edit test cases, or run/execute a QA test plan for a release.

QA Test Plan

An agentic QA plan is a markdown document that replaces the traditional QA spreadsheet. Each test case carries machine-actionable steps and objective pass criteria so an agent can execute it autonomously; the filled-out document is both the checklist and the report.

Everything for this skill lives in this directory (.cursor/skills/qa-test-plan/):

  • Reusable template for new plans: template.md
  • Ready-to-run plan — examples smoke/feature test: examples/test-plan.md (24 cases: SDK-001 build + one per examples/ project). Shared helpers live alongside it in examples/ (run_probe.sh, probe.py).
  • Ready-to-run plan — Elodin-DB deep suite: elodin-db/test-plan.md (23 cases: generate realistic DBs from the examples — drone, logstream, video-stream, sensor-camera, apollo-lander, rc-jet — then exercise every elodin-db subcommand, serving mode, replication, exports, and clients on them). Helper: elodin-db/serve_probe.py; reuses the examples probes.
  • Ready-to-run plan — Elodin Editor deep suite: elodin-editor/test-plan.md (19 cases: release build, live/recorded DB connect, screenshot gallery across examples covering feature-catalog §16–17, --schematic preload, inspector feature check; helpers elodin-editor/capture.sh). Visual cases use ELODIN_SCREENSHOT* (see elodin-editor-dev).
  • Dated run reports and instantiated plans live under gitignored ai-context/qa-test-plan/<yyyy-mm-dd>-<release>/ (not in this skill folder).

Source files are never the report. Do not write Results, Evidence, Notes, Summary ticks, or Plan Header run metadata into template.md, examples/test-plan.md, elodin-db/test-plan.md, or elodin-editor/test-plan.md. Those keep AUTHOR-VALIDATED baselines and blank Results. Every execution (and every new custom plan) works on a dated copy under ai-context/.

Agent entry point

  • "Run/execute the examples QA plan" (or "smoke-test the examples for a release") → copy examples/test-plan.md into a dated folder (see Executing a Plan), then fill the copy's header and run cases top-to-bottom using that document's Execution Rules. It is self-contained and every agent case has an AUTHOR-VALIDATED baseline. Run from the repo root inside nix develop. Note the two hard-won prerequisites baked into examples/run_probe.sh: live-run cases bind port 2240 exclusively (never parallelize them), and tearing a run down requires a process-group kill (the s10 child restarts on a plain kill).
  • "Run/execute the Elodin-DB QA plan" (or "put elodin-db through its paces") → copy elodin-db/test-plan.md the same way, then execute the copy. It first generates a stable of realistic DBs under /tmp/qa-db/ from the examples, then runs the full elodin-db command surface over them; its Hard-won operational rules section (group-kill teardown, the tcp+1 asset-server port collision) is required reading before touching live servers.
  • "Run/execute the Elodin Editor QA plan" (or "screenshot / visual-regression the editor") → copy elodin-editor/test-plan.md the same way, then execute the copy. Prefer a warm target/release/elodin (EDITOR-100). Never parallelize live-editor cases (port 2240). For agent+visual criteria, Read the PNG — file existence alone is insufficient. Stale video-stream-db / voyager DB dirs must be deleted before those captures (handled by elodin-editor/capture.sh).
  • "Create/author a new plan for <release>" → follow Instantiating a Plan for a Release below (copy template.md into ai-context/qa-test-plan/).
  • "Add/edit a test case" → follow Authoring Test Cases below and the case anatomy rules. Persist new cases on the source ready-to-run plan and/or template.md, not on a dated run report.

There are three workflows: authoring test cases (edit sources), instantiating a custom plan from template.md (dated copy), and executing a ready-to-run suite (dated copy of that suite). The execution rules themselves live inside the plan so a copy is self-contained.

Authoring Test Cases

Anatomy of a case

Every case is a markdown block with these fields (see template for exact layout):

FieldPurpose
Checkbox + ID + name#### - [ ] AREA-NNN — Short name
PriorityP0 release-blocking smoke / P1 core functionality / P2 nice-to-have
Modeagent, agent+visual, or manual
RequiresCase IDs that must PASS first (keep chains shallow; most cases require only SDK-001)
DescriptionOne or two sentences: what behavior this verifies and why it matters
Expected durationLets the executor set command timeouts sensibly
StepsExact shell commands, one per line
Pass criteriaObjective checklist; every item must be verifiable from command output or artifacts
Result / Evidence / NotesFilled in during execution, left blank when authoring
Rules for agent-executable cases
  1. One behavior per case. If a case verifies two unrelated things, split it.
  2. Steps are exact commands, run from repo root inside the Nix shell (nix develop --command ...). Never write prose steps like "open the editor and check it works".
  3. Commands must terminate. Beware: elodin run <sim.py> and elodin editor <sim.py> keep serving the database even after the sim reaches max_ticks — they never exit on their own. The terminating form is bench mode: uv run python <sim.py> bench --ticks N (honors ELODIN_DB_PATH). For servers, background them and kill them in the same case.
  4. Pass criteria are objective: exit codes, specific output strings, file existence, row counts, screenshot contents. If a criterion can't be checked mechanically or from a screenshot, the case belongs in manual mode.
  5. Cases are independent. No case may rely on another case's side effects except through the declared Requires line. Use /tmp/qa-run/<case-id>/ for scratch state and clean it up.
  6. Deterministic where possible: fixed seeds, fixed tick counts, tolerance ranges for anything timing-dependent.
  7. Never pipe the command under test (cmd | tail reports the pipe's exit code, not cmd's). Redirect to a file in the artifacts directory and inspect that instead.
  8. Background processes must be managed inside one wrapper command: capture the PID, probe, kill by PID, and exit with the probe's code (see DB-002 in the template).
Show full SKILL.md (499 more words)Show less
ID and area conventions

IDs are AREA-NNN, stable across releases — never renumber or reuse an ID; retired cases keep their number forever and new cases append. Current areas:

PrefixArea
SDKPython SDK build/install
SIMSimulation runtime (headless)
DBElodin-DB
EDITORElodin Editor
RUST, LINTBuild area: workspace tests, CI checks
ALEPHFlight computer (usually manual — needs hardware)

Add new areas as needed; record them in this table so IDs stay consistent.

Execution modes
ModeMeaning
agentFully autonomous, shell-only
agent+visualAgent runs it but verification needs a display/screenshot; BLOCKED on headless machines
manualA human must perform it (hardware, subjective judgment); agent marks it SKIPPED and reports it

Instantiating a Plan for a Release

Use this when the user wants a new custom plan (not one of the ready-to-run suites). Copy template.md into gitignored ai-context/, never edit it in place:

bash
PLAN_DIR="ai-context/qa-test-plan/$(date +%F)-<release>"
mkdir -p "$PLAN_DIR"
cp .cursor/skills/qa-test-plan/template.md "$PLAN_DIR/test-plan.md"
  1. Fill the copy's Plan Header: release name, git rev-parse --short HEAD, git branch --show-current, date, environment (note whether a display is available), executor.
  2. Scope the copy: delete cases irrelevant to this release, add release-specific cases following the authoring rules. Keep the Summary table in sync with the case blocks — same IDs, same order.
  3. If new cases were added that future releases should keep, also add them to template.md (and the relevant ready-to-run suite) so the sources stay the source of truth.

Executing a Plan

First action: dated copy. Do not skip this. Ready-to-run suites (examples/, elodin-db/, elodin-editor/) and template.md are templates. Filling Results into them is a bug.

bash
# <suite> is examples | elodin-db | elodin-editor
# <release> is a short slug the user named, or the suite name if they did not
PLAN_DIR="ai-context/qa-test-plan/$(date +%F)-<release>"
mkdir -p "$PLAN_DIR"
cp ".cursor/skills/qa-test-plan/<suite>/test-plan.md" "$PLAN_DIR/test-plan.md"

Work only on $PLAN_DIR/test-plan.md. Leave the source plan's Status, Summary Results, and case Result/Evidence blank (AUTHOR-VALIDATED notes stay on the source).

The binding rules are in the copied plan itself ("Execution Rules" section) — read them first. Operationally:

  1. On the copy, set the header Status to IN PROGRESS (commit, branch, date, environment, executor).
  2. Work through cases strictly in Summary-table order, one at a time. For each case: check Requires, run the steps, verify every pass criterion, write Evidence (exit codes, matching output lines, artifact paths), then set Result in the case block and mirror it in the Summary row.
  3. Long builds are normal (SDK-001 up to 30 min, RUST-001 up to 40 min) — use the case's Expected duration to size timeouts instead of assuming a hang.
  4. On FAIL, save output to <artifacts>/<case-id>-fail.log, diagnose briefly in Notes, and move on. Never fix code mid-run; a QA run measures the release as it is.
  5. When all cases have a result: fill the Run Summary counts, list notable issues and follow-ups, set Status to COMPLETE, and report to the user — lead with FAIL/BLOCKED cases and anything a human must do (manual cases marked SKIPPED). Point them at the dated copy path, not the source suite.

Example: well-formed vs poor case

Poor (not agent-executable):

Steps: Open the editor and load a simulation. Check that everything looks right.

Well-formed: see SIM-001 in template.md — exact command, bounded runtime, three mechanical pass criteria (exit code, summary block present, no traceback/panic).

© elodin-sys, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 10 other files in .cursor/skills/qa-test-plan of elodin-sys/elodin.

  • SKILL.md
  • elodin-db/serve_probe.py
  • elodin-db/test-plan.md
  • elodin-editor/capture.sh
  • elodin-editor/test-plan.md
  • examples/probe.py
  • examples/run_probe.sh
  • examples/test-plan.md
  • feature-catalog.md
  • markdown-inventory.md
  • template.md

Open the folder on GitHubat commit 3bc1d99

Compare with similar skills

QA Test Plan 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.

QA Test Plan compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
QA Test Plan this skillelodin-sys/elodin547—~2.7kAutomated safety check: PassApache-2.0
Emcaklofas/kicad-happy1.4k1 repos~2.8kAutomated safety check: PassMIT
Swig Testswig/swig6.3k—~2.3kAutomated safety check: PassCustom licence
Generate Test Cases342164796/generate-test-cases1191 repos~2.9kAutomated safety check: PassNone
Verify Cc Safety Netkenryu42/cc-safety-net1.6k—~2kAutomated safety check: PassMIT
Wioworkersio/skills190—~5.8kAutomated safety check: PassMIT

Similar skills

  • Emc

    aklofas/kicad-happy

    EMC pre-compliance risk analysis for KiCad PCB designs — 18 check categories, 44 rule IDs covering ground planes, decoupling, I/O filtering, switching harmonics, clock routing, differential pair…

    1.4k GitHub starsUsed in 1 repo~2.8k tokens
    Testing & QAAuto-check passed

  • Swig Test

    swig/swig

    Run SWIG test suite for specific languages. An agent skill from swig/swig.

    6.3k GitHub stars~2.3k tokensUpdated yesterday
    Testing & QAAuto-check passed

  • Generate Test Cases

    342164796/generate-test-cases

    自主学习型测试文档生成器。从需求文档（Markdown）生成测试用例 XMind 文件，支持持久化记忆和持续学习。当用户提到"生成测试用例"、"根据需求生成测试"时触发。

    119 GitHub starsUsed in 1 repo~2.9k tokens
    Testing & QAAuto-check passed

  • Verify Cc Safety Net

    kenryu42/cc-safety-net

    Launch and drive the real cc-safety-net CLI — the hook decision path, explain, status/doctor, logs, and the local policy GUI — against an isolated home, capturing evidence.

    1.6k GitHub stars~2k tokensUpdated today
    Testing & QAAuto-check passed

  • Wio

    workersio/skills

    Testing workflow skill for finding high-value test candidates, writing focused tests, generating realistic workloads, reviewing test value, and diagnosing test-suite health.

    190 GitHub stars~5.8k tokensUpdated 2 mo ago
    Testing & QAAuto-check passed

  • File Server

    microsoft/WindowsProtocolTestSuites

    Official

    ALWAYS LOAD THIS SKILL when working with FileServer, SMB, SMB2, SMB3, CIFS, file sharing, MS-SMB2, MS-FSCC, MS-FSA, MS-DFSC, MS-FSRVP, MS-RSVD, MS-SQOS, or any file server protocol test…

    567 GitHub stars~4.1k tokensUpdated 23 days ago
    Testing & QAAuto-check passed

More from elodin-sys/elodin

All 14 skills in this repo

  • Branch Regression

    elodin-sys/elodin

    Compare two git branches (usually the current branch vs main) by running every example on each, capturing exit codes, logs, and editor screenshots, then diffing the results.

    547 GitHub stars~1.6k tokensUpdated yesterday
    Auto-check passed

  • Elodin Cranelift

    elodin-sys/elodin

    Work with the Cranelift JIT MLIR backend. An agent skill from elodin-sys/elodin.

    547 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • Elodin DB

    elodin-sys/elodin

    Work with Elodin-DB, the time-series telemetry database. An agent skill from elodin-sys/elodin.

    547 GitHub stars~2.8k tokensUpdated yesterday
    Auto-check passed

  • Elodin Dev

    elodin-sys/elodin

    Develop and contribute to the Elodin codebase. An agent skill from elodin-sys/elodin.

    547 GitHub stars~896 tokensUpdated yesterday
    Auto-check passed

  • Elodin Editor Dev

    elodin-sys/elodin

    Contribute to the Elodin Editor, the 3D viewer and graphing tool.

    547 GitHub stars~3.4k tokensUpdated yesterday
    Auto-check passed

  • Elodin Headless Capture

    elodin-sys/elodin

    Run the Elodin Editor without a physical display in Gamescope, take screenshots, and record video through PipeWire and GStreamer.

    547 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check: notes

Categories

Questions about QA Test Plan

What does QA Test Plan do?

Author, instantiate, and execute agentic QA test case plans for Elodin releases. QA Test Plan is an agent skill from elodin-sys/elodin. Author, instantiate, and execute agentic QA test case plans for Elodin releases.

When should I use QA Test Plan?

QA Test Plan fits situations like: the user asks to create a QA plan; release test checklist; edit test cases; run/execute a QA test plan for a release.

How do I install QA Test Plan in Claude Code?

Run `npx skills add elodin-sys/elodin --skill qa-test-plan -a claude-code`. Or copy the skill folder (.cursor/skills/qa-test-plan in elodin-sys/elodin) into .claude/skills/qa-test-plan in your project. Claude Code loads it when a task matches its description.

How do I install QA Test Plan in Codex?

Run `npx skills add elodin-sys/elodin --skill qa-test-plan -a codex`. Or copy the skill folder (.cursor/skills/qa-test-plan in elodin-sys/elodin) into .agents/skills/qa-test-plan in your project. Codex loads it when a task matches its description.

Can I use QA Test Plan 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 elodin-sys/elodin --skill qa-test-plan -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/qa-test-plan, .gemini/skills/qa-test-plan, .github/skills/qa-test-plan and .opencode/skills/qa-test-plan in your project.

What does QA Test Plan need to run?

Going by SKILL.md and its folder, QA Test Plan needs Python and a shell for the scripts in its folder and the command-line tools its instructions call (nix, git and uv). Our summary lists: Python 3; A Bash shell.

Does QA Test Plan access the network?

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

Is QA Test Plan 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 QA Test Plan use?

QA Test Plan is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does QA Test Plan use?

About 2.7k tokens (SKILL.md is roughly 11k 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 QA Test Plan?

Skills that share tags, products or a category with QA Test Plan: Emc (aklofas/kicad-happy, 1.4k stars), Swig Test (swig/swig, 6.3k stars), Generate Test Cases (342164796/generate-test-cases, 119 stars) and Verify Cc Safety Net (kenryu42/cc-safety-net, 1.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains QA Test Plan?

elodin-sys (a GitHub organization) maintains it in elodin-sys/elodin, which has 547 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 7, 2026.

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