本文へ移動
cccskills
無料GitHub で公開

tdd-workflow

Use this skill for developing software in TDD (Test-Driven Design).

archibate/dotfiles-opencode
インストール方法を見る

含まれるファイル（1）

  • SKILL.md6.8 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

TDD Workflow

Overview

A strict 7-step TDD cycle that produces high-quality, well-tested code. Each step must be verified and confirmed before proceeding. Status is only updated after real verification

  • never hallucinated.

Core principle: RED (failing test) -> GREEN (minimal implementation) -> REFACTOR.

Step 0 - Check Existing Progress

At the start of each session, before doing anything else:

  • List tdd-summary/ to check for existing step reports (e.g. step-1.md, step-2.md).
  • If reports exist, read them to understand prior context, then resume from the next step.

Step 1 - Understand Intent

  • Explore the codebase for relevant context.
  • Derive functional requirements from the available information (user prompt + codebase).
  • If any requirement is ambiguous, document the assumption explicitly in step-1.md under an "Assumptions" section rather than asking for clarification.

Write tdd-summary/step-1.md:

# Step 1 - Understand Intent

## Functional Requirements

### FR-1: <title>
<description>

### FR-2: <title>
<description>

## Assumptions

- <any ambiguous point and the assumption made>

Step 2 - Write Scenario Docs

For each functional requirement, create a scenario document at docs/scenario/<name>.md:

# Scenario: <Title>
- Given: <precondition>
- When: <action>
- Then: <expected outcome>

## Test Steps

- Case 1 (happy path): <brief description>
- Case 2 (edge case): <brief description>
- Case N: ...

## Status
- [x] Write scenario document
- [ ] Write solid test according to document
- [ ] Run test and watch it failing
- [ ] Implement to make test pass
- [ ] Run test and confirm it passed
- [ ] Refactor implementation without breaking test
- [ ] Run test and confirm still passing after refactor

**IMPORTANT**: Only update above status when a step is confirmed complete. Do not hallucinate.

Invariant: Count of FR = count of scenario documents. Verify before continuing.

Write tdd-summary/step-2.md:

# Step 2 - Write Scenario Docs

## Scenario Documents Created

- FR-1: <title> - `docs/scenario/<name>.md`
- ...

Step 3 - Write Failing Test (RED)

For each scenario document:

  • Write tests at tests/scenario/test_<name>.py (or equivalent).
  • Each scenario must have at least 2 test cases. Add edge cases if missing.
  • All acceptance criteria from the scenario document must be covered.
  • Tests must not be empty or dummy.
  • Update scenario status: check - [x] Write solid test according to document.

After writing, run each test and verify it fails:

  • Expected failure (e.g. feature not found, endpoint missing) - this is correct.
    • Update scenario status: check - [x] Run test and watch it failing.
  • Unexpected failure (e.g. import error, missing dependency) - fix the environment first.
  • Test passes - the feature is not implemented yet; there is no reason it should pass. Fix the test.

Invariant: Count of scenario documents = count of test files. Verify before continuing.

Write tdd-summary/step-3.md:

# Step 3 - Write Failing Test

## Failing Tests Created

- FR-1: <title> - `docs/scenario/<name>.md` - `tests/scenario/test_<name>.py`
- ...

Step 4 - Implement to Make Tests Pass (GREEN)

For each failing test:

  • Write the minimal production code necessary to make the test pass. Nothing more.
  • Do not introduce changes unrelated to the current functional requirement.
  • Update scenario status: check - [x] Implement to make test pass.
  • Run the test. If it fails, fix the implementation and retry.
  • After confirming it passes, update scenario status: check - [x] Run test and confirm it passed.

Write tdd-summary/step-4.md:

# Step 4 - Implement to Make Tests Pass

## Implementations Completed

- FR-1: <title> - `docs/scenario/<name>.md` - Implementation in `<module>`
- ...

All tests now pass. Scenario documents updated.

Step 5 - Refactor for Maintainability

For each scenario where tests now pass:

  • Improve readability, structure, and maintainability without changing external behavior.
  • Update scenario status: check - [x] Refactor implementation without breaking test.
  • Run the tests again after refactoring.
    • If tests fail: fix the refactoring. If impossible, rollback to the pre-refactor version.
  • After confirming tests still pass, update scenario status: check - [x] Run test and confirm still passing after refactor.

Write tdd-summary/step-5.md:

# Step 5 - Refactor for Maintainability

## Refactorings Completed

- FR-1: <title> - `docs/scenario/<name>.md` - <what was improved>
- ...

All tests still pass after refactoring. Scenario documents updated.

Step 6 - Regression Test

Run the complete test suite (all tests, not just those added in this session):

  • If regression occurs in unrelated tests:
    • Analyze the failure and understand its impact on existing functionality.
    • Fix the implementation to restore all passing tests.
    • Re-run the complete suite until everything passes.

NEVER modify existing tests that are unrelated to the current functional requirements.

Write tdd-summary/step-6.md:

# Step 6 - Regression Test

## Regression Test Results

- Complete test suite executed: `<command>`
- All tests pass: Yes / No
- If regression found: <brief description of fix applied>

Step 7 - Final Review

Verify that every scenario document has all status checkboxes checked.

Review:

  • Every FR has a corresponding scenario document and test file.
  • All tests pass and code is clean.

Write tdd-summary/step-7.md:

# Step 7 - Final Review

## Summary

- Functional requirements addressed:
    - FR-1: ...
- Scenario documents: `docs/scenario/...`
- Test files: `tests/scenario/...`
- Implementation complete and all tests passing after refactoring.

## How to Test

Run: `<test command>`

Finally, archive the summary folder:

mv tdd-summary/ completed-tdd-archives/tdd-$(date +%Y%m%d-%H%M%S)

TDD workflow complete.

Iron Rules

  • Do not skip steps. Each step must be verified before the next begins.
  • Do not edit tests during implementation or refactor steps, unless the test itself was obviously written incorrectly in Step 3.
  • Do not hallucinate status. Only check a status checkbox after real, confirmed verification.
  • Keep counts equal. FR count = scenario doc count = test file count at all times.
  • Step gates: If running interactively, present each step report and wait for confirmation before continuing. If running as a delegated subagent, proceed automatically through all steps.
  • If changes are requested at any step, loop back to the appropriate step and adjust all downstream artifacts accordingly.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

agent-browser

無料

Browser automation CLI for AI agents. Use when needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. TRIGGER when user requests to "open a website", "fill out a form", "click a button", "take a screenshot", "debug this in browser", "scrape data from a page", "test this web app", "login to a site", "frontend UI/UX aesthetics", "automate browser actions", or any task requiring programmatic web interaction.

日本語の概要は準備中です。原文の説明を表示しています。

archibate/dotfiles-opencode1082026年4月29日 更新

anti-defensive

無料

Review common AI slops of defensive programming patterns, avoid silent errors. TRIGGER when reviewing code for defensive anti-patterns, writing fail-fast code, or auditing error handling quality.

日本語の概要は準備中です。原文の説明を表示しています。

archibate/dotfiles-opencode1082026年4月29日 更新

ast-grep

無料

Guide for writing ast-grep rules to perform structural code search and analysis. This skill should be used when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search, or when a simple grep/glob search is insufficient for structural code pattern matching.

日本語の概要は準備中です。原文の説明を表示しています。

archibate/dotfiles-opencode1082026年4月29日 更新

better-translate

無料

Best practices for AI-driven English-to-Chinese translation. This skill should be used when the user asks to "translate to Chinese", "update the Chinese translation", "improve Chinese translation", "fix translation quality", "review Chinese translation", or when translating any English text into Chinese. Also applies when polishing an existing Chinese translation of English content.

日本語の概要は準備中です。原文の説明を表示しています。

archibate/dotfiles-opencode1082026年4月29日 更新

bilibili-api

無料

This skill should be used when the user asks to "use bilibili API", "download bilibili video", "get bilibili user info", "list bilibili favorites", "send bilibili danmaku", "upload video to bilibili", "monitor bilibili live room", "search bilibili", "get bilibili comments", or needs guidance on the bilibili_api Python library usage, authentication, API endpoints, or workflow patterns.

日本語の概要は準備中です。原文の説明を表示しています。

archibate/dotfiles-opencode1082026年4月29日 更新

cc-connect

無料

This skill should be used when sending images, files, or notifications back to the user via messaging platforms (Discord, Feishu, Telegram, etc.) through cc-connect. TRIGGER when agent generates a plot/chart/screenshot and wants to show the user; agent creates a report/PDF/file the user should receive; agent needs to proactively notify the user (e.g. task completed, alert, reminder); user asks to "send image", "show me the chart", "notify me", "send the file", "send to Telegram", "show plot in Discord".

日本語の概要は準備中です。原文の説明を表示しています。

archibate/dotfiles-opencode1082026年4月29日 更新

archibate のスキルをすべて見る

このスキルの問題を報告する