ワンクリックで
ci-testcase
Generate YAML test cases from requirements or acceptance criteria
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Generate YAML test cases from requirements or acceptance criteria
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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.