npm - @shinaps/skills - Versions diffs - 0.15.0 → 0.16.0 - Mend

@shinaps/skills 0.15.0 → 0.16.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (21) hide show

package/README.md CHANGED Viewed

@@ -20,12 +20,11 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
 | `extract-rules` | PRレビューからruleを抽出する |
 | `simplify` | 目的から見直して不要な構造や手順を削る |
-| `verify-ui` | 対象環境の実画面で見た目・操作を確かめる |
 | `commit` | 開始時に通常（推奨）・自律を確認し、検証できる単位へ分けてコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
-`dev` は簡素化を適用した後の差分をレビューする。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
+Claude版の `dev` は実装後にレビュー・規約照合・簡素化の提案を並行して集め、全結果を同じ architect が統合して実装担当へ修正を依頼する。実装後のレビューは最大2ラウンドで終了する。コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 ## Claude Code
@@ -140,7 +139,7 @@ codex mcp add shinaps-ai --url https://app.shinaps.ai/mcp
 codex mcp login shinaps-ai
 ```
-未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`verify-ui`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
+未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release` の基本手順はMCP接続を必須としない。
 ## Subagents (Claude: 15 / Codex: 13)
@@ -148,7 +147,7 @@ codex mcp login shinaps-ai
 |---|---|
 | `shinaps-explorer` | コードベース探索、必読ファイル抽出 |
 | `shinaps-investigator` | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
-| `shinaps-architect` | 設計。Claude版では実装後に再開し、設計適合性もレビュー |
+| `shinaps-architect` | 設計。Claude版では同じ担当がプラン統合・実装レビュー・全指摘の統合を行う |
 | `shinaps-plan-reviewer` | 計画レビュー (confidence 閾値 70)。Claude版はOpus 2体が独立して指摘と修正案を返す |
 | `shinaps-implementer` (Claudeのみ) | 確定した計画の実装・簡素化・検証、レビュー後の修正 (Opus) |
 | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80) |
@@ -164,15 +163,41 @@ codex mcp login shinaps-ai
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
-Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect は `best / high`、プランレビューは `opus / high` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / high`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。
+Claude版の `dev` は、委託が許可されている場合に `shinaps-implementer` 1体へ実装と修正を渡す。architect は `best / medium`、プランレビューは `opus / medium` 2体、実装担当は `opus / medium` を使う。実装後は同じ architect の設計適合性レビューと、独立した reviewer (`opus / medium`) のコードレビューを並行して行い、両者の結果が揃ってから修正する。
-Claude版の `dev` は `simplify`・`refine` と必要な `verify-ui` を Skill ツールで明示的に呼ぶ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。提案・指摘を統合してから実装担当が修正する。メインは仕様判断・進行管理と実際の差分・検証結果の確認を担う。
+Claude版の `dev` は `review` (開発レビュー)・`refine`・`simplify` を Skill ツールで明示的に呼び、担当のバックグラウンド起動後に全結果を待つ。`simplify` と `refine` はそれぞれ Opus / medium の2体で同じ対象を独立して確認する。architect が提案・指摘を根拠から統合し、実装担当へ一つの修正指示を返す。メインは起動・待機・記録とユーザーへの確認を担う。実装後のレビューは初回と修正後の最大2ラウンドとし、2回目の修正後はテスト結果と残課題を報告する。最終修正が再レビューされていないことを明示し、重大な未解決事項を完了扱いにしない。UIレビューは別途Codex側で行う。
 Codex版は親モデルを継承する既存の構成を維持し、Claude専用の実装・簡素化担当は追加しない。
 **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
+## Claude版 dev の流れ
+全エージェントの effort は medium。architect は保持したIDで再開し、実装中は新しい作業を依頼しない。
+```mermaid
+flowchart TD
+    A["architect: best / medium<br/>設計・実装計画"] --> B["プランレビュー: Opus / medium × 2"]
+    B --> C["同じ architect が統合・計画確定"]
+    C --> D["implementer: Opus / medium<br/>実装・テスト"]
+    D --> E["同じ差分でレビュー開始"]
+    E --> F["同じ architect: 設計適合性"]
+    E --> G["review: Opus / medium × 1"]
+    E --> H["refine: Opus / medium × 2"]
+    E --> I["simplify: Opus / medium × 2"]
+    F --> J["同じ architect が全指摘を統合"]
+    G --> J
+    H --> J
+    I --> J
+    J --> K{"修正が必要？"}
+    K -- いいえ --> N["検証結果・残課題を報告"]
+    K -- はい --> L["同じ implementer が修正・テスト"]
+    L --> M{"レビューを2回実施した？"}
+    M -- まだ1回 --> E
+    M -- 2回済み --> N
+```
 ## 作業成果物
 作業記録はプロジェクトルートの `.shinaps/work/` に保存する。初回作成時に `.shinaps/.gitignore` を内容 `*` と改行で作成する。既存のignoreは保持し、必要な場合だけ `*` を追記する。これによりignore自身を含む配下の未追跡ファイルが除外され、ユーザーによるグローバルignoreやプロジェクトルートのignore設定は不要になる。追跡済みファイルには効かないため、無断で追跡解除せず報告する。

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

package/plugins/shinaps-claude/.claude-plugin/plugin.json CHANGED Viewed

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
-  "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・UI検証・レビュー・コミット・PR・リリースを支援する12スキル。",
-  "version": "0.15.0",
+  "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースを支援する11スキル。",
+  "version": "0.16.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

package/plugins/shinaps-claude/agents/shinaps-architect.md CHANGED Viewed

@@ -1,14 +1,16 @@
 ---
 name: shinaps-architect
-description: shinaps:dev の設計を担当し、実装後は同じ担当を再開して確定した計画・受入条件と実際のコードの整合性をレビューする
+description: shinaps:dev の設計・プラン指摘の統合・実装レビュー・全指摘の統合を同じ担当として行い、implementer への実装・修正指示を返す
 model: best
-effort: high
+effort: medium
 color: green
 ---
 あなたは `/shinaps:dev` の設計担当です。メインから指定された工程に従います。
 - **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。
+- **プラン統合時**: 2体のプランレビュー指摘を根拠から検証し、採否と修正版の最終計画を返す。
+- **指摘統合時**: 自分の実装レビュー完了後に全担当の結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
 - **実装レビュー時**: 下記の「実装レビュー」に従い、計画の再作成ではなく実際のコードとの整合性を検証する。
 ## 作業前の必須確認
@@ -48,15 +50,27 @@ color: green
 - 自分の初回案ではなく、プランレビュー後に確定した `plan.md` と、その後に合意された変更を基準にする。メインから渡された受入条件、実装報告、差分、検証結果と、現在のコードを読む。
 - 受入条件・責務分割・データフロー・外部契約が実装と検証で満たされているかを確認する。形式的に計画と異なるだけでは不具合扱いにせず、具体的な影響を示す。
 - 設計自体に欠陥があれば、自分の設計を正当化せず、設計側の問題として根拠と修正案を返す。仕様変更の判断はメインへ返す。
-- 独立 reviewer の今回のレポートは読まず、意見を交換しない。コードの正しさ・安全性などの独立レビューは別担当が行う。
+- 自分の実装レビューを返すまでは、今回の reviewer / refine / simplify の結果を読まず、意見を交換しない。自分の結果を確定した後、全担当が完了してから指摘統合へ進む。
 - 総合判定と Critical / Warning / Info、各指摘の計画節・コードの file:line・影響・修正案、確認済みと未確認の受入条件を返す。指摘がなければその旨を示す。
 - 再レビューでは修正後の実装と合意済みの最新計画を確認する。コードや計画は編集しない。
+## 全指摘の統合
+メインから「指摘統合」として、自分のレビュー、独立 reviewer、refine 2体、simplify 2体の全結果と最新の差分・検証結果を受け取る。
+- 各指摘・提案を要件・コード・規約と照合する。重複をまとめ、対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
+- すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
+- 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を起動しない。
+- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、権限や対象範囲の拡大が必要な判断だけ、理由と推奨案をメインへ返してユーザーに確認してもらう。
+- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
+コード編集とエージェント起動は行わない。メインがあなたの指示を implementer へ渡し、結果を保存する。
 ## 動作原則
 - **規約絶対遵守**: CLAUDE.md / rule カタログを最優先
 - **断言する**: 「〜が良いと思います」ではなく「〜にする」
 - **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
 - **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **設計時は一つの推奨案を出す**: 実装レビュー時は根拠付きの指摘を返す
+- **工程に合わせて返す**: 設計・プラン統合時は最終計画、実装レビュー時は根拠付き指摘、指摘統合時は採否と実装担当への修正指示
 - **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される

package/plugins/shinaps-claude/agents/shinaps-debug-validator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-debug-validator
 description: shinaps:debug 専用の仮説検証エージェント。shinaps-debugger の仮説を実コードと照合し、root-cause / contributing-factor / red-herring / needs-reproduction に分類する。修正方針は対症療法を排除し、根本解決を提示する
 model: opus
-effort: high
+effort: medium
 color: gray
 ---

package/plugins/shinaps-claude/agents/shinaps-debugger.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-debugger
 description: shinaps:debug 専用の根本原因調査エージェント。症状からコードを追跡し、WebSearch / GitHub Issue 検索で外部情報を収集し、根本原因の仮説を立案する。既存の調査・実装成果物と rule カタログを踏まえて仮説候補を予選する
 model: opus
-effort: high
+effort: medium
 color: magenta
 ---

package/plugins/shinaps-claude/agents/shinaps-investigator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-investigator
 description: shinaps:explore の各質問ラウンドで起動される read-only 調査エージェント。人間の現在の疑問に絞ってコード、テスト、設定、git history、必要な公式情報を辿り、confirmed / inference / unknown を分離した根拠付き回答と次に有効な質問候補を返す
 model: opus
-effort: high
+effort: medium
 color: blue
 ---

package/plugins/shinaps-claude/agents/shinaps-plan-reviewer.md CHANGED Viewed

@@ -2,12 +2,12 @@
 name: shinaps-plan-reviewer
 description: shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、独立した指摘と具体的な修正案を返す。2体で同じ計画を別々に検証する
 model: opus
-effort: high
+effort: medium
 color: purple
 ---
 あなたは `/shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。
-`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。メインが両者の指摘を統合して最終計画を保存します。
+`shinaps-architect` の計画を独立して検証し、Critical / Warning / Info の指摘と具体的な修正案を返してください。同じ計画をレビューする他の担当のレポートは読まず、意見を交換しません。設計担当の architect が両者の指摘を統合し、メインが最終計画を保存します。
 ## 作業前の必須確認

package/plugins/shinaps-claude/agents/shinaps-review-validator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-review-validator
 description: shinaps:review 専用のレビュー妥当性検証エージェント。shinaps-reviewer の指摘を受け取り、該当コードを実際に Read して事実確認・妥当性検証を行う。false positive を排除し、見落としを追加発見する
 model: opus
-effort: high
+effort: medium
 color: orange
 ---

package/plugins/shinaps-claude/agents/shinaps-reviewer.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-reviewer
 description: shinaps:dev のセルフレビューおよび shinaps:review の一次レビューを担当。実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的にレビューし、Critical / Warning / Info で報告する
 model: opus
-effort: high
+effort: medium
 color: red
 ---

package/plugins/shinaps-claude/agents/shinaps-split-reviewer.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-split-reviewer
 description: shinaps:commit の Step 1 で起動される分割計画レビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない
 model: opus
-effort: high
+effort: medium
 color: blue
 ---

package/plugins/shinaps-claude/agents/shinaps-survey-validator.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-survey-validator
 description: shinaps-tech-surveyor のレポートを受け取り、出典 URL を WebFetch で再確認しながら情報の鮮度・出典の妥当性・主張の正確性を検証する。CLAUDE.md / rule カタログに反する候補は Critical で報告する
 model: opus
-effort: high
+effort: medium
 color: yellow
 ---

package/plugins/shinaps-claude/agents/shinaps-tech-surveyor.md CHANGED Viewed

@@ -2,7 +2,7 @@
 name: shinaps-tech-surveyor
 description: shinaps:spec / shinaps:review / shinaps:debug で共有利用される外部技術調査エージェント。WebSearch / WebFetch で最新情報を集め、ライブラリ・フレームワーク・サービスを観点別に比較する一次レポートを作成する。既存スタック規約と rule カタログとの整合性を必ず評価対象に含める
 model: opus
-effort: high
+effort: medium
 color: teal
 ---

package/plugins/shinaps-claude/skills/dev/SKILL.md CHANGED Viewed

@@ -32,12 +32,12 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 | エージェント | subagent_type | 役割 |
 |---|---|---|
 | Shinaps Explorer | `shinaps-explorer` | コードベース探索、必読ファイル抽出 (spec / explore の事前調査が十分なら再起動しない) |
-| Shinaps Architect | `shinaps-architect` | 設計を担当し、実装後は再開して設計適合性をレビュー |
+| Shinaps Architect | `shinaps-architect` | 設計・プラン統合・設計適合性レビュー・全指摘の統合を担当 |
 | Shinaps Plan Reviewer | `shinaps-plan-reviewer` | Opus 2体で同じ計画を独立レビューし、指摘と修正案を返す |
 | Shinaps Implementer | `shinaps-implementer` | 確定した計画の実装・検証と、レビュー後に決まった修正 (Opus) |
 | Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点でレビュー |
-委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、メインは仕様判断・進行管理・成果物の確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
+委託が許可されている場合、実装と修正は **`shinaps-implementer` (Opus) 1 体**が担当し、architect が設計判断と全指摘の統合を担い、メインはスキル呼び出し・エージェントの起動と再開・待機・記録・ユーザーへの確認を担う。設計判断を実装へ引き継ぎつつモデルの利用を分けるため、確定した計画・判断理由・規約を実装担当へ渡す。委託不可またはエージェントを利用できない場合はメインが担当し、その旨を報告する。
 ## ディレクトリ規約
@@ -109,7 +109,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 ### Phase 3: 実装ブループリント策定
-`shinaps-architect` を 1 体起動。実装レビューで同じ担当を再開できるよう、応答時のエージェントIDを保持する。
+`shinaps-architect` を 1 体起動。応答時のエージェントIDを保持し、プラン統合・実装レビュー・指摘統合で同じ担当を再開する。implementer が作業する間もIDと文脈を保持し、architect を破棄しない。再開できない場合だけ設計判断・最新計画・過去の指摘と採否を後任に引き継ぎ、その旨を記録する。
 **プロンプトに含める情報**:
 - タスク内容
@@ -121,7 +121,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 ### Phase 4: プランレビュー
-委託が許可されている場合、`shinaps-plan-reviewer` (Opus / high) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
+委託が許可されている場合、`shinaps-plan-reviewer` (Opus / medium) を **2体並列**で起動し、両者へ同じ情報を渡す。起動時にモデルを上書きしない。同時実行枠が不足する場合は順次起動し、2体分の独立した結果を揃える。
 - タスクの目的・受入条件、Phase 2 の調査結果と rule 全文
 - Phase 3 の architect 案全文 (再策定時は最新案)
@@ -129,7 +129,7 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 両者の完了までは対象の計画を変更しない。メインは結果を `raw/plan-review-{round}-1.md` と `raw/plan-review-{round}-2.md` に保存する (round は 1 始まり)。片方が失敗・未完了なら2体で検証済みと扱わず、未完了分を完了させてから統合する。
-メインが各指摘を要件・コード・規約と照合し、重複をまとめる。多数決では判断せず、採否と根拠を記録する。採用した修正を architect 案に反映し、単一の最終 `plan.md` を保存する。仕様判断や設計の対立が既存の合意で解決できない場合はユーザーへ一問ずつ確認する。
+メインが同じ architect を「プラン統合」として再開し、2体の全指摘を渡す。architect が根拠を検証して重複・対立を整理し、採否と修正版の最終計画を返す。メインは結果を保存し、単一の `plan.md` を確定する。architect が仕様判断や範囲拡大の相談を返した場合だけ、メインがユーザーへ一問ずつ確認して決定を戻す。
 差し戻しがある場合は、その根拠を検証し、必要な再策定を同じ architect に依頼する。修正版を `raw/architect-revised-{n}.md` に保存し、2体とも同じ修正版を改めてレビューする。採用した Critical / Warning が計画に反映され、未解決の判断がなくなってから Phase 5 へ進む。委託不可の場合はメインが同じ観点で確認し、独立レビュー未実施と明記する。
@@ -166,58 +166,47 @@ Phase 1 で読んだ成果物と同ディレクトリの raw report を取り込
 - 実行した検証コマンドと結果、未実施の確認
 - 残課題・規約衝突・未解決の論点
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UI変更の実画面確認は簡素化の適用後に Phase 6 の `verify-ui` 呼び出しで行う。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
+必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの開発フローとは別に Codex 側で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
-### Phase 6: 簡素化後のセルフレビュー + refine
+### Phase 6: review・refine・simplify を並行実行
-`Skill(skill="shinaps:simplify", args="提案のみ。対象・目的・受入条件・最終 plan・規約・現在の差分を参照し、2体の独立した提案を統合して返す")` を呼ぶ。引数には今回の具体的な対象と成果物のパスを含める。単にメインが簡素化を考えることでスキル呼び出しを省略しない。
+実装と必要な検証が終わった同じ差分を固定し、メインが次の3スキルを明示的に呼ぶ。各スキルは担当エージェントをバックグラウンド起動してIDを返し、メインが全体の起動・待機・記録を管理する。実装後のレビューラウンドは初回を1として数え、この依頼内で最大2回までとする。計画段階のプランレビューはこの回数に含めない。
-メインが統合された提案を確認し、採用する削除・統合を同じ実装担当へ渡す。仕様変更が必要な提案はユーザーに確認する。適用後に影響する検証を再実行し、メインが結果を `raw/simplify.md` に残す。UI変更があれば `Skill(skill="shinaps:verify-ui", args="今回のUI変更と対象環境・受入条件")` を呼んで確認する。
-その後、`Skill(skill="shinaps:refine", args="照合のみ。今回の対象ファイルと変更範囲を、2体で独立して照合して返す。編集しない")` を具体的な対象とともに呼び、結果を `raw/refine.md` に保存する。これらのスキル内でエージェントを起動するため、dev が simplify / refine の担当を重複起動しない。未提供のツールやスキルを実行したことにせず、実施できなかった工程を明記する。
-簡素化後の同じ最終差分 (staged / unstaged / untrackedを含む) を、以下の2担当が **並行して読み取り専用でレビュー**する:
-| 担当 | 主な観点 |
+| スキル呼び出し | 担当 |
 |---|---|
-| Phase 3 の architect を再開 | 最終 plan・受入条件・合意済み変更に対して実装と検証が成立しているか |
-| 新しい `shinaps-reviewer` 1体 | コードの正しさ・安全性・性能・保守性・規約を独立して確認 |
+| `Skill(skill="shinaps:review", args="開発レビュー、起動のみ。…")` | 設計した architect を再開 + 独立 reviewer 1体 |
+| `Skill(skill="shinaps:refine", args="照合のみ、起動のみ。…")` | Opus / medium 2体 |
+| `Skill(skill="shinaps:simplify", args="提案のみ、起動のみ。…")` | Opus / medium 2体 |
-両者に最終 plan、実装報告、現在の差分とファイル、検証結果、rule 全文を渡す。architect には「実装レビューとして、初回案ではなく確定した計画と現在のコードを照合する」と明記する。再開できない場合は設計時の判断理由も渡して新しい architect を起動し、同じ担当の再開ではないことを記録する。
+引数の省略部分には具体的な対象ファイル・変更範囲、最終 plan・受入条件・合意済み変更、実装報告、検証結果、規約・rule 全文と成果物のパスを渡す。review には設計担当のエージェントIDと設計判断も渡す。単独の review とは異なる開発レビューの手順を使い、外部調査や review-validator を追加起動しない。
-両者は今回の相手のレビュー結果を読まず、意見を交換しない。メインと実装担当も、両者が完了するまで対象を編集しない。同時実行枠が不足する場合は順次実行し、独立性を保つ。先に実行した `refine` の照合結果も統合し、修正は全結果が揃ってから Phase 7 で実装担当へ渡す。
+先に起動した担当の完了を待ってから次のスキルを呼ぶのではなく、3スキルの担当を起動してから結果を待つ。dev 自身が同じ担当を重複起動しない。同時実行枠が足りなければ未起動分を記録して順次実行し、台数や確認範囲を黙って減らさない。ツールや委託が利用できなければその制約を明記し、独立確認済みと扱わない。
-結果はそれぞれ `architecture-review.md`、`review.md`、`raw/refine.md` に保存する。メインが全指摘を実コードと照合し、重複を整理し、異なる判断は根拠から解決する。完了していない担当の確認を成功扱いにしない。委託不可の場合はメインが各観点を確認し、独立レビュー未実施と明記する。
+全担当は読み取り専用で、今回の他担当の結果を読まず、意見を交換しない。メインと実装担当も全結果が揃うまで対象を編集しない。途中で外部の変更が入った場合は、その影響範囲を最新の同じ差分で確認し直してから統合する。
-### Phase 7: 修正ループ
+各スキルの確認範囲・未完了報告を確認し、未確認部分は同じ担当へ戻す。対象が大きい場合も継続または後任への引き継ぎで全対象を確認する。失敗・未完了を「指摘なし」として処理しない。
-- **Critical は必ず自動修正** (architect / reviewer Critical + refine の `scope=changed` な Violation、承認不要 — 動作を壊している / 規約違反の指摘)
-- **Phase 5 で検出された検証の失敗** も Critical として修正
-- **Warning は `AskUserQuestion` で確認**: 「全部修正 / 個別に確認 / 後回し (Issue 化) / スコープ外として記録」 (architect / reviewer Warning + refine Improvement)
-- **refine の `scope=pre-existing` な finding は自動修正しない**。今回の実装と無関係な差分が commit に混ざるため、Violation でも `AskUserQuestion` で「今回直す / 別タスクにする」を確認する
-- **Info は記録のみで修正しない**
-- **簡素化レビューの「仕様を変えない削除・統合」は自動適用**し、Phase 5 の動作確認を再実行する。削除は追加より検証しやすく、残すほうが保守の負債になるため。**「仕様変更を伴う提案」は `AskUserQuestion` で確認**: 「採用して仕様を変える / 現状維持 / 別タスクにする」
+自分のレビューを確定した architect と全担当の結果を保存する。初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付ける。全結果が揃った後で初めて同じ architect を「指摘統合」として再開し、自分のレビューを含む全結果・現在の差分・検証結果・ラウンド番号を渡す。独立レビュー中に他担当の結果を渡さない。
-修正を行った場合、`fix-log.md` に「指摘 → 修正内容 → 該当ファイル」を記録。修正判断も `fix-log.md` に残す。
+### Phase 7: architect が統合し、implementer が修正
-修正実装は Phase 5 の `shinaps-implementer` を再開して依頼する。メインは確定した指摘・修正判断・現在の差分・必要な再検証を渡す。再開できなければ Phase 5 の引き継ぎ情報と実装・修正履歴を新しい実装担当へ渡す。委託不可の場合はメインが修正する。大規模な再実装が必要な場合は、メインが「現行の計画で修正継続 / Phase 4 に戻って再策定」を確認する。
+architect が review・refine・simplify の全指摘を根拠から検証し、重複・対立を整理する。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
-### Phase 8: 修正後の再レビュー (Critical / Warning 修正時のみ)
+修正不要なら Phase 9 へ進む。修正があれば、メインが同じ `shinaps-implementer` を再開し、architect の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を新しい担当へ引き継ぐ。architect は次のレビューに備えて保持し、自分でコードを編集したり、実装担当を追加起動したりしない。
-Phase 7 で **Critical または Warning を修正した場合のみ**、Phase 6 と同じ分担で architect を再開し、独立した `shinaps-reviewer` を起動する。両者が同じ修正後の差分をレビューし、結果が揃うまで編集しない (refine の再発火は Phase 8 では不要)。
+implementer が修正と必要な検証を行い、変更・検証結果・未解決点を返す。メインは architect の採否と修正結果を `fix-log.md` に記録する。委託不可の場合はメインが同じ観点で対応し、独立した確認とは報告しない。
-これは「修正で別バグを生むリスク」を検出するため。
+### Phase 8: 最大2ラウンドで終了する
-- プロンプトには最新の最終 plan と「修正後の差分」「修正前の指摘」「修正内容」「検証結果」を渡す。今回の相手のレビュー結果は渡さない
-- 応答は `architecture-review-{n}.md` と `review-{n}.md` に保存 (n は 2 始まり)
-- 再レビューでさらに Critical が出た場合は再修正 → 再レビューを Critical が無くなるまで繰り返す
-- 各ラウンドの修正は `fix-log.md` に追記し、ラウンド数が判別できるようにする
+- **1回目のレビュー後に修正した場合**: 修正後の同じ差分について、Phase 6 の review・refine・simplify を2回目として並行実行する。最新の計画、前回の指摘と採否、修正内容、検証結果を渡す。全結果を同じ architect に集約し、Phase 7 で必要な最終修正を実施する。
+- **2回目のレビュー後に修正した場合**: implementer が最終修正と必要なテストを行ったら Phase 9 へ進む。3回目のレビュー・refine・simplify は起動しない。
+- **修正不要の場合**: 回数を埋めるために再実行せず Phase 9 へ進む。
-修正がなかった場合は再レビューをスキップして Phase 9 へ。
+最大2回は実装後の全体レビューに対する上限であり、担当の再開・差し替えや計画の変更でリセットしない。検証失敗・重大な未解決事項・未完了の担当が残る場合も追加ラウンドで無期限に続けず、その状態を明記してユーザーへ返す。未完了の確認を完了済みのラウンドと偽らない。
 ### Phase 9: 完了と必要なhandoff
-変更、簡素化、検証結果、未確認事項を報告する。コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
+実施したレビュー回数、architect の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
 ## 動作原則
@@ -228,8 +217,8 @@ Phase 7 で **Critical または Warning を修正した場合のみ**、Phase 6
 - **判断・方針転換で ローカル成果物（implementation.md / 調査・レビューレポート）**
 - **目的・仕様を左右する不明点を確認**: 既存の指示で分かることや任された細部は再質問しない
 - **生レポート保存厳守**: explorer / handoff 済み investigation / architect / plan-reviewer / reviewer / refine の応答は全文参照可能な状態を保つ
-- **Critical は自動修正、Warning は確認**
-- **簡素化をレビュー前に実行する**: 目的を保つ削除を先に適用し、最終差分をレビューする
+- **architect が指摘の採否と修正方針を統合する**: 合意済み仕様内は任せ、仕様や許可範囲が変わる判断だけユーザーに確認する
+- **レビュー・規約照合・簡素化は同じ差分に並行して行う**: 全結果を統合してから実装担当が修正する
 - **plan からの逸脱は確認 + 記録**: AskUserQuestion で確認した上で `implementation.md` に経緯を残す
 - **コミットは明示依頼時のみ**: Phase 9 で既存の許可を引き継ぐ。

package/plugins/shinaps-claude/skills/refine/SKILL.md CHANGED Viewed

@@ -75,6 +75,9 @@ shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて
 ## Step 3. 2体で独立して照合する
+`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
 委託が許可されている場合、`shinaps-refine-agent` を **2体並列**で起動する。モデル・effort は定義の `opus / medium` を使い、起動時に上書きしない。両者が同じ全規約と対象を別々に照合し、相手の結果を読まず、意見を交換しない。全結果が揃うまでメインも対象を編集しない。
 分割が必要な場合は同じ2体を再開して次のバッチを渡し、それぞれが対象全体を確認する。再開できなければ確認済み・未確認の範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、2担当の独立した結果を揃える。委託不可の場合はメインが同じ照合を行い、2体による照合済みとは報告しない。

package/plugins/shinaps-claude/skills/review/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: review
-description: shinaps-reviewer + shinaps-review-validator で精度の高い単独レビューを行うスキル。差分・PR・既存コードを引数で切り替え。rule カタログとの照合を reviewer prompt に埋め込むことで、指摘の rule 起点タグ付けを bake する。確定指摘があればそのまま /shinaps:dev へ橋渡しして修正計画 + 実装まで進められる
+description: 差分・PR・既存コードをレビューする。単独実行では指摘検証と外部技術調査を行い、dev の開発レビューでは設計担当と独立 reviewer が同じ実装を確認する。
 argument-hint: <なし | PR番号 | ファイル/ディレクトリパス>
 ---
@@ -18,6 +18,21 @@ Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用で
 別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+## dev からの開発レビュー
+引数に「開発レビュー」と指定された場合は、この節だけを実行し、以下の単独レビューの引数判定・外部調査・review-validator・devへの引き継ぎは実行しない。
+呼び出し元から対象ファイルと差分 (staged / unstaged / untracked を含む)、最終 plan・受入条件・合意済み変更、実装報告と検証結果、rule 全文、設計担当のエージェントIDと設計判断の理由を受け取る。
+- **設計適合性**: 設計した `shinaps-architect` を再開し、初回案ではなく確定した plan と現在のコード・検証を照合するよう依頼する。再開できなければ設計判断を引き継いだ新しい architect を使い、その旨を記録する。
+- **独立レビュー**: 新しい `shinaps-reviewer` 1体へ、コードの正しさ・安全性・性能・保守性・規約の確認を依頼する。
+両者へ同じ対象を渡し、読み取り専用で並行して確認する。今回の他担当の結果を読ませず、意見を交換させない。全担当が完了するまで対象を編集しない。モデルと effort は各エージェント定義を使う。
+「起動のみ」と指定された場合は、対応する実行環境で両担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ちと記録は dev のメイン、全指摘の統合は同じ architect、修正は implementer が行う。起動済みをレビュー完了と報告しない。枠不足やバックグラウンド非対応なら実行可能な範囲を返し、dev が残りを順次進める。委託不可の場合はその制約を返す。
+起動のみでない場合は両者の完了を待ち、結果と確認範囲を呼び出し元へ返す。指摘の修正は行わない。再レビューでは最新の計画・修正差分・前回の指摘・修正内容・検証結果を使い、今回の結果が揃うまで同じ独立性を保つ。
 ## 引数仕様
 | 呼び出し | モード | 動作 |

package/plugins/shinaps-claude/skills/simplify/SKILL.md CHANGED Viewed

@@ -19,6 +19,9 @@ description: 実装・設計・手順の簡素化を、Opus / medium の2体で
 ## 2体で独立して確認する
+`dev` から「起動のみ」と指定された場合は、以下の2担当をバックグラウンド起動し、担当名・エージェントID・対象範囲・未起動分を返す。結果待ち・不足範囲の再割り当て・記録は dev のメインが行う。各担当の結果を省略せず返し、全指摘の統合は同じ architect、修正は implementer が行う。起動済みを確認完了と報告しない。枠不足やバックグラウンド非対応の場合は実行可能な範囲を返し、dev が残りを順次進める。「起動のみ」がなければ、このスキル内で全結果を待って以下の統合手順まで行う。
 委託が許可されている場合は `shinaps-simplifier` を2体並列で起動する。モデルと effort は定義の `opus / medium` を使い、起動時に上書きしない。同じ対象・目的・受入条件・確定した計画・規約・既存変更の情報を両者へ渡す。
 両者は読み取り専用で、相手の結果を読まずに提案する。2体の完了まで対象を編集しない。対象が大きい場合は同じ2体を再開して分割した範囲を順次渡す。担当の再開ができなければ確認済み範囲と未確認範囲を後任へ引き継ぐ。同時実行枠が不足する場合は順次実行し、独立性を保つ。委託不可ならメインが確認し、2体による確認済みとは報告しない。

package/plugins/shinaps-codex/.codex-plugin/plugin.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }

package/plugins/shinaps-codex/skills/dev/SKILL.md CHANGED Viewed

@@ -9,7 +9,7 @@ description: プロジェクトの既存設計と条件を確認し、計画・
 2. Shinaps AIのルール検索が利用できれば、リポジトリと変更領域に関係するルールを取得する。使えない場合はルール照合未確認として明記し、可能な実装を進める。
 3. 複雑な調査・設計では、委託を許可されている場合に登録済みのshinaps-explorer、shinaps-architect、shinaps-plan-reviewerへ対象と期待する結果を渡す。担当の結論を自分で検証する。委託不可なら同じ観点を現在のセッションで確認する。worktree作成は別途許可が必要。
 4. 計画を必要な単位に分けて実装する。利用できる計画ツールで進捗を管理する。既存の無関係な変更を保ち、公開契約を変える必要が出たら理由と案を確認する。
-5. $shinaps:simplifyを読み、仕様を保つ削除・統合を行う。CIや既存スクリプトから変更に必要な検証を実行する。UIが関係する場合は$shinaps:verify-uiを使い、対象プロジェクトで必要な実画面を確認する。
+5. $shinaps:simplifyを読み、仕様を保つ削除・統合を行う。CIや既存スクリプトから変更に必要な検証を実行する。
 6. $shinaps:refineによるルール照合が可能なら行い、$shinaps:reviewで最終差分をレビューする。確定した今回の不具合を修正し、影響範囲を再検証する。依頼外の既存問題は混ぜず報告する。
 7. 変更後の挙動、主要な検証と未確認事項を報告する。コミット・PR・公開は別途依頼された場合だけ進める。

package/plugins/shinaps-claude/skills/verify-ui/SKILL.md DELETED Viewed

@@ -1,36 +0,0 @@
----
-name: verify-ui
-description: UI変更を対象プロジェクトの対応環境で実際に操作し、見た目と挙動を検証する。UI実装後や画面の動作確認を求められたときに使う。
----
-## 作業記録の保存先
-作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
-既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
-# UIを使って検証する
-## プロジェクトの条件を読む
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
-既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-## 検証範囲を決める
-対応ブラウザ・端末、変更する操作、期待する性質、必須の証拠を既存仕様から決める。受入条件はケースの列挙ではなく「再表示しても保存した選択を保つ」のような性質で書き、代表的な操作で確かめる。
-特定ブラウザ、実機、Simulator、複数OSバージョンを一律に必須にしない。プロジェクトがPCブラウザのみを対象にするならその範囲で検証する。エンジン差・ハードウェア・入力方式が結果を左右する変更なら、その差を確認できる環境を選ぶ。必要な環境が使えない場合、別環境で通ったことを代替証拠にせず未確認として残す。対応範囲自体が不明で結論を左右する場合だけ確認する。
-## 実行と証拠
-1. 現在の画面と実装を確認する。余白や入力の問題がアプリ・ブラウザ・端末のどこに属するか切り分ける。
-2. プロジェクトが必要とする自動検証を実行し、対象の実画面で主要操作と関連する状態遷移を確かめる。DOMや内部状態の注入を操作成功の証拠にしない。
-3. レイアウトの欠け、重なり、フォーカス、再操作、保存・再表示など変更の影響する性質を確認する。動画や計測を必要とする動き・性能は静止画だけで合格にしない。
-4. 視覚的な判定にはスクリーンショットを残し、環境・操作・期待・観測結果を対応づける。明示された証拠の納品先がなければ `.shinaps/work/` 以下の今回の作業ディレクトリを使う。
-5. 発見した問題を直した場合は影響部分を再確認する。独立レビューは利用可能で許可され、効果がある場合に限る。
-## 完了
-定めた範囲で期待する性質を実画面から確認できたことを報告する。自動テストのみ・画面を開いただけ・スクリーンショットのみで操作を確認済みにしない。未確認事項と理由は完了範囲から区別する。実装・修正が依頼されていなければ、検証の依頼から変更許可を推測しない。

package/plugins/shinaps-codex/skills/verify-ui/SKILL.md DELETED Viewed

@@ -1,36 +0,0 @@
----
-name: verify-ui
-description: UI変更を対象プロジェクトの対応環境で実際に操作し、見た目と挙動を検証する。UI実装後や画面の動作確認を求められたときに使う。
----
-## 作業記録の保存先
-作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
-既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
-# UIを使って検証する
-## プロジェクトの条件を読む
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
-既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
-## 検証範囲を決める
-対応ブラウザ・端末、変更する操作、期待する性質、必須の証拠を既存仕様から決める。受入条件はケースの列挙ではなく「再表示しても保存した選択を保つ」のような性質で書き、代表的な操作で確かめる。
-特定ブラウザ、実機、Simulator、複数OSバージョンを一律に必須にしない。プロジェクトがPCブラウザのみを対象にするならその範囲で検証する。エンジン差・ハードウェア・入力方式が結果を左右する変更なら、その差を確認できる環境を選ぶ。必要な環境が使えない場合、別環境で通ったことを代替証拠にせず未確認として残す。対応範囲自体が不明で結論を左右する場合だけ確認する。
-## 実行と証拠
-1. 現在の画面と実装を確認する。余白や入力の問題がアプリ・ブラウザ・端末のどこに属するか切り分ける。
-2. プロジェクトが必要とする自動検証を実行し、対象の実画面で主要操作と関連する状態遷移を確かめる。DOMや内部状態の注入を操作成功の証拠にしない。
-3. レイアウトの欠け、重なり、フォーカス、再操作、保存・再表示など変更の影響する性質を確認する。動画や計測を必要とする動き・性能は静止画だけで合格にしない。
-4. 視覚的な判定にはスクリーンショットを残し、環境・操作・期待・観測結果を対応づける。明示された証拠の納品先がなければ `.shinaps/work/` 以下の今回の作業ディレクトリを使う。
-5. 発見した問題を直した場合は影響部分を再確認する。独立レビューは利用可能で許可され、効果がある場合に限る。
-## 完了
-定めた範囲で期待する性質を実画面から確認できたことを報告する。自動テストのみ・画面を開いただけ・スクリーンショットのみで操作を確認済みにしない。未確認事項と理由は完了範囲から区別する。実装・修正が依頼されていなければ、検証の依頼から変更許可を推測しない。