@shinaps/skills 0.50.1 → 0.50.3

package/dist/bin/skills.js

@@ -5,15 +5,30 @@ import { packageRoot } from "../lib/layout.js";
 import { LINEAR_CONFIG_VERSION, validateLinearConfig } from "../lib/linear-config.js";
 import { validateManagedConfig } from "../lib/managed-config.js";
 import { managed } from "../lib/managed.js";
-import { run } from "../lib/install.js";
+import { INSTALL_COMMAND, run } from "../lib/install.js";
 import { autoUpdate } from "../lib/auto-update.js";
 import { lint } from "../lib/lint.js";
-import { ruleCoverage } from "../lib/rule-coverage.js";
-import { ruleSnapshot } from "../lib/rule-snapshot.js";
+import { RULE_COVERAGE_COMMAND, ruleCoverage } from "../lib/rule-coverage.js";
+import { RULE_SNAPSHOT_COMMAND, ruleSnapshot } from "../lib/rule-snapshot.js";
 import { errorMessage } from "../lib/fs.js";
+const usage = [
+    `Usage: ${INSTALL_COMMAND}`,
+    '       shinaps-skills validate-linear-config <file>',
+    '       shinaps-skills validate-managed-config <file>',
+    '       shinaps-skills managed <setup|run|status|reply|collect> (see managed --help)',
+    '       shinaps-skills auto-update <enable|disable|status|check> codex',
+    '       shinaps-skills lint --checks <checks.json> --root <project> --out <result.json> -- <files...>',
+    `       ${RULE_SNAPSHOT_COMMAND}`,
+    `       ${RULE_COVERAGE_COMMAND}`,
+    'Claude Code: /plugin marketplace add sh1n4ps/shinaps-skills',
+    '             /plugin install shinaps@shinaps-skills',
+].join('\n');
 const [command, ...rest] = process.argv.slice(2);
 try {
-    if (command === '--version') {
+    if (!command || command === 'help' || command === '--help') {
+        console.log(usage);
+    }
+    else if (command === '--version') {
         console.log(JSON.parse(await readFile(join(packageRoot, 'package.json'), 'utf8')).version);
     }
     else if (command === 'validate-linear-config') {

package/dist/lib/install.js

@@ -5,23 +5,10 @@ import { spawnSync } from 'node:child_process';
 import { registerPlugin, replaceInstallation, restore, } from "./transaction.js";
 import { withLock } from "./lock.js";
 import { readTextIfExists, sha256, writeFileAtomic } from "./fs.js";
-import { RULE_COVERAGE_COMMAND } from "./rule-coverage.js";
-import { RULE_SNAPSHOT_COMMAND } from "./rule-snapshot.js";
 import { codexHomeMismatch, codexHomeOf, isRecordedCodexHome, managedAgent, managedRoot, marketplaceName, packageRoot, payloadDir, payloadPaths, pluginDir, pluginId, statePath, } from "./layout.js";
 const actions = ['install', 'update', 'uninstall', 'recover'];
 const isAction = (value) => actions.includes(value);
-const usage = [
-    'Usage: shinaps-skills <install|update|uninstall|recover> codex',
-    '       shinaps-skills validate-linear-config <file>',
-    '       shinaps-skills validate-managed-config <file>',
-    '       shinaps-skills managed <setup|run|status|reply|collect> (see managed --help)',
-    '       shinaps-skills auto-update <enable|disable|status|check> codex',
-    '       shinaps-skills lint --checks <checks.json> --root <project> --out <result.json> -- <files...>',
-    `       ${RULE_SNAPSHOT_COMMAND}`,
-    `       ${RULE_COVERAGE_COMMAND}`,
-    'Claude Code: /plugin marketplace add sh1n4ps/shinaps-skills',
-    '             /plugin install shinaps@shinaps-skills',
-].join('\n');
+export const INSTALL_COMMAND = 'shinaps-skills <install|update|uninstall|recover> codex';
 const installGuidance = [
     'No Shinaps AI account is required to install. For MCP features, create an account at https://app.shinaps.ai and use your client’s authentication flow.',
     'MCP setup (only if not already configured): codex mcp add shinaps-ai --url https://app.shinaps.ai/mcp',
@@ -34,14 +21,9 @@ const installGuidance = [
  * @param options 動作環境の指定。`auto-update check` とテストが使う。
  */
 export async function run(args, options = {}) {
-    const log = options.log ?? console.log;
     const [action, target, ...extra] = args;
-    if (!action || action === '--help' || action === 'help') {
-        log(usage);
-        return;
-    }
-    if (!isAction(action) || target !== 'codex' || extra.length) {
-        throw new Error(`Unknown command: ${args.join(' ')}. ${usage.split('\n')[0]} (see --help).`);
+    if (!action || !isAction(action) || target !== 'codex' || extra.length) {
+        throw new Error(`Unknown command: ${args.join(' ')}. Usage: ${INSTALL_COMMAND} (see --help).`);
     }
     const installation = openInstallation(options);
     switch (action) {

package/docs/development.md

@@ -16,6 +16,7 @@
 - Managed の共通定義は `plugins/shinaps-claude/managed-agents/` を編集元として Codex 版へ複製し、テストで一致を確認する。Managed の skill の `staffing.md`・`workflow.md`・`launch.md` は Claude 版を写した適応版で一致はテストしないため（`review.md`・`design.md` は下の正本の複製でテストする）、Claude 版の工程・体制の基準を変えたら Managed への適用可否を判断する。
 - レビューの共通契約は `references/review.md` を正本とし、本文を Managed の skill の `references/review.md` に複製してテストで一致を確認する。Codex の `shinaps-reviewer` は、Claude 版の「レビューの種類」以降の本文を同じ文で持ち、テストで一致を確認する。担当の構成・対象の固定・完了の判定・採否は契約に、種類ごとの作業手順は役割の定義に、単独起動の対象・体制・到達点は `references/review-standalone.md` に、担当の起動と修正の引き継ぎ先だけを両版の `review` の `SKILL.md` に書く。
 - テスト方針は各版の `references/testing.md` を正本とし、その段落を役割定義と Managed の lead の定義に複製する。設計の観点は `references/dev/design.md` を正本とし、本文を独立設計担当（`shinaps-architect`）の定義と Managed の skill の `references/design.md` に複製する。どちらもテストで一致を確認する。
+- 上の完全一致の複製（`references`・Managed の共通定義・Managed の skill の `review.md`・`design.md`）は、編集元を直した後に `npm run sync:copies` で依存の順に上書きできる（編集元で消したファイルは写しからも手で消す）。役割定義の本文やテスト方針の段落のような部分の写しは対象外で、手で揃える。
 - 役割の定義は Claude 版が Markdown、Codex 版が TOML、Managed 版が `ant apply` 用の frontmatter を付けた Markdown。サブエージェント内では shinaps MCP を直接呼ばず、rule の全文はスキル側から渡すか、スキル側が機械保存した snapshot のファイルを読ませる（MCP の利用量が重複せず、全文をモデルに書き写させないため）。この原則を全ての役割定義に書く。
 - `autonomous-commit-review` の役割は `commit` に統合した。旧 `linear` の入口は廃止し、`linear-plan`・`linear-execute` に分けた。規約照合と簡素化の独立した入口は `review` に統合し、規約の一括抽出の入口は廃止した（規約の登録は利用者がその場で依頼する）。個人用の別 AI 呼び出し・ブラウザ管理・ゴール管理・動画制作はこの plugin に含めない。Bridge 本体は同梱せず、導入済みの MCP と WebStorm プラグインを使う。
 

package/docs/install.md

@@ -13,7 +13,7 @@ npx @shinaps/skills@latest uninstall codex
 npx @shinaps/skills@latest recover codex
 ```
 
-`install` はスキルを Codex plugin として登録し、10 個のサブエージェントを `${CODEX_HOME:-~/.codex}/agents/` へ配置します。新しいセッションから使えます。
+`install` はスキルを Codex plugin として登録し、[サブエージェント](agents.md)を `${CODEX_HOME:-~/.codex}/agents/` へ配置します。新しいセッションから使えます。
 
 - 配布物は `~/.local/share/shinaps-ai/skills/codex/` に保持し、一時的な npx のキャッシュに依存しません。同じ親ディレクトリの `state.json` に、配置したエージェントと内容のハッシュを記録します。
 - 管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せずに止まります。必要な変更を退避してから再実行してください。`CODEX_HOME` を変える場合は、元の配置先で先に `uninstall` します。
@@ -26,7 +26,7 @@ npx @shinaps/skills@latest recover codex
 設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査と受け渡し（`lint`・`rule-snapshot`・`rule-coverage`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.50.1
+npm install -g @shinaps/skills@0.50.3
 shinaps-skills --version
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.50.1",
+  "version": "0.50.3",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {
@@ -23,6 +23,7 @@
     "test": "node --test \"test/*.test.ts\"",
     "check": "npm run format:check && tsc --noEmit",
     "verify:package": "node scripts/verify-package.ts",
+    "sync:copies": "node scripts/sync-copies.ts",
     "format": "biome format --write .",
     "format:check": "biome format ."
   },

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

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
-  "version": "0.50.1",
+  "version": "0.50.3",
   "author": {
     "name": "shinaps"
   },

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/review.md

@@ -14,6 +14,10 @@
 
 依頼が種類を限定している場合（規約照合だけ、簡素化だけなど）は、限定された種類だけを依頼する。担当は1名とする。ただし ULTRA を同時に指定され、限定された種類に規約照合または可読性・慣習レビューが含まれるときは、その種類を技術領域ごとに1名へ依頼する。
 
+指摘の検証の担当は、この構成の人数とは別に、呼び出す入口の手順が定める条件で加える（単独の `review` は単独レビューの手順、dev は体制の判断に従う）。
+
+規約を照らす種類は、独立コードレビュー（rule 観点）・規約照合・可読性・慣習レビューとする。依頼する種類にこれらを含むときだけ、入口の手順で規約を取得し、機械検査と照合の範囲の報告を行う。実装の簡素化・指摘の検証だけのレビューでは規約の取得と機械検査を必須にせず、目的・維持する外部契約・コード・利用側・テストで判断する。ただし、規約を根拠にする指摘を検証するときは、その規約だけを（元のレビューの snapshot、または id からの全文の取得で）渡す。担当には渡した規約だけを読ませ、渡していない規約の読了を求めない。
+
 技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにし、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
 ## 対象の固定
@@ -25,12 +29,12 @@
 
 ## 担当へ渡すもの
 
-- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、合意済み仕様。規約を照らす種類では、規約全文または読むファイルの指定。入手できなかったもの（計画・受入条件など）はそのことを伝える。
 - 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
 - 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
 - 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
 - 実装の簡素化: 目的、維持する外部契約、対象コード、計画。
-- 指摘の検証: 元の対象、検証する指摘の全文、確認範囲、外部調査があればその結果。
+- 指摘の検証: 元の対象、検証する指摘の全文（規約を根拠にする指摘はその規約の全文または読むファイル）、確認範囲、外部調査があればその結果。
 
 ## 独立性
 
@@ -38,7 +42,7 @@
 
 ## 機械検査
 
-規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
+規約を照らす種類を依頼し、規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
 
 - 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
 - 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
@@ -67,4 +71,4 @@
 
 ## 報告
 
-固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。独立コードレビューを依頼し規約照合の種類を依頼しなかった場合は、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。どちらも依頼しなかった場合は、規約を照合していないと書く。
+固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。規約照合の種類を依頼せず、規約を照らす他の種類を依頼した場合は、規約をその種類の中で照らし、ファイルごとの完了一覧が無いことを書く。規約を照らす種類を依頼しなかった場合は、規約を照合していないと書く。

package/plugins/shinaps-claude/references/dev/workflow.md

@@ -80,6 +80,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 - 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
 - [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+- Claude CodeでiOSの不具合の再現や原因の調査に実際の画面・操作の観測が必要な場合は、Apple公式のXcodeプラグインの `device-interaction` スキルを使える。使うのはこの目的の場合だけとし、同スキルがUI変更後の毎回の確認を勧めていても実装後の一律確認には使わない（動作QAは[QAと証拠](../linear/qa.md)の工程が担う）。操作とセッションの手順は同スキルに従う。端末は上の「Simulatorの所有と再利用」に従ってUDIDで指定し、同スキルのツールは指定に近い端末を選ぶことがあるため、開始したセッションの端末がそのUDIDと一致することを確かめる。未導入・未承認・その端末を選べない・一致しないなど使えない場合は、導入や権限の変更を手順に加えず、観測していない内容を未確認として扱う。観測は対象版・端末と合わせて `implementation.md`（Phase 7と修正サイクルでは `fix-log.md`）に残し、検証やQAの合格に読み替えない。
 - 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を記録し、追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
 メインは `implementation.md` に、変更ファイルと変更内容、設計理由、確認した先例と慣習から外れる判断の理由、簡素化した点、計画からの変更と合意、検証コマンドと終了コード・証拠の所在、未実施事項・未解決点を書く。実行していない検証を成功と書かない。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。

package/plugins/shinaps-claude/references/linear/configuration.md

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.50.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.1`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.50.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.3`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
 0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 

package/plugins/shinaps-claude/references/review-standalone.md

@@ -43,11 +43,11 @@
 
 ## 4. 規約と機械検査
 
-[Shinaps規約の取得](rules.md)の「照合のために取得する」に従い、対象ファイルについて snapshot を作り、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
+依頼する種類が契約の「規約を照らす種類」を含むときは、[Shinaps規約の取得](rules.md)の「照合のために取得する」に従い、対象ファイルについて snapshot を作り、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。含まないときは、対象ファイルの snapshot と機械検査を行わない（指摘の検証の根拠の規約は契約のとおり渡す）。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs は、どちらの場合も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
 
 ## 5. 検証と報告
 
-契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、またはメインと指摘元の根拠の対立が解消しないときは、別の担当に「指摘の検証」を依頼する。テストに関わる指摘は[テスト方針](testing.md)に従う。採否の確定後に[規約の適用結果](rules.md#適用結果を記録する)を既定で記録する（依頼でOFFにできる。失敗は未記録として報告する）。契約の「報告」と `findings.md` のパスを報告する。
+契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、メインと指摘元の根拠の対立が解消しないとき、または採否を誤ったときの影響が大きい簡素化の提案（公開契約や状態管理に触れる、影響が広範囲に及ぶなど）があるときは、別の担当1名に「指摘の検証」を依頼する。簡素化の提案はその提案だけを渡して、失う契約・増える複雑さ・変更範囲を確かめさせ、対象全体のレビューを繰り返さない。どの場合も、利用者が担当の人数を限っているときは追加せず、独立検証していない指摘として報告する（根拠の対立は未解決とする）。テストに関わる指摘は[テスト方針](testing.md)に従う。採否の確定後に[規約の適用結果](rules.md#適用結果を記録する)を既定で記録する（依頼でOFFにできる。失敗は未記録として報告する）。契約の「報告」と `findings.md` のパスを報告する。
 
 ## 6. 到達点
 

package/plugins/shinaps-claude/references/review.md

@@ -14,6 +14,10 @@
 
 依頼が種類を限定している場合（規約照合だけ、簡素化だけなど）は、限定された種類だけを依頼する。担当は1名とする。ただし ULTRA を同時に指定され、限定された種類に規約照合または可読性・慣習レビューが含まれるときは、その種類を技術領域ごとに1名へ依頼する。
 
+指摘の検証の担当は、この構成の人数とは別に、呼び出す入口の手順が定める条件で加える（単独の `review` は単独レビューの手順、dev は体制の判断に従う）。
+
+規約を照らす種類は、独立コードレビュー（rule 観点）・規約照合・可読性・慣習レビューとする。依頼する種類にこれらを含むときだけ、入口の手順で規約を取得し、機械検査と照合の範囲の報告を行う。実装の簡素化・指摘の検証だけのレビューでは規約の取得と機械検査を必須にせず、目的・維持する外部契約・コード・利用側・テストで判断する。ただし、規約を根拠にする指摘を検証するときは、その規約だけを（元のレビューの snapshot、または id からの全文の取得で）渡す。担当には渡した規約だけを読ませ、渡していない規約の読了を求めない。
+
 技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにし、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
 ## 対象の固定
@@ -25,12 +29,12 @@
 
 ## 担当へ渡すもの
 
-- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、合意済み仕様。規約を照らす種類では、規約全文または読むファイルの指定。入手できなかったもの（計画・受入条件など）はそのことを伝える。
 - 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
 - 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
 - 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
 - 実装の簡素化: 目的、維持する外部契約、対象コード、計画。
-- 指摘の検証: 元の対象、検証する指摘の全文、確認範囲、外部調査があればその結果。
+- 指摘の検証: 元の対象、検証する指摘の全文（規約を根拠にする指摘はその規約の全文または読むファイル）、確認範囲、外部調査があればその結果。
 
 ## 独立性
 
@@ -38,7 +42,7 @@
 
 ## 機械検査
 
-規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
+規約を照らす種類を依頼し、規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
 
 - 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
 - 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
@@ -67,4 +71,4 @@
 
 ## 報告
 
-固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。独立コードレビューを依頼し規約照合の種類を依頼しなかった場合は、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。どちらも依頼しなかった場合は、規約を照合していないと書く。
+固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。規約照合の種類を依頼せず、規約を照らす他の種類を依頼した場合は、規約をその種類の中で照らし、ファイルごとの完了一覧が無いことを書く。規約を照らす種類を依頼しなかった場合は、規約を照合していないと書く。

package/plugins/shinaps-claude/references/rules.md

@@ -42,7 +42,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 照合のために取得する
 
-対象ファイルが確定した照合の手順。応答をモデルが書き写すと本文や `checks` が欠けうるので、plugin の hook（PostToolUse）が応答をそのまま `<Gitのルート>/.shinaps/work/rule-captures/` へ保存し、そこから `shinaps-skills rule-snapshot` が担当と機械検査の読むファイルを作る。保存先はGit管理の外のローカルで、サーバーへは送らない。
+対象ファイルが確定した照合の手順。応答をモデルが書き写すと本文や `checks` が欠けうるので、plugin の hook（PostToolUse）が応答をそのまま `<セッションの作業ディレクトリのGitのルート（無ければ作業ディレクトリ）>/.shinaps/work/rule-captures/` へ保存し、そこから `shinaps-skills rule-snapshot` が担当と機械検査の読むファイルを作る。保存先はGit管理の外のローカルで、サーバーへは送らない。
 
 1. 取得の前の時刻を `date +%s000` で記録する。
 2. 領域ごとに入力を作業記録の下（例: `rules/<領域>/input.json`）へ書く。「一覧を取る」と同じ条件で、`fields` だけ `"full"` にする。
@@ -53,7 +53,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
    shinaps-skills rule-snapshot --since <時刻> --input <input.json> [--exclude-label <slug>] --out <作業記録>/rules/<領域>
    ```
 
-   取得と同じGitのルートで実行する（別の場所なら `--captures <dir>` で保存先を渡す）。`rule-snapshot` が無いときは、利用中のスキルと同じ版のCLIを導入する。`--exclude-label` には、「全文を取る規約を選ぶ」の除外の条件に当たる軸のlabelだけを渡す（CLIはこの条件を判定しない）。除外した規約はidと理由が `manifest.json` に残る。
+   取得と同じGitのルートで実行する。それと違う場所（プロジェクトを開かずに始めたチャットから対象のリポジトリで実行するときなど）では、捕捉はチャット側にあるので、その保存先を `--captures <dir>` で渡す。`rule-snapshot` が無いときは、利用中のスキルと同じ版のCLIを導入する。`--exclude-label` には、「全文を取る規約を選ぶ」の除外の条件に当たる軸のlabelだけを渡す（CLIはこの条件を判定しない）。除外した規約はidと理由が `manifest.json` に残る。
 
 出力は `manifest.json`（`contentHash`、入力、`ruleIds`、除外、partのhash）、`parts/part-NNN.json`（全文）、`lint-checks.json`（全文の `checks` そのまま）。
 

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

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

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/review.md

@@ -14,6 +14,10 @@
 
 依頼が種類を限定している場合（規約照合だけ、簡素化だけなど）は、限定された種類だけを依頼する。担当は1名とする。ただし ULTRA を同時に指定され、限定された種類に規約照合または可読性・慣習レビューが含まれるときは、その種類を技術領域ごとに1名へ依頼する。
 
+指摘の検証の担当は、この構成の人数とは別に、呼び出す入口の手順が定める条件で加える（単独の `review` は単独レビューの手順、dev は体制の判断に従う）。
+
+規約を照らす種類は、独立コードレビュー（rule 観点）・規約照合・可読性・慣習レビューとする。依頼する種類にこれらを含むときだけ、入口の手順で規約を取得し、機械検査と照合の範囲の報告を行う。実装の簡素化・指摘の検証だけのレビューでは規約の取得と機械検査を必須にせず、目的・維持する外部契約・コード・利用側・テストで判断する。ただし、規約を根拠にする指摘を検証するときは、その規約だけを（元のレビューの snapshot、または id からの全文の取得で）渡す。担当には渡した規約だけを読ませ、渡していない規約の読了を求めない。
+
 技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにし、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
 ## 対象の固定
@@ -25,12 +29,12 @@
 
 ## 担当へ渡すもの
 
-- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、合意済み仕様。規約を照らす種類では、規約全文または読むファイルの指定。入手できなかったもの（計画・受入条件など）はそのことを伝える。
 - 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
 - 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
 - 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
 - 実装の簡素化: 目的、維持する外部契約、対象コード、計画。
-- 指摘の検証: 元の対象、検証する指摘の全文、確認範囲、外部調査があればその結果。
+- 指摘の検証: 元の対象、検証する指摘の全文（規約を根拠にする指摘はその規約の全文または読むファイル）、確認範囲、外部調査があればその結果。
 
 ## 独立性
 
@@ -38,7 +42,7 @@
 
 ## 機械検査
 
-規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
+規約を照らす種類を依頼し、規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
 
 - 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
 - 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
@@ -67,4 +71,4 @@
 
 ## 報告
 
-固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。独立コードレビューを依頼し規約照合の種類を依頼しなかった場合は、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。どちらも依頼しなかった場合は、規約を照合していないと書く。
+固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。規約照合の種類を依頼せず、規約を照らす他の種類を依頼した場合は、規約をその種類の中で照らし、ファイルごとの完了一覧が無いことを書く。規約を照らす種類を依頼しなかった場合は、規約を照合していないと書く。

package/plugins/shinaps-codex/references/dev/workflow.md

@@ -80,6 +80,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 - 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
 - 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
 - [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+- Claude CodeでiOSの不具合の再現や原因の調査に実際の画面・操作の観測が必要な場合は、Apple公式のXcodeプラグインの `device-interaction` スキルを使える。使うのはこの目的の場合だけとし、同スキルがUI変更後の毎回の確認を勧めていても実装後の一律確認には使わない（動作QAは[QAと証拠](../linear/qa.md)の工程が担う）。操作とセッションの手順は同スキルに従う。端末は上の「Simulatorの所有と再利用」に従ってUDIDで指定し、同スキルのツールは指定に近い端末を選ぶことがあるため、開始したセッションの端末がそのUDIDと一致することを確かめる。未導入・未承認・その端末を選べない・一致しないなど使えない場合は、導入や権限の変更を手順に加えず、観測していない内容を未確認として扱う。観測は対象版・端末と合わせて `implementation.md`（Phase 7と修正サイクルでは `fix-log.md`）に残し、検証やQAの合格に読み替えない。
 - 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を記録し、追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
 メインは `implementation.md` に、変更ファイルと変更内容、設計理由、確認した先例と慣習から外れる判断の理由、簡素化した点、計画からの変更と合意、検証コマンドと終了コード・証拠の所在、未実施事項・未解決点を書く。実行していない検証を成功と書かない。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。

package/plugins/shinaps-codex/references/linear/configuration.md

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.50.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.1`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.50.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.3`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
 0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 

package/plugins/shinaps-codex/references/review-standalone.md

@@ -43,11 +43,11 @@
 
 ## 4. 規約と機械検査
 
-[Shinaps規約の取得](rules.md)の「照合のために取得する」に従い、対象ファイルについて snapshot を作り、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
+依頼する種類が契約の「規約を照らす種類」を含むときは、[Shinaps規約の取得](rules.md)の「照合のために取得する」に従い、対象ファイルについて snapshot を作り、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。含まないときは、対象ファイルの snapshot と機械検査を行わない（指摘の検証の根拠の規約は契約のとおり渡す）。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs は、どちらの場合も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
 
 ## 5. 検証と報告
 
-契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、またはメインと指摘元の根拠の対立が解消しないときは、別の担当に「指摘の検証」を依頼する。テストに関わる指摘は[テスト方針](testing.md)に従う。採否の確定後に[規約の適用結果](rules.md#適用結果を記録する)を既定で記録する（依頼でOFFにできる。失敗は未記録として報告する）。契約の「報告」と `findings.md` のパスを報告する。
+契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、メインと指摘元の根拠の対立が解消しないとき、または採否を誤ったときの影響が大きい簡素化の提案（公開契約や状態管理に触れる、影響が広範囲に及ぶなど）があるときは、別の担当1名に「指摘の検証」を依頼する。簡素化の提案はその提案だけを渡して、失う契約・増える複雑さ・変更範囲を確かめさせ、対象全体のレビューを繰り返さない。どの場合も、利用者が担当の人数を限っているときは追加せず、独立検証していない指摘として報告する（根拠の対立は未解決とする）。テストに関わる指摘は[テスト方針](testing.md)に従う。採否の確定後に[規約の適用結果](rules.md#適用結果を記録する)を既定で記録する（依頼でOFFにできる。失敗は未記録として報告する）。契約の「報告」と `findings.md` のパスを報告する。
 
 ## 6. 到達点
 

package/plugins/shinaps-codex/references/review.md

@@ -14,6 +14,10 @@
 
 依頼が種類を限定している場合（規約照合だけ、簡素化だけなど）は、限定された種類だけを依頼する。担当は1名とする。ただし ULTRA を同時に指定され、限定された種類に規約照合または可読性・慣習レビューが含まれるときは、その種類を技術領域ごとに1名へ依頼する。
 
+指摘の検証の担当は、この構成の人数とは別に、呼び出す入口の手順が定める条件で加える（単独の `review` は単独レビューの手順、dev は体制の判断に従う）。
+
+規約を照らす種類は、独立コードレビュー（rule 観点）・規約照合・可読性・慣習レビューとする。依頼する種類にこれらを含むときだけ、入口の手順で規約を取得し、機械検査と照合の範囲の報告を行う。実装の簡素化・指摘の検証だけのレビューでは規約の取得と機械検査を必須にせず、目的・維持する外部契約・コード・利用側・テストで判断する。ただし、規約を根拠にする指摘を検証するときは、その規約だけを（元のレビューの snapshot、または id からの全文の取得で）渡す。担当には渡した規約だけを読ませ、渡していない規約の読了を求めない。
+
 技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにし、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
 ## 対象の固定
@@ -25,12 +29,12 @@
 
 ## 担当へ渡すもの
 
-- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、合意済み仕様。規約を照らす種類では、規約全文または読むファイルの指定。入手できなかったもの（計画・受入条件など）はそのことを伝える。
 - 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
 - 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
 - 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
 - 実装の簡素化: 目的、維持する外部契約、対象コード、計画。
-- 指摘の検証: 元の対象、検証する指摘の全文、確認範囲、外部調査があればその結果。
+- 指摘の検証: 元の対象、検証する指摘の全文（規約を根拠にする指摘はその規約の全文または読むファイル）、確認範囲、外部調査があればその結果。
 
 ## 独立性
 
@@ -38,7 +42,7 @@
 
 ## 機械検査
 
-規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
+規約を照らす種類を依頼し、規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
 
 - 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
 - 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
@@ -67,4 +71,4 @@
 
 ## 報告
 
-固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。独立コードレビューを依頼し規約照合の種類を依頼しなかった場合は、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。どちらも依頼しなかった場合は、規約を照合していないと書く。
+固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。規約照合の種類を依頼せず、規約を照らす他の種類を依頼した場合は、規約をその種類の中で照らし、ファイルごとの完了一覧が無いことを書く。規約を照らす種類を依頼しなかった場合は、規約を照合していないと書く。

package/plugins/shinaps-codex/references/rules.md

@@ -42,7 +42,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 照合のために取得する
 
-対象ファイルが確定した照合の手順。応答をモデルが書き写すと本文や `checks` が欠けうるので、plugin の hook（PostToolUse）が応答をそのまま `<Gitのルート>/.shinaps/work/rule-captures/` へ保存し、そこから `shinaps-skills rule-snapshot` が担当と機械検査の読むファイルを作る。保存先はGit管理の外のローカルで、サーバーへは送らない。
+対象ファイルが確定した照合の手順。応答をモデルが書き写すと本文や `checks` が欠けうるので、plugin の hook（PostToolUse）が応答をそのまま `<セッションの作業ディレクトリのGitのルート（無ければ作業ディレクトリ）>/.shinaps/work/rule-captures/` へ保存し、そこから `shinaps-skills rule-snapshot` が担当と機械検査の読むファイルを作る。保存先はGit管理の外のローカルで、サーバーへは送らない。
 
 1. 取得の前の時刻を `date +%s000` で記録する。
 2. 領域ごとに入力を作業記録の下（例: `rules/<領域>/input.json`）へ書く。「一覧を取る」と同じ条件で、`fields` だけ `"full"` にする。
@@ -53,7 +53,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
    shinaps-skills rule-snapshot --since <時刻> --input <input.json> [--exclude-label <slug>] --out <作業記録>/rules/<領域>
    ```
 
-   取得と同じGitのルートで実行する（別の場所なら `--captures <dir>` で保存先を渡す）。`rule-snapshot` が無いときは、利用中のスキルと同じ版のCLIを導入する。`--exclude-label` には、「全文を取る規約を選ぶ」の除外の条件に当たる軸のlabelだけを渡す（CLIはこの条件を判定しない）。除外した規約はidと理由が `manifest.json` に残る。
+   取得と同じGitのルートで実行する。それと違う場所（プロジェクトを開かずに始めたチャットから対象のリポジトリで実行するときなど）では、捕捉はチャット側にあるので、その保存先を `--captures <dir>` で渡す。`rule-snapshot` が無いときは、利用中のスキルと同じ版のCLIを導入する。`--exclude-label` には、「全文を取る規約を選ぶ」の除外の条件に当たる軸のlabelだけを渡す（CLIはこの条件を判定しない）。除外した規約はidと理由が `manifest.json` に残る。
 
 出力は `manifest.json`（`contentHash`、入力、`ruleIds`、除外、partのhash）、`parts/part-NNN.json`（全文）、`lint-checks.json`（全文の `checks` そのまま）。