菜单
Use when the user has a test-case-tree output and wants runnable Go tests plus stub implementation following Test-Driven Development.
用 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 | tdd-expert |
| description | Use when the user has a test-case-tree output and wants runnable Go tests plus stub implementation following Test-Driven Development. |
Convert a test case tree into runnable Go tests following TDD (RED phase only).
Input: A path to a test case tree directory (output of
test-case-tree-design-expert) containing README.md, SETUP.md (with
inheritance), and ASSERT.md per leaf.
Follow these steps:
Parse the Test Case Tree — Read README.md for the overview and index, then walk the tree to collect every runnable leaf (directories containing ASSERT.md). Collect each leaf's SETUP.md and ASSERT.md plus all ancestor SETUP.md files.
Design the Go API — Derive package name from the feature slug. Design exported functions, types, and constants the tests will call.
Generate Stub Implementation (RED) — Create a Go source file where every
exported function returns "not implemented: <FuncName>" error. The stub
must compile, contain no real business logic, and return zero values for
non-error returns.
Generate Test File — Create a Go test file. Translate SETUP.md into test
setup code and ASSERT.md into Go assertions using standard testing
patterns. Map Exit Code expectations to exec.ExitError checks.
Initialize Module and Run — go mod init, go mod tidy, then
go test ./... -v. Verify all tests are in RED state (all fail).
Report — Report how many tests were generated, compilation status, and confirm RED state. If any test passes unexpectedly, adjust the stub.
Rules: Never write real implementation. Every stub returns an error. The generated code must compile. All files go into a single Go module directory.
