com um clique
ci-testcase
Generate YAML test cases from requirements or acceptance criteria
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Generate YAML test cases from requirements or acceptance criteria
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Apply a built ollama37 image onto a testbed through CI — recreate the container, never docker compose by hand
Build the ollama37 CI image on a self-hosted GPU runner — never with a local make
Run a decision-grade FA/CUDA performance experiment via CI — verified throughput, self-reverting testbed
Graph-first verify discipline: re-ground in the codebase knowledge graph before AND after any non-trivial code change, and especially after a failed build/test or wrong output. Re-index the changed repo, re-trace the symbols you touched (callers, callees, data flow), and — for a port/adaptation — diff against the reference project, then verify against the live file before editing. Confirm any relationship- or reachability-based claim (who-calls, what-derefs, which-case-runs) with a graph trace, not grep alone. Use when implementing or porting non-trivial code, when an attempt fails, or before iterating on a fix. Complements (does not replace) the codebase-memory tool reference and codebase-graph-navigation IDE-movement skills.
Execute test cases with the simple judge by default, or opt in the agent judge
| name | ci-testcase |
| description | Generate YAML test cases from requirements or acceptance criteria |
| user-invocable | true |
Generate a YAML test case file from requirements or acceptance criteria.
$ARGUMENTS
## PURPOSE
Read requirements (story, ticket, or description) and generate YAML test case(s) that verify the acceptance criteria.
---
## AGENT WORKFLOW
### Step 1: Understand Requirements
Input can be:
- A story/requirement file path — read and analyze it
- A description of what to test — use it directly
- A ticket ID — look for related docs or ask the user
Identify:
- What functionality to test
- What commands or tools to call
- What output to expect
- What would indicate failure
### Step 2: Review Existing Tests
Read existing test cases in `cicd/tests/testcases/` to:
- Find the next available ID number per suite
- Follow existing naming and pattern conventions
- Avoid duplicating existing coverage
### Step 3: Generate Test Case YAML
Create test case file(s) in `cicd/tests/testcases/<suite>/` using this format:
```yaml
id: TC-[SUITE]-[NUMBER]
name: Descriptive test name
suite: build|integration|e2e
goal: One-line test objective for agent judge
priority: 1-10 (lower = runs first)
timeout: 30000
dependencies: []
tags: [feature-name]
steps:
- name: Step description
command: <shell command or mcp-client.ts call>
timeout: 5000 # Optional
expectPatterns:
- "regex pattern"
rejectPatterns:
- "error"
capture: # Optional: extract values for later steps
varName: "json.path"
criteria: |
Human-readable criteria for agent judge evaluation.
Suite guidelines:
build — compilation, dependency checks, environment validationintegration — single tool/API calls, verify output format and correctnesse2e — multi-step workflows, verify end-to-end stateID format: TC-BUILD-XXX, TC-INT-XXX, TC-E2E-XXX
Tags: Use feature names or capability areas (e.g., auth, api, build). Tags enable per-feature CI workflows via --tag.
For MCP tool testing:
command: npx tsx cicd/tests/src/mcp-client.ts <tool_name> '{"arg":"value"}'
For shell command testing:
command: curl -s http://localhost:3000/api/endpoint
For multi-step with variable capture:
steps:
- name: Create resource
command: <command that returns JSON>
capture:
resourceId: "id"
- name: Use captured value
command: <command using {{resourceId}}>
Variables resolve from captured step output first, then fall back to process.env.
Show the user:
/ci-run to execute testsPaths to created test case files.