القائمة
Use when the user wants a decision-tree style test case design with inherited setup and per-leaf assertions.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Brainstorming specialist. Use before implementing any feature, fix or cli design to discuss the approach with the user first. Plans data models, storage layouts, test scenarios, and expected outputs.
Produce LOOP_<YYYY-MM-DD>_<slug>.md — a real runnable repro/verify runbook from user logs or prose. Expands to precise CLI/URL ops, builds workspace tools, runs steps 1–4 for real, records SYMPTOM CONFIRMED or VERIFY PASS. Pair with run-the-loop for fixes. Use for /establish-a-loop, "establish a loop", or "create a debug loop".
Fix until done: goal + inspect script under script/debug/, then iterate implement → inspect until PASS. Use after establish-a-loop or standalone for /run-the-loop, "loop until done", "max effort", "don't stop until".
Clarification-phase followup. Use when the user mentions followup to stay in discussion mode without moving to implementation.
OpenAI-compatible HTTP mock server for testing agents without real LLM calls. Loads a JSON config of request→response exchanges and returns pre-configured responses. Use when writing doctests or integration tests for agent runners.
Incremental deduplication workflow: map overlapping implementations, plan a PR stack into shared packages, seal doctests, migrate callers without behavior change. Use when the user mentions consolidate, dedupe, shared package, move enrichment into dot-pkgs, eliminate duplication, or /consolidate-code. Pair with investigate (overlap map) and doctest-tdd (sealed tests → impl).
| name | test-case-tree-design-expert |
| description | Use when the user wants a decision-tree style test case design with inherited setup and per-leaf assertions. |
Model test cases as a decision tree with inherited setup and per-leaf assertions.
Mode Selection: Check the input. If terse or vague, follow all steps (1-5). If already comprehensive with explicit decisions, skip to steps 3-5.
Brainstorm — Identify all modes, flags, subcommands, decision points, error states, and happy-path/sad-path outcomes.
Clarify — If details are ambiguous, call add-pending-questions with
JSON arguments (each with a question and optional options array). Stop
and wait after calling.
Propose Outline — Present a flat list of proposed test cases (name +
one-line description). Call add-pending-questions to get user approval.
Build the Decision Tree — Structure as root (feature) → modes (top-level branches) → decision nodes → leaves (runnable test cases).
Produce Output — Create the directory structure:
<feature-slug>-test-cases/
├── README.md # mermaid graph + text tree + test case index
├── SETUP.md # Global setup (inherited)
├── mode-xxx/
│ ├── SETUP.md # Inherits + mode-specific setup
│ └── leaf-a/
│ ├── SETUP.md
│ └── ASSERT.md
...
SETUP.md: Inherited along ancestor chain. Format: Preconditions, Steps, Context sections, plus optional executable Go code at the end.
ASSERT.md: Per-leaf assertions. Format: Expected, Side Effects, Errors, Exit Code sections, plus mandatory executable Go Assert function at the end.
README.md: DOT graph, ASCII text tree, test case index table.
Every runnable leaf must have both SETUP.md and ASSERT.md. After writing,
validate with validate_test_case_tree <output-dir>.