@ripla/godd-mcp 0.1.2-beta-20260312091403

package/templates/prompts/commit.hbs

@@ -0,0 +1,96 @@
+{{> 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`: `documents/**`
+- `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

@@ -0,0 +1,127 @@
+{{> 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 run --rm --profile test <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

@@ -0,0 +1,95 @@
+{{> ssot-header }}
+{{> godd-core }}
+{{> ssot-rules }}
+{{> project-context }}
+
+## Purpose
+
+プロジェクトに `docs/` フォルダ構造をテンプレートから生成する。  
+ripla Notes（テキストノート / テーブルノート / drawio）で閲覧・編集可能なドキュメント初期構造を作成する。
+
+## docs/ フォルダ構成（テンプレート）
+
+以下の構造を生成すること:
+
+```
+docs/
+├── README.md                          # docs 全体の入口・構成説明
+├── 001_project/
+│   ├── README.md                      # プロジェクト概要（背景・目的・MVP・用語）
+│   ├── features.csv                   # 機能要件一覧（テーブルノート）
+│   ├── screens.csv                    # 画面要件一覧（テーブルノート）
+│   └── template_README.md
+├── 002_business_flow/
+│   ├── README.md                      # ビジネスフロー概要（Mermaid 含む）
+│   └── flow-overview.drawio
+├── 003_requirements/
+│   ├── README.md                      # 要件概要
+│   ├── requirements-list.csv          # 要件一覧（テーブルノート）
+│   └── template_requirements.md
+├── 004_non_functional_requirements/
+│   ├── README.md
+│   └── nfr-list.csv
+├── 005_pages/
+│   ├── README.md
+│   ├── page-definitions.csv
+│   └── template_page.md
+├── 006_designs/
+│   ├── README.md
+│   ├── api/api.md
+│   ├── db/db.md
+│   ├── db/tables.csv
+│   ├── infra/infra.md
+│   └── features/README.md
+└── 007_development/
+    ├── README.md
+    ├── structure.md
+    ├── workflow.md
+    ├── stacks.md
+    └── git.md
+```
+
+## ルール
+
+1. プロジェクトスキャン結果と入力パラメータ（プロジェクト名、ロール、画面ID）を使って各ファイルの内容を生成
+2. CSV ファイルはヘッダー行 + サンプル行を含める
+3. README.md は Mermaid ダイアグラムを含める（適切な場合）
+4. 既に `docs/` が存在する場合は既存構造を尊重し、不足分のみ追加
+5. 各ファイルの先頭にファイルの目的を1行コメントで記載
+
+## CSV ヘッダー定義
+
+### features.csv
+```
+機能ID,機能名,概要,phase,優先度,ステータス
+```
+
+### screens.csv
+```
+画面ID,画面名,概要,提供フェーズ,関連機能ID,ステータス
+```
+
+### requirements-list.csv
+```
+要件ID,要件名,概要,優先度,ステータス
+```
+
+### nfr-list.csv
+```
+NFR-ID,カテゴリ,要件,基準,優先度
+```
+
+### page-definitions.csv
+```
+画面ID,画面名,URL,認証要否,概要
+```
+
+### tables.csv
+```
+テーブル名,カラム名,型,制約,説明
+```
+
+## 出力
+
+- 生成した全ファイルのパスと内容
+- 生成理由の簡潔な説明

package/templates/prompts/docs-update.hbs

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

package/templates/prompts/git-workflow.hbs

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

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

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

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