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

package/templates/prompts/release-notes.hbs

@@ -1,38 +0,0 @@
-{{> 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

@@ -1,29 +0,0 @@
-{{> 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 `docs/003_requirements/spec/`

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

@@ -1,26 +0,0 @@
-{{> 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

@@ -1,126 +0,0 @@
-{{> 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}}

package/templates/prompts/setup.hbs

@@ -1,247 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-{{> cogito-root-daily }}
-
-## Purpose
-**Actually set up** this project's local environment by running commands and creating files. The Agent executes everything — not just a guide.
-
-## Critical Prerequisites (MUST)
-- When this tool is called, GoDD MCP Server is already running (= `config.godd` and `.cursor/mcp.json` are minimally functional)
-- However, the configuration **may be incomplete or templated**. Detect gaps and fill them
-- **Actually execute runnable commands**. Do not just list instructions
-- **Do not overwrite existing files**. Report differences and ask the user for confirmation
-
----
-
-## Phase 1: GoDD MCP Config Verification & Generation
-
-Check the following files and create/fix if missing or incomplete:
-
-### 1-1. `godd-mcp-server/config.godd`
-```yaml
-# GoDD MCP Server config
-license_key: "<set your license key here>"
-stack_profile: "{{profile_name}}"
-language: "en"   # ja | en
-```
-
-- File does not exist → Create with the above content
-- `license_key` is unset (empty or placeholder) → Ask the user for input
-- `stack_profile` doesn't match current profile (`{{profile_name}}`) → Warn and confirm
-
-### 1-2. `.cursor/mcp.json`（project root）
-```json
-{
-  "mcpServers": {
-    "godd": {
-      "command": "npx",
-      "args": ["tsx", "godd-mcp-server/src/index.ts"],
-      "env": {
-        "GODD_CONFIG": "./godd-mcp-server/config.godd",
-        "GODD_PROJECT_ROOT": "."
-      }
-    }
-  }
-}
-```
-
-- `.cursor/` directory does not exist → Create with `mkdir .cursor`
-- `mcp.json` does not exist → Create with the above content
-- Already exists with `godd` key → Compare and report differences (do not overwrite)
-- Already exists without `godd` key → Add `godd` entry (preserve existing entries)
-
-### 1-3. GoDD MCP Server dependencies
-```bash
-cd godd-mcp-server && pnpm install
-```
-- `node_modules/` does not exist → Run `pnpm install`
-- Exists → Skip
-
----
-
-## Phase 2: Project Environment Setup
-
-### 2-1. Environment Variable Files
-{{#if project.env_templates.length}}
-The following templates were detected. Copy to create `.env` if it doesn't exist:
-
-{{#each project.env_templates}}
-- `{{this}}`:
-{{/each}}
-
-**Specific steps:**
-1. Copy `.env.example` → `.env` (project root)
-2. Copy `env.electron.example` → `frontend/.env.local` (if exists)
-3. After copying, verify defaults work (DB password etc. can use template values for local dev)
-4. If `.env` already exists → Report diff with template and confirm missing keys with user
-{{/if}}
-
-### 2-2. Required Tools Verification
-**Actually execute** the following commands to verify each tool is installed:
-
-```bash
-git --version
-docker --version
-docker compose version
-{{#each project.detected_stacks}}
-{{#if (eq this.id "react")}}node --version    # v20+ 必須
-pnpm --version{{/if}}
-{{#if (eq this.id "fastapi")}}python --version  # 3.11+ 必須
-uv --version{{/if}}
-{{/each}}
-```
-
-- If a tool is missing, **provide installation instructions** and install after user approval
-- Also warn if versions are insufficient
-
-### 2-3. Frontend Dependencies
-{{#if frontend}}
-```bash
-pnpm -C {{frontend.root_dir}} install
-```
-- `{{frontend.root_dir}}/node_modules/` does not exist → Execute
-- Exists → Skip
-{{/if}}
-
-### 2-4. Backend Dependencies
-{{#if backend}}
-```bash
-cd {{backend.root_dir}} && uv sync
-```
-- `{{backend.root_dir}}/.venv/` does not exist → Execute
-- Exists → Skip
-{{/if}}
-
-### 2-5. Docker Services Startup
-{{#if project.docker_services.length}}
-The following services are defined in `docker-compose.yml`:
-{{#each project.docker_services}}
-- `{{this}}`
-{{/each}}
-
-```bash
-docker compose up -d
-docker compose ps    # 全サービスが healthy か確認
-```
-- Already running → Report `docker compose ps` result and skip
-- Not running → Execute `docker compose up -d` and wait for healthcheck
-- Healthcheck fails → Check `docker compose logs <service>` and report error
-{{/if}}
-
-### 2-6. DB Migration
-{{#if backend}}
-Once Postgres is healthy, check and run migrations:
-
-```bash
-cd {{backend.root_dir}} && uv run alembic upgrade head
-```
-- Skip if no migration files exist
-- Report "Already up to date" if current
-{{/if}}
-
-{{#if project.vendor_items.length}}
-### 2-7. Vendor / OSS Subprojects
-The following vendor tools are available. After initializing submodules, run each setup:
-
-```bash
-git submodule update --init --recursive
-```
-
-{{#each project.vendor_items}}
-- **vendor/{{this.name}}**: `cd vendor/{{this.name}} && {{this.setupHint}}`
-{{/each}}
-- If submodules are empty → Run `git submodule update --init --recursive`
-- If already set up → Skip
-{{/if}}
-
----
-
-## Phase 3: Smoke Test
-
-After all setup is complete, **actually execute** the following smoke tests:
-
-### 3-1. Docker Service Connectivity
-```bash
-docker compose ps
-```
-- All services should be `healthy` or `running`
-
-{{#if backend}}
-### 3-2. API Connectivity
-```bash
-curl -s http://localhost:${API_PORT:-8000}/health || echo "API unreachable"
-```
-- 200 OK = success. On failure, investigate with `docker compose logs api`
-{{/if}}
-
-{{#if frontend}}
-### 3-3. Frontend Build Check
-```bash
-{{frontend.build_command}}
-```
-- Build success means frontend environment is OK
-{{/if}}
-
-{{#if quality_gate}}
-### 3-4. Quality Gate (Optional)
-Optionally run the quality gate to verify overall health:
-{{#if quality_gate.frontend}}
-- Frontend: `{{quality_gate.frontend}}`
-{{/if}}
-{{#if quality_gate.backend}}
-- Backend: `{{quality_gate.backend}}`
-{{/if}}
-{{/if}}
-
----
-
-## Execution Scope by Mode
-
-| Mode | Phase 1 (GoDD) | Phase 2 (Project) | Phase 3 (Smoke) |
-|---|---|---|---|
-| `full` | ✅ | ✅ | ✅ |
-| `godd-only` | ✅ | ⏭ Skip | ⏭ Skip |
-| `project-only` | ⏭ Skip | ✅ | ✅ |
-
----
-
-## Notes
-- Do not edit CI/CD configurations (`.github/workflows/`)
-- Do not commit `.env` files (`.gitignore` target)
-- Treat `config.godd` license key as sensitive information
-- **Tests run inside Docker containers** — quality gate uses `docker compose --profile test run --rm <service>-test`. Host-local test execution is not supported
-
-## Required Output on Completion (MUST)
-
-After setup completion, **always** report the following to the user:
-
-### 1. Setup Result Summary
-```
-✅ Successful:
-  - config.godd created
-  - .cursor/mcp.json created
-  - ...
-
-⚠️ Needs attention:
-  - License key is still placeholder
-  - ...
-
-❌ Failed:
-  - Docker startup failed (error: ...)
-  - ...
-```
-
-### 2. Next Steps
-- If GoDD MCP is healthy → Guide with "You can start development with `godd_dev`"
-- If there are issues → Provide specific fix steps

package/templates/prompts/spec.hbs

@@ -1,35 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-{{> cogito-root-daily }}
-
-## Purpose
-Transform requirements into implementation-ready Spec (SSOT) at appropriate granularity.
-The Spec must be complete enough that any developer (human or Agent) can implement without guessing.
-
-## Process
-1. First, list **"missing information (questions)"** (up to 5-10, in priority order) using the Question Template
-2. Next, select the required Spec types and draft based on standard templates:
-   - **API Spec**: Endpoints, request/response schemas, error codes, auth requirements
-   - **UI Spec**: Screens, components, state management, user flows, accessibility
-   - **DB Spec**: Tables, relationships, indexes, migrations, constraints
-   - **Feature Spec**: Business rules, acceptance criteria (Given-When-Then), edge cases
-   - **Usecase Spec**: Actor, preconditions, main flow, alternative flows, postconditions
-   - **Error Codes Spec**: Error taxonomy, user-facing messages, recovery actions
-3. Always fill in **compatibility/migration/rollback** (use placeholders + mark as TBD if unknown)
-
-## Output
-- **Questions** (if any) — using the Question Template format
-- **Spec document** in Markdown, with all sections filled
-- Mark unknown items as **TBD** with a note on what information is needed
-- Include **acceptance criteria** in Given-When-Then format for each feature/behavior

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

@@ -1,24 +0,0 @@
-{{> ssot-header }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-daily }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-## Purpose
-Transform Specs (`docs/003_requirements/spec/`) into an implementable task list.
-
-## Input
-- Target Spec (API/UI/DB/Feature/Usecase/Error Codes)
-
-## Output
-- Task list (ordered)
-  - Impact layer ({{#if backend}}Backend: {{backend.architecture}}{{#if backend.dependency_direction}} ({{backend.dependency_direction}}){{/if}}{{/if}}{{#if frontend}}, Front: UI/hooks/services{{/if}}, Agent/Infra)
-  - Estimated files to add/change
-  - Test perspective (unit/integration/e2e)
-  - Risks (compatibility/migration/security/performance)

package/templates/prompts/submit.hbs

@@ -1,143 +0,0 @@
-{{> ssot-header }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-## Purpose
-Execute the **complete submission workflow**: pre-submission checks → git push → PR creation, as a single unified command. The developer only needs to invoke this tool — the Agent handles everything.
-
-## References (detailed specs for each step)
-- Pre-submission check + Push: `godd_push_execute` tool
-- PR creation: `godd_pr_create` tool
-
-## Auto-confirm Mode
-{{#if auto_confirm}}
-**auto_confirm is ENABLED** — All phases run without user confirmation. Check results, push, and PR creation proceed automatically. Results are reported afterward.
-{{else}}
-**auto_confirm is DISABLED (default)** — Each phase pauses for user confirmation when decisions are needed.
-{{/if}}
-
-## Draft Mode
-{{#if draft}}
-**draft is ENABLED** — The PR will be created as a Draft PR.
-{{else}}
-**draft is DISABLED (default)** — The PR will be created as a regular (ready for review) PR.
-{{/if}}
-
-## Agent Steps (MUST)
-
-### Phase 1: Pre-submission Checks
-
-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
-   - 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
-3. Execute pre-submission checks:
-   - **Quality gate**: Run project's quality gate commands
-   - **Spec reflection**: Check if `docs/003_requirements/spec/` needs updates
-   - **Secret check**: Scan for potential secrets in committed content
-   - **Breaking changes**: Verify migration docs if breaking changes exist
-4. Present check results
-
-{{#if auto_confirm}}
-**Auto-confirm**: If all checks pass, proceed directly to Phase 2. If checks fail, attempt to fix and re-run before aborting.
-{{else}}
-**Pause**: Present results and wait for user confirmation before proceeding
-{{/if}}
-
-### Phase 2: Push to Remote
-
-1. Determine push command:
-   - If remote tracking branch exists: `git push`
-   - If no remote tracking branch: `git push -u origin HEAD`
-2. Execute push
-3. Verify push result:
-   - `git status` confirms branch is up to date with remote
-   - No unpushed commits remain
-
-{{#if auto_confirm}}
-**Auto-confirm**: On success, proceed directly to Phase 3. On failure, report error and abort.
-{{else}}
-**Pause**: Report push result. On success, ask if user wants to proceed to PR creation.
-{{/if}}
-
-### Phase 3: PR Creation
-
-1. Gather information:
-   - Current branch name, base branch (user-specified or `main`)
-   - `git log origin/<base>..HEAD --oneline` for commit list
-   - `git diff origin/<base>...HEAD --stat` for change summary
-2. Generate PR content:
-   - **Title**: Use user-provided title, or derive from branch name and changes
-   - **Body**: Follow PR template (`docs/006_development_workflow/pr.template.md`) — fill ALL sections
-3. Present PR title and body for review
-
-{{#if auto_confirm}}
-**Auto-confirm**: Skip review and create PR immediately
-{{else}}
-**Pause**: Wait for user review and approval of PR content
-{{/if}}
-
-4. Create PR:
-   ```
-   gh pr create --title "<title>" --base <base_branch> --head <current_branch> --body "<body>"{{#if draft}} --draft{{/if}}
-   ```
-5. Report PR URL and metadata
-
-## Flow Overview
-
-```
-[Start]
-  |
-  v
-Phase 1: Pre-submission Checks
-  |  |- Check failed -> fix and re-run (or abort)
-  |  '- All checks passed
-  v
-Phase 2: Push to Remote
-  |  |- Push failed -> report error and abort
-  |  '- Push succeeded
-  v
-Phase 3: PR Creation
-  |  |- Generate PR content from changes
-  |  |- Present for review (unless auto_confirm)
-  |  '- Create PR via gh CLI
-  v
-[Complete]
-```
-
-## Output
-Report results progressively for each phase:
-
-### Phase 1 Result
-- Check results: Each item with pass/fail status
-- Commits to push (count and list)
-
-### Phase 2 Result
-- Push result: Success (remote URL + branch) or failure reason
-- Post-push state: `git status` summary
-
-### Phase 3 Result
-- PR title and body (for user review)
-- PR URL after creation
-- PR metadata: number, state, base/head branches
-
-### Final Summary
-```
-[submit complete]
-- Checks: All passed (N items)
-- Push: Pushed N commits to origin/<branch>
-- PR: Created #<number> (<url>)
-  - Title: <title>
-  - Base: <base> ← Head: <head>
-  - State: Open{{#if draft}} (Draft){{/if}}
-```