一键在 Manus 中运行任何 Skill

test-driven-development

星标2

分支0

更新时间2026年7月11日 07:40

Apply a focused red-green-refactor workflow for behavior changes and bug fixes. Use when the user asks for TDD, regression tests, test-first implementation, bug fixes with tests, or when a change has clear observable behavior that should be protected by tests.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

jedipunkz

jedipunkz/dotfiles

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Test Driven Development

Use this skill when the safest path is to lock behavior down before implementation.

Red-Green-Refactor

Identify the observable behavior to protect. Keep the test scope narrow enough to fail for the intended reason.
Find the repository's existing test style, framework, fixtures, and naming conventions before adding a test.
Write or update a focused failing test first. For a bug fix, the test should reproduce the bug. For a feature, it should encode the requested behavior.
Run the targeted test and confirm it fails for the expected reason. If it passes, improve the test before editing production code.
Implement the smallest production change that can make the test pass.
Run the targeted test again. Then run the nearest relevant broader test or lint command when the blast radius justifies it.
Refactor only after the behavior is green, keeping tests green after each meaningful cleanup.

When Test-First Is Not Practical

If a test-first loop is not practical, state why before implementation. Good reasons include missing test infrastructure, changes limited to prompt text or documentation, a purely mechanical configuration change, or a test that would require unsafe external services.

When skipping a test, still choose the best available verification: static check, existing suite, manual reproducer, CLI smoke test, or diff review.

Guardrails

Do not add brittle tests that assert incidental implementation details.
Prefer one focused regression over a broad snapshot unless the project already uses snapshots for this surface.
Keep fixtures minimal and local to the test unless the repository has shared fixture patterns.
Do not rewrite existing tests just to fit a new style.

同仓库更多 Skills

同仓库

systematic-debugging

jedipunkz/dotfiles

Reproduce and debug failures through an evidence-first root-cause workflow. Use when tests fail, a bug is reported, behavior is flaky, an error message needs investigation, or the user asks to debug, diagnose, investigate, or fix a failure.

2026-07-112

verification-before-completion

jedipunkz/dotfiles

Verify completed work before reporting it as done. Use after making code, config, documentation, workflow, or UI changes; when the user asks whether something is fixed; when a dev server is started; or before claiming implementation, debugging, migration, or setup work is complete.

2026-07-112

web-research

jedipunkz/dotfiles

Research current or uncertain information on the web using source-aware evidence. Use when the user asks to research, look up, browse, verify latest information, compare public options, find recommendations, cite sources, or when facts may have changed recently.

2026-07-112

github-publish

jedipunkz/dotfiles

GitHub へローカル変更を公開する workflow。ユーザーが commit、branch push、PR 作成、publish を依頼した場合に、通常の git と gh pr create で安全に実行します。

2026-07-112

finance-mcp

jedipunkz/dotfiles

株価・為替・暗号資産・財務データを MCP サーバ (alphavantage / twelvedata / edinetdb) 経由で取得・分析します。「株価を調べて」「銘柄の推移を」「為替レート」「企業の財務を」「決算」「ASCII グラフにして」「米国株 / 日本株を調査」などのリクエストがあった場合に使用します。

2026-06-202

codex-review

jedipunkz/dotfiles

ネストした OpenAI Codex CLI でコード、設定ファイル、ドキュメントのレビューを実行します。通常は Codex 組み込みの /review を優先し、ユーザーが明示的に「別 Codex でレビュー」「codex exec でレビュー」と頼んだ場合にだけ使用します。

2026-05-032

name	test-driven-development
description	Apply a focused red-green-refactor workflow for behavior changes and bug fixes. Use when the user asks for TDD, regression tests, test-first implementation, bug fixes with tests, or when a change has clear observable behavior that should be protected by tests.

Test Driven Development

Use this skill when the safest path is to lock behavior down before implementation.

Red-Green-Refactor

Identify the observable behavior to protect. Keep the test scope narrow enough to fail for the intended reason.
Find the repository's existing test style, framework, fixtures, and naming conventions before adding a test.
Write or update a focused failing test first. For a bug fix, the test should reproduce the bug. For a feature, it should encode the requested behavior.
Run the targeted test and confirm it fails for the expected reason. If it passes, improve the test before editing production code.
Implement the smallest production change that can make the test pass.
Run the targeted test again. Then run the nearest relevant broader test or lint command when the blast radius justifies it.
Refactor only after the behavior is green, keeping tests green after each meaningful cleanup.

When Test-First Is Not Practical

When skipping a test, still choose the best available verification: static check, existing suite, manual reproducer, CLI smoke test, or diff review.

Guardrails

Do not add brittle tests that assert incidental implementation details.
Prefer one focused regression over a broad snapshot unless the project already uses snapshots for this surface.
Keep fixtures minimal and local to the test unless the repository has shared fixture patterns.
Do not rewrite existing tests just to fit a new style.