developing

skanehira's avatarfrom skanehira

テスト駆動開発(TDD)方法論に従って新機能の実装やバグ修正を行います。新機能の実装、バグ修正、既存機能の拡張時に使用します。RED→GREEN→REFACTORサイクルをテストファーストアプローチで厳格に遵守します。高凝集度・低結合度・コロケーションを意識したアーキテクチャ設計を適用します。

⭐80stars🔀4forks📁View on GitHub🕐Updated Jan 3, 2026

When & Why to Use This Skill

This Claude skill automates the software development lifecycle using a strict Test-Driven Development (TDD) methodology. It streamlines the implementation of new features and bug fixes by adhering to the Red-Green-Refactor cycle. By integrating advanced architectural principles such as high cohesion, low coupling, and collocation, it ensures the production of clean, maintainable, and robust codebases that meet professional engineering standards.

Use Cases

  • New Feature Implementation: Building robust software components from scratch by writing failing tests first to define requirements and ensure full functional coverage.
  • Bug Fixing and Regression Testing: Identifying and resolving software defects by creating reproduction tests, ensuring that fixes are verified and do not introduce new issues.
  • Legacy Code Refactoring: Systematically improving existing code structures and maintainability while preserving functional integrity through continuous automated testing.
  • Architectural Optimization: Designing and organizing code modules with a focus on dependency injection and collocation to minimize system complexity and improve scalability.
namedeveloping
descriptionテスト駆動開発(TDD)方法論に従って新機能の実装やバグ修正を行います。新機能の実装、バグ修正、既存機能の拡張時に使用します。RED→GREEN→REFACTORサイクルをテストファーストアプローチで厳格に遵守します。

開発(TDD + アーキテクチャ設計)

参照ルール

  • TDDルール: rules/core/tdd.md
  • 設計原則: rules/core/design.md
  • テストルール: rules/core/testing.md
  • コミットルール: rules/core/commit.md

Design Thinking(設計思考)

実装前に以下の観点で設計を検討する:

1. 責務の明確化

  • この機能の単一責務は何か?
  • この変更は既存の責務を侵害しないか?
  • テストしやすい単位に分割できるか?

2. 依存関係の分析

  • このモジュールが依存するものは何か?
  • 依存を注入可能にできるか?(テストダブルで置換可能か)
  • 循環依存が発生しないか?

3. 配置の決定

  • この機能はどこに配置すべきか?(コロケーション原則に従う)
  • 関連するテスト・型・ヘルパーは同じ場所に配置できるか?
  • 変更時に影響範囲が最小化されるか?

ワークフロー

ステップ1: 設計思考

実装前に問いかける:

□ この機能の単一責務は何か?
□ どのディレクトリに配置すべきか?
□ 依存は注入可能か?
□ 既存コードへの影響範囲は?

ステップ2: 作業計画(TodoWriteを使用)

構造化されたタスクリストを作成:

- [ ] 失敗するテストを書く(RED)
- [ ] テストを通過させる最小限の実装(GREEN)
- [ ] リファクタリング(必要に応じて)
- [ ] 品質チェック(lint, format, build, test)

ステップ3: REDフェーズ - 失敗するテストを書く

テストを作成し、実行して失敗を確認。

ステップ4: GREENフェーズ - テストを通過させる

テストを通過させる最小限の実装を行う。

ステップ5: REFACTORフェーズ - 品質向上

すべてのテストがグリーンの場合のみ進める。

リファクタリングの観点(詳細は rules/core/design.md を参照):

  • 高凝集度を維持しているか
  • 低結合度を維持しているか
  • 重複を排除できるか

ステップ6: 品質チェック(必須)

# すべてのチェックが通過するまでタスクは完了しない
npm run lint     # リンターを実行
npm run format   # フォーマッターを実行
npm run build    # ビルドを実行
npm test         # テストを実行

バグ修正プロセス

  1. テストでバグを再現(テストは失敗するべき)
  2. 最小限の変更で修正
  3. エッジケーステストを追加
  4. 必要に応じてリファクタリング

リソース

references/architecture-patterns.md

高凝集度・低結合度・コロケーションの詳細パターン


覚えておくこと: すべての実装はテスト駆動でなければならない。例外なし。