@whatasoda/agent-tools 0.1.0

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

@@ -0,0 +1,333 @@
+
+Create a detailed implementation plan for the given task.
+
+Use English for internal reasoning (thinking). Plan content (written to plan mode file) must be in English — use structured data, code snippets, and technical English for maximum AI interpretability and compaction resilience. User interaction (AskUserQuestion options, confirmation messages, investigation summaries presented before plan mode) must be in Japanese.
+
+If $ARGUMENTS is empty, ask the user what they want to implement before proceeding.
+
+## Procedure
+
+1. **Investigate**: Explore the codebase to understand the scope, affected areas, and existing patterns.
+   - **Design Decision check**: Before launching sub-agents, query existing decisions via `sd decision list --repo <owner/repo>` (detect owner/repo from git remote).
+     - If decisions found:
+       - Present the found decisions and ask the user which apply to this task (always confirm — some may be stale or unrelated)
+       - Extract decisions as **mandatory constraints** — every applicable decision must be traceable to a plan step
+       - Extract `rejected_alternatives` from each decision as **exclusion constraints** — approaches listed as rejected must not be re-proposed
+     - If no decisions found: proceed normally (conversation-context-based input)
+   - **Sub-agent output contract**: Every sub-agent prompt MUST end with the following output format requirement:
+       > Return findings in this exact format:
+       > ### Files
+       > - `path/to/file` — relevance to the task
+       > ### Patterns
+       > - pattern name — description of the convention or pattern found
+       > ### Dependencies
+       > - dependency — how it affects the task
+       > ### Open Questions
+       > - question — what remains unclear from this investigation alone
+     - Launch a sub-agent (Task, subagent_type: Explore) to survey project structure, dependencies, and conventions relevant to the task.
+     - Summarize the agent's findings into a Common Context block.
+     - Based on findings, optionally launch 1-2 focused sub-agents in parallel. Each prompt must include the Common Context block (summarized, not raw output), the specific investigation question, and both the constraint block and output contract.
+   - **Sub-agent prompt constraints**: Every sub-agent prompt (both survey and focused) MUST begin with the following constraint block:
+     > 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.
+   - Summarize investigation results before proceeding.
+   - If investigation reveals multiple fundamentally different approaches, use AskUserQuestion to let the user decide: "方針を調整して続行" / "ここで中断して方針を整理". Do not choose an approach autonomously.
+2. **Branch Strategy**: Use AskUserQuestion to determine branch strategy before planning:
+   - "新ブランチ作成"
+   - "現ブランチ続行"
+
+   If the user chooses a new branch, derive the branch name from the task description.
+   Do NOT proceed to Step 3 until the user confirms branch strategy.
+3. **Plan**:
+
+   **Technical Pre-Gathering (M/L tasks only)**: After task scale classification, if the task is scale M or L, pre-gather technical details before entering plan mode:
+   - Identify rough step areas from investigation findings (affected areas, key files, functional groupings)
+   - For each area (up to 3), launch a sub-agent (Task, subagent_type: Explore, model: sonnet) in parallel with the Step Detail Template below
+   - Sub-agent prompts must include the constraint block, the specific area to investigate, and the Step Detail Template
+   - Use gathered details to write the plan with concrete technical context (type signatures, API contracts, test patterns) rather than re-investigating during plan writing
+
+   **Step Detail Template**: When pre-gathering technical details for M/L tasks, each sub-agent prompt MUST end with the following output format:
+   > Return findings in this exact format:
+   > ### File State
+   > - `path/to/file` — current exports, key functions, line count
+   > ### Type Signatures
+   > - `TypeName` — definition (from source)
+   > ### API Contracts
+   > - endpoint/function — signature and behavior
+   > ### Test Patterns
+   > - test file — existing test patterns, coverage gaps
+   > ### Validation Approaches
+   > - (how to verify changes in this area)
+
+   Compose the plan content as markdown text (do not enter plan mode yet). Include the following elements. Do not follow a fixed template — organize and format them as best fits the task. Follow the Compact-Resilience Guidelines below when authoring plan content. After composition, proceed to the Codex Review sub-section before entering plan mode.
+
+   **Required elements:**
+   - **Task summary and branch name**
+   - **Investigation summary** — key findings, affected areas, relevant patterns discovered
+   - **Steps** — each step must include:
+     - Progress marker: `- [ ]` prefix (updated to `- [x]` during implementation as each step completes)
+     - Commit message (imperative mood)
+     - File changes with full paths and rationale (`path/to/file` — what and why)
+     - Validation criteria — how to verify this step is correct (test command, expected behavior, manual check)
+     - Dependencies on prior steps and what this step produces for later steps (do not rely on ordering alone)
+   - **Risks and mitigation** — at least one risk with a concrete mitigation strategy
+
+   **Conditional elements** (include when applicable):
+   - **Technical context per step** — type signatures, API contracts, data shapes, algorithms
+   - **Design rationale** — for non-obvious decisions, state "why" explicitly as a labeled callout, not embedded in prose
+   - **Cross-step shared context** — types, constants, or contracts used by multiple steps. Define once and reference by name in each step.
+   - **Subagent utilization plan** (include for scale M and L) — for each step, indicate whether it should be executed in a subagent or in the main context. See Subagent Criteria below for the decision rules.
+   - **Transition note** (include for scale L only) — note that execution transitions to `/soda-team-init` → `/soda-team-run`. The plan serves as input context for task decomposition. See Execution Phase for details.
+   - **Design decisions** (include when the plan involves architecture, external contracts, or user-facing behavior choices) — present each decision as a labeled callout in the plan body:
+     > **Design Decision: [topic]**
+     > Option A: ... — [trade-off]
+     > Option B: ... — [trade-off]
+     > Recommended: [option] — [rationale]
+
+     Design decisions are discussed individually during the Plan Discussion Phase before ExitPlanMode. If a decision significantly changes the plan structure, note this dependency explicitly.
+
+     Examples of decisions that require callouts:
+     - Architecture patterns (e.g., monolith vs microservice, event-driven vs request-response)
+     - Library or framework selection
+     - Data model design (schema, relationships)
+     - API contract design (endpoints, request/response shapes)
+     - State management approach
+     - Authentication/authorization strategy
+
+     Examples that do NOT require callouts (implementation details):
+     - Variable/function naming
+     - Internal helper structure
+     - Iteration order
+     - File organization within an already-decided architecture
+   - **Ambiguities** — if there are ambiguous requirements or missing information, note them as labeled callouts in the plan body rather than asking separately.
+
+### Codex Review (pre-plan-mode)
+
+Delegate codex review to a subagent in findings-only mode. The subagent reports issues but does NOT revise the content — the plan author incorporates findings to preserve original intent.
+
+1. Resolve session JSONL path (for context-aware review):
+   Run via Bash: `sd session resolve`
+   Capture stdout as session path. If empty, proceed without session context.
+
+2. Launch a codex review subagent:
+   - Tool: `Task(subagent_type: soda:codex-review)`
+   - Prompt: Include the review request with composed content.
+   - Review request:
+     ```
+     ## Codex Review Request
+     - **Mode**: findings
+     - **Instruction**: "Review this plan. Skip trivial issues — only flag critical problems"
+     - **Session Path**: <resolved session path from step 1, or omit if empty>
+
+     ### Content
+     [composed plan content]
+     ```
+3. Use the subagent's response:
+   - If **critical issues found**: read the `Issues` section and revise the plan in the main context to address them, preserving the original intent and voice.
+   - If **no critical issues**, **Status: Skipped**, or subagent failure: continue without changes.
+
+After the codex review completes, use the EnterPlanMode tool to enter plan mode. Write the reviewed plan content to the plan file. Proceed with the Plan Discussion Phase below, then exit plan mode via ExitPlanMode.
+
+## Plan Discussion Phase
+
+After writing the plan, extract **discussion items** — areas that benefit from interactive confirmation before implementation. Discussion items fall into two categories:
+
+- **Review points**: Steps where user domain knowledge would improve plan quality (business logic, unverified assumptions, context-dependent risks)
+- **Design decisions**: Choices presented as `**Design Decision: [topic]**` callouts in the plan
+
+### Procedure
+
+1. **Extract and present**: List all discussion items with their category and dependency relationships:
+
+   > **議論アイテム**: 以下の項目を順に確認します：
+   > 1. [category] Step N: {{description}}
+   > 2. [category] Step M: {{description}}
+   >
+   > 依存関係: Item 1 の結論が Item 2 の選択肢に影響します。
+
+   The user may reorder items or mark some as skip.
+
+2. **Discuss one at a time**: Present each item individually, following soda-discuss Interaction Principles (referenced from `/soda-discuss` SKILL.md — not duplicated here):
+
+   - **提示して委ねる**: Present context/options as text output, let the user respond freely
+   - **一度に一つ、承認を待つ**: Wait for the user's response before moving to the next item
+   - **選択肢には根拠と推奨を添える**: For design decisions, include tradeoffs and a recommendation
+   - **データが先、判断が後**: Present investigation data before asking for a decision
+   - **判断の保留は深掘りのシグナル**: If the user defers, provide deeper analysis before re-presenting
+
+   For each item type:
+   - **Review point**: Present the relevant plan section and what is uncertain → wait for domain knowledge
+   - **Design decision**: Present options, tradeoffs, and recommendation → wait for direction
+
+3. **Reflect conclusions**: After each item is resolved, immediately update the plan:
+   - Review point conclusions: mark as `**User Context**: {{correction or additional information}}`
+   - Design decision conclusions: update the callout to show the confirmed option
+
+   These labeled callouts ensure domain knowledge and decisions survive context compaction.
+
+4. **Handle emergent items**: If discussion reveals new items, add them to the list at the appropriate position based on dependency relationships.
+
+5. **Complete**: When all items are resolved (or the user signals readiness), proceed to ExitPlanMode.
+
+If no discussion items are identified, skip this phase and proceed directly to ExitPlanMode.
+
+## Execution Phase
+
+After plan approval (ExitPlanMode), execution routing depends on the task scale classification.
+
+### Scale S — Main Context
+
+Execute all steps in the main context sequentially. No worktree isolation or review cycle.
+
+### Scale M — Worker → Reviewer Core Loop
+
+Subagent-eligible steps are executed via `team-worker` → `team-reviewer` cycle on isolated worktrees. Main-context steps execute in the main context as before.
+
+**For each subagent-eligible step:**
+
+1. **Create worktree**:
+   ```bash
+   git worktree add .worktrees/step-{{N}} -b plan/step-{{N}} HEAD
+   ```
+
+2. **Launch Worker** via `Task(subagent_type: soda:team-worker)` with prompt:
+   ```
+   ## Task
+   ### Definition
+   {{step description and file changes from plan}}
+   ### Design Constraints
+   {{design decisions and constraints from plan, if any}}
+   ### Context
+   {{investigation summary and cross-step shared context from plan}}
+   ### Validation
+   {{validation criteria from plan step}}
+
+   ## Commit Message
+   {{commit message from plan step}}
+
+   ## Working Directory
+   {{worktree absolute path}}
+   ```
+
+3. **On Worker DONE** → launch Reviewer via `Task(subagent_type: soda:team-reviewer)`:
+   ```
+   ## Task Definition
+   {{same task sections as Worker input (Definition, Design Constraints, Context, Validation)}}
+   ## Working Directory
+   {{worktree path}}
+   ## Changes to Review
+   {{git diff of worktree branch vs base}}
+   ```
+
+   > **Why no `## Architecture Decisions`**: soda-plan context does not maintain ARCHITECTURE.md. Reviewer evaluates against the step's own Design Constraints and Validation criteria instead.
+
+4. **Handle verdict**:
+   - **PASS / PASS_WITH_FIX** → merge worktree branch to current branch, clean up:
+     ```bash
+     git checkout {{current_branch}}
+     git merge --squash plan/step-{{N}}
+     git commit -m "{{commit message}} (plan/step-{{N}})"
+     git worktree remove .worktrees/step-{{N}}
+     git branch -D plan/step-{{N}}
+     ```
+     **Merge conflict handling**: If merge fails due to conflicts:
+     ```bash
+     git reset --merge
+     ```
+     Report conflicting files to user via AskUserQuestion with options:
+     - "コンフリクトを手動で解決する" → user resolves, then resume
+     - "このステップをスキップ" → clean up worktree and branch:
+       ```bash
+       git worktree remove .worktrees/step-{{N}}
+       git branch -D plan/step-{{N}}
+       ```
+   - **FAIL** → append Reviewer's "For Next Worker" findings to the step's Context section, reset worktree to the base commit, retry Worker once:
+     ```bash
+     cd .worktrees/step-{{N}}
+     git clean -fd
+     git reset --hard {{current_branch}}
+     ```
+     > **Why `{{current_branch}}` not `~1`**: Worker may create multiple commits. Resetting to the branch the worktree was created from guarantees a clean slate, matching soda-team-run's pattern.
+
+     If second attempt also FAILs → report to user via AskUserQuestion with Reviewer findings and options:
+     - "実装を受け入れる" → merge worktree branch as-is (same as PASS flow)
+     - "このステップをスキップ" → clean up worktree and branch, skip this step:
+       ```bash
+       git worktree remove .worktrees/step-{{N}}
+       git branch -D plan/step-{{N}}
+       ```
+   - **ESCALATE** → report to user via AskUserQuestion with escalation details and options:
+     - "実装を受け入れる" → merge worktree branch as-is (same as PASS flow)
+     - "このステップをスキップ" → clean up worktree and branch, skip this step:
+       ```bash
+       git worktree remove .worktrees/step-{{N}}
+       git branch -D plan/step-{{N}}
+       ```
+
+5. **On Worker BLOCKED** → read BLOCKER.md from worktree root, report to user via AskUserQuestion.
+
+**Sequencing**: Subagent-eligible steps with no mutual dependencies may run in parallel (separate worktrees). Steps with dependencies execute sequentially — wait for the dependency to merge before creating the next worktree.
+
+### Scale L — Transition to /soda-team-init
+
+Scale L tasks are too large for soda-plan's inline execution. After plan approval, present transition guidance:
+
+> このタスクは規模が大きいため、`/soda-team-init` でタスク分解し `/soda-team-run` で実行することを推奨します。
+> プランの内容を `/soda-team-init` の入力コンテキストとして活用できます。
+
+Do NOT execute implementation inline. The approved plan serves as input context for `/soda-team-init`.
+
+## Constraints
+
+- Do NOT begin implementation until the user approves the plan.
+- Branch strategy is determined by the user in Step 2 (Branch Strategy). If the user chooses a new branch, create it from the current branch unless a different base is specified.
+- The plan must include incremental commits throughout the work.
+- The plan must be self-contained: include enough technical context (as code snippets and structured data, not prose) that implementation can proceed from the plan alone, even after context compaction.
+- Each step must define a commit with an imperative-mood message, explicit dependencies on prior steps, and validation criteria.
+- The plan must identify at least one risk and its mitigation.
+- Design decisions must be presented as labeled callouts in the plan body. Each decision is discussed individually during the Plan Discussion Phase before ExitPlanMode.
+- During implementation, update the plan's step markers from `- [ ]` to `- [x]` as each step's commit is completed. This provides at-a-glance progress visibility.
+- If design decisions are loaded from the DB, all applicable decisions must be reflected in plan steps. Each step that implements a decision must reference it by name. Rejected alternatives from each decision must not be re-proposed as approaches.
+
+## Compact-Resilience Guidelines
+
+Plans must survive context compaction. Follow these rules when authoring plan content:
+
+- **Explicit dependency chains**: State what each step depends on and produces. Do not rely on step ordering alone — ordering is lost during compaction.
+- **Code over prose**: Prefer code snippets and structured data (`interface Foo { bar: string }`) over prose descriptions ("Foo has a bar field of type string"). Code survives intact; prose gets summarized away.
+- **Labeled callouts**: State design rationale as "Why: ..." callouts, not embedded in paragraphs. Labeled callouts are retained as structure; prose rationale is dropped.
+
+## Subagent Criteria
+
+When executing the approved plan, use subagents (Task tool) for steps that meet ALL of the following:
+
+1. **Self-contained** — The step does not need to read results from a prior step's execution at runtime. All inputs are defined in the plan (file paths, type signatures, expected behavior).
+2. **No cross-step file conflicts** — The step does not modify files that a concurrent step also modifies.
+3. **Verifiable in isolation** — The step has validation criteria that can be checked without running the full application or depending on other steps' output.
+
+Use the main context for steps that:
+- Depend on runtime output from a prior step (e.g., "adjust based on test results from Step 2")
+- Modify shared files (e.g., a central config, shared type file) that other steps also touch
+- Require iterative adjustment based on integration feedback
+- Are the final integration or verification step
+
+When the plan includes a subagent utilization plan, annotate each step with one of:
+- **Subagent-eligible** — meets all three criteria above
+- **Main-context** — state which criterion is not met
+
+## Task Scale Classification
+
+Immediately after investigation (Step 1) completes, classify the task scale based on investigation results. The classification determines which conditional elements to include and how execution is routed.
+
+**Classification criteria** (use the first matching category):
+
+- **S (Small)** — 1-3 steps, no cross-step dependencies beyond sequential ordering
+  - Subagent utilization plan: omit (no benefit from subagent overhead)
+  - Execution method: main context (see Execution Phase)
+- **M (Medium)** — 4-6 steps, fewer than 2 independent subtrees in the dependency graph
+  - Subagent utilization plan: include (per-step annotation as before)
+  - Execution method: Worker → Reviewer core loop for subagent-eligible steps (see Execution Phase)
+- **L (Large)** — 7+ steps, OR 4+ steps with 2+ independent subtrees in the dependency graph
+  - Subagent utilization plan: include (per-step annotation)
+  - Execution method: transition to `/soda-team-init` → `/soda-team-run` (see Execution Phase)
+
+State the classification at the top of the plan body: `**Task Scale: [S|M|L]**`

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

@@ -0,0 +1,127 @@
+
+Perform deep, structured codebase research on the given topic and produce a reusable Research Summary artifact.
+
+Use English for internal reasoning (thinking). All user-facing output — topic framing, findings presentation, and AskUserQuestion options — must be in Japanese. The Research Summary block must use the exact English template format for downstream compatibility.
+
+If $ARGUMENTS is empty, ask the user what they want to research before proceeding.
+
+## Procedure
+
+### Step 1: Topic Framing
+
+Restate the research topic described in $ARGUMENTS. Identify:
+
+- **Research scope**: What specific areas of the codebase to investigate (files, patterns, architecture, dependencies)
+- **Research questions**: 2-3 concrete questions this research should answer
+- **Expected output**: What kind of understanding the user needs (architecture overview, dependency mapping, pattern discovery, implementation details)
+
+Present this framing briefly. Do NOT use AskUserQuestion — proceed directly to Step 2.
+
+### Step 2: Investigation
+
+**Sub-agent prompt constraints**: Every sub-agent prompt MUST begin with the following constraint block:
+> 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 the following output format requirement:
+> 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
+
+#### Round 1: Survey
+
+Launch a sub-agent (Task, subagent_type: Explore) with a prompt that includes the constraint block, then:
+- The research topic and scope from Step 1
+- Instruction to survey: project structure, key files, dependencies, and conventions related to the topic
+- The output contract
+
+Synthesize the agent's findings into a Common Context block.
+
+#### Round 2: Focused Investigation
+
+Based on Round 1 findings, launch 1-2 focused sub-agents in parallel (Task, subagent_type: Explore). Each prompt must include:
+1. The constraint block
+2. The Common Context block from Round 1 (summarized, not raw output)
+3. A specific research question from Step 1 or a new question that emerged from Round 1
+4. The output contract
+
+### Step 3: Findings Presentation
+
+Synthesize all investigation results into a structured findings report. Organize by theme (not by agent). Present in Japanese:
+
+- **主要な発見**: Key discoveries with file paths and specific code references (`path/to/file:L42-L78`)
+- **パターンと規約**: Patterns and conventions found in the codebase
+- **アーキテクチャと依存関係**: Architecture relationships, dependency chains, data flow
+- **未解決の疑問**: Open questions and areas of uncertainty
+- **調査範囲**: What was covered and what was not
+
+### Step 4: Annotation Cycle
+
+This is the core differentiator of this skill — iterative refinement through user feedback, inspired by Boris Tane's annotation-driven workflow. Optimal depth is typically 2-3 rounds, but there is no hard limit.
+
+Use AskUserQuestion:
+- "特定の領域をさらに深掘り" — user specifies what to investigate more deeply
+- "この理解に補足・修正を加える" — user provides domain knowledge corrections or additions
+- "別の角度から調査" — pivot the investigation to a different perspective
+- "十分理解できた（Research Summary を出力）" — finalize and emit Research Summary
+
+**If "特定の領域をさらに深掘り"**: Ask the user which area to investigate. Launch 1 focused sub-agent with the accumulated context and the user's direction. Present additional findings, then return to this AskUserQuestion.
+
+**If "この理解に補足・修正を加える"**: Accept the user's free-text input. Record it as domain knowledge. Revise any affected findings to reflect the correction. Present the updated findings, then return to this AskUserQuestion.
+
+**If "別の角度から調査"**: Ask the user what angle to take. Launch 1 sub-agent with the new perspective. Present findings from the new angle alongside existing findings, then return to this AskUserQuestion.
+
+**If "十分理解できた"**: Proceed to Step 5.
+
+### Step 5: Research Summary
+
+Emit the following structured handoff block. This enables same-session chaining to `/soda-discuss` or `/soda-plan`.
+
+```
+## Research Summary
+
+**Topic**: (one-sentence research question)
+**Scope**: (what areas were investigated)
+
+### Key Findings
+- `path/to/file` — (discovery with specific details)
+- (pattern or convention found)
+
+### Architecture & Dependencies
+- (relationship discovered)
+- (dependency chain)
+
+### Code References
+- `path/to/file:L42-L78` — (what this code does and why it matters)
+
+### Open Questions
+- (unresolved question that could not be answered from code alone)
+
+### Domain Knowledge
+- (corrections or additions provided by user during annotation cycle)
+(omit this section if no user annotations were provided)
+```
+
+Then print next steps:
+
+```
+Research complete:
+- Research Summary emitted for handoff
+
+Next:
+  /soda-discuss — Discuss direction and explore approaches using this research
+  /soda-plan — Plan implementation directly using this research
+```
+
+## Constraints
+
+- This skill only investigates. Do NOT modify any code.
+- Do NOT enter plan mode (no EnterPlanMode).
+- The Research Summary block format should be stable — downstream skills use it as conversation context.
+- Findings presentation must be organized by theme, not by agent. Merge and deduplicate findings across agents.
+- Domain Knowledge entries from user annotations are authoritative — they override investigation findings when there is a conflict.

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

@@ -0,0 +1,165 @@
+
+Review branch changes for design conformance — checking implementation against Design Decisions (DD-N) from Living Discussion Documents and detecting implicit design decisions introduced during implementation.
+
+Use English for internal reasoning (thinking). All user-facing output must be in Japanese.
+
+## Current Branch Context
+
+!`sd review detect-base-branch`
+
+The above JSON provides `baseBranch`, `mergeBase`, `changedFiles`, `potentialConflicts`, and ready-to-use `commands.diff` / `commands.log`.
+
+If $ARGUMENTS is not empty, treat it as the review focus or an alternative base branch specification. When an alternative base is specified, re-compute the diff using that base instead of the detected one.
+
+## Procedure
+
+1. **Identify the diff**: Use the pre-fetched branch context JSON above. Run `commands.diff` to get the full diff. If $ARGUMENTS specifies a different base, re-compute the merge-base and diff accordingly. If the JSON contains an `error` field, present the error to the user and use AskUserQuestion: "別のベースブランチを指定" / "レビューを中止". If the diff is empty, inform the user and use AskUserQuestion: "別のベースブランチを指定" / "レビューを終了".
+
+2. **Load design decisions**: Query `sd decision list --repo <owner/repo>` (detect owner/repo from git remote).
+   - **If decisions found**: Present the found decisions and use AskUserQuestion to ask which apply to this review. Extract:
+     - Decision constraints as **verification targets**
+     - `rejected_alternatives` as **exclusion reference** (for context, not verification)
+   - **If no decisions found** (degraded mode): Note that no design decisions exist. Skip decision verification in step 4. The implicit decision detection agent will run in discovery mode — identifying all non-trivial design judgments as formalization candidates rather than checking against a baseline.
+
+3. **Prepare diff content**: Run `commands.diff` via Bash and capture the full diff output.
+
+4. **Launch conformance check sub-agents**: Launch two sub-agents in parallel using Task tool. Both sub-agent prompts MUST begin with the standard constraint block.
+
+   **Sub-agent A — DD Verification Agent** (skip if no-decisions mode):
+   ```
+   Task(subagent_type: Explore)
+   ```
+   Prompt structure:
+   > 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.
+   >
+   > ## Task
+   > Verify whether the following Design Decisions (DD-N) from a Living Discussion Document are satisfied by the implementation changes in the diff below.
+   >
+   > For each DD-N, determine:
+   > - **SATISFIED**: The implementation clearly fulfills the constraint
+   > - **VIOLATED**: The implementation contradicts or fails to implement the constraint
+   > - **UNCLEAR**: Cannot determine from the diff alone (may need broader codebase context)
+   >
+   > When checking, read the actual source files (not just the diff) to understand the full implementation context. The diff shows what changed, but the constraint may be about the resulting state.
+   >
+   > ## Design Decisions
+   > {{extracted DD-N entries with full Constraint/Why/Scope text}}
+   >
+   > ## Diff
+   > {{full diff output}}
+   >
+   > Return findings in this exact format:
+   > ### DD Verification
+   > - **DD-N**: {{SATISFIED | VIOLATED | UNCLEAR}} — {{evidence with file:line references}}
+   > ### Violation Details
+   > - **DD-N**: {{what was required}} vs {{what was found}} — {{file:line}}
+   > ### Notes
+   > - {{any additional context or caveats}}
+
+   **Sub-agent B — Implicit Decision Detection Agent**:
+   ```
+   Task(subagent_type: Explore)
+   ```
+   Prompt structure:
+   > 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.
+   >
+   > ## Task
+   > Examine the following diff and identify design decisions that were made during implementation. A "design decision" is a non-trivial judgment about architecture, data modeling, API shape, error handling strategy, or behavioral semantics — NOT routine implementation details like variable naming, loop structure, or formatting.
+   >
+   > Examples of design decisions to detect:
+   > - Introducing a new data structure or type that defines a contract
+   > - Choosing an error handling strategy (throw vs return vs union type)
+   > - Defining an API shape (function signatures, parameter types, return types)
+   > - Selecting an architectural pattern (observer, middleware, pipeline)
+   > - Adding a new dependency or integration point
+   >
+   > Examples of routine implementation details to SKIP:
+   > - Variable/function naming choices
+   > - Import ordering
+   > - Iteration approach (for vs map vs reduce)
+   > - Formatting and style
+   > - Adding type annotations to existing code
+   >
+   > {{IF DD-N entries available}}
+   > The following Design Decisions are already recorded. Only report decisions NOT covered by these entries:
+   > {{DD-N list with Constraint text}}
+   > {{ELSE}}
+   > No prior Design Decisions are recorded. Report all non-trivial design judgments found in the diff as candidates for formalization.
+   > {{END}}
+   >
+   > ## Diff
+   > {{full diff output}}
+   >
+   > Return findings in this exact format:
+   > ### Implicit Design Decisions
+   > - **[file:line]** {{decision description}} — {{why this is a design decision, not routine implementation}}
+   > ### Formalization Candidates
+   > - {{which of the above should be recorded as formal DD entries, and why}}
+   > ### Notes
+   > - {{any additional context}}
+
+5. **Integrate results**: Combine both sub-agent outputs into a unified conformance report.
+
+6. **Present report**: Output the conformance report to the user in the format specified below.
+
+7. **Next steps**: Use AskUserQuestion with context-dependent options:
+   - If violations found:
+     - "違反箇所の修正をプランする" (suggest `/soda-plan`)
+     - "DD を実装に合わせて更新する"
+     - "メモして後で対応"
+   - If implicit decisions found but no violations:
+     - "暗黙の判断を DD として記録する"
+     - "問題なし、このまま進める"
+   - If clean (no violations, no implicit decisions):
+     - "設計適合性に問題なし"
+     - "別の観点でレビュー"
+
+## Report Format
+
+```
+## 設計適合性レポート
+
+### 対象
+- ブランチ: {{branch name}}
+- ベース: {{base branch}} ({{merge-base commit}})
+- 参照: {{selected design decisions, or "なし (探索モード)"}}
+
+### DD 検証結果
+| DD | 制約 | 判定 | 根拠 |
+|---|---|---|---|
+| DD-N | {{constraint summary}} | SATISFIED / VIOLATED / UNCLEAR | {{file:line — evidence}} |
+
+### DD 違反の詳細
+{{For each VIOLATED DD:}}
+#### DD-N: {{name}}
+- **制約**: {{what was required}}
+- **実装**: {{what was found}} ({{file:line}})
+- **推奨対応**: 実装を修正 / DD を更新
+
+### 暗黙の設計判断
+| # | ファイル | 判断内容 | DD化推奨 |
+|---|---|---|---|
+| 1 | {{file:line}} | {{description}} | Yes / No |
+
+### サマリー
+- DD 検証: {{N}} 件中 {{satisfied}} 件適合、{{violated}} 件違反、{{unclear}} 件不明
+- 暗黙の設計判断: {{N}} 件検出 (うち {{M}} 件 DD 化推奨)
+```
+
+When in no-decisions mode (no Living Discussion Document), omit the "DD 検証結果" and "DD 違反の詳細" sections and update the summary. Replace with:
+
+```
+### DD 検証結果
+Living Discussion Document が見つからないため、DD 検証はスキップしました。
+暗黙の設計判断の探索のみ実行しています。
+
+### サマリー
+- DD 検証: スキップ (Living Discussion Document なし)
+- 暗黙の設計判断: {{N}} 件検出 (うち {{M}} 件 DD 化推奨)
+```
+
+## Constraints
+
+- **Report only** — do NOT modify any code or files. If a fix is needed, suggest a direction but do not apply it.
+- **No code quality review** — this skill focuses exclusively on design conformance. Code quality concerns (bugs, style, performance) are handled by `/soda-fix` and manual review.
+- Sub-agent prompts MUST begin with: "You are a research-only agent. Do NOT use AskUserQuestion, EnterPlanMode, or any interactive/planning tools."

package/dist/skills/soda-review-todos/body.md

@@ -0,0 +1,19 @@
+
+## Available CLI Commands (wat)
+
+| Command | Description |
+|---|---|
+| `sd node search` | Search nodes with `--query`, `--kind`, `--tags`, `--limit`, `--offset` |
+| `sd node update <id>` | Update a node's `--body`, `--kind`, `--prop`, `--props-json`, or via `--stdin` |
+| `sd node get <id>` | Retrieve a node with all its relations (tags, links) |
+| `sd list kinds` | List all node kinds with counts |
+
+## Instructions
+1. Fetch all TODOs: `sd node search --kind todo`
+2. If tags provided, filter: `sd node search --kind todo --tags <tag1>,<tag2>`
+3. Present TODOs grouped by status (pending → in_progress → done)
+4. For each pending TODO, discuss with user:
+   - Priority assessment (suggest based on deadlines, dependencies)
+   - Status update if needed → `sd node update <id> --prop status=in_progress --prop priority=high`
+5. Identify blocked or stale TODOs
+6. Summarize changes made