@einja/dev-cli 0.1.6

package/scaffolds/steering/task-management.md

@@ -0,0 +1,367 @@
+# タスク管理ガイドライン
+
+このドキュメントでは、プロジェクトのタスク管理における階層構造、GitHub Issue管理、用語定義を説明します。
+
+## タスク管理の方法
+
+このプロジェクトでは**GitHub Issue**を使用してタスクを管理します。
+
+### 基本構造
+
+- **1 spec = 1 GitHub Issue**
+- 各specフォルダ（`docs/specs/issues/issue{issue番号}-{機能名}/`）に対して1つのGitHub Issueを作成
+- requirements.mdとdesign.mdはファイルとして保持
+- タスク一覧のみGitHub Issueで管理
+
+### GitHub Issueの構造
+
+Issue本文には以下のセクションを含みます：
+
+```markdown
+## AS-IS
+<!-- requirements.mdから抽出した現在の状態・問題点 -->
+
+## TO-BE
+<!-- requirements.mdから抽出した実装後の期待する状態 -->
+
+## 対応方針
+<!-- design.mdから抽出した技術的アプローチ、使用ライブラリ、実装方針 -->
+
+## タスク一覧
+
+### Phase 1: [フェーズ名]
+
+- [ ] 1.1 [タスクグループ名]
+
+  - 1.1.1 [タスク名]
+    - サブタスク内容
+    - **要件**: Story X
+    - **依存関係**: なし
+    - **完了条件**: [テスト条件]が通ること（AC[番号]を満たす）
+    - **対応設計**: design.md「[セクション名]」セクション
+    - **シナリオテスト**: なし（基盤構築タスク、UIフロー未実装のため）
+
+  - 1.1.2 [タスク名]
+    - サブタスク内容
+    - **要件**: Story X
+    - **依存関係**: 1.1.1
+    - **完了条件**: [テスト条件]が通ること（AC[番号]を満たす）
+    - **対応設計**: design.md「[セクション名]」セクション
+    - **シナリオテスト**: シナリオ1 Step 1-3（部分実行）
+
+- [ ] 1.2 [タスクグループ名]
+
+  - 1.2.1 [タスク名]
+    - サブタスク内容
+    - **要件**: Story X
+    - **依存関係**: 1.1
+    - **完了条件**: ...
+    - **対応設計**: design.md「[セクション名]」セクション
+    - **シナリオテスト**: シナリオ2 Step 1-5
+
+### Phase 2: [フェーズ名]
+
+- [ ] 2.1 [タスクグループ名]
+
+  - 2.1.1 [タスク名]
+    - サブタスク内容
+    - **要件**: Story X
+    - **依存関係**: Phase 1完了
+    - **完了条件**: ...
+    - **対応設計**: design.md「[セクション名]」セクション
+    - **シナリオテスト**: シナリオ3 全ステップ
+```
+
+### タスクグループのステータス管理
+
+GitHub Issueのチェックボックスでタスクグループのステータスを管理します：
+
+**未着手**:
+```markdown
+- [ ] 1.1 タスクグループ名
+```
+
+**完了**（チェックボックスをON）:
+```markdown
+- [x] 1.1 タスクグループ名
+```
+
+**注意**: タスクグループの完了時、GitHub Issueのチェックボックス更新はユーザーが明示的に指示した場合のみ行います。`/task-exec`コマンドは自動でIssueを更新しません。
+
+### Issueのライフサイクル
+
+1. **Issue作成**: `/spec-create`コマンドで仕様書作成時に自動生成
+2. **タスクグループ実行**: `/task-exec #{issue_number} {タスクグループ番号}`でタスクグループを実行
+3. **タスクグループ完了**: 実装・テスト・レビュー完了後、チェックボックスをON（手動更新）
+4. **Issue完了**: すべてのタスクグループが完了したらIssueをClose
+
+## タスク階層の用語定義
+
+プロジェクトのタスク管理では、以下の4階層を使用します。
+
+### タスク階層一覧表
+
+| 階層 | 番号形式 | 粒度・定義 | 成果物 | Issueでの書式 |
+|------|----------|------------|--------|---------------|
+| Phase | 1, 2, 3 | 一連のACを確認できる単位（2-3個、全Phase完了で全AC網羅） | リリース | `### Phase 1: [名前]` |
+| タスクグループ | X.Y | 1つまたは一部のACが確認できる単位（大きめの1PRでもOK） | 1PR・マージ・デプロイ | `- [ ] 1.1 [名前]` |
+| タスク | X.Y.Z | コミット単位（15分〜1時間程度） | 個別コミット | `  - 1.1.1 [名前]` + メタデータ |
+| サブタスク | なし | タスク内の詳細作業（任意） | タスクの一部 | `    - [内容]`（任意） |
+
+### Phase完了確認タスクグループ
+
+各Phaseの最後には、必ず**Phase完了確認**タスクグループを配置します：
+
+```markdown
+## Phase 1完了確認
+
+- [ ] 1.X フェーズ1完了条件確認
+
+  - 1.X.1 フェーズ1全タスク完了確認
+    - タスクグループ1.1〜1.N の全タスク完了確認
+    - 全シナリオテストの成功確認
+    - コードレビュー完了確認
+    - デプロイ可能な状態であることを確認
+    - **要件**: Story 1, Story 2（該当する全Story）
+    - **依存関係**: 1.N.Z（Phase内の最後のタスク番号）
+    - **完了条件**: フェーズ1の全タスクグループが完了し、受け入れ基準**AC1.1〜AC1.N**を満たすことが確認できること
+    - **対応設計**: design.md 全セクション
+    - **シナリオテスト**: 全シナリオ（リグレッション確認）
+```
+
+**目的**:
+- Phase内の全タスクが完了していることを明示的に確認
+- 次Phaseへの移行条件を完了条件に明記
+- QAチェックポイントとして機能
+
+### 粒度の判断基準
+
+| 階層 | ✅ 適切 | ❌ 不適切 |
+|------|---------|----------|
+| **Phase** | 2-3個で全AC網羅、機能的区切りで分割 | 4個以上、細かすぎる分割 |
+| **タスクグループ** | 縦切り（フルスタック）、AC検証可能、1PR単位 | 横切り（画面/レイヤー/クラス単位）、設定1個だけ |
+| **タスク** | 1コミット単位、具体的な作業 | 曖昧な作業、複数日かかる作業 |
+
+### 🔴 ATDDタスクグループ設計原則
+
+**タスクグループ = ACを検証可能にする単位**
+
+ATDDの本質は「受け入れ基準（AC）を中心にタスクを分解する」こと。
+タスクグループ完了時に、対応するACがデプロイして検証可能な状態になっていなければならない。
+
+**原則: 縦切り（フルスタック）で分割、横切り（レイヤー/画面）は❌**
+
+✅ **縦切り**（1機能をフルスタックで）:
+- Domain → Infrastructure → UseCase → API → UI を1タスクグループで
+- 完了時にACが検証可能
+
+❌ **横切り**（レイヤー/画面ごと）:
+- Domain層の実装 / Infra層の実装 / UseCase実装 / API実装 / UI実装
+- 各層単体では検証不可能
+
+### ❌ アンチパターン（絶対にやってはいけない分割）
+
+**パターン1: 画面ごとの分割**
+```
+❌ NG例:
+- 3.2 一覧画面の実装
+- 3.3 詳細画面の実装
+- 3.4 新規登録画面の実装
+- 3.5 編集画面の実装
+- 3.6 削除機能の実装
+
+✅ OK例:
+- 2.2 CRUD機能の実装（一覧・詳細・作成・編集・削除）
+```
+
+**パターン2: レイヤーごとの分割**
+```
+❌ NG例:
+- 2.1 Domain層の実装（Entity, VO, Repository IF）
+- 2.2 Infrastructure層の実装（Mapper, Repository）
+- 2.3 Application層の実装（UseCase）
+- 2.4 Presentation層の実装（API, UI）
+
+✅ OK例:
+- 2.1 招待・パスワード設定機能
+  - Domain〜UIまでフルスタックで実装
+  - AC3〜AC5を検証可能
+```
+
+**パターン3: クラスごとの分割**
+```
+❌ NG例（これらはタスクグループではなくタスクレベル（X.Y.Z）であるべき）:
+- 2.1 User Entityの実装
+- 2.2 Invitation Entityの実装
+- 2.3 HashedPassword VOの実装
+```
+
+### メタデータの記述（タスク単位に付与）
+
+各タスク（X.Y.Z）には以下のメタデータを**必須**で付与します：
+
+```markdown
+- [ ] 1.1 Server Core構築とDB設定
+
+  - 1.1.1 packages/server-core初期化とtsconfig設定
+    - tsconfig.jsonの設定
+    - 依存パッケージのインストール
+    - **要件**: Story 1
+    - **依存関係**: なし
+    - **完了条件**: server-coreパッケージが初期化されること（AC1.1を満たす）
+    - **対応設計**: design.md「Server Core構築」セクション
+    - **シナリオテスト**: なし（基盤構築タスク、UIフロー未実装のため）
+
+  - 1.1.2 DB接続設定とマイグレーション
+    - Prismaスキーマの作成
+    - マイグレーションの実行
+    - **要件**: Story 1
+    - **依存関係**: 1.1.1
+    - **完了条件**: DBに接続できること（AC1.2〜AC1.3を満たす）
+    - **対応設計**: design.md「DB設計」セクション
+    - **シナリオテスト**: なし（DB設定のみ、UIフロー未実装のため）
+```
+
+**メタデータ項目（全て必須）**:
+- **要件**: 対応するStory番号
+- **依存関係**: なし / X.Y.Z / Phase X完了
+- **完了条件**: AC番号を含む完了条件
+- **対応設計**: design.mdの参照セクション
+- **シナリオテスト**: 該当タスク完了時に実行するシナリオ（該当なければ「なし」と理由を明記）
+
+**注意**: サブタスクは**任意**で記載。詳細はrequirements.md/design.mdを参照。
+
+### 依存関係の記述形式（重要）
+
+**🔴 `pnpm task:loop`スクリプトが認識できる形式のみ使用すること**
+
+| 記述形式 | 意味 | 例 |
+|---------|------|-----|
+| `なし` | 依存関係なし | `**依存関係**: なし` |
+| `X.Y` | タスクグループ依存 | `**依存関係**: 1.1` |
+| `X.Y, X.Y` | 複数タスクグループ依存 | `**依存関係**: 1.2, 1.3` |
+| `Phase X完了` | Phase依存 | `**依存関係**: Phase 1完了` |
+
+**❌ 使用禁止の形式:**
+- `1.1完了` → スクリプトが認識できない
+- `タスク1.1` → スクリプトが認識できない
+- `1.1、1.2` → 全角カンマは避ける（半角カンマ推奨）
+
+## タスク管理のワークフロー
+
+> **詳細なフロー（仕様書作成からレビュー・マージまで）は[開発ワークフロー](development-workflow.md)を参照してください。**
+
+### 1. タスクグループを選定・実行
+- `/task-exec #{issue_number} {タスクグループ番号}`コマンドを実行
+- タスクグループ番号は必須引数（例: `1.1`, `2.3`）
+- executer → reviewer → qa の3段階で実行
+
+### 2. タスクを順次実装し、コミット
+- 各タスク（1.1.1, 1.1.2...）完了ごとにコミット
+- コミットメッセージにタスク内容を記載
+- 例: `feat(server-core): packages/server-core初期化とtsconfig設定`
+- コミットルールは[コミットルール](commit-rules.md)を参照
+
+### 3. タスクグループ完了時にPR作成
+- 全タスクが完了したらPR作成
+- PR単位でレビュー・デプロイ・QA実施
+- PRタイトル: `[タスクグループ番号] タスクグループ名`（例: `[1.1] Server Core構築とDB設定`）
+
+### 4. Issue更新（手動）
+- タスクグループ完了後、GitHub Issueのチェックボックスを手動でON
+- または、ユーザーが明示的に指示した場合のみ自動更新
+- すべてのタスクグループが完了したら、IssueをClose
+
+## Vibe-Kanbanタスク作成時の必須情報
+
+### タスクタイトル形式
+```
+[タスクグループ番号] タスクグループ名
+```
+
+**例**: `[1.1] Server Core構築とDB設定`
+
+### タスク説明形式
+
+```markdown
+## GitHub Issue
+#{issue_number}
+
+## タスクグループ番号
+<タスクグループ番号>
+
+## 概要
+<タスクグループの概要>
+
+## タスク
+<GitHub Issueから抽出したタスク一覧>
+
+## 依存関係
+<依存するタスクグループ番号>
+
+## 完了条件
+<受け入れ基準を含む完了条件>
+
+## 対応設計
+<design.mdの参照箇所>
+```
+
+**例**:
+```markdown
+## GitHub Issue
+#17
+
+## タスクグループ番号
+1.1
+
+## 概要
+packages/server-coreの初期化からDB接続設定まで、Server Coreの基盤構築を完了
+
+## タスク
+- 1.1.1 packages/server-core初期化とtsconfig設定
+- 1.1.2 DB接続設定とマイグレーション
+
+## 依存関係
+なし
+
+## 完了条件
+server-coreパッケージが動作し、DBに接続できること（AC1.1を満たす）
+
+## 対応設計
+design.md「Server Core構築」セクション
+```
+
+## コマンドリファレンス
+
+### タスク管理関連コマンド
+
+**仕様書作成とIssue生成**:
+```bash
+/spec-create [タスク内容の説明]
+```
+- requirements.md、design.mdを作成し、GitHub Issueを自動生成
+
+**タスクグループ実行**:
+```bash
+/task-exec #{issue_number} {タスクグループ番号}
+```
+- Issue番号とタスクグループ番号は両方必須
+- executer → reviewer → qa の3段階で実行
+- QA合格後は追加指示待ち状態に入る
+- GitHub Issue更新はユーザーの明示的指示時のみ
+
+**自動ループ実行**:
+```bash
+pnpm task:loop <issue番号>
+pnpm task:loop <issue番号> --max-group <番号>  # 指定番号まで実行
+pnpm task:loop <issue番号> --branch <ブランチ> # ベースブランチ指定
+```
+- 着手可能なタスクグループを並列でVibe-Kanbanに登録
+- Done状態を監視して次のタスクを自動開始
+- **前提**: `npx @einja/cli init` 実行済み、Claude Code インストール済み
+
+**仕様書からドキュメント更新**:
+```bash
+/update-docs-by-task-specs [タスク仕様書ディレクトリパス]
+```
+- タスク仕様書の内容をfeature仕様書とsteering仕様書に反映

package/templates/README.md

@@ -0,0 +1,159 @@
+# ドキュメントテンプレート
+
+このディレクトリには、新規タスク作成時に使用する公式テンプレートが格納されています。
+
+## 使用方法
+
+### 新規タスクの要件定義書を作成する場合
+
+1. `requirements.md.template` をコピー
+2. `docs/specs/issues/[issue番号]-[機能名]/requirements.md` として保存
+3. テンプレート内のコメントに従って内容を記入
+4. **「受け入れ基準（Acceptance Criteria）」セクションは必ず記入すること**
+
+### 新規タスクの設計書を作成する場合
+
+1. `design.md.template` をコピー
+2. `docs/specs/issues/[issue番号]-[機能名]/design.md` として保存
+3. テンプレート内のコメントに従って内容を記入
+
+## 重要事項
+
+### 受け入れ基準（Acceptance Criteria）について
+
+- **受け入れ基準（Acceptance Criteria）セクションは必須です**
+- QAエージェント（task-qa）はこのセクションを参照してテストシナリオを作成します
+- セクションの構造を変更しないでください
+- Given/When/Then形式を使用してください
+
+### Given/When/Then形式の書き方
+
+受け入れ基準は以下の形式で記載してください：
+
+```markdown
+- [ ] Given: [前提条件]
+      When: [実行する操作]
+      Then: [期待される結果]
+```
+
+**良い例**:
+```markdown
+- [ ] Given: ログインページにアクセスした
+      When: 有効なメールアドレスを入力して送信
+      Then: 成功メッセージが表示され、メールが送信される
+```
+
+**悪い例**:
+```markdown
+- [ ] ログインフォームが実装されている
+- [ ] メール送信機能が動作すること
+```
+
+### 受け入れ基準作成のガイドライン
+
+詳細は `docs/einja/steering/acceptance-criteria-and-qa-guide.md` を参照してください。
+
+#### Do（推奨）
+- 振る舞い・入力・観測可能な結果をセットで書く（Given/When/Then）
+- ビジネス価値やユーザー影響が分かる文脈を添える
+- 正常系に加え、代表的な異常・境界ケースを列挙する
+- 観測手段（APIレスポンス、イベント、DB状態など）を明示する
+- 実装と無関係な用語で書き、内部構造への言及は避ける
+
+#### Don't（非推奨）
+- 「ファイルが存在する」「〇〇を返すクラスがある」など構造・命名のみを確認させる
+- 単一の肯定文で完結させて振る舞いの条件や観測結果を書かない
+- テストレベルを曖昧にし、誰がどの観点で検証するか不明瞭にする
+- 期待結果を「問題ないこと」「成功すること」で済ませる
+- 実装手段（特定フレームワーク、DBテーブル構造など）を強制する
+
+## テンプレート一覧
+
+### requirements.md.template
+
+要件定義書のテンプレートです。
+
+**重要なセクション**:
+- **受け入れ基準（Acceptance Criteria）**: QAエージェント（task-qa）がこのセクションを参照してテストシナリオを作成します
+- **AC番号体系**: AC1.1, AC1.2 のように、ストーリー番号.連番 で一意に識別
+- **検証レベル**: Unit/Integration/E2E を必ず指定
+- **検証者**: task-executer または task-qa を明記
+
+**使い方**:
+1. ストーリーごとに受け入れ基準を記載
+2. 各 AC に番号・検証レベル・検証者を付与
+3. Given/When/Then 形式で振る舞いを明確に記述
+
+**含まれるセクション**:
+- 概要
+- AS-IS/TO-BE
+- ビジネス価値
+- スコープ
+- 画面要件（該当する場合）
+- ユーザーストーリー
+  - **受け入れ基準（必須）**
+- 詳細なビジネス要件
+- 非機能要件
+- 技術的制約
+- 依存関係
+- リスクと対策
+- 成功指標
+
+### design.md.template
+
+設計書のテンプレートです。以下のセクションを含みます：
+
+- システムアーキテクチャ
+- データモデル
+- API仕様
+- フロントエンドコンポーネント構造
+- 技術選定
+- セキュリティ考慮事項
+- パフォーマンス考慮事項
+- テスト戦略
+- マイグレーション戦略（該当する場合）
+
+### design-simple.md.template
+
+設計書の簡易版テンプレートです。シンプルな機能向けに必須セクションのみを含みます。
+
+**用途**:
+- 小規模・中規模の機能追加
+- 既存アーキテクチャに準拠する機能
+- 複雑なパフォーマンス最適化が不要な機能
+
+**含まれるセクション**:
+- システムアーキテクチャ
+- データモデル
+- API仕様
+- セキュリティ考慮事項
+- テスト戦略
+
+**使い分けの基準**:
+- **design-simple.md.template を使用**: 既存パターンに従う標準的な CRUD 機能、シンプルなビジネスロジック
+- **design.md.template を使用**: 新しいアーキテクチャパターンの導入、複雑な状態管理、大規模なパフォーマンス最適化が必要な機能
+
+### qa-test.md.template
+
+QA テスト結果記録のテンプレートです。
+
+**用途**:
+- task-qa が Integration/E2E テストの結果を記録
+- テストシナリオと実施結果を構造化して管理
+
+**構造**:
+- 受け入れ条件（requirements.md から自動抽出）
+- テストシナリオ（Integration/E2E 別）
+- 実施結果とステータス
+- 失敗時の原因分類と推奨アクション
+
+**保存場所**: `docs/specs/tasks/[task-dir]/qa-tests/phaseN/X-Y.md`
+
+## 関連ドキュメント
+
+- [タスク管理ガイド](../docs/einja/steering/task-management.md)
+- [受け入れ基準とQAガイド](../docs/einja/steering/acceptance-criteria-and-qa-guide.md)
+
+## サポート
+
+テンプレートの使用方法や記載内容について不明な点がある場合は、既存の実装例を参照してください。

package/templates/design-simple.md.template

@@ -0,0 +1,172 @@
+# [機能名] 設計書（簡易版）
+
+<!-- このテンプレートはシンプルな機能の設計書作成時に使用してください -->
+<!-- 複雑な機能の場合は design.md.template を使用してください -->
+
+## システムアーキテクチャ
+
+### システム構成図
+
+```mermaid
+graph TD
+    A[コンポーネントA] --> B[コンポーネントB]
+    B --> C[コンポーネントC]
+```
+
+### データフロー
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant Server
+    participant Database
+
+    Client->>Server: リクエスト
+    Server->>Database: データ取得
+    Database->>Server: データ返却
+    Server->>Client: レスポンス
+```
+
+## データモデル
+
+### Prismaスキーマ
+
+```prisma
+// 主要なデータモデルを記載
+
+model User {
+  id        String   @id @default(cuid())
+  name      String
+  email     String   @unique
+  createdAt DateTime @default(now())
+  updatedAt DateTime @updatedAt
+}
+```
+
+### データモデル説明
+<!-- 各モデルの役割と主要フィールドの説明を記載 -->
+
+## API仕様
+
+### エンドポイント一覧
+
+| メソッド | エンドポイント | 説明 | 認証 |
+|---------|--------------|------|------|
+| POST | /api/resource | リソース作成 | 必要 |
+| GET | /api/resource/:id | リソース取得 | 必要 |
+| PUT | /api/resource/:id | リソース更新 | 必要 |
+| DELETE | /api/resource/:id | リソース削除 | 必要 |
+
+### API詳細
+
+#### POST /api/resource
+
+**リクエスト**:
+```typescript
+{
+  "field1": "value1",
+  "field2": "value2"
+}
+```
+
+**レスポンス（成功時）**:
+```typescript
+{
+  "success": true,
+  "data": {
+    "id": "resource_id",
+    "field1": "value1",
+    "field2": "value2",
+    "createdAt": "2024-01-01T00:00:00Z"
+  }
+}
+```
+
+**レスポンス（エラー時）**:
+```typescript
+{
+  "success": false,
+  "error": {
+    "code": "ERROR_CODE",
+    "message": "エラーメッセージ"
+  }
+}
+```
+
+### エラーハンドリング
+
+| HTTPステータス | エラーコード | 説明 | 対処方法 |
+|--------------|------------|------|---------|
+| 400 | INVALID_REQUEST | リクエストが不正 | リクエストパラメータを確認 |
+| 401 | UNAUTHORIZED | 認証エラー | 認証情報を確認 |
+| 403 | FORBIDDEN | アクセス権限なし | 権限を確認 |
+| 404 | NOT_FOUND | リソースが見つからない | リソースの存在を確認 |
+| 500 | INTERNAL_ERROR | サーバーエラー | サポートに連絡 |
+
+## セキュリティ考慮事項
+
+### 認証・認可
+
+**認証方式**: <!-- JWT / Session / その他 -->
+
+**認可モデル**: <!-- RBAC / ABAC / その他 -->
+
+**実装方針**:
+- 認証フロー: <!-- 認証フローを記載 -->
+- 権限チェック: <!-- 権限チェック方法を記載 -->
+
+### データ保護
+
+**暗号化**:
+- 通信: TLS 1.3
+- 保存データ: <!-- 必要に応じて暗号化方法を記載 -->
+- パスワード: bcrypt（コスト係数: 12）
+
+**入力検証**:
+- クライアントサイド: <!-- 検証方法を記載 -->
+- サーバーサイド: <!-- 検証方法を記載 -->
+
+### 脆弱性対策
+
+| 脆弱性 | 対策 |
+|--------|------|
+| XSS | エスケープ処理、Content Security Policy |
+| CSRF | トークン検証 |
+| SQLインジェクション | Prismaによるパラメータ化クエリ |
+| 機密情報漏洩 | 環境変数による管理 |
+
+## テスト戦略
+
+### テストレベル
+
+| レベル | 対象 | ツール | カバレッジ目標 |
+|--------|------|--------|--------------|
+| Unit | ロジック、ユーティリティ | Vitest | 80%以上 |
+| Integration | API、データベース | Vitest | 70%以上 |
+| E2E | ユーザーシナリオ | Playwright | クリティカルパス |
+
+### テストケース設計
+
+**単体テスト**:
+- 正常系
+- 異常系
+- 境界値
+
+**統合テスト**:
+- APIエンドポイント
+- データベース操作
+- 認証・認可
+
+**E2Eテスト**:
+- クリティカルパス（requirements.mdの受け入れ基準に基づく）
+- ユーザーシナリオ
+
+## 参考資料
+
+### 関連ドキュメント
+- 要件定義書: `requirements.md`
+- QAテスト: `qa-tests/`
+
+### 外部リソース
+- [参考ドキュメント1のタイトル](URL)
+- [参考ドキュメント2のタイトル](URL)