Menú
Run tests and analyze results for OhMyCode. Use when user wants to run, check, or verify tests — or after any code change.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Run OhMyCode benchmarks — score any provider/model with token tracking. Use when user wants to benchmark, evaluate, test performance, or compare models.
Generate high-quality tests for OhMyCode modules. Use when user wants to create, add, or generate tests for a module or file.
Guide for debugging OhMyCode issues. Use when user reports errors, unexpected behavior, or connection problems.
Guide for adding a new feature to OhMyCode. Use when user wants to add functionality that goes beyond existing extension points (tools/providers). Always start by reading docs/DEVELOPMENT_GUIDE.md.
Guide for adding a new LLM provider to OhMyCode. Use when user wants to connect a new AI model backend.
Guide for adding a new tool to OhMyCode. Use when user wants to create a custom tool.
| name | run-tests |
| description | Run tests and analyze results for OhMyCode. Use when user wants to run, check, or verify tests — or after any code change. |
Run the project test suite, analyze results, and take action on failures.
This skill is part of the OhMyCode development closed-loop:
编码 ──→ /gen-tests ──→ /run-tests ──→ 分析失败 ──→ 修代码 ──╮
↑ │
╰────────────────────────────────────────────────────────────╯
/gen-tests generates new test files — verify them immediatelyohmycode/ — catch regressions/run-tests — confirm the fix$ARGUMENTS — optional scope specifier. If empty, run the full suite.
| Argument | pytest path |
|---|---|
| (empty) | tests/ (full suite) |
tools | tests/tools/ |
tools/bash | tests/tools/test_bash.py |
core | tests/core/ |
core/loop | tests/core/test_loop.py |
providers | tests/providers/ |
config | tests/config/ |
skills | tests/skills/ |
| specific file path | use as-is |
Resolve $ARGUMENTS to a pytest target path using the table above.
If a specific file is given, verify it exists. If not, check for the closest match under tests/.
python3 -m pytest <resolved_path> -v --tb=short 2>&1 | tee tests_run.log
Use -v for verbose output and --tb=short for concise tracebacks.
Report the result summary (e.g., "73 passed in 2.1s") and confirm the code is healthy. No further action needed.
For each failure:
ohmycode//run-tests — repeat until all green ✓This is the core of the closed-loop: fail → diagnose → fix → re-run → pass.
Review warnings in the output. Common ones:
| Warning | Action |
|---|---|
PytestUnraisableExceptionWarning | Usually async cleanup — check for missing await |
DeprecationWarning | Note for future cleanup, not blocking |
RuntimeWarning: coroutine was never awaited | Missing await — fix immediately |
Ignore warnings that don't affect correctness unless they indicate real bugs.
If Step 2 only ran a subset of tests, prompt to run the full suite:
python3 -m pytest tests/ -v --tb=short 2>&1 | tee tests_run.log
This catches regressions in other modules caused by the recent change. The task is not complete until the full suite passes.
Use /run-tests at every transition in the closed-loop:
| When | What to do |
|---|---|
After /gen-tests | Run new tests to verify they pass |
After editing ohmycode/ source | Catch regressions early |
| After fixing a failure | Confirm the fix, re-enter loop if still red |
| Before committing | Full suite gate — python3 -m pytest tests/ -v must be all green |
| When resuming work | Baseline health check |
/gen-tests — generates tests; always follow up with /run-tests/commit-conventions — commit after all tests pass