Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

test-driven-development

Étoiles4

Forks0

Mis à jour14 mai 2026 à 11:06

Use when implementing a feature or bug fix where behavior can be verified through tests, especially when the user mentions TDD, regression tests, red-green-refactor, or integration tests.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

ushiradineth

ushiradineth/nix-config

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	test-driven-development
description	Use when implementing a feature or bug fix where behavior can be verified through tests, especially when the user mentions TDD, regression tests, red-green-refactor, or integration tests.

Test driven development

Core rule

One behavior at a time. Red, green, then refactor. Never refactor while red.

Workflow

Identify the public interface or user-visible behavior.
Write one failing test for one behavior.
Run it and confirm it fails for the expected reason.
Write the smallest implementation that passes.
Run the test and relevant nearby checks.
Refactor only after green, then run checks again.
Repeat for the next behavior.

Test quality

Prefer behavior tests through public interfaces.
Avoid tests coupled to private implementation details.
Each test should survive internal refactors when behavior stays the same.
Do not write a batch of imagined tests before the first implementation slice teaches you more.

When not to use

Pure formatting or prompt-only changes.
Config changes with no meaningful test seam, where parse or build checks are the right evidence.

Plus depuis ce dépôt

même dépôt

personal-writing-identity

ushiradineth/nix-config

Use when writing technical articles, blog posts, X/Twitter threads, LinkedIn posts, documentation, runbooks, or any text that must sound like a specific person, not a generic assistant. Also use when the user asks to humanize text, remove AI-sounding language, rewrite in their voice, or convert rough notes into publishable content. Trigger even when the user just says "write this up" or "draft a post about X" without explicitly mentioning voice or tone.

2026-05-294

architecture-deepening

ushiradineth/nix-config

Use when reviewing architecture, planning refactors, reducing coupling, improving testability, or deciding whether modules should become deeper behind simpler interfaces.

2026-05-144

caveman

ushiradineth/nix-config

Use when the user asks for caveman mode, terse mode, fewer tokens, less prose, or very brief technical communication.

2026-05-144

diagnose

ushiradineth/nix-config

Use for hard bugs, failing checks, pipeline failures, homelab incidents, performance regressions, or reports that something is broken and needs root-cause analysis.

2026-05-144

git-guardrails

ushiradineth/nix-config

Use before git mutation, branch deletion, resets, cleaning, force pushes, broad restore commands, PR operations, or any git action with destructive or remote side effects.

2026-05-144

grill-me

ushiradineth/nix-config

Use when a plan, design, or implementation request has ambiguity that could change scope, architecture, acceptance criteria, safety, or validation.

2026-05-144

name	test-driven-development
description	Use when implementing a feature or bug fix where behavior can be verified through tests, especially when the user mentions TDD, regression tests, red-green-refactor, or integration tests.

Test driven development

Core rule

One behavior at a time. Red, green, then refactor. Never refactor while red.

Workflow

Identify the public interface or user-visible behavior.
Write one failing test for one behavior.
Run it and confirm it fails for the expected reason.
Write the smallest implementation that passes.
Run the test and relevant nearby checks.
Refactor only after green, then run checks again.
Repeat for the next behavior.

Test quality

Prefer behavior tests through public interfaces.
Avoid tests coupled to private implementation details.
Each test should survive internal refactors when behavior stays the same.
Do not write a batch of imagined tests before the first implementation slice teaches you more.

When not to use

Pure formatting or prompt-only changes.
Config changes with no meaningful test seam, where parse or build checks are the right evidence.