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

package/templates/prompts/git-workflow.hbs

@@ -1,125 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-## Purpose
-Execute **default branch sync → new branch creation → commit with proper granularity** as a unified workflow. The developer only needs to provide the branch name and purpose.
-
-## References (detailed specs for each step)
-- sync: `godd_sync` tool
-- new-branch: `godd_new_branch` tool
-- commit: `godd_commit` tool
-
-## Input
-- **branch_name** (required): Branch name to create (follows naming convention from `godd_new_branch`)
-- **purpose** (optional): What the branch is for (improves commit message accuracy)
-- **auto_confirm** (optional, default: false): When true, skip all user confirmations and execute the entire workflow automatically
-
-## Auto-confirm Mode
-{{#if auto_confirm}}
-**auto_confirm is ENABLED** — All phases run without user confirmation. Conflicts are resolved by Agent's best judgment. Commit plans are executed immediately. Results are reported afterward.
-{{else}}
-**auto_confirm is DISABLED (default)** — Each phase pauses for user confirmation when decisions are needed.
-{{/if}}
-
-## Agent Steps (MUST)
-
-### Phase 1: Default Branch Sync (sync)
-
-1. Run `git status` to check for uncommitted changes
-2. If uncommitted changes exist, run `git stash --include-untracked`
-3. Run `git fetch origin main` to get remote latest
-4. Run `git merge origin/main` to sync
-   - On conflict: Resolve using SSOT-priority policy (SSOT-compliant side first; integrate if both comply; ask user if uncertain)
-5. If stashed, run `git stash pop` to restore (resolve conflicts if any)
-
-{{#if auto_confirm}}
-**Auto-confirm**: Agent resolves conflicts by best judgment and continues to Phase 2
-{{else}}
-**Abort condition**: If conflict resolution requires user confirmation, do NOT proceed to Phase 2 — wait for user input
-{{/if}}
-
-### Phase 2: New Branch Creation (new-branch)
-
-1. If uncommitted changes exist, run `git stash --include-untracked`
-2. Run `git checkout -b <branch_name> origin/main` to create and switch
-   - Phase 1 already synced main, so the latest main is the base
-3. If stashed, run `git stash pop` to restore (resolve conflicts if any)
-
-{{#if auto_confirm}}
-**Auto-confirm**: If a branch with the same name already exists, delete it and recreate
-{{else}}
-**Abort condition**: If a branch with the same name already exists, ask the user
-{{/if}}
-
-### Phase 3: Commit with Proper Granularity (commit)
-
-1. Run `git status` / `git diff` to review changes
-   - **If no changes**: Report "No changes to commit. Branch creation and sync complete." and exit
-2. Classify changed files by **hard scope** (frontend / backend / repo-root) and create a commit plan by responsibility unit
-3. Present the commit plan to the user and wait for approval
-4. After approval, execute commits one by one following the plan
-
-{{#if auto_confirm}}
-**Auto-confirm**: Skip approval and execute commits immediately after creating the plan
-{{else}}
-**Abort condition**: Commit plan requires user approval (never auto-execute)
-{{/if}}
-
-## Flow Overview
-
-```
-[Start]
-  |
-  v
-Phase 1: sync (merge latest main)
-  |  |- Conflict -> resolve or abort for user confirmation
-  |  '- Success
-  v
-Phase 2: new-branch (create branch)
-  |  |- Same name exists -> abort for user confirmation
-  |  '- Success
-  v
-Phase 3: commit (responsibility-unit commits)
-  |  |- No changes -> report completion
-  |  |- Changes exist -> present commit plan -> wait for approval
-  |  '- After approval -> execute commits
-  v
-[Complete]
-```
-
-## Output
-Report results progressively for each phase:
-
-### Phase 1 Result
-- Sync result: Success / Conflicts resolved / Already up to date
-- Number of commits synced
-
-### Phase 2 Result
-- Created branch name
-- Base point (origin/main commit hash)
-- Stash restore result
-
-### Phase 3 Result
-- Commit plan (for user review)
-- Execution result: Each commit hash and message
-- Final state: `git status` / `git log --oneline -5`
-
-### Final Summary
-```
-[git-workflow complete]
-- Sync: Merged N commits from latest main
-- Branch: Created <branch_name> (base: <hash>)
-- Commits: Executed N commits
-- State: Clean / Uncommitted changes remain
-```

package/templates/prompts/impact-analysis.hbs

@@ -1,43 +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
-Identify the blast radius before making changes and prevent oversights.
-Evaluate from **all perspectives**: functional, performance, UX, security, and operational impact.
-
-## Input
-- Change summary (what / why)
-- Target modules ({{#each stacks}}{{this.label}}{{#unless @last}} / {{/unless}}{{/each}})
-- Whether breaking changes exist
-
-## Analysis Framework
-For each affected area, evaluate:
-1. **Direct impact**: What changes and why
-2. **Indirect impact**: What could be affected as a side effect
-3. **Risk level**: HIGH / MEDIUM / LOW with justification
-4. **Mitigation**: How to reduce or eliminate the risk
-5. **Rollback plan**: How to undo the change if something goes wrong
-
-## Output
-Markdown filling in each section of the impact-analysis template:
-- **Change overview**: What is being changed and why
-- **Affected modules/components**: List with impact type (direct/indirect)
-- **Breaking changes**: Yes/No, details if Yes
-- **Migration requirements**: Steps needed for existing data/users
-- **Rollback plan**: Step-by-step reversal procedure
-- **Risk matrix**: Impact × likelihood for each identified risk
-- **Test requirements**: What needs to be tested to verify the change is safe
-
-Mark unclear items as **TBD** and list questions at the end using the Question Template.

package/templates/prompts/install.hbs

@@ -1,40 +0,0 @@
-{{> ssot-header }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-daily }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-## Purpose
-Install and activate the specified tool/MCP server with environment-appropriate procedures.
-
-## Supported Tools
-- **Context7**: Official pattern reference MCP
-- **Chrome DevTools MCP**: Browser debugging support (DevTools integration)
-- **MarkItDown MCP**: Document conversion (PDF/Office → Markdown)
-- **MCP OCR**: OCR (image/PDF text extraction)
-- **Serena**: Reference tracking/safe editing MCP
-- **Vibe ODF Read MCP**: ODF (.odt etc.) reading
-- Any other user-specified tool
-
-## Input (fill by asking)
-- Tool name to install
-- OS (Windows/macOS/Linux)
-- Network constraints (internal/proxy)
-- Cursor MCP config scope (workspace/user)
-
-## Output
-- **Installation steps** (commands in copy-paste-ready format)
-- **Activation/connectivity verification** steps
-- **Common failure points** and workarounds
-- **Operational rules** (when to use / when not to use)
-
-## Rules
-- Do not guess when prerequisites are unclear. Ask the user first
-- Installation commands are highly environment-dependent; always confirm OS/network constraints
-- Include an example of adding to Cursor's MCP config (`.cursor/mcp.json`)

package/templates/prompts/new-branch.hbs

@@ -1,61 +0,0 @@
-{{> ssot-header }}
-
-{{> godd-core }}
-
-{{> ssot-rules }}
-
-{{> project-context }}
-
-{{> cogito-grammar }}
-{{> cogito-root-core }}
-{{> cogito-particle }}
-{{> cogito-godd }}
-{{> cogito-root-dev }}
-
-## Purpose
-Safely stash any in-progress changes, create a new branch from the latest default branch, and restore the stashed changes. The developer only needs to provide the branch name (or purpose).
-
-## Input
-- **branch_name** (required): The branch name to create. If not provided, the Agent proposes one based on the purpose and asks for confirmation
-- **base_branch** (optional): Base branch to create from. Defaults to `origin/main`
-
-### Branch Naming Convention
-- Feature: `feat/<slug>`
-- UI implementation: `feat/<slug>-frontend` / `feat/<slug>-backend` (Front/Back separation required)
-- Bug fix: `fix/<slug>`
-- Documentation: `docs/<slug>`
-- Refactoring: `refactor/<slug>`
-- Other: `chore/<slug>`
-
-## Agent Steps (MUST)
-
-### Step 1: Check Current State
-1. Run `git status` to check for uncommitted changes (staged / unstaged / untracked)
-2. Record the current branch name via `git branch --show-current`
-
-### Step 2: Stash Changes (only if uncommitted changes exist)
-1. Run `git stash --include-untracked` to stash all changes
-2. Verify stash succeeded (`git stash list` shows the entry at top)
-   - **If no changes**: Skip stash, proceed to Step 3
-
-### Step 3: Fetch Remote and Create Branch
-1. Run `git fetch origin` to update remote
-2. Run `git checkout -b <branch_name> <base_branch>` to create and switch to the new branch
-   - If base_branch not specified: `git checkout -b <branch_name> origin/main`
-   - If a branch with the same name already exists: Ask the user (overwrite or rename)
-
-### Step 4: Restore Stashed Changes (only if stashed)
-1. Run `git stash pop` to restore stashed changes
-2. Check result:
-   - **Success**: Complete
-   - **Conflict**: Report conflicted files and resolve:
-     - **Keep SSOT-compliant side**: If one side adheres to SSOT, adopt it
-     - **Both compliant and integrable**: Integrate both
-     - **Uncertain**: Ask the user (never guess)
-
-## Output
-- **Created branch name**: Full branch name
-- **Base**: Which branch/commit it was created from
-- **Previous branch**: Branch name before switching
-- **Stash restore result**: Success / Conflicts / Not needed
-- **Current state**: `git status` summary

package/templates/prompts/notes-deploy.hbs

@@ -1,138 +0,0 @@
-{{> ssot-header }}
-{{> godd-core }}
-{{> project-context }}
-
-## Purpose
-
-GoDD Notes（notes-app / notes-api）をデプロイする。
-AI エージェントが自律的にデプロイを完了できる手順を提供する。
-
-## アーキテクチャ
-
-```
-notes-app (React + Vite)  ──proxy──▶  notes-api (FastAPI)  ──▶  GitHub API
-     :5175                                :8000
-```
-
-## AI 向けデプロイフロー（推奨）
-
-### フロー選択
-
-| 条件 | 使うコマンド |
-|------|-------------|
-| ローカルで試す / 開発環境 | `godd notes compose --auto` |
-| 設定をカスタマイズしたい | `godd notes compose --config <path>` |
-| AWS にデプロイ | `godd notes deploy -y` |
-| インフラとアプリ雛形を新規構築 | `godd notes infra` |
-
-### A. ローカルデプロイ（最も簡単）
-
-**前提**: Docker が起動していること
-
-**ステップ 1**: 環境変数を設定
-
-```bash
-export GITHUB_TOKEN=ghp_xxx
-export GITHUB_OWNER=owner
-export GITHUB_REPO=repo
-```
-
-**ステップ 2**: 自動デプロイ
-
-```bash
-godd notes compose --auto
-```
-
-これで以下が自動実行される:
-1. デフォルト設定で `.env` 生成（DB パスワード・JWT シークレット等は自動生成）
-2. notes-api / notes-app / PostgreSQL を Docker Compose で起動
-3. ヘルスチェック待機
-
-**ステップ 3**: 状態確認
-
-```bash
-godd notes status
-```
-
-**カスタム設定が必要な場合**:
-
-```bash
-# 設定ファイルを作成
-cat > notes-config.json << 'EOF'
-{
-  "deployDir": "./godd-notes",
-  "githubToken": "ghp_xxx",
-  "githubOwner": "owner",
-  "githubRepo": "repo",
-  "githubBranch": "main",
-  "postgresPort": "5432",
-  "notesApiPort": "3100",
-  "notesAppPort": "5175"
-}
-EOF
-
-godd notes compose --config notes-config.json
-```
-
-### B. AWS デプロイ
-
-**前提**: 
-- AWS CLI でログイン済み（`aws sts get-caller-identity` が成功すること）
-- `godd notes infra` でインフラ構築済み
-- `notes-api/` と `notes-app/` がデプロイ対象ルートに存在すること
-- `.godd-notes-infra.json` が存在すること
-
-```bash
-godd notes deploy -y
-```
-
-デプロイ後の確認:
-
-```bash
-godd notes status
-```
-
-### C. デプロイ後の確認
-
-```bash
-# ヘルスチェック
-curl http://localhost:3100/api/health
-
-# ログイン確認
-curl -X POST http://localhost:3100/api/auth/login \
-  -H "Content-Type: application/json" \
-  -d '{"username":"admin","password":"<生成されたパスワード>"}'
-```
-
-## 人間に委譲が必要な操作
-
-以下は AI では自動化できない。人間に依頼すること:
-
-1. **GitHub Token の発行**: https://github.com/settings/tokens
-   - スコープ: `repo`（プライベートリポジトリ）または `public_repo`（パブリック）
-2. **AWS SSO ログイン**: `aws sso login --profile <profile>` → ブラウザ認証
-3. **DNS 設定**: カスタムドメインの CNAME/A レコード設定
-4. **初回 Terraform apply**: `terraform init && terraform apply`（インフラ新規作成時）
-
-## テスト実行（Docker 完全環境）
-
-```bash
-docker compose --profile test run --rm notes-api-test
-docker compose --profile test run --rm notes-app-test
-```
-
-## トラブルシューティング
-
-| 症状 | 対処 |
-|------|------|
-| Docker not running | Docker Desktop を起動してもらう（人間に依頼） |
-| GitHub Token 未設定 | 環境変数 `GITHUB_TOKEN` を設定 |
-| ポート競合 | `--config` で別ポートを指定 |
-| ECS デプロイ遅延 | `godd notes status` で安定化を確認（5-10分） |
-| DB 接続エラー | `docker compose logs db` でログ確認 |
-
-## 出力
-
-- デプロイ完了報告（URL・管理者情報）
-- 設定ファイル（`.godd-notes-compose.json` / `.godd-notes-infra.json`）
-- ヘルスチェック結果

package/templates/prompts/pr-analyze.hbs

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

@@ -1,125 +0,0 @@
-{{> 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 (`docs/006_development_workflow/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: `docs/006_development_workflow/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

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

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