@ripla/godd-mcp 1.0.4-canary.8 → 1.0.4

package/templates/partials/ssot-rules.hbs

@@ -1,30 +0,0 @@
-## SSOT Update & Question Management Rules (MUST)
-
-### Handling Spec Changes
-- When the user communicates a new spec, **update the SSOT**
-- If the SSOT update contradicts other specs, **ask the user for clarification**
-
-### Question Management
-- When the user **does not clearly answer** a question (no answer / ambiguous answer), add the question to **`docs/003_requirements/questions.csv`** (path: `{{project.question_list_path}}`)
-- CSV columns: `id,category,question,context,answer,spec_file,status`
-- Status values:
-  - `unanswered` — not yet answered
-  - `answered` — user provided a clear answer
-  - `spec_reflected` — answer has been reflected in the spec document (hidden in Notes view)
-- When a question is answered: update `answer` column → reflect in spec → set status to `spec_reflected`
-- Create the file with header row if it does not exist
-
-### Implementation Decisions
-- When instructed to implement without answers to questions:
-  - **Apply the "common sense" approach**
-- When clear answers or specs are available:
-  - **Never guess** — implement exactly as specified
-
-### Question Template (Use This Format When Asking Questions)
-When you need to ask the user a question, structure it as follows:
-
-1. **Current understanding**: What you know so far
-2. **Unclear point**: What specifically is ambiguous
-3. **Options**: Available choices (if any)
-4. **Recommendation**: Your suggested approach and why
-5. **Additional info needed**: What would help you decide

package/templates/prompts/adr.hbs

@@ -1,39 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-daily }}
-
-## Purpose
-Create an ADR (Architecture Decision Record) that records design decisions in a form where readers can later reach the same conclusion.
-An ADR must explain the **why** so thoroughly that a future reader can independently evaluate whether the decision still holds.
-
-## Input
-- What to decide (Decision)
-- Background (Context)
-- Alternatives (Options)
-
-## Output
-Markdown ADR with the following sections:
-- **Title**: Short, descriptive name for the decision
-- **Status**: Proposed / Accepted / Deprecated / Superseded
-- **Context**: What is the issue? What forces are at play? What constraints exist?
-- **Decision**: What was decided and why
-- **Alternatives Considered**: For each alternative:
-  - Description
-  - Pros and cons
-  - Why it was not chosen
-- **Consequences**: What becomes easier or harder as a result of this decision
-- **Trade-offs**: What was sacrificed and what was gained (be explicit)
-- **Rollback Plan**: How to reverse this decision if it proves wrong
-- **Related Decisions**: Links to related ADRs or Spec documents
-
-Always include **trade-offs** and **rollback plan** — these are the most valuable parts of an ADR.

package/templates/prompts/agent-dev-workflow.hbs

@@ -1,34 +0,0 @@
-{{> ssot-header }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-## Purpose (Terminal-free operation)
-Enable developers to complete the full cycle — from environment setup to implementation, testing, commit, push, and PR creation — simply by requesting in natural language, without ever touching a terminal.
-
-## Absolute Rules (Important)
-- **Default branch protection**: Before making any code changes, check the current branch. If on the default branch (main/master), **always create a new feature branch first**
-  - Branch naming: `feat/<slug-or-task-summary>-<YYYYMMDD>` (e.g. `feat/add-auth-20260212`)
-  - Never commit directly to the default branch
-- When **UI implementation is involved**, always separate into **frontend** and **backend branches**
-  - `feat/<slug>-frontend-<YYYYMMDD>` / `feat/<slug>-backend-<YYYYMMDD>`
-- **1 commit = 1 responsibility** (mixed Front/Back commits are prohibited)
-- **End-of-work commits**: When development is complete, group changes into logical commit units (by concern: schema, backend, frontend, tests, config, docs) — do NOT make a single monolithic commit
-- Humans review **only via GitHub PR diffs**
-
-## Canonical References
-- Spec: `docs/003_requirements/spec/`
-{{#if frontend}}- Frontend quality gate: `{{frontend.build_command}}`
-{{/if}}{{#if backend}}- Backend quality gate: `{{quality_gate.backend}}`
-{{/if}}
-
-## How to proceed (Important)
-- **The developer's (human) entry point is the `dev` prompt** (with @references + purpose + completion criteria)
-- The procedures and commands in this prompt are **Agent-internal execution methods** (reference only); humans do not need to memorize or execute them

package/templates/prompts/analyze-report.hbs

@@ -1,36 +0,0 @@
-{{> ssot-header }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-daily }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-## Purpose
-Produce a consistent report at task completion, following the template structure.
-
-## Output
-Fill in the following headings concisely, leaving no blanks (keep code blocks minimal).
-
-### Change Summary
--
-
-### Impact Scope
-{{#if frontend}}- Frontend（`{{frontend.root_dir}}`）:
-{{/if}}{{#if backend}}- Backend（`{{backend.root_dir}}`）:
-{{/if}}- Other:
-
-### Verification Performed
-- Command/Result:
-
-### Compatibility / Migration
-- Breaking changes: Yes/No
-- Migration steps:
-- Rollback:
-
-### Remaining Risks / Open Items
--

package/templates/prompts/auto-documentation.hbs

@@ -1,37 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-daily }}
-
-## Purpose
-From the changes, comprehensively identify all documentation updates needed and draft the diffs.
-Documentation must stay in sync with implementation — stale docs are worse than no docs.
-
-## Input
-- Change details (target files / behavior diff)
-- Reason for change (purpose / completion criteria)
-
-## Document Types to Check
-Review whether each of these needs updating:
-- **Spec documents**: Feature specs, API specs, DB specs
-- **README files**: Project root and module-level READMEs
-- **Configuration docs**: Environment variables, setup instructions
-- **Tech stack docs**: Dependencies, versions, architecture decisions
-- **Operational docs**: Deployment, migration, rollback procedures
-- **SSOT documents**: Spec index, operational rules, question list
-- **ADR (Architecture Decision Records)**: If the change involves a design decision
-
-## Output
-1. **List of documents to update** (file paths, with priority)
-2. **Addition/modification points** for each document (bullet list with specific changes)
-3. **Broken-reference check** items (links / paths that may be invalidated by the change)
-4. **New documents needed** (if the change introduces a new feature/module with no documentation)

package/templates/prompts/check.hbs

@@ -1,52 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-## Purpose
-Check the "minimum quality gate" before submitting changes and identify any missing perspectives.
-This is the **last line of defense** — be thorough and systematic.
-
-## Checklist (Evaluate Every Item)
-
-- **Spec alignment**: Does the Spec need updates? If gaps exist, propose additions. If Spec is missing for the change, flag it.
-- **Impact scope**: Has the impact been analyzed? Are all affected modules identified?
-- **Test plan**: Is the test plan documented? Does it cover boundary values and error cases?
-- **Compatibility/Migration**: If breaking changes exist, is migration/rollback documented?
-- **Tests (highest priority)**: Continue improving until **API tests/E2E tests pass** within available test infrastructure
-  - If unable to run tests: document the **reason**, **alternative verification**, and **remaining risks**
-  - Test priority: unit → integration → e2e
-{{#if frontend}}
-- **Frontend (if changed)**: Run `{{frontend.build_command}}` — must pass
-{{/if}}
-{{#if backend}}
-- **Backend (if changed)**: Minimal backend verification (startup / main API endpoints respond)
-{{/if}}
-- **Security**: Ensure secrets are not exposed in logs, exceptions, or UI
-- **SSOT consistency**: Are all SSOT documents (Spec, operational rules) still consistent after this change?
-- **Commit hygiene**: 1 commit = 1 responsibility? No Front/Back mixed commits?
-
-## Output
-For each checklist item, report:
-- **Status**: PASS / FAIL / N/A
-- **Details**: What was checked, what was found
-- **Action needed**: If FAIL, what needs to be fixed
-
-{{#if frontend.mindset}}
-## Frontend Review Criteria
-{{{frontend.mindset}}}
-{{/if}}
-
-{{#if backend.mindset}}
-## Backend Review Criteria
-{{{backend.mindset}}}
-{{/if}}

package/templates/prompts/commit.hbs

@@ -1,96 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-## Purpose
-Split changes into **proper granularity (1 commit = 1 responsibility)** and commit them with **rule-compliant commit messages**. The Agent handles the full flow: propose → confirm → execute.
-
-## Auto-confirm Mode
-{{#if auto_confirm}}
-**auto_confirm is ENABLED** — Skip user approval for the commit plan. Execute immediately after creating the plan and report results afterward.
-{{else}}
-**auto_confirm is DISABLED (default)** — Wait for user approval before executing the commit plan.
-{{/if}}
-
-## Rules (1 commit = 1 responsibility)
-
-### Hard Scope (mixing these in a single commit is NG)
-- `frontend`: `frontend/**`
-- `backend`: `backend/**`
-- `repo-root`: Everything else
-
-### Soft Scope (can be included in the same commit)
-- `docs`: `docs/**`
-- `scripts`: `scripts/**`
-
-Example: `frontend + docs` is OK, `frontend + backend` is NG.
-
-### Commit Message Rules
-- **Subject (line 1)**: Max 50 characters, start with lowercase English verb
-  - Prefixes: `add` / `update` / `fix` / `refactor` / `remove` / `docs` / `chore` / `test`
-  - Example: `add user authentication endpoint`
-  - Example: `fix validation error on login form`
-- **Blank line**
-- **Body**: May be in the project's working language. Include:
-  - **Why**: Why this change is needed (1-2 lines)
-  - **What**: What was changed (bullet list)
-  - **Impact**: Scope of impact (required for breaking changes)
-
-## Agent Steps (MUST)
-
-### Step 1: Review All Changes
-1. Run `git status` to list changed files (staged / unstaged / untracked)
-2. Run `git diff` for unstaged diffs
-3. Run `git diff --cached` for staged diffs
-   - **If no changes**: Report "No changes to commit" and exit
-
-### Step 2: Create Commit Plan by Responsibility
-1. Classify changed files by **hard scope**:
-   - `frontend/**` → frontend group
-   - `backend/**` → backend group
-   - Other → repo-root group
-2. Within each group, further split by **logical responsibility**:
-   - Same feature/purpose → group into one commit
-   - Different features → separate commits
-   - `docs` / `scripts` may be included with their related hard scope commit
-3. Create a **commit plan** (what goes into which commit, in what order)
-
-### Step 3: Present Plan and Confirm
-1. Present the commit plan to the user:
-   ```
-   Commit Plan:
-   1. [scope] <proposed commit message>
-      - Files: file1, file2, ...
-   2. [scope] <proposed commit message>
-      - Files: file3, file4, ...
-   ```
-{{#if auto_confirm}}
-2. **Auto-confirm enabled**: Skip approval and proceed directly to Step 4
-{{else}}
-2. Wait for user approval
-   - If modifications are requested, revise and re-present
-{{/if}}
-
-### Step 4: Execute Commits
-1. For each commit in the plan:
-   - `git add <target files>` to stage
-   - `git diff --cached --stat` to verify staged content
-   - `git commit -m "<commit message>"` to commit
-2. After each commit, verify with `git log --oneline -1`
-3. After all commits, show `git log --oneline -<commit count>`
-
-## Output
-- **Commit plan**: Responsibility split and message proposals (for user confirmation)
-- **Execution result**: Each commit hash and message
-- **Final state**: `git status` summary (any remaining uncommitted changes)
-- **Warnings** (if applicable): Hard scope mixing detected, oversized commits

package/templates/prompts/dev.hbs

@@ -1,127 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-## Purpose
-This is the **canonical development entry prompt** that enables an Agent to automatically complete the following when a developer (human) simply **makes a request in natural language**.
-
-- Environment/prerequisite check (preflight)
-- Post-change quality gate (quality-gate)
-- PR body generation (template-compliant, fact-based)
-
-## Input
-- **Request (what you want to do)**
-- **Completion criteria (measurable)**
-
-### Optional (fill in what you can)
-- slug (ticket/short identifier)
-- Constraints
-- Integration test (DB): `yes` | `no` | `unknown`
-- Post-integration DB cleanup: `down-volumes` | `down` | `none`
-
-## Output
-- **Execution log**: preflight/quality-gate results (pass/fail, log file path)
-- **Change summary**: What, why, where
-- **Test results**: Commands executed and results
-- **PR body (final)**: Markdown with all template fields filled
-- **PR creation metadata**: base/head/title/body (for GitHub MCP PR creation)
-
-## Rules (SSOT)
-- Spec is the SSOT for specifications. If ambiguous, ask questions first to clarify
-{{#if backend}}- Backend dependency direction: {{backend.dependency_direction}}{{/if}}
-- Front separates UI and side effects (into hooks/services)
-{{#if frontend}}- At minimum for frontend changes, run `{{frontend.build_command}}`{{/if}}
-- Do not edit CI/CD configurations
-- **Tests run inside Docker containers** — use `docker compose --profile test run --rm <service>-test` for each project. Never run tests directly on the host
-
-## Branch Management (Mandatory — execute BEFORE any code changes)
-1. Run `git branch --show-current` to check the current branch
-2. Run `git remote show origin | grep 'HEAD branch'` (or equivalent) to identify the default branch (e.g. `main`, `master`)
-3. **If the current branch IS the default branch**:
-   - Create a new feature branch and switch to it **before making any changes**
-   - Branch naming convention: `feat/<slug-or-task-summary>-<YYYYMMDD>`
-     - If `slug` is provided → use it (e.g. `feat/add-auth-20260212`)
-     - If no slug → derive a short kebab-case summary from the task description (max 5 words, e.g. `feat/fix-login-validation-20260212`)
-   - Date is the current date in `YYYYMMDD` format
-   - Command: `git checkout -b feat/<branch-name>`
-   - Inform the developer that a new branch was created and why
-4. **If already on a feature branch** → continue on the current branch (no action needed)
-
-## Agent Workflow (Required — Follow This Exact Sequence)
-
-### Phase 0: Branch Check
-Execute "Branch Management" above — always first, before any code changes.
-
-### Phase 1: Pre-work Analysis (MUST — Do Not Skip)
-Before writing any code, analyze and present to the user:
-
-1. **Goal & completion criteria** — Restate the request in measurable terms
-2. **Existing structure & constraints** — Review relevant code, patterns, and dependencies
-3. **Impact scope & risks** — Which modules/layers are affected? What could break?
-4. **Implementation approach** — Choose and justify your approach (standard / conservative / bold)
-5. **Open questions** — If anything is unclear, ask NOW (do not proceed with assumptions)
-
-If open questions exist, **stop and present them to the user** using the Question Template before continuing.
-
-### Phase 2: Spec & Test Design (ATDD — MUST for new features)
-1. Verify/supplement Spec (create/update if needed)
-2. **Define acceptance criteria** in Given-When-Then format for the requested change
-3. **Write acceptance tests FIRST** (Red phase — tests should fail because the feature doesn't exist yet)
-   - For bug fixes: write a reproduction test first
-   - For refactoring: ensure existing tests cover the area, or add characterization tests first
-
-### Phase 3: Implementation
-1. Impact analysis → Split Front/Back branches/PRs if necessary
-2. Run preflight (opt-in DB→API→migration→integration if needed, cleanup policy per SSOT)
-3. Implement (Self-documenting code, minimal Why comments)
-   - Implement failure paths first, then happy path
-   - Apply early returns to keep nesting shallow
-   - 1 commit = 1 responsibility — keep changes focused
-4. **Make acceptance tests pass** (Green phase)
-5. Refactor if needed — tests remain as regression suite
-
-### Phase 4: Quality Assurance
-1. Run quality-gate
-{{#if quality_gate}}{{#if quality_gate.frontend}}   - Frontend: `{{quality_gate.frontend}}`
-{{/if}}{{#if quality_gate.backend}}   - Backend: `{{quality_gate.backend}}`
-{{/if}}{{/if}}
-2. **Continue fixing until all tests pass** — do not give up
-3. If tests cannot run: document reason, alternative verification, and remaining risks
-
-### Phase 5: Commit & PR
-1. Follow "End-of-Work Commit Strategy" below
-2. Generate PR body (fully template-compliant, fact-based)
-3. Prepare PR creation metadata for GitHub MCP
-
-## End-of-Work Commit Strategy (Mandatory — execute AFTER implementation is complete)
-When all implementation and quality-gate checks are done:
-1. Run `git status` and `git diff` to review all changes
-2. **Group changes into logical commit units** (1 commit = 1 responsibility):
-   - Separate by concern: schema/migration, backend logic, frontend UI, tests, config, docs
-   - Each commit should be independently reviewable and revertable
-   - Do NOT create a single monolithic commit for all changes
-3. For each logical unit:
-   - Stage only the relevant files: `git add <specific-files>`
-   - Write a clear commit message (short first line, body with reason/impact/verification)
-4. Verify with `git log --oneline -n <N>` that the commit history is clean and readable
-5. Inform the developer of the commits created and their scope
-
-{{#if frontend.mindset}}
-## Frontend Mindset
-{{{frontend.mindset}}}
-{{/if}}
-
-{{#if backend.mindset}}
-## Backend Mindset
-{{{backend.mindset}}}
-{{/if}}

package/templates/prompts/docs-init.hbs

@@ -1,101 +0,0 @@
-{{> ssot-header }}
-{{> godd-core }}
-{{> ssot-rules }}
-{{> project-context }}
-
-## Purpose
-
-プロジェクトに `docs/` フォルダ構造をテンプレートから生成する。  
-GoDD Notes（テキストノート / テーブルノート / drawio）で閲覧・編集可能なドキュメント初期構造を作成する。
-
-## docs/ フォルダ構成（テンプレート）
-
-以下の構造を生成すること:
-
-```
-docs/
-├── README.md                              # docs 全体の入口・構成説明
-├── 001_project/
-│   ├── README.md                          # プロジェクト概要（背景・目的・プロダクト・システム構成・用語）
-│   ├── pages.csv                          # 各プロダクトの画面一覧（テーブルノート）と各画面の概要
-│   ├── features.csv                       # 画面ごとの機能一覧（テーブルノート）と各機能の概要
-│   └── tasks.csv                          # 開発チームからの質問リストと要件定義チームからの要望一覧
-├── 002_business_flow/
-│   ├── README.md                          # ビジネスフロー概要、フォルダ内で整理するビジネスフロー一覧
-│   ├── business_flow_name.template.md     # 特定業務のビジネスフローを解説
-│   └── business_flow_name.template.drawio # 特定業務のビジネスフローを図示
-├── 003_requirements/
-│   ├── README.md                          # フォルダの説明、フォルダ内で整理するrequirements一覧
-│   ├── requirements.template.md           # 概要、背景、ユーザーストーリー、画面要件、機能要件、機能詳細、非機能要件、備考
-│   ├── <Product Name>/                    # 管理画面、ユーザー向け画面などプロダクトごとにフォルダ作成
-│   │   └── <feature_name>.md              # 機能別の要件定義
-│   └── spec/                              # 仕様 SSOT（API仕様、インフラ仕様、言語仕様等）
-├── 004_pages/                             # 画面設計
-│   ├── README.md                          # フォルダの説明
-│   └── app/                               # 画面のURLパスを整理するため、Reactの app/ ディレクトリを配置
-│       ├── admin/
-│       │   └── corporations/
-│       │       └── requirements.md        # 画面ごとの画面要件を記載
-│       └── users/
-├── 005_architecture/                      # 開発をするにあたっての実際の設計（インフラ、DB、API、各機能の設計）
-│   ├── README.md                          # フォルダの説明
-│   ├── stacks/                            # 技術スタック
-│   ├── api/                               # APIのSwaggerなど
-│   ├── db/                                # DB設計（ER図など）
-│   ├── infra/                             # インフラアーキテクチャの設計
-│   └── features/                          # 各機能の設計
-│       └── feature.template.md            # 機能設計書、データフロー、DB設計などを記載
-├── 006_development_workflow/              # 開発のルールやワークフローなどについて
-│   ├── README.md                          # フォルダの説明
-│   ├── git.md                             # Gitルール
-│   └── workflow.md                        # 開発ワークフロー
-└── 007_guides/                            # ガイド集
-    ├── README.md                          # フォルダの説明
-    ├── godd_notes_getting_started.md      # GoDD Notes 使い始め方（初期セットアップ/ログイン/編集/Issue・PR作成）
-    ├── godd_notes_usage.md                # GoDD Notesの利用方法（編集操作リファレンス）
-    ├── release-procedure.md               # canary 自動リリース・production 手動リリースの手順
-    ├── ci-cd-guide.md                     # CI/CDパイプライン全体像・主要ワークフロー・手動実行・失敗確認
-    ├── godd_usage.md                      # GoDD のコマンド一覧、ツール一覧、利用方法
-    ├── setup_godd.md                      # GoDD の始め方
-    ├── setup_godd_notes.md                # GoDD Notesの構築方法（ローカル構築〜デプロイ）
-    ├── setup_infra.md                     # インフラのCI/CDの構築ガイド
-    └── setup_local_environment.md         # ローカル環境構築ガイド
-```
-
-## ルール
-
-1. プロジェクトスキャン結果と入力パラメータ（プロジェクト名、ロール、画面ID）を使って各ファイルの内容を生成
-2. CSV ファイルはヘッダー行 + サンプル行を含める
-3. README.md は Mermaid ダイアグラムを含める（適切な場合）
-4. 既に `docs/` が存在する場合は既存構造を尊重し、不足分のみ追加
-5. 各ファイルの先頭にファイルの目的を1行コメントで記載
-6. `007_guides/godd_notes_getting_started.md` は「初期セットアップ・ログイン・ファイル編集・Issue/PR 作成」の 4 ステップをカバーし、GoDD Notes を初めて使うユーザーが迷わず操作できる導線を提供する
-7. `007_guides/release-procedure.md` は「canary 自動リリース（main マージ時）」と「production 手動リリース（Actions 手動実行）」の両フローを説明し、必要な Secrets・確認コマンド・トラブルシューティングを含める
-8. `007_guides/ci-cd-guide.md` は「CI/CD 全体像・主要ワークフロー一覧・手動実行手順・失敗時の確認ポイント」を含め、PR から本番デプロイまでのフローを一覧できる
-
-## CSV ヘッダー定義
-
-### tasks.csv
-```
-id,type,product,category,subject,detail,created_by,created_at,priority,deadline,status,issue,remarks
-```
-
-### features.csv
-```
-機能ID,機能名,概要,phase,優先度,ステータス
-```
-
-### pages.csv
-```
-画面ID,画面名,概要,提供フェーズ,関連機能ID,ステータス
-```
-
-### tables.csv
-```
-テーブル名,カラム名,型,制約,説明
-```
-
-## 出力
-
-- 生成した全ファイルのパスと内容
-- 生成理由の簡潔な説明

package/templates/prompts/docs-update.hbs

@@ -1,51 +0,0 @@
-{{> ssot-header }}
-{{> godd-core }}
-{{> ssot-rules }}
-{{> project-context }}
-
-## Purpose
-
-コード変更後に `docs/` 内の関連ドキュメント（MD/CSV）を同期・更新する。  
-変更内容から影響するドキュメントを特定し、更新差分を提案する。
-
-## 対象ドキュメント構造
-
-```
-docs/
-├── 001_project/     # プロジェクト概要、機能要件、画面要件
-├── 002_business_flow/ # ビジネスフロー
-├── 003_requirements/  # 要件定義
-├── 004_pages/        # 画面設計
-├── 005_architecture/ # 詳細設計（インフラ/DB/API/機能別）
-├── 006_development_workflow/ # 開発ルール・ワークフロー
-└── 007_guides/       # 利用・構築・運用ガイド
-```
-
-## ルール
-
-1. 変更内容を分析し、影響を受ける docs/ セクション（001-007）を特定する
-2. 各セクションの既存ドキュメントを確認し、更新が必要な箇所を特定する
-3. MD ファイルの更新差分を提案する（追記/修正ポイントを明確に）
-4. CSV ファイルに行の追加/更新が必要な場合は具体的な行内容を提示する
-5. Mermaid ダイアグラムが古くなっている場合は更新版を提案する
-6. **既存の内容を壊さない**ように差分のみ提案する
-
-## 影響マッピング
-
-| コード変更種別 | 影響するセクション |
-|---|---|
-| 新機能追加 | 001 (features.csv), 003 (requirements), 006 (features/) |
-| API 変更 | 005 (api/), 003 (requirements) |
-| DB スキーマ変更 | 005 (db/) |
-| 画面追加/変更 | 001 (pages.csv), 004 (app/) |
-| インフラ変更 | 005 (infra/) |
-| アーキテクチャ変更 | 005 (architecture.md) |
-| 開発フロー変更 | 006 (workflow.md, git.md) |
-| ビジネスフロー変更 | 002 (business_flow/) |
-
-## 出力
-
-1. 影響を受けるドキュメント一覧（ファイルパス）
-2. 各ドキュメントの追記/修正ポイント（箇条書き）
-3. 具体的な更新内容（差分形式）
-4. 参照切れチェック結果