一键在 Manus 中运行任何 Skill

开始使用

plan-execution-tdd

星标6

分支0

更新时间2026年6月3日 05:45

Supplementary TDD protocol injected into execution prompts when testCommand is configured

安装

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

在 Manus 中运行

来源

shipshitdev

shipshitdev/shipcode

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

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

软件质量保证分析师与测试员计算机与数学类职业·SOC 15-1253

SKILL.md

readonly

name	plan-execution-tdd
description	Supplementary TDD protocol injected into execution prompts when testCommand is configured

<testing_protocol> When implementing changes, follow the test-driven development cycle for every behavioral change:

RED — Write a failing test first.
- The test must fail because the feature does not exist yet, not because of a syntax error or import problem.
- Run the test. Confirm it fails. If it passes, your test is wrong — it does not actually verify the new behavior.
- Keep the failure output concise and reviewer-useful. If the failure exposes an unexpected plan gap, record it in implementation-notes.md.
GREEN — Write the minimum code to make the test pass.
- Do not write more than the test demands. Resist the urge to generalize.
- Run the test again. Confirm it passes.
REFACTOR — Clean up while tests stay green.
- Extract shared setup, rename for clarity, remove duplication.
- Run the full relevant test file after each refactor step.

Bug fixes use the Prove-It Pattern:

Write a test that reproduces the bug (it must fail).
Confirm the test fails for the right reason.
Fix the code.
Confirm the test passes.
Run the broader test suite to check for regressions.

Hard limits:

Never write more than 100 lines of implementation code without running tests.
If a test is flaky (passes sometimes, fails sometimes), investigate immediately — do not skip it.
If the plan's acceptance criteria include tests, those tests must exist and pass before you commit.
Passing tests are not enough. Before committing, confirm the tests exercise user-visible or system-visible behavior named in the plan, not private implementation details.
If tests fail twice for the same root cause and the fix would exceed the approved plan, stop and hand off the exact command, failure summary, and suspected plan gap in implementation-notes.md. </testing_protocol>

同仓库更多 Skills

同仓库

plan-generation

shipshitdev/shipcode

Planner skill — turn a user task into a precise, atomic, verifiable ShipCodePlan

2026-07-146

security-expert

shipshitdev/shipcode

Expert in application security, OWASP Top 10, authentication, authorization, data protection, and security best practices for React, Next.js, and NestJS applications. Use when implementing authentication or authorization, reviewing code for vulnerabilities, handling sensitive data, or implementing encryption or hashing.

2026-07-116

biome-validator

shipshitdev/shipcode

Validate Biome 2.3+ configuration and detect outdated patterns. Ensures proper schema version, domains, assists, and recommended rules. Use before any linting work or when auditing existing projects.

2026-07-106

bun-validator

shipshitdev/shipcode

Validate Bun workspace configuration and detect common monorepo issues. Ensures proper workspace setup, dependency catalogs, isolated installs, and Bun 1.3+ best practices. Use when setting up a Bun monorepo, before adding workspace dependencies, auditing an existing Bun workspace, or validating package.json in CI.

2026-07-106

component-library

shipshitdev/shipcode

Expert React/Next.js component architect specializing in creating consistent, reusable, and maintainable components for monorepo projects. Use when creating or refactoring UI components, reviewing component architecture, or setting up shared component patterns in a monorepo.

2026-07-106

prompt-engineering

shipshitdev/shipcode

Expert guide on prompt engineering patterns, best practices, and optimization techniques. Use when user wants to improve prompts, learn prompting strategies, debug agent behavior, or design content generation prompts.

2026-07-106

name	plan-execution-tdd
description	Supplementary TDD protocol injected into execution prompts when testCommand is configured

<testing_protocol> When implementing changes, follow the test-driven development cycle for every behavioral change:

RED — Write a failing test first.
- The test must fail because the feature does not exist yet, not because of a syntax error or import problem.
- Run the test. Confirm it fails. If it passes, your test is wrong — it does not actually verify the new behavior.
- Keep the failure output concise and reviewer-useful. If the failure exposes an unexpected plan gap, record it in implementation-notes.md.
GREEN — Write the minimum code to make the test pass.
- Do not write more than the test demands. Resist the urge to generalize.
- Run the test again. Confirm it passes.
REFACTOR — Clean up while tests stay green.
- Extract shared setup, rename for clarity, remove duplication.
- Run the full relevant test file after each refactor step.

Bug fixes use the Prove-It Pattern:

Write a test that reproduces the bug (it must fail).
Confirm the test fails for the right reason.
Fix the code.
Confirm the test passes.
Run the broader test suite to check for regressions.

Hard limits:

Never write more than 100 lines of implementation code without running tests.
If a test is flaky (passes sometimes, fails sometimes), investigate immediately — do not skip it.
If the plan's acceptance criteria include tests, those tests must exist and pass before you commit.
Passing tests are not enough. Before committing, confirm the tests exercise user-visible or system-visible behavior named in the plan, not private implementation details.
If tests fail twice for the same root cause and the fix would exceed the approved plan, stop and hand off the exact command, failure summary, and suspected plan gap in implementation-notes.md. </testing_protocol>