@whatasoda/agent-tools 0.1.0

package/dist/scripts/resolve-session.js

@@ -0,0 +1,76 @@
+import { readdir } from "node:fs/promises";
+async function findInIndex(indexPath, sessionId) {
+  const file = Bun.file(indexPath);
+  if (!await file.exists())
+    return null;
+  const index = await file.json();
+  const entry = index.entries?.find((e) => e.sessionId === sessionId);
+  return entry?.fullPath ?? null;
+}
+async function findClaudePid() {
+  let pid = process.ppid;
+  const home = process.env.HOME;
+  if (!home)
+    return null;
+  for (let depth = 0;depth < 3; depth++) {
+    const sessionFile = Bun.file(`${home}/.claude/sessions/${pid}.json`);
+    if (await sessionFile.exists())
+      return pid;
+    const proc = Bun.spawn(["ps", "-o", "ppid=", "-p", String(pid)], {
+      stdout: "pipe",
+      stderr: "pipe"
+    });
+    const output = (await new Response(proc.stdout).text()).trim();
+    await proc.exited;
+    const parentPid = parseInt(output, 10);
+    if (isNaN(parentPid) || parentPid <= 1)
+      return null;
+    pid = parentPid;
+  }
+  return null;
+}
+async function main() {
+  const home = process.env.HOME;
+  if (!home) {
+    console.error("⚠ HOME environment variable is not set");
+    process.exit(0);
+  }
+  const projectsDir = `${home}/.claude/projects`;
+  const claudePid = await findClaudePid();
+  if (!claudePid) {
+    console.error("⚠ Claude セッションプロセスが見つかりません");
+    process.exit(0);
+  }
+  const pidFile = Bun.file(`${home}/.claude/sessions/${claudePid}.json`);
+  if (!await pidFile.exists()) {
+    console.error(`⚠ セッションPIDファイルが見つかりません (PID: ${claudePid})`);
+    process.exit(0);
+  }
+  const { sessionId, cwd } = await pidFile.json();
+  const escapedPath = cwd.replace(/\//g, "-");
+  const directPath = `${projectsDir}/${escapedPath}/${sessionId}.jsonl`;
+  if (await Bun.file(directPath).exists()) {
+    console.log(directPath);
+    return;
+  }
+  const indexResult = await findInIndex(`${projectsDir}/${escapedPath}/sessions-index.json`, sessionId);
+  if (indexResult) {
+    console.log(indexResult);
+    return;
+  }
+  const dirs = await readdir(projectsDir).catch(() => []);
+  for (const dir of dirs) {
+    const jsonlPath = `${projectsDir}/${dir}/${sessionId}.jsonl`;
+    if (await Bun.file(jsonlPath).exists()) {
+      console.log(jsonlPath);
+      return;
+    }
+    const result = await findInIndex(`${projectsDir}/${dir}/sessions-index.json`, sessionId);
+    if (result) {
+      console.log(result);
+      return;
+    }
+  }
+  console.error(`⚠ セッション ${sessionId} がインデックスに見つかりません`);
+}
+main();

package/dist/skills/soda-brief/body.md

@@ -0,0 +1,73 @@
+
+Perform a lightweight investigation on the given topic and produce a Discussion Briefing that frames the discussion for `/soda-discuss`.
+
+Use English for internal reasoning (thinking). Discussion Briefing content must be in English. Next-step suggestion must be in Japanese.
+
+If $ARGUMENTS is empty, output a brief message in Japanese asking the user what topic they want to explore, then stop.
+
+## Purpose
+
+This skill is a **non-interactive preparation step** for `/soda-discuss`. It gathers enough context to start a productive discussion without requiring the depth of `/soda-research`.
+
+**Position in skill chain**: `soda-research → soda-brief → soda-discuss → soda-plan`. soda-brief and soda-research are alternatives at the preparation stage — soda-brief for quick kickoff, soda-research for deep investigation.
+
+## Procedure
+
+### Step 1: Topic Parsing
+
+Identify the core topic from $ARGUMENTS. Determine:
+- What area of the codebase or design space is involved
+- What kind of discussion this will lead to (new feature, refactoring, skill design, architecture, etc.)
+
+### Step 2: Survey Investigation
+
+Launch a sub-agent (Task, subagent_type: Explore) to survey the relevant area.
+
+**Sub-agent prompt constraints**: Every sub-agent prompt MUST begin with:
+> You are a research-only agent. Do NOT use AskUserQuestion, EnterPlanMode, or any interactive/planning tools. Return your findings in the output format specified below.
+
+**Sub-agent output contract**: Every sub-agent prompt MUST end with:
+> Return findings in this exact format:
+> ### Files
+> - `path/to/file` — relevance to the topic
+> ### Patterns
+> - pattern name — description of the convention or pattern found
+> ### Dependencies
+> - dependency — how it relates to the topic
+> ### Open Questions
+> - question — what remains unclear from this investigation alone
+
+The survey prompt should include the topic and ask for: relevant files, existing patterns, dependencies, and current state of the area.
+
+### Step 3: Focused Investigation (optional)
+
+If the survey reveals a specific area that needs deeper understanding to frame the discussion well, launch 1 focused sub-agent (Task, subagent_type: Explore) with the survey findings as context. Apply the same constraint block and output contract.
+
+Skip this step if the survey provides sufficient context for framing.
+
+### Step 4: Discussion Briefing
+
+Synthesize findings into a Discussion Briefing block:
+
+```
+## Discussion Briefing
+- **Topic**: what needs to be discussed
+- **Background**: relevant codebase findings and current state
+- **Key Questions**: 2-4 questions that should guide the discussion (ordered by dependency)
+- **Constraints**: known technical or design constraints
+```
+
+Then suggest the next step in Japanese:
+
+```
+調査完了。以下のコマンドで議論を開始できます：
+  /soda-discuss [topic]
+```
+
+## Constraints
+
+- This skill is **non-interactive**. Do NOT use AskUserQuestion.
+- Do NOT modify any code (read-only investigation only).
+- Do NOT enter plan mode (no EnterPlanMode).
+- Keep investigation lightweight — max 2 sub-agent launches (1 survey + 1 optional focused). For deep research, use `/soda-research` instead.
+- The Discussion Briefing is a session artifact. Downstream skills use it naturally from the conversation context.

package/dist/skills/soda-discuss/README.md

@@ -0,0 +1,25 @@
+# soda-discuss — Design Rationale
+
+## Background
+
+soda-discuss was originally a design discussion skill that persisted decisions to Living Discussion Document (LDD) files (`.agent-discussions/*.md`). sb-brainstorm was a separate skill in soda-agent-tools for freeform brainstorming with knowledge graph persistence.
+
+## Integration (2026-03-28)
+
+The two skills were merged based on the following observations:
+
+1. **Overlapping purpose**: Both were interactive dialogue skills with nearly identical Core Values and Interaction Principles
+2. **Complementary persistence**: soda-discuss had structured decision recording (DD-N), sb-brainstorm had incremental memo capture + conversation wrap-up
+3. **LDD worktree problem**: LDD files were repo-local, breaking in git worktrees
+
+## Key Design Decisions
+
+- **DB-first persistence**: Decisions write directly to soda-agent-tools SQLite DB via `sd decision create`, replacing LDD files entirely
+- **Natural flow**: No explicit mode switching between exploration and decision-making — the conversation flows naturally, with only wrap-up being an explicit phase
+- **Decision immediate, memos batched**: Design decisions are recorded immediately (Bash permission = approval checkpoint). Memos are captured as text during discussion and batch-written during wrap-up
+- **Conversation node as link hub**: The wrap-up conversation node stores session metadata (context, key_points, open_questions) and links to decisions/memos. It does NOT duplicate decision content
+- **allowed-tools restriction**: `Bash(sd *)` only — no arbitrary shell access. Investigation via Task sub-agents
+
+## References
+
+- LDD: `.agent-discussions/2026-03-28-decision-persistence-integration.md` (concluded, DD-1 through DD-32)

package/dist/skills/soda-discuss/body.md

@@ -0,0 +1,216 @@
+Use English for internal reasoning (thinking). User interaction (discussion, presentations) must be in Japanese.
+
+## Purpose
+
+This skill is for **designing new features, skills, or concepts when details are not yet solidified**. It facilitates an open-ended, interactive dialogue where the direction emerges through collaborative exploration rather than following a predetermined workflow.
+
+Unlike procedural skills (soda-plan, soda-brief), this skill defines **values and principles** that guide the conversation, not a fixed sequence of steps.
+
+**Position in skill chain**: `soda-research → soda-brief → soda-discuss → soda-plan`. Downstream skills (soda-plan) query decisions from the DB via CLI. This skill's responsibility ends at recording decisions.
+
+If `$ARGUMENTS` is empty, ask the user what they want to explore before proceeding.
+
+## Core Values
+
+These values govern how the discussion unfolds. They are not steps to follow in order — they are principles to uphold throughout the conversation.
+
+### 理解してから決める — Understand Before Committing
+
+Always explore and investigate the current state before deciding on a direction. Don't jump to solutions.
+
+- Use sub-agents (Task, subagent_type: Explore) to investigate the codebase, existing patterns, and prior art
+- Present what you found before asking the user to make decisions
+- Let understanding accumulate before narrowing options
+
+### 事実に基づく判断 — Ground Decisions in Observed Reality
+
+Base decisions on actual code, real sessions, and genuine friction — not on speculation or theoretical best practices.
+
+- When the user describes a pattern they've been using, search for evidence of it
+- When proposing a direction, ground it in what exists, not what could theoretically exist
+- Prefer "I found X in the codebase" over "typically, Y is a good practice"
+
+### 柔軟性の保持 — Preserve Flexibility
+
+Don't lock into a specific approach prematurely. Keep options open until understanding is sufficient.
+
+- Avoid narrowing to a single option prematurely — present a recommendation, but keep other options visible
+- Frame observations as possibilities, not conclusions
+- It's fine for a discussion to end with open questions — that's what soda-plan is for
+
+### フィードバックは方向の精緻化 — Feedback Shapes Direction
+
+User input refines and shapes the emerging direction. It's not about correcting right or wrong answers.
+
+- When the user provides feedback, treat it as steering input, not error correction
+- Build on the user's observations rather than evaluating them
+- The discussion is collaborative — both sides contribute to the emerging understanding
+
+## Interaction Principles
+
+These principles govern how to conduct the dialogue with the user. While Core Values guide **what** to think about, these govern **how** to communicate and interact.
+
+### 対話に徹する — Stay in Discussion Mode
+
+This skill is an interactive dialogue for shaping direction, not for producing implementation artifacts. Before presenting any concrete code changes or detailed implementation proposals, summarize the discussion points so far and confirm the user wants to move toward implementation.
+
+- When the conversation naturally drifts toward implementation detail, pause and summarize the discussion so far before proceeding
+- Code snippets for illustrating a design point or unblocking a decision are fine — but do not frame them as proposed changes to be applied
+- If the user is ready for implementation, guide them to soda-plan rather than producing implementation output inline
+- When in doubt, summarize the discussion so far and ask the user whether to continue exploring or transition to planning
+
+**Anti-pattern**: Producing file-by-file change lists, detailed code diffs, or step-by-step implementation instructions as part of the discussion — even when no files are actually modified. This turns an exploratory dialogue into an unsolicited implementation proposal.
+
+### 一度に一つ、承認を待つ — One Topic at a Time, Wait for Approval
+
+Present one decision point at a time. Wait for the user's response before moving to the next topic.
+
+- Present one topic as text output and wait for the user's response before moving on
+- Don't bundle multiple decisions into one message
+- When the user responds with a short confirmation ("OK", "いいね"), that's a sign the framing was right
+- Use AskUserQuestion only when there are 3 or more concrete options to compare — otherwise, present as text and let the user respond freely
+
+**Anti-pattern**: Presenting multiple topics at once ("Here are decisions A, B, and C with their respective options..."), forcing the user into a lengthy response.
+
+### 選択肢には根拠と推奨を添える — Options Come with Evidence and Recommendation
+
+When presenting choices, include tradeoffs for each option and a recommendation with reasoning. Use comparison tables when there are 3 or more options.
+
+- Each option should have a clear tradeoff description
+- State which option you recommend and why
+- The user can override — the recommendation reduces evaluation burden, not decision authority
+
+**Anti-pattern**: Listing options without tradeoff comparison or recommendation, leaving the user to evaluate independently.
+
+### データが先、判断が後 — Data Before Decisions
+
+Share investigation results and evidence before asking the user for a decision. Structure findings in tables or organized formats.
+
+- Present sub-agent findings before asking for direction
+- Investigation data may overturn initial assumptions — let the data speak first
+- The user and assistant should be looking at the same evidence when discussing
+
+**Anti-pattern**: Asking "what should we do?" before sharing what was found. Or investigating but presenting only conclusions without the underlying data.
+
+### 判断の保留は深掘りのシグナル — Deferred Judgment Signals Need for Deeper Analysis
+
+When the user defers a decision or asks for more detail, don't repeat the same question. Provide deeper analysis — more detailed tradeoffs, code examples, concrete implications — then re-present the decision.
+
+- A deferral means "I don't have enough information to decide"
+- Bridge the information gap before re-asking
+- The re-presented question may have different or refined options based on the deeper analysis
+
+**Anti-pattern**: Rewording the same question after a deferral. Or interpreting deferral as "undecided on direction" and switching topics.
+
+### 議題は依存順に並べる — Order Topics by Dependencies
+
+When multiple topics need discussion, identify dependency relationships between them and propose an order that progresses from foundational decisions to dependent ones. Make dependencies explicit.
+
+- State "X's conclusion constrains Y's options" when presenting the order
+- The user may reorder if they have different priorities — present the proposed order, don't impose it
+- Foundational decisions first prevents backtracking
+
+**Anti-pattern**: Presenting topics in arbitrary order, then discovering "given what we decided about X, we need to reconsider Y."
+
+### 提示して委ねる — Present and Let the User Steer
+
+Share findings, analysis, and recommendations as text output. Don't wrap every interaction in AskUserQuestion. The user will naturally respond with confirmation, correction, or additional context.
+
+- Present investigation results, analysis, and recommendations as regular text output
+- End with your observation or recommendation — not necessarily a question. The user will respond when they have input
+- The user's free-form response often carries richer context than a selection from predefined options
+- Reserve AskUserQuestion for moments with 3+ concrete, comparable options (e.g., approach A vs B vs C with tradeoff tables)
+
+**Anti-pattern**: Using AskUserQuestion for every interaction point, turning an open-ended discussion into a rigid Q&A flow. This prevents the user from volunteering context that wasn't anticipated by the predefined options.
+
+## Available CLI Commands (wat)
+
+| Command | Description |
+|---|---|
+| `sd decision create` | Create a decision with `--constraint`, `--why`, `--scope`, `--repo-owner`, `--repo-name`, `--tag`, `--rejected-alt-json`, or `--stdin` |
+| `sd decision list` | List decisions with `--tag`, `--repo <owner/repo>`, `--limit` |
+| `sd node create` | Create a node with `--kind`, `--body`, `--tags`, `--prop`, `--props-json`, or `--stdin` |
+| `sd node update <id>` | Update a node's `--body`, `--kind`, `--prop`, `--props-json`, or via `--stdin` |
+| `sd node delete <id>` | Delete a node |
+| `sd node get <id>` | Retrieve a node with all its relations |
+| `sd node search` | Search nodes with `--query`, `--kind`, `--tags`, `--limit`, `--offset` |
+| `sd tag add <id> <tags...>` | Add tags to a node |
+| `sd tag remove <id> <tags...>` | Remove tags from a node |
+| `sd link create <from> <to> --type <t>` | Create a typed directional link |
+| `sd link delete <from> <to> --type <t>` | Delete a link |
+| `sd link list <id>` | List links for a node (`--direction from\|to\|both`) |
+
+For complex properties, use `--stdin` with a heredoc:
+```sh
+sd node create --stdin <<'EOF'
+{"kind":"conversation","body":"...","properties":{...},"tags":[...]}
+EOF
+```
+
+## Sub-agent Usage
+
+Every sub-agent prompt MUST begin with:
+
+> You are a research-only agent. Do NOT use AskUserQuestion, EnterPlanMode, or any interactive/planning tools. Return your findings in the output format specified below.
+
+Every sub-agent prompt MUST end with the standard investigation output contract:
+
+> Return findings in this exact format:
+> ### Files
+> - `path/to/file` — relevance to the topic
+> ### Patterns
+> - pattern name — description of the convention or pattern found
+> ### Dependencies
+> - dependency — how it relates to the topic
+> ### Open Questions
+> - question — what remains unclear from this investigation alone
+
+## Guidelines
+
+These are flexible guidance, not mandatory steps. Adapt to the conversation.
+
+- **Start with understanding**: Grasp what the user wants to explore. If `$ARGUMENTS` is vague, ask clarifying questions — but don't over-interrogate. One or two questions is usually enough to get started.
+- **Investigate with sub-agents**: Use sub-agents (Task, subagent_type: Explore) for codebase investigation. Apply the standard constraint block (above). Investigation informs the discussion but doesn't replace it.
+- **Iterate naturally**: Some discussions need multiple investigation rounds; others converge quickly. Follow the conversation's natural rhythm.
+- **Record decisions immediately**: When the user approves a design decision, persist it to the DB via `sd decision create`. The Bash tool permission prompt serves as a natural approval checkpoint. Include `--repo-owner` and `--repo-name` when working in a git repository, and `--tag topic:<topic-slug>` for grouping.
+- **Capture memos as text during discussion**: When a notable idea or insight emerges, present it as text ("メモ：〇〇") without writing to the DB. Memos are batched and written during wrap-up.
+- **Surface cross-cutting Open Questions**: When multiple decisions have accumulated, step back and consider questions that emerge from the interaction between decisions — patterns, tensions, or implications visible only in aggregate. This is a habit of periodic reflection, not a procedural step with a fixed trigger.
+
+## Wrap-up Procedure
+
+Wrap-up can be initiated by the user ("まとめて", "終わり") or suggested by the skill at natural conversation boundaries ("他に議論したいことはありますか？なければ wrap-up に進められます"). The skill does not unilaterally enter wrap-up.
+
+### Steps
+
+1. **Memo batch write**: Present a list of memos captured as text during discussion. Let the user review — discard, keep, or adjust. Write accepted memos to DB:
+   ```sh
+   sd node create --kind memo --body "<memo content>" --tag "topic:<slug>"
+   ```
+
+2. **Conversation node creation**: Create a conversation node summarizing the session:
+   ```sh
+   sd node create --stdin <<'EOF'
+   {"kind":"conversation","body":"<session title>","properties":{"context":"...","key_points":[...],"open_questions":[...],"summary_en":"...","keywords_en":[...]},"tags":["topic:<slug>"]}
+   EOF
+   ```
+
+3. **Link decisions and memos to conversation**:
+   ```sh
+   sd link create <decision_id> <conversation_id> --type decided_during
+   sd link create <memo_id> <conversation_id> --type captured_during
+   ```
+
+4. **Optional memo promotion**: Ask "昇格したいメモはありますか？" If the user wants to promote memos to idea/todo:
+   ```sh
+   sd node update <memo_id> --kind idea --props-json '{"summary_en":"...","keywords_en":[...]}'
+   ```
+   Link promoted nodes: `sd link create <promoted_id> <conversation_id> --type derived_from`
+
+5. **Summarize**: Present the final state — conversation node + linked decisions + memos + promotions.
+
+## Skill Boundaries
+
+- **Don't force a fixed sequence of steps.** The conversation flow should emerge from the topic, not from a template.
+- **Don't make autonomous decisions about direction.** Always confirm with the user before narrowing the discussion.
+- **Don't produce detailed implementation plans.** That's what `/soda-plan` is for.
+- **Don't produce implementation artifacts — whether as file edits or as text output.** DB writes via `wat` CLI are discussion artifacts, not implementation artifacts — writing decisions and memos is expected. This boundary prohibits file-by-file change lists, detailed diffs, and step-by-step implementation instructions. Code snippets for illustrating design points are fine; framing them as actionable proposals is not. When the user is ready to implement, transition to `/soda-plan`.

package/dist/skills/soda-fix/body.md

@@ -0,0 +1,137 @@
+
+Review current branch changes using codex-review (findings mode), classify issues by severity, and apply fixes with appropriate user decision gates.
+
+Use English for internal reasoning (thinking). All user-facing output must be in Japanese.
+
+## Phase 1: Collect Changes
+
+1. Run `sd review detect-base-branch` and use the `baseBranch` and `mergeBase` from its JSON output. If the script fails, default to `main`. If the JSON contains an `error` field, present the error to the user and use AskUserQuestion: "ベースブランチを指定する" / "中止". If the user specifies a base branch, re-compute the diff using that base. If the user cancels, stop.
+2. Run `git diff <base>...HEAD` to collect the current branch's changes.
+3. If the diff is empty, inform the user and stop.
+4. Present a brief summary to the user:
+   > **変更概要**
+   > - 変更ファイル数: N
+   > - 追加行数: +X / 削除行数: -Y
+
+## Phase 2: Review via codex-review
+
+Invoke codex-review in findings mode:
+
+```
+Task(subagent_type: soda:codex-review)
+```
+
+Prompt:
+
+```
+## Codex Review Request
+- **Mode**: findings
+- **Instruction**: "Review these code changes. For each issue found, output in the following structured format:
+
+ISSUE
+Severity: Critical | High | Medium | Low
+Summary: <one-line description>
+File: <file path>
+Location: <line range or function name>
+Fix Strategy: <description of the suggested fix>
+Alternative: <alternative fix strategy, if applicable — omit if only one clear approach>
+---
+
+Focus on correctness, security, performance, and maintainability. Do not report style-only issues."
+
+### Content
+<git diff output>
+```
+
+If the codex-review sub-agent returns Status: "Skipped", inform the user that review is unavailable and stop.
+
+## Phase 3: Classify Issues
+
+Parse the codex-review output from the Issues section. For each issue, classify into one of three categories:
+
+- **Auto-fix**: Severity is Critical or High, AND the issue has a single clear fix strategy (no Alternative field, or Alternative is trivially equivalent)
+- **User-confirm**: Severity is Critical or High, AND one of:
+  - Multiple meaningfully different fix strategies exist (Alternative field present and distinct)
+  - The fix necessity itself is debatable (e.g., trade-off between correctness and performance)
+- **Skip**: Severity is Medium or Low
+
+**Fallback rule**: If the codex output cannot be parsed into the structured format above, treat ALL issues as User-confirm. Do NOT auto-fix unparseable findings.
+
+## Phase 4: Present Summary
+
+Present the classification summary to the user:
+
+> **レビュー結果**
+> - 自動修正: N件 (Critical/High, 修正方針が明確)
+> - 確認待ち: M件 (Critical/High, 複数の選択肢あり)
+> - スキップ: K件 (Medium/Low, 報告のみ)
+>
+> **スキップ対象の指摘** (Medium/Low):
+> - [issue summary] (file) — Severity
+> - ...
+
+Use AskUserQuestion with the following options:
+- "すべて進める" — Apply auto-fixes, then proceed to user-confirm issues one by one
+- "自動修正のみ先に適用" — Apply auto-fixes only, skip user-confirm issues
+- "すべて個別に確認" — Treat all issues (including auto-fix) as user-confirm
+- "中止" — Stop without making any changes
+
+If the user selects "中止", stop immediately.
+
+If the user selects "すべて進める", proceed to Phase 5, then Phase 6 for any remaining User-confirm issues.
+
+If the user selects "自動修正のみ先に適用", proceed to Phase 5, then skip Phase 6 and go directly to Phase 7.
+
+If the user selects "すべて個別に確認", reclassify all Auto-fix issues as User-confirm and proceed to Phase 6 (skip Phase 5).
+
+## Phase 5: Apply Auto-fixes
+
+For each Auto-fix issue (in file order to minimize conflicts):
+
+1. Read the target file.
+2. Apply the fix using the Edit tool.
+3. Commit with a descriptive message: `fix(<scope>): <issue summary>`
+
+If an edit fails (e.g., the target code has changed), skip the issue and add it to the User-confirm list with a note explaining the failure.
+
+After all auto-fixes are applied, follow the routing selected in Phase 4 (Phase 6 for "すべて進める", or Phase 7 for "自動修正のみ先に適用").
+
+## Phase 6: User Decision Gates
+
+For each User-confirm issue, present the issue details and use AskUserQuestion:
+
+> **指摘内容**: [issue summary]
+> **重要度**: [severity]
+> **ファイル**: [file path] ([location])
+> **詳細**: [full issue description from codex output]
+
+Options:
+- Each available fix strategy as a separate option (2-4 options max), with a brief description of the trade-off
+- "修正しない（スキップ）" — Skip this issue
+
+If the user selects a fix strategy:
+1. Read the target file.
+2. Apply the selected fix using the Edit tool.
+3. Commit: `fix(<scope>): <issue summary>`
+
+If the user selects "修正しない（スキップ）", move to the next issue.
+
+## Phase 7: Summary Report
+
+Present the final summary:
+
+> **修正結果**
+> - 自動修正: N件 適用済み
+> - ユーザー確認修正: M件 (適用: X, スキップ: Y)
+> - 未対応 (Medium/Low): K件
+
+Use AskUserQuestion:
+- "再レビューを実行" — Run codex-review (findings mode, fresh session) on the updated diff to verify fixes and check for new issues. If new issues are found, restart from Phase 3 with the new results.
+- "完了" — End the skill execution.
+
+## Constraints
+
+- This skill modifies code. Use Edit tool for precise changes, not Write tool for full file rewrites.
+- Each fix must be committed individually for easy revert.
+- Never auto-fix issues that cannot be parsed from the codex output (fallback rule).
+- All user-facing text must be in Japanese.