# devtools スキル開発プロセスガイド

本書では、`devtools` スキルを活用したプロジェクト開発の全体フロー、および各ドキュメントとタスクの管理方法について定義します。

---

## 1. 開発基本方針：ドキュメント駆動開発

当プロジェクトでは、コードを書き始める前にまずドキュメントを作成・更新し、設計や仕様を明確化する**「ドキュメント駆動開発」**を採用しています。
これにより、設計の不整合や要件の漏れを早期に検出し、手戻りを防ぎます。

---

## 2. 開発プロセスの全体像

開発プロセスは、大きく以下の2つのフェーズで進行します。

```mermaid
flowchart TD
    subgraph Phase1 ["フェーズ 1: 設計・仕様定義"]
        CONCEPT["CONCEPT.md (コンセプト)"] --> REQUIREMENTS["REQUIREMENTS.md (要件定義)"]
        CONCEPT --> SECURITY["SECURITY.md (セキュリティ)"]
        CONCEPT --> SCHEMA["SCHEMA.md (スキーマ定義)"]
        
        REQUIREMENTS --> ARCHITECTURE["ARCHITECTURE.md (基本設計)"]
        SECURITY --> ARCHITECTURE
        
        ARCHITECTURE --> DESIGN["DESIGN.md (詳細設計)"]
        SCHEMA --> MODELS["models/*.md (モデル定義)"]
        
        ARCHITECTURE --> SPEC["SPEC.md (仕様書)"]
        DESIGN --> SPEC
        MODELS --> SPEC
        
        SPEC --> TEST_SPEC["TEST_SPEC.md (テスト仕様)"]
    end

    subgraph Phase2 ["フェーズ 2: 開発・タスク実行 (Backlog)"]
        TEST_SPEC --> PLAN["PLAN.md (実装計画)"]
        PLAN --> WBS["WBS.md (タスク工程分割)"]
        WBS --> BACKLOG["BACKLOG.md (課題・タスク管理)"]
        BACKLOG --> ISSUE["ISSUE-XXXX.md (課題起票)"]
        ISSUE --> TASK["TASK-XXXX.md (作業タスク定義)"]
        TASK --> IMPL["実装・テスト実行 (TDD推奨)"]
    end
```

---

## 3. フェーズ 1: 設計・仕様定義フェーズ

上流のコンセプトから徐々に具体化し、テストケースが定義されるまで実装フェーズには移行しません。

### 各ドキュメントの作成フロー

1. **コンセプトの決定**
   *   作成ドキュメント: `docs/CONCEPT.md`
   *   対応スキル: `create-concept`
   *   目的: プロジェクトの概要、ターゲット、主要機能、動作環境を定義します。

2. **要件定義とセキュリティ方針の策定**
   *   作成ドキュメント: `docs/REQUIREMENTS.md`, `docs/SECURITY.md`
   *   対応スキル: `create-requirements`, `create-security`
   *   目的: 機能・画面一覧の抽出、およびセキュリティ基本方針を策定します。

3. **基本設計・データベース設計**
   *   作成ドキュメント: `docs/ARCHITECTURE.md`, `docs/SCHEMA.md`, `docs/models/<table-name>.md`
   *   対応スキル: `create-architecture`, `create-schema`, `create-model`
   *   目的: システム構成、技術スタック、データベースER図、各テーブルの物理モデルを設計します。

4. **詳細設計・共通ロジック定義**
   *   作成ドキュメント: `docs/DESIGN.md`, `docs/services/<service-name>.md`
   *   対応スキル: `create-design`, `create-service`
   *   目的: アプリケーションのコンポーネント構成、ディレクトリ構造、共通ビジネスロジック・DTOを設計します。

5. **仕様書の作成**
   *   作成ドキュメント: `docs/SPEC.md`
   *   対応スキル: `create-spec`
   *   目的: 各画面・機能ごとの入出力仕様、ViewModel定義など、実装のための完全な仕様書を用意します。

6. **テスト仕様書の作成**
   *   作成ドキュメント: `docs/TEST_SPEC.md`
   *   対応スキル: `create-testspec`
   *   目的: 仕様書に基づき、機能・画面が正しく動作するか検証するためのテストケースをすべて定義します。

---

## 4. フェーズ 2: 開発・タスク実行フェーズ (Backlog 管理)

仕様とテスト項目が確定した後、タスク管理と実際の実装フェーズへ移行します。

### 1. 開発計画とWBSへの分解

*   **実装計画書の作成 (`docs/PLAN.md`)**
    *   対応スキル: `create-plan`
    *   目的: フロントエンド、バックエンド、ライブラリなどの実装順序と依存関係を整理します。
*   **WBSの作成 (`backlog/WBS.md`)**
    *   対応スキル: `create-wbs`
    *   目的: 実装計画と仕様を元に、スケジュール・工数・担当者を設定した細分化されたタスクリストを作成します。

### 2. Backlog 運用による課題とタスクの管理

*   **課題（ISSUE）の登録**
    *   作成ファイル: `backlog/issues/ISSUE-XXXX.md`（または SaaS 上の Issue）
    *   目的: `WBS.md` に紐づく、または突発的なバグ・変更要求を「課題」として登録し、ステータスを管理します。
*   **タスク（TASK）の起票**
    *   作成ファイル: `backlog/tasks/TASK-XXXX.md`
    *   対応スキル: `create-task`
    *   目的: 課題を解決するための具体的な作業手順書を定義します。

### 3. テスト駆動開発 (TDD) の採用

実装においては、先にテストコードを書いてから本体の実装を行う**テスト駆動開発（TDD）**の採用を推奨します。

*   `docs/TEST_SPEC.md` から当該タスクに該当する検証項目を抽出します。
*   実装前に機能テストまたは単体テストのコードを作成します（この時点ではテストは失敗します）。
*   テストをパスするように最小限の実装を行い、その後リファクタリングを行います。

### 4. 実装・検証ライフサイクル（運用フロー）

開発を進める際の実装設計・コーディング・テスト・レビュー、および手戻りのプロセスフローを以下に定義します。エージェントおよび開発者はこのフローに従ってタスクを実行します。

#### ワークフロー図

```mermaid
flowchart TD
    WBS["WBS (計画)"] -->|"タスク切り出し"| ISSUE["SaaS/ローカル ISSUES (課題登録)"]
    QA["テスト/開発後の不具合・機能追加"] -->|"課題登録"| ISSUE
    
    ISSUE -->|"課題解決タスク作成"| TASK["TASK-XXXX.md (タスク定義)"]
    
    subgraph DevLoop ["実装・検証ループ"]
        TASK -->|"A: 実装計画書作成/更新"| PLAN["Implementation Plan (実装計画)"]
        PLAN -->|"B: コーディング実行"| CODE["Implementation (実装/TDD推奨)"]
        
        CODE -->|"検証"| TEST_U["Unit Test (単体テスト)"]
        TEST_U -->|"Pass"| TEST_I["Integration Test (結合テスト)"]
        TEST_I -->|"Pass"| REVIEW["Review (コードレビュー)"]
        
        TEST_U -->|"Fail"| CODE
        TEST_I -->|"Fail"| CODE
        REVIEW -->|"指摘あり"| CODE
        
        REVIEW -->|"根本的に解決不能 / 設計変更が必要"| PLAN
        TEST_I -->|"設計変更が必要な失敗"| PLAN
    end
    
    REVIEW -->|"問題なし (All Green)"| COMPLETE["Task Complete (タスク完了 / 課題クローズ)"]
```

#### ライフサイクル手順詳細

1. **課題登録 (ISSUES)**:
    *   **新規開発の場合**: WBSから対象機能のタスクを切り出し、課題（SaaS Issue または `ISSUE-XXXX.md`）に登録します。
    *   **保守・追加開発の場合**: テスト実行時の不具合報告や、後発の機能追加要件から直接 `ISSUE` に登録されます。
2. **タスク作成 (TASK)**:
    *   `ISSUE` の内容を解決するための具体的な作業指示書として `TASK-XXXX.md` を作成します（対応スキル: `create-task`）。
3. **実装計画の作成 (A: Implementation Plan)**:
    *   実装に着手する前に、何を変更し、どのように検証するか（影響範囲やテスト計画）を実装計画としてまとめます（TASKファイル内に併記、または計画ドキュメント化）。
4. **実装・開発 (B: Implementation)**:
    *   実装計画に基づき、対象コードベースのコーディングおよび修正を実行します。TDD（テスト駆動開発）を採用する場合、実装前にテストコードを記述します。
5. **単体テスト (Unit Test)**:
    *   実装したコードに対応する単体テスト（自動テスト）を実行、および `UNIT_CHECKLIST-{XXXX}.md` を使用した動作確認を実施します。エラーがあれば **「B: 実装・開発」** に戻ります。
6. **結合テスト (Integration Test)**:
    *   他モジュールやDBとの連携、画面間遷移などの結合テストを実行、および `INTEGRATION_CHECKLIST-{XXXX}.md` に従いシナリオ動作を確認します。不具合が検出された場合は **「B: 実装・開発」** または根本的な設計不備なら **「A: 実装計画の作成」** に戻ります。
7. **コードレビュー (Review)**:
    *   実装および各種テスト結果をエージェント自身またはレビューアが検証し、設計・コード品質をチェックします。指摘があれば **「B: 実装・開発」** に戻ります。
8. **タスク完了 (Task Complete)**:
    *   単体テスト、結合テスト、およびコードレビューのすべてで問題が出なくなった（All Green）段階で、タスク完了となり課題（ISSUE）をクローズします。

---

## 5. ドキュメントの維持・管理

コードや仕様の追加・変更が発生した場合は、速やかに関連ドキュメントを更新する必要があります。

*   **一括/個別更新スキル (`update-documents`, `update-document`)** を活用し、ドキュメント間の整合性を維持します。
*   ドキュメントの品質や整合性をチェックするため、**レビュースキル (`review-document`)** も必要に応じて実行してください。
