@ripla/godd-mcp 0.1.2-beta-20260312091403

package/templates/prompts/notes-deploy.hbs

@@ -0,0 +1,72 @@
+{{> ssot-header }}
+{{> godd-core }}
+{{> project-context }}
+
+## Purpose
+
+ripla Notes（notes-app / notes-api）のデプロイ手順を案内する。
+デプロイ先に応じた具体的なセットアップ手順を提供する。
+
+## アーキテクチャ
+
+```
+notes-app (React + Vite)  ──proxy──▶  notes-api (FastAPI)  ──▶  GitHub API
+     :5175                                :8000
+```
+
+## 必要な環境変数（notes-api）
+
+```bash
+GITHUB_TOKEN=ghp_xxx           # GitHub API トークン（必須）
+GITHUB_OWNER=owner             # リポジトリオーナー
+GITHUB_REPO=repo               # リポジトリ名
+GITHUB_BRANCH=main             # ベースブランチ
+DOCS_PATH=docs                 # docs フォルダパス
+```
+
+## デプロイ方法
+
+### 1. Docker Compose（推奨）
+
+Docker Compose ファイルを生成し、`docker compose up -d` で起動する手順を案内する。
+
+### 2. クラウドデプロイ
+
+- notes-app: Vercel / Cloudflare Pages にデプロイ（Vite ビルド）
+- notes-api: Railway / Render にデプロイ（FastAPI + uvicorn）
+- 環境変数の設定手順を含める
+
+### 3. 手動セットアップ
+
+```bash
+# notes-api（FastAPI）
+cd notes-api
+uv sync
+uv run uvicorn main:app --reload --port 8000
+
+# notes-app（React + Vite）
+cd notes-app
+pnpm install
+pnpm dev  # or pnpm build && pnpm preview
+```
+
+## テスト実行（Docker 完全環境）
+
+```bash
+docker compose run --rm --profile test notes-api-test
+docker compose run --rm --profile test notes-app-test
+```
+
+## ルール
+
+1. デプロイ先に応じた具体的な手順を提示する
+2. 環境変数の設定を漏れなく案内する
+3. HTTPS / CORS の設定を含める
+4. GitHub Token のスコープ要件を明記する（`repo` or `contents:read`）
+5. ヘルスチェック確認手順を含める
+
+## 出力
+
+- デプロイ手順（ステップバイステップ）
+- 必要な設定ファイル（Docker Compose / クラウド設定等）
+- 確認手順

package/templates/prompts/pr-analyze.hbs

@@ -0,0 +1,44 @@
+{{> ssot-header }}
+
+{{> godd-core }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-dev }}
+
+## Purpose
+Read the PR diff and organize **review perspectives / risks / additional information needed** (analysis).
+
+> **Scope clarification**: This tool focuses on **analysis** — organizing the information a reviewer needs.
+> PR body **generation** is handled by the dev workflow. This tool prepares the analytical foundation.
+
+## Input
+- Background / purpose of the change
+- Change details (per file / feature)
+- Blast radius ({{#each stacks}}{{this.label}}{{#unless @last}} / {{/unless}}{{/each}})
+- Compatibility / migration requirements
+- Verification (commands / manual steps)
+
+## Analysis Perspectives
+Evaluate each change through these lenses:
+1. **Correctness**: Does the implementation match the spec/intent?
+2. **Design**: Proper separation of concerns, dependency direction, SOLID
+3. **Security**: Secret exposure, injection vectors, access control
+4. **Performance**: N+1 queries, unnecessary full scans, missing indexes
+5. **Operations**: Logging, error handling, migration safety, rollback path
+6. **Test coverage**: Are changes adequately tested? Missing edge cases?
+7. **Commit quality**: 1 commit = 1 responsibility? Clean history?
+
+## Output
+Return Markdown with the following structure:
+- **Change summary**: What changed and why (1-3 sentences)
+- **Risk assessment**: HIGH / MEDIUM / LOW for each area
+- **Review focus areas**: Where reviewers should pay most attention
+- **Questions to confirm**: Information gaps that need answers before merge
+- **Suggested improvements**: Optional enhancements (not blockers)

package/templates/prompts/pr-create.hbs

@@ -0,0 +1,125 @@
+{{> ssot-header }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-dev }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+## Purpose
+Create a **Pull Request** on GitHub with a well-structured body following the PR template (`documents/templates/pr-template.md`). The Agent analyzes changes, generates PR content, and creates the PR.
+
+## Auto-confirm Mode
+{{#if auto_confirm}}
+**auto_confirm is ENABLED** — Skip user review of the PR body. Create the PR immediately after generating content and report the URL afterward.
+{{else}}
+**auto_confirm is DISABLED (default)** — Present the generated PR body to the user for review before creating the PR.
+{{/if}}
+
+## Draft Mode
+{{#if draft}}
+**draft is ENABLED** — Create the PR as a Draft PR.
+{{else}}
+**draft is DISABLED (default)** — Create the PR as a regular (ready for review) PR.
+{{/if}}
+
+## PR Template (SSOT: `documents/templates/pr-template.md`)
+The PR body MUST follow this structure:
+
+### TL;DR (3-7 lines)
+- What / Why / How verified / Remaining risks (brief summary)
+
+### Background / Purpose (Why)
+- Reason for this change, prerequisites, issues, expected outcomes
+
+### Changes (What)
+- Bullet list at review-friendly granularity
+
+### Impact Scope (Where)
+- Front / Back / Agent / Infra / Docs-Scripts (list affected areas)
+
+### Compatibility / Migration (Breaking?)
+- Breaking changes: Yes / No
+- Migration steps (if applicable)
+- Rollback steps (if applicable)
+
+### Verification (How verified)
+- Commands executed (e.g., `pnpm quality-gate`)
+- Manual checks (if applicable)
+
+### Remaining Risks / Open Items (required)
+- E.g., "integration tests not run without DB environment"
+
+### Notes
+- Monitoring / operational / constraint / background links
+
+## Agent Steps (MUST)
+
+### Step 1: Gather Information
+1. Run `git branch --show-current` to get current branch name
+2. Determine base branch:
+   - Use user-specified base branch if provided
+   - Default: `main`
+3. Run `git log origin/<base>..HEAD --oneline` to list commits in the PR
+   - **If no commits**: Report "No commits to create PR for" and exit
+4. Run `git diff origin/<base>...HEAD --stat` to get change summary
+5. Run `git diff origin/<base>...HEAD` to analyze detailed changes
+6. Check if the branch has been pushed to remote:
+   - Run `git ls-remote --heads origin <current-branch>`
+   - **If not pushed**: Report "Branch not pushed to remote. Run `godd_push_execute` first." and exit
+
+### Step 2: Generate PR Content
+1. Analyze the commits and diffs from Step 1
+2. Generate a **PR title**:
+   - Use user-provided title if available
+   - Otherwise, derive from branch name and change summary
+   - Format: Concise description of the change (max 72 characters)
+3. Generate **PR body** following the template structure above:
+   - Fill in ALL sections based on actual changes (do NOT leave placeholders)
+   - **TL;DR**: Summarize key changes in 3-7 bullet points
+   - **Background**: Derive from commit messages and context
+   - **Changes**: List all changes at appropriate granularity
+   - **Impact Scope**: Map changed files to areas (Front/Back/Agent/Infra/Docs)
+   - **Compatibility**: Check for breaking changes in API/schema/config
+   - **Verification**: List quality gate results and manual verification done
+   - **Remaining Risks**: Honestly assess what hasn't been verified
+
+### Step 3: Present and Confirm
+1. Present the generated PR title and body:
+   ```
+   PR Title: <generated title>
+   Base: <base branch> ← Head: <current branch>
+   
+   --- PR Body ---
+   <generated body>
+   ```
+{{#if auto_confirm}}
+2. **Auto-confirm enabled**: Skip review and proceed directly to Step 4
+{{else}}
+2. Wait for user review and approval
+   - If modifications are requested, revise and re-present
+{{/if}}
+
+### Step 4: Create PR
+1. Create the PR using `gh` CLI:
+   ```
+   gh pr create --title "<title>" --base <base_branch> --head <current_branch> --body "<body>"{{#if draft}} --draft{{/if}}
+   ```
+   - If `gh` is not available, provide the PR creation command and body for manual creation
+2. Capture and report the PR URL
+
+### Step 5: Post-creation
+1. Report the PR URL
+2. Run `gh pr view --json url,number,title,state` to verify creation
+3. Suggest next steps (e.g., request reviewers, add labels)
+
+## Output
+- **PR title**: Generated or user-provided
+- **PR body**: Complete PR template content
+- **PR URL**: Link to the created PR
+- **PR metadata**: Number, state, base/head branches
+- **Warnings** (if applicable): Missing verification, large diff, etc.

package/templates/prompts/push-execute.hbs

@@ -0,0 +1,83 @@
+{{> ssot-header }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-dev }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+## Purpose
+Execute **pre-submission checks** and then **push to remote** (`git push`). The Agent runs the full check-then-push flow.
+
+## Auto-confirm Mode
+{{#if auto_confirm}}
+**auto_confirm is ENABLED** — Skip user confirmation after pre-submission checks pass. Push immediately and report results afterward.
+{{else}}
+**auto_confirm is DISABLED (default)** — After pre-submission checks pass, present results to the user and wait for confirmation before pushing.
+{{/if}}
+
+## Agent Steps (MUST)
+
+### Step 1: Pre-flight Verification
+1. Run `git status` to verify:
+   - Current branch is NOT the default branch (main/master) — **abort if on default branch**
+   - There are commits to push (compare with remote tracking branch)
+   - No uncommitted changes remain (warn if any exist)
+2. Run `git log origin/<current-branch>..HEAD --oneline` to list unpushed commits
+   - If remote branch does not exist yet, run `git log --oneline -10` instead
+   - **If no unpushed commits**: Report "No commits to push" and exit
+
+### Step 2: Pre-submission Checks (Quality Gate)
+1. **Spec reflection**: Check if `documents/spec/` needs updates for the changes
+2. **Quality gate**: Run the project's quality gate commands:
+   - If available: `pnpm quality-gate` (or equivalent from project config)
+   - Fallback: lint + typecheck + test for changed areas
+3. **Secret check**: Scan staged/committed content for potential secrets:
+   - API keys, tokens, passwords in code or config
+   - `.env` files that should not be committed
+   - Private keys or certificates
+4. **Breaking changes**: If breaking changes exist, verify migration/rollback docs are present
+
+### Step 3: Report and Confirm
+1. Present check results:
+   ```
+   Pre-submission Check Results:
+   ✅ Quality gate: Passed
+   ✅ Spec reflection: No updates needed (or: Updated documents/spec/xxx.md)
+   ✅ Secret check: No secrets detected
+   ✅ Breaking changes: None (or: Migration documented)
+   
+   Commits to push (N):
+   - abc1234 add user authentication endpoint
+   - def5678 update login form validation
+   ```
+{{#if auto_confirm}}
+2. **Auto-confirm enabled**: Skip confirmation and proceed directly to Step 4
+{{else}}
+2. Wait for user confirmation
+   - If issues are found, fix them first and re-run checks
+{{/if}}
+
+### Step 4: Execute Push
+1. Determine push command:
+   - If remote tracking branch exists: `git push`
+   - If no remote tracking branch: `git push -u origin HEAD`
+2. Execute the push command
+3. Verify push result:
+   - Run `git status` to confirm "Your branch is up to date with 'origin/...'"
+   - Run `git log origin/<branch>..HEAD --oneline` to confirm no unpushed commits remain
+
+### Step 5: Handle Failures
+- **Push rejected (non-fast-forward)**: Report the error and suggest `git pull --rebase` or `godd_sync`
+- **Authentication failure**: Report and suggest checking credentials
+- **Network error**: Report and suggest retry
+
+## Output
+- **Check results**: Each check item with pass/fail status
+- **Commits pushed**: List of commit hashes and messages
+- **Push result**: Success (remote URL + branch) or failure reason
+- **Post-push state**: `git status` summary

package/templates/prompts/push.hbs

@@ -0,0 +1,24 @@
+{{> ssot-header }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-dev }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+## Purpose
+Organize everything that needs to be done before push/submission — ensuring nothing is missed (**Agent executes by default**).
+
+## Output (Checklist)
+- Local verification (required commands/results)
+- Spec (`documents/spec`) reflection status
+- Template (impact analysis/test plan/PR body) creation status
+- Documentation of breaking changes/migration/rollback
+- Secret information leakage check (logs/config/screenshots/etc.)
+
+## Notes
+- UI implementation requires `-frontend` / `-backend` branch separation

package/templates/prompts/release-notes.hbs

@@ -0,0 +1,38 @@
+{{> ssot-header }}
+
+{{> godd-core }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-daily }}
+
+## Purpose
+Create release notes that clearly communicate changes, migrations, and known issues.
+The audience is end users and operators — write for clarity and actionability.
+
+## Input
+- Changes (additions / modifications / fixes)
+- Compatibility / migration requirements
+- Known issues
+
+## Output
+Markdown release notes with the following sections:
+- **Version**: Version number and release date
+- **Highlights**: 1-3 sentence summary of the most important changes
+- **Added**: New features and capabilities
+- **Changed**: Modifications to existing behavior (include migration steps if needed)
+- **Fixed**: Bug fixes with brief description of the issue and resolution
+- **Deprecated**: Features scheduled for removal (include timeline and alternatives)
+- **Removed**: Features that were removed in this release
+- **Security**: Security-related changes (CVEs, vulnerability fixes)
+- **Breaking Changes**: Changes that require user action (migration guide must be included)
+- **Known Issues**: Outstanding problems with workarounds if available
+- **Migration Guide**: Step-by-step instructions for upgrading (if applicable)
+
+Fill every applicable section. Mark empty sections as "None in this release."

package/templates/prompts/requirements-to-business-flow.hbs

@@ -0,0 +1,29 @@
+{{> ssot-header }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-daily }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+## Purpose
+Transform requirements (natural language) into business flows (As-Is / To-Be) and use cases.
+
+## Output
+
+### As-Is (Current Flow)
+-
+
+### To-Be (Target Flow)
+-
+
+### Use Case List
+- Purpose/Trigger/Main success scenario/Alternative scenario/Exceptions
+
+### Spec Mapping
+- List the required Spec templates (UI/API/DB/Feature/Usecase/Error Codes) and recommend which to create
+- Specs are placed under `documents/spec/`

package/templates/prompts/requirements-to-tickets.hbs

@@ -0,0 +1,26 @@
+{{> ssot-header }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-daily }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+## Purpose
+Break down requirements into implementation tasks (tickets).
+
+## Output
+- Ticket list (1 line = 1 ticket)
+  - Title
+  - Purpose (Done criteria)
+  - Impact scope ({{#if frontend}}Front/{{/if}}{{#if backend}}Back/{{/if}}Agent/Infra)
+  - Dependencies (Specs/tasks required first)
+  - Verification method (minimal)
+
+## Rules
+- If Specs are not yet created/finalized, add a "Create Spec" ticket as the highest priority
+- If there are breaking changes, always include a "Migration/Rollback" ticket

package/templates/prompts/review.hbs

@@ -0,0 +1,126 @@
+{{> ssot-header }}
+
+{{> godd-core }}
+
+{{> ssot-rules }}
+
+{{> project-context }}
+
+{{> cogito-grammar }}
+{{> cogito-root-core }}
+{{> cogito-particle }}
+{{> cogito-godd }}
+{{> cogito-root-dev }}
+
+## Purpose
+Perform a **CTO-level code review** that goes beyond syntax and style. Evaluate changes from strategic, architectural, and business-impact perspectives while maintaining rigorous technical standards.
+
+## Review Perspective (CTO Level)
+
+You review as a CTO who:
+- Thinks about **long-term maintainability** and **team scalability**
+- Evaluates **architectural alignment** with the project's overall direction
+- Considers **business impact** and **operational risk**
+- Prioritizes **security** and **data integrity** as non-negotiable
+- Balances **pragmatism** with **engineering excellence**
+
+## Review Criteria
+
+### 1. Architecture & Design
+- Separation of concerns, dependency direction{{#if backend}} ({{backend.dependency_direction}}){{/if}}, SOLID principles
+- **Architectural consistency**: Does this change align with existing patterns or introduce divergence?
+- **Scalability**: Will this approach hold up as the codebase and team grow?
+- **Technical debt**: Does this add, reduce, or leave tech debt neutral?
+- **Abstraction quality**: Right level of abstraction? Over-engineering or under-engineering?
+
+### 2. Type Safety & Code Quality
+- No `any`, treat external input as `unknown`, proper validation at boundaries
+- **Readability**: Can a new team member understand this without extensive context?
+- **Complexity**: Cyclomatic complexity, nesting depth, function length
+- **Naming**: Domain-accurate naming that communicates intent
+
+### 3. Testing & Reliability
+- Sufficient test coverage for changes, boundary values & error cases covered
+- New features: Are acceptance tests present (ATDD)?
+- Bug fixes: Is there a reproduction test?
+- **Determinism**: Are tests independent and repeatable?
+- **Test architecture**: AAA pattern, no test-to-test dependencies
+
+### 4. Error Handling & Resilience
+- Failure paths handled first? Early returns for clean flow?
+- **Graceful degradation**: How does the system behave under partial failure?
+- **Error messages**: Actionable, specific, no secret leakage
+
+### 5. Security
+- Secret leaks, SQL injection, XSS, improper access control
+- **Data exposure**: PII/sensitive data in logs, responses, or error messages?
+- **Authentication/Authorization**: Proper boundary enforcement?
+- **Dependency risk**: Known vulnerabilities in added dependencies?
+
+### 6. Performance & Operations
+- **N+1 queries**, unnecessary full-table scans, missing indexes
+- **Resource management**: Memory leaks, connection pool exhaustion, file handle leaks
+- **Observability**: Adequate logging, metrics, health checks
+- **Migration/Rollback**: Is the change reversible? Data migration plan?
+
+### 7. Business Impact
+- **User experience**: Does this change affect UX positively/negatively?
+- **Backward compatibility**: API contract changes? Client impact?
+- **Feature completeness**: Edge cases handled? Accessibility considered?
+
+### 8. Commit & PR Hygiene
+- 1 commit = 1 responsibility? No Front/Back mixed commits?
+- **PR scope**: Is the PR focused or doing too many things?
+
+## Output Format
+
+### Severity Classification
+
+Use these severity levels for each finding:
+
+- **CRITICAL**: Must fix before merge. Security vulnerability, data loss risk, or production-breaking bug.
+- **MAJOR**: Should fix before merge. Architectural issue, significant performance concern, or missing test coverage.
+- **MINOR**: Nice to fix. Code quality improvement, naming suggestion, or style consistency.
+- **SUGGESTION**: Optional improvement. Alternative approach, future optimization, or pattern recommendation.
+
+### Output Structure
+
+```
+## Summary
+Overall assessment (2-3 lines). Risk level: LOW / MEDIUM / HIGH / CRITICAL.
+
+## Findings
+
+### CRITICAL
+- [Finding]: Description + suggested fix + rationale
+
+### MAJOR
+- [Finding]: Description + suggested fix + rationale
+
+### MINOR
+- [Finding]: Description + suggested fix
+
+### SUGGESTION
+- [Finding]: Description + alternative approach
+
+## Positive Points
+- What was done well (encourage good practices)
+
+## Architecture Notes
+- Impact on overall system architecture
+- Technical debt assessment (+/- /neutral)
+- Scalability considerations
+
+## Questions for Author
+- Points needing clarification before approval
+```
+
+{{#if frontend.mindset}}
+## Frontend Review Criteria
+{{{frontend.mindset}}}
+{{/if}}
+
+{{#if backend.mindset}}
+## Backend Review Criteria
+{{{backend.mindset}}}
+{{/if}}