yodogawa 2.1.1 → 2.2.0

package/scripts/setup-docs.sh

@@ -1,92 +0,0 @@
-#!/bin/bash
-
-# setup-docs.sh
-# プロジェクトのドキュメントディレクトリ構造を作成するスクリプト
-
-set -e
-
-DOCS_DIR="docs"
-
-echo "📂 ドキュメント構造のセットアップを開始します..."
-
-# 1. 現在の状態確認
-if [ -d "$DOCS_DIR" ]; then
-  echo "⚠️  '$DOCS_DIR' ディレクトリは既に存在します。"
-  read -p "既存の構造を保持したまま、不足しているディレクトリを追加しますか？ (y/N): " confirm
-  if [[ ! "$confirm" =~ ^[Yy]$ ]]; then
-    echo "❌ 中断しました。"
-    exit 0
-  fi
-fi
-
-# 2. ディレクトリ構造の作成
-echo "🔨 ディレクトリを作成中..."
-mkdir -p "$DOCS_DIR/project/01-requirements"
-mkdir -p "$DOCS_DIR/project/02-behavior"
-mkdir -p "$DOCS_DIR/project/03-domain"
-mkdir -p "$DOCS_DIR/project/04-design"
-mkdir -p "$DOCS_DIR/tasks"
-
-# 3. docs/README.md の作成
-README_FILE="$DOCS_DIR/README.md"
-if [ -f "$README_FILE" ]; then
-  echo "⚠️  '$README_FILE' は既に存在します。"
-  read -p "上書きしますか？ (y/N): " confirm_readme
-  if [[ ! "$confirm_readme" =~ ^[Yy]$ ]]; then
-    echo "ℹ️  READMEの作成をスキップしました。"
-  else
-    CREATE_README=true
-  fi
-else
-  CREATE_README=true
-fi
-
-if [ "$CREATE_README" = true ]; then
-  echo "📝 README.md を作成中..."
-  cat > "$README_FILE" <<EOF
-# プロジェクトドキュメント
-
-このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
-
-## 構成
-
-### project/
-プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
-
-- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
-- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
-- **03-domain/**: ドメインモデル（エンティティ、用語集など）
-- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
-
-### tasks/
-個別タスクのドキュメント。Issue やチケット単位で作成します。
-
-## 更新方針
-
-### プロジェクト全体のドキュメント (project/)
-- プロジェクトのスコープ全体に影響する情報を記載
-- チーム全体で共有すべき要件・設計・アーキテクチャを管理
-- 更新時は関係者にレビューを依頼
-
-### 個別タスクのドキュメント (tasks/)
-- 特定の Issue やチケットに紐づく情報を記載
-- タスク単位で作成・完了・アーカイブ
-- 完了後は参照資料として保持、または削除
-
-## ドキュメント作成ガイドライン
-
-- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
-- **測定可能**: 成功基準やパフォーマンス目標を定量化
-- **最新**: 変更があれば速やかに更新し、古い情報を残さない
-- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
-EOF
-fi
-
-# 4. 完了報告
-echo ""
-echo "✅ ドキュメントディレクトリ構造のセットアップが完了しました！"
-echo ""
-find "$DOCS_DIR" -maxdepth 2 | sort
-echo ""
-echo "次のステップ:"
-echo "  - 必要に応じて 'git add $DOCS_DIR' を実行してください。"

package/templates/documentation-rules.md

@@ -1,143 +0,0 @@
-### Documents
-
-ドキュメンテーション構造
-
----
-
-## プロジェクト単位
-
-#### 1. 要件（何を作るか）
-
-- **要件定義**
-  - システム概要：背景（解決する課題）と目的（提供する価値、解決策）
-  - 実装済み機能一覧：既に実装されている機能
-  - 未実装機能一覧：今後実装予定の機能
-  - 非機能要件一覧：性能、セキュリティ、可用性、スケーラビリティなど
-- **ユーザーストーリー**
-  - ユーザーストーリー一覧：各ユーザーストーリー
-
-#### 2. 振る舞い（どう動くか）
-
-- **振る舞い**
-  - Gherkinシナリオ一覧：Given-When-Then形式の理想的な動作シナリオ
-
-#### 3. ドメイン（ドメインモデルと用語）
-
-- **ドメインモデル**
-  - Event Storming形式のドメインモデル：Bounded Context、Actors、Commands、Events、Policies、Aggregatesなど
-  - Context Map：Bounded Context間の関係性
-- **ユビキタス言語**
-  - ユビキタス言語一覧：プロジェクト共通の用語定義、Bounded Contextごとの用語
-
-#### 4. 設計（どう作るか）
-
-- **テックスタック**
-  - 技術スタック一覧：使用する言語、フレームワーク、ライブラリ、ツール
-- **リポジトリ構造**
-  - ディレクトリ構造：プロジェクトのフォルダとファイルの整理方法
-- **画面設計**
-  - 画面遷移図：画面間の遷移フローと条件
-  - 各画面の役割：各画面の目的と主要な機能
-- **データモデル**
-  - ERD（Entity Relationship Diagram）：エンティティ、属性、関係性
-- **API仕様**
-  - API仕様書：エンドポイント、リクエスト/レスポンス形式、認証方式
-- **アーキテクチャ設計**
-  - システムアーキテクチャ図：システム全体の構成とコンポーネントの関係
-- **インフラ設計**
-  - インフラ構成図：サーバー構成、ネットワーク、環境設定
-
----
-
-## タスク単位
-
-作成順序：A → B → C
-
-### A. タスク定義ドキュメント
-
-#### 1. 目的
-
-- 解決する問題：具体的な課題や不便
-- 提供する価値：ユーザーやシステムが得られる利益
-
-#### 2. ユーザーストーリー一覧
-
-- [役割]として、[目的]がしたい、なぜなら[理由]
-
-#### 3. 変更内容一覧
-
-- 画面：追加・変更する画面とUIコンポーネント
-- データモデル：エンティティ、テーブル、フィールドの追加・変更
-- API：エンドポイント、リクエスト/レスポンス形式の追加・変更
-- その他：環境設定、インフラ、ツール設定
-
-#### 4. 受け入れ基準
-
-- タスク完了の判断条件（例：画面表示の確認、APIの応答確認、Gherkinシナリオ）
-
-### B. リサーチドキュメント
-
-#### 1. ベストプラクティス
-
-- 技術的なベストプラクティス
-- 設計パターンとアーキテクチャの妥当性
-
-#### 2. 既存コードの調査
-
-- 類似機能の実装箇所と実装パターン
-- 再利用可能なコンポーネントや関数
-- 参考にすべきコード構造
-
-### C. 実装タスクリスト
-
-#### フェーズとステップ
-
-テスト可能なフェーズに分割し、各フェーズ内にチェック可能なステップを配置
-
-- **フェーズ 1**：[フェーズ名]（例：データモデルの実装）
-  - [ ] ステップ 1：[タスク内容]
-    - 成果物：[生成されるもの]
-  - [ ] ステップ 2：[タスク内容]
-    - 成果物：[生成されるもの]
-- **フェーズ 2**：[フェーズ名]（例：API実装とテスト）
-  - [ ] ステップ 1：[タスク内容]
-    - 成果物：[生成されるもの]
-
----
-
-## ディレクトリ構造
-
-```
-docs/
-├── README.md                           # ドキュメント構造の説明
-├── project/                            # プロジェクト単位
-│   ├── 01-requirements/                # 要件
-│   │   ├── 01-system-overview.md       # システム概要
-│   │   ├── 02-features-implemented.md  # 実装済み機能一覧
-│   │   ├── 03-features-planned.md      # 未実装機能一覧
-│   │   ├── 04-non-functional-requirements.md  # 非機能要件
-│   │   └── 05-user-stories.md          # ユーザーストーリー
-│   ├── 02-behavior/                    # 振る舞い
-│   │   └── 01-scenarios.md             # Gherkinシナリオ一覧
-│   ├── 03-domain/                      # ドメイン
-│   │   ├── 01-domain-model.md          # ドメインモデル（Event Storming形式）
-│   │   └── 02-ubiquitous-language.md   # ユビキタス言語
-│   └── 04-design/                      # 設計
-│       ├── 01-tech-stack.md            # テックスタック
-│       ├── 02-repository-structure.md  # リポジトリ構造
-│       ├── 03-ui-design.md             # 画面設計
-│       ├── 04-data-model.md            # データモデル（ERD）
-│       ├── 05-api-spec.md              # API仕様
-│       ├── 06-architecture.md          # アーキテクチャ設計
-│       └── 07-infrastructure.md        # インフラ設計
-└── tasks/                              # タスク単位
-    ├── TASK-001-feature-name/
-    │   ├── a-definition.md             # タスク定義ドキュメント
-    │   ├── b-research.md               # リサーチドキュメント
-    │   └── c-implementation.md         # 実装タスクリスト
-    ├── TASK-002-another-feature/
-    │   ├── a-definition.md
-    │   ├── b-research.md
-    │   └── c-implementation.md
-    └── ...
-```

package/templates/project/01-requirements/01-system-overview.md

@@ -1,49 +0,0 @@
-# システム概要
-
-## 背景
-
-<!--
-何を書くか: このシステムで解決しようとしている問題を記述
-
-文量: 2-4文程度（100-200文字）
-トーン: 客観的で事実ベース。感情的な表現は避ける
-必須情報:
-  - 現在直面している具体的な問題や課題
-  - なぜその問題が重要なのか
-  - 問題の影響を受けるステークホルダー
-
-ベストプラクティス:
-  - 具体的な数値やデータがあれば含める（例: 「3ヶ月かかる」「70%が離脱」）
-  - 「〜できない」「〜が困難」など問題を明確に表現
-  - 誰が・いつ・どこで困っているかを具体的に示す
-  - 現状の workaround や代替手段があればそれも言及
-  - 抽象的な表現（「効率が悪い」）より具体的な表現（「手動で2時間かかる作業」）を使う
--->
-
-**例:**
-新入社員が既存社員とコミュニケーションを取る機会が限られており、チームに溶け込むまでに時間がかかる。また、リモートワークの増加により、雑談や自然な関係構築の場が減少している。
-
----
-
-## 目的
-
-<!--
-何を書くか: このシステムが提供する価値や解決策を記述
-
-文量: 2-4文程度（100-200文字）
-トーン: ポジティブで具体的。実現可能な内容に留める
-必須情報:
-  - システムがどのように問題を解決するか
-  - ユーザーや組織が得られる具体的な価値
-  - 期待される成果や変化
-
-ベストプラクティス:
-  - 「〜を可能にする」「〜を支援する」など能動的な表現を使う
-  - 技術的な詳細（「React使用」）よりもビジネス価値（「開発速度2倍」）に焦点を当てる
-  - 測定可能な成果があれば言及する（例: 「作業時間を50%削減」「離脱率を20%改善」）
-  - どのように問題を解決するか、具体的なメカニズムを簡潔に示す
-  - ユーザーにとっての before/after が想像できる表現を使う
--->
-
-**例:**
-社員がライフラインチャートを通じて自己紹介し、共通点を見つけやすくすることで、組織横断のコミュニケーションを活性化する。コメント機能により双方向の対話を促進し、早期の関係構築を支援する。

package/templates/project/01-requirements/03-features-planned.md

@@ -1,75 +0,0 @@
-# 未実装機能一覧
-
-<!--
-何を書くか: 今後実装を検討・予定している機能のリスト
-
-目的:
-  - プロダクトのロードマップや将来ビジョンを可視化
-  - ステークホルダーとの期待値調整
-  - 技術的負債や機能gap の把握
-  - 実装優先度の議論のベース資料
-
-特徴:
-  - 機能IDなし: まだ確定していないため識別子は不要
-  - 優先度なし: 優先度は常に変動し混乱を招くため記載しない
-  - 柔軟性重視: アイデア段階の機能も含めて良い
-
-記載粒度: 実装済み機能一覧と同程度（ユーザーが認識できる機能単位）
-
-更新頻度:
-  - 機能を実装したら「実装済み機能一覧」に移動し、こちらから削除
-  - 新しいアイデアや要望が出たら随時追加
-  - 四半期ごとなど定期的に見直し、不要な機能は削除
--->
-
-<!--
-テーブル構成:
-
-【Category 1】（大分類）
-  - 実装済み機能一覧と同じカテゴリ体系を使用
-  - 既存カテゴリに当てはまらない場合は新カテゴリを追加
-  - 例: ユーザー管理、コンテンツ、決済、通知、分析
-
-【Category 2】（中分類）
-  - 実装済み機能一覧と同じカテゴリ体系を使用
-  - より具体的な機能領域で分類
-  - 例: ユーザー管理 → 認証、プロフィール、権限
-
-【機能名】
-  - 簡潔で分かりやすい名称（2-5単語程度）
-  - ユーザー視点の表現を使う
-  - まだ確定していなくても仮の名称で記載OK
-  - 例: 「二段階認証」「下書き保存」「AIレコメンド」
-
-【説明】
-  - 1-2文で機能の内容を記述（50-100文字程度）
-  - 何を実現したいか（目的）を中心に記述
-  - 「〜したい」「〜できるようにする」など意図が伝わる表現
-  - 実装方法が未定でもユーザー価値を記述
-
-ベストプラクティス:
-  - 実装の難易度や工数は記載しない（別途見積もりで管理）
-  - 「いつか実装したい」程度のアイデアも含めて良い（柔軟に）
-  - 競合製品の機能を参考にする場合は、自社プロダクトでの意義を明確に
-  - カテゴリ分類により、特定領域の機能が不足していないか確認できる
-  - 定期的に見直し、実装しない判断をした機能は削除（理由はGitコミットメッセージに残す）
-  - 技術的な表現（「WebSocket実装」）より価値の表現（「リアルタイム通知」）を優先
--->
-
-| Category 1 | Category 2 | 機能名 | 説明 |
-|-----------|-----------|--------|------|
-| <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
-
----
-
-**例:**
-
-| Category 1 | Category 2 | 機能名 | 説明 |
-|-----------|-----------|--------|------|
-| ユーザー管理 | 認証 | 二段階認証 | SMS/アプリでの二段階認証 |
-| ユーザー管理 | 認証 | ソーシャルログイン | Google/GitHubアカウントでログイン |
-| ユーザー管理 | プロフィール | バッジシステム | 実績に応じたバッジ表示 |
-| コンテンツ | 投稿 | 下書き保存 | 記事の下書き保存機能 |
-| コンテンツ | 投稿 | 予約投稿 | 指定日時での自動投稿 |
-| コンテンツ | コメント | 返信機能 | コメントへの返信スレッド |
-| コンテンツ | コメント | いいね機能 | コメントへのいいね |