メニュー
Test-driven development workflow for Rust. Use before writing any implementation code — write a failing test first, then implement, then refactor.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Write an implementation plan as a markdown file, then immediately serialize it to a timestamped YAML task file in .ctx/tasks/. Use before touching any code when given a spec or approved design.
Design-first workflow for new features, components, or architecture decisions. Use before writing any code — get explicit approval on a design first.
Commit-and-push workflow with validation. Use when asked to "cap", "commit and push", or "ship it".
Systematic debugging for Rust. Use before proposing any fix — establish root cause first, then write a failing test, then fix.
Dispatch parallel subagents for independent tasks. Use when 2+ tasks have no shared state or sequential dependencies.
Task graph management for a session. Use to create tasks, track progress, execute the next unblocked task, or manage dependencies between work items.
| name | godmode-tdd |
| description | Test-driven development workflow for Rust. Use before writing any implementation code — write a failing test first, then implement, then refactor. |
Iron Law: No production code without a prior failing test. Delete and restart if you wrote code before the test.
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_thing_does_x() {
// Arrange / Act / Assert — must FAIL before implementation
}
}
Run and confirm failure:
cargo nextest run -p <crate> -- <test_name>
Verify failure is for the right reason — not a compile error. The test must exist, compile, and fail because the behavior isn't implemented.
Write the least code that makes the test pass. No extras.
cargo nextest run -p <crate> # all tests must pass
cargo clippy -p <crate> -- -D warnings
cargo fmt -p <crate>
cargo nextest run -p <crate> # still green
git commit -m "feat(<crate>): <what it does>"
#[cfg(test)] modules or tests/ for integration tests.If a test is still failing after 3 attempts: either the architecture is wrong (step back and redesign) or the requirement is unclear (ask the user). Never brute-force past 3 failures.