원클릭으로 Manus에서 모든 스킬 실행

tdd-pro

스타0

포크0

업데이트2026년 7월 18일 13:49

Test-driven development workflow using red-green-refactor for features, bug fixes, and risky behavior changes. Adapted from Matt Pocock-style TDD for Codex v4.1. Use when tests can clarify requirements, prevent regressions, or guide implementation in small vertical slices.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

PAISHU-AI

PAISHU-AI/PAI-zong-NB-v5.8

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

TDD Pro

Workflow

Identify one externally visible behavior.
Write the smallest failing test that proves the missing behavior or bug.
Run the narrow test and confirm it fails for the expected reason.
Implement the smallest code change to pass.
Run the test and relevant adjacent checks.
Refactor only after green.
Repeat for the next behavior or edge case.

Good Tests

Assert behavior, not private implementation.
Use realistic inputs and domain language.
Cover one reason to fail per test where practical.
Include regression tests for fixed bugs.
Keep mocks at external boundaries.
Avoid snapshot-only tests for meaningful logic.

When Not To Force TDD

Pure styling changes with low behavioral risk.
Exploratory prototypes intended to be thrown away.
Codebases with no viable test harness, unless adding one is in scope.

Output

Report failing test added, implementation change, final test command, and result. If TDD was skipped, state why.

이 저장소의 다른 Skills

같은 저장소

router

PAISHU-AI/PAI-zong-NB-v5.8

Route user requests to the right Codex role, output mode, and minimal skill set. Use for every task before deciding whether the answer is simple consultation, architecture, project assistance, coding, debugging, review, documentation, or rule maintenance.

2026-07-180

project-context

PAISHU-AI/PAI-zong-NB-v5.8

Inspect and summarize project context before coding. Use when Codex needs to modify a repository, understand structure, follow existing conventions, locate scripts, read AGENTS.md, README, package manifests, or project documentation.

2026-07-180

ui-design

PAISHU-AI/PAI-zong-NB-v5.8

Design practical user interfaces, flows, information architecture, layout systems, component states, and design tokens. Use for page design, UX redesign, dashboards, tools, mobile/web UI, interaction design, and before frontend implementation when visual or workflow decisions matter.

2026-07-180

frontend

PAISHU-AI/PAI-zong-NB-v5.8

Build and modify frontend pages, components, state logic, styling, forms, client-side interactions, and UI behavior in React, Vue, Svelte, vanilla HTML/CSS/JS, or similar frameworks. Use for frontend implementation and frontend bug fixes.

2026-07-180

backend

PAISHU-AI/PAI-zong-NB-v5.8

Implement backend services, business logic, API handlers, jobs, integrations, file processing, authentication flows, and server-side fixes. Use for backend coding and debugging in Node, Python, Go, Java, Rust, PHP, or similar stacks.

2026-07-180

api-design

PAISHU-AI/PAI-zong-NB-v5.8

Design REST, GraphQL, RPC, webhook, and internal service APIs. Use for routes, status codes, request/response schemas, error models, pagination, filtering, versioning, idempotency, and OpenAPI or contract documentation.

2026-07-180

name	tdd-pro
description	Test-driven development workflow using red-green-refactor for features, bug fixes, and risky behavior changes. Adapted from Matt Pocock-style TDD for Codex v4.1. Use when tests can clarify requirements, prevent regressions, or guide implementation in small vertical slices.

TDD Pro

Workflow

Identify one externally visible behavior.
Write the smallest failing test that proves the missing behavior or bug.
Run the narrow test and confirm it fails for the expected reason.
Implement the smallest code change to pass.
Run the test and relevant adjacent checks.
Refactor only after green.
Repeat for the next behavior or edge case.

Good Tests

Assert behavior, not private implementation.
Use realistic inputs and domain language.
Cover one reason to fail per test where practical.
Include regression tests for fixed bugs.
Keep mocks at external boundaries.
Avoid snapshot-only tests for meaningful logic.

When Not To Force TDD

Pure styling changes with low behavioral risk.
Exploratory prototypes intended to be thrown away.
Codebases with no viable test harness, unless adding one is in scope.

Output

Report failing test added, implementation change, final test command, and result. If TDD was skipped, state why.