القائمة
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.