Decide Fit First

• Core job: RED-GREEN-REFACTOR 워크플로우를 강제하는 TDD 개발 스킬 이 스킬은 ForkLore 프로젝트에서 TDD(Test-Driven Development) 워크플로우를 강제합니다. poetry run pytest apps…
• Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
• Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

• Structure: The skill is organized around “워크플로우”, “1. RED 단계 - 실패하는 테스트 먼저 작성”, “2. GREEN 단계 - 최소한의 구현”, “3. REFACTOR 단계 - 코드 개선”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
• Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
• Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

• Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
• Invocation: Name tdd-flow directly; if the source includes slash commands, start with the command and then add task context.
• Validation: Start small and check whether the result follows “워크플로우 / 1. RED 단계 - 실패하는 테스트 먼저 작성 / 2. GREEN 단계 - 최소한의 구현” before expanding.

Boundaries And Review

• Dependencies: It usually needs no extra API key, so start with a small validation task.
• Permissions: Declared permissions include read; ask the agent to state file, command, and rollback boundaries before acting.
• Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.