| name | test-gen |
| description | Use this skill after code changes to generate or update targeted tests, acceptance coverage, and regression checks with stack-aware verification. |
| version | 0.3.0 |
| source | fork |
| checksum | b1ebfd132bb3dad91e0dcd418ff413c01aedf317a598fbb13d32b1c7038747bc |
| updated_at | 2026-03-12T10:57:03.000Z |
| intent | testing |
| layer | quality |
Test Gen Skill
Codex invocation: use $test-gen ... or test-gen: ...
Generate smart post-implementation tests for changed code with explicit regression coverage.
Capabilities
- Detect changed files and test stack automatically.
- Classify risk signals and derive acceptance/regression checklists.
- Generate or update closest-fit tests (unit/integration/e2e).
- Prefer existing test conventions over creating new patterns.
- Report residual testing gaps honestly.
Input Requirements
target (required): changed file, module, or feature area.intent (optional): bugfix | feature | refactor.scope (optional): specific paths to include/exclude.risk_level (optional): low | medium | high.verify_mode (optional): targeted | full.
How to Use
$test-gen src/router/skill-router.js
$test-gen Cover changed auth files with regression tests
$test-gen Generate tests for checkout flow refactor
Routing Boundary
- Use
$test-gen after implementation changes already exist.
- Use
$tdd-workflow when you need strict test-first flow before coding.
- Use
$verification-loop when verification is failing and you need repeated fix cycles.
Workflow
State file: .omc/state/test-gen-state.json
Phase 1: Detect Context
omcodex test detect-stack
omcodex test changed
omcodex test analyze <target>
Collect:
- target kind and complexity
- risk signals
- nearby existing tests
- stack and runner commands
Phase 2: Generate Testing Pack
omcodex test gen <target>
Expected artifacts:
- test plan
- acceptance checklist
- regression checklist
- testing playbook
Phase 3: Write or Update Tests
Decision policy:
- pure logic -> unit tests
- UI behavior -> component/integration tests
- async + IO -> integration tests
- high-risk path -> regression-focused assertions
Prefer editing nearby existing tests when possible.
Phase 4: Verify
Run smallest useful command first, then widen only when needed.
Examples:
npm test -- <target-test-file>
npm run test:coverage
npm run test
For non-node stacks, use repository-native equivalents.
Verification Escalation Rules
- targeted test command fails -> run module-level suite
- module-level suite fails -> run full test suite
- full suite fails -> handoff to
$verification-loop
Output Contract
[TEST-GEN]
- target files analyzed
- risk summary
[GENERATED]
- tests added/updated
- acceptance items covered
- regression items covered
[VERIFY]
- commands executed
- pass/fail results
[GAPS]
- unautomated scenarios
- manual regression checklist (if needed)
[STATUS]
- phase: <detect|generate|write|verify>
- result: <complete|blocked|in_progress>
- promise: <PROMISE tag>
Completion and Blocking Tags
[PROMISE:TEST_GEN_COMPLETE][PROMISE:TEST_GEN_BLOCKED]
Block when:
- no runnable test environment is available
- required fixtures/mocks are unavailable
- changed behavior cannot be validated automatically
Rules
- Do not stop at happy path.
- Always add regression assertions for high-risk changes.
- Avoid implementation-detail-only tests.
- If automation is unsafe, provide an explicit manual checklist.
