@shinaps/skills 0.38.0 → 0.39.1

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 (19) hide show
  1. package/README.md +56 -245
  2. package/docs/agents.md +24 -0
  3. package/docs/development.md +49 -0
  4. package/docs/install.md +59 -0
  5. package/package.json +2 -1
  6. package/plugins/shinaps-claude/.claude-plugin/plugin.json +2 -3
  7. package/plugins/shinaps-claude/references/dev/launch.md +1 -1
  8. package/plugins/shinaps-claude/references/linear/claude-cli.md +14 -8
  9. package/plugins/shinaps-claude/references/linear/configuration.md +15 -12
  10. package/plugins/shinaps-claude/references/linear/configuration.schema.json +2 -1
  11. package/plugins/shinaps-claude/references/linear/workflow.md +1 -1
  12. package/plugins/shinaps-claude/references/managed/execute.md +1 -1
  13. package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
  14. package/plugins/shinaps-codex/references/linear/claude-cli.md +14 -8
  15. package/plugins/shinaps-codex/references/linear/configuration.md +15 -12
  16. package/plugins/shinaps-codex/references/linear/configuration.schema.json +2 -1
  17. package/plugins/shinaps-codex/references/linear/workflow.md +1 -1
  18. package/plugins/shinaps-codex/references/managed/execute.md +1 -1
  19. package/plugins/shinaps-codex/skills/linear-execute/SKILL.md +1 -1
package/README.md CHANGED
@@ -1,287 +1,98 @@
1
1
  # shinaps-skills
2
2
 
3
- Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexにはそれぞれに適したplugin・カスタムエージェントとして配布する。実装はClaude Codeが行い（Linear進行では、境界内のUIの微調整をCodexが行える。[担当と工程](plugins/shinaps-claude/references/linear/workflow.md#codexによるuiの微調整)）、Codexは進行・QA・レビュー等を担当する。Claude Managed Agents向けには、draft PRまで進むdev工程の共通定義を両pluginの `managed-agents/` に置き、`managed-setup` で利用者の組織へ導入し、`managed-execute` で依頼する。スキルのダウンロードと導入にShinaps AIのアカウントは不要。サービスのrule検索・登録を使うときにアカウント作成と認証を行う。
3
+ Claude Code と Codex で使う、開発ワークフローのスキル集です。調査・仕様の整理・実装・レビュー・コミット・PR・リリースの手順を、それぞれのクライアント向けの plugin として配布します。
4
4
 
5
- ## プロジェクトごとの条件
5
+ - 実装は Claude Code が行います。Codex は調査・レビュー・Linear での進行管理と QA を担当します。
6
+ - 導入に Shinaps AI のアカウントは不要です。コーディング規約（rule）の照合・抽出を使うときだけ、[Shinaps AI](https://app.shinaps.ai) でアカウントを作成して MCP を接続します。
6
7
 
7
- 共通スキルが持つのは判断手順。対象環境・必須検証・公開条件は、対象プロジェクトの `AGENTS.md` / `CLAUDE.md` と参照先、README、CI、既存スクリプトから読み取る。専用設定ファイルは必須にしない。
8
+ ## 必要なもの
8
9
 
9
- 例外として `linear-execute` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.json` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定は `config_storage: shared` でGit共有、`local` でメインの作業ツリーだけに保存する。必須キーの欠落は設定不備として止め、旧設定は明示移行する。sharedは現在のcheckout、localはメインの設定と補足を正本とする。共有設定が欠けていても端末別のlocal設定では補わない。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)の読取・保存手順に従う。設定がなくてもIssueの読み取り・整理はできる。設定が必要な実行で共通の読取手順により真に未設定と確認できた場合だけ、同じセッションで `linear-plan` の初期設定ヒアリングへ進み、合意した設定の保存・確認後に元の依頼を再開する。
10
+ - Claude Code または Codex CLI
11
+ - Node.js 22 以上（Codex への導入と、設定の検証・Managed Agents の操作に使う[配布 CLI](docs/install.md#配布-cli)に必要）
12
+ - 機能によって追加で必要なもの（Linear・Claude Managed Agents など）は、下の「機能別の資料」の各資料に書いています。
10
13
 
11
- sharedで採用する `instructions.md` は共有JSONの `references.specifications` に明記して開始・再開時に読み、他の必要補足は内容に対応する `references` に記載する。必要補足の欠落・読取不能は依存工程を止め、未採用とは扱わない。設定・採用補足・ignoreの個別例外を一緒に共有するか、共有済み資料への参照に置き換える。端末の絶対パスやsession/thread ID、進捗・QA結果は `.shinaps/work/` に分け、秘密値はどちらにも保存しない。保存方式の合意だけでstage・commit・push・追跡解除を許可しない。
14
+ ## インストール
12
15
 
13
- 例えばPCブラウザのみのプロジェクトには対応ブラウザと確認コマンドを書く。iOSプロジェクトにはSimulatorと実機の使い分けを記す。スキルは一律の端末数やOS数を追加しない。既存の情報で決まらず結果を左右する条件だけ確認し、保存を了承された方針をプロジェクト側に残す。
14
-
15
- ## JSON設定の検証
16
-
17
- 0.33.0から `.shinaps/linear.json`（`config_version: 2`）を使います。`config_version: 1`・`implementation_skill`・`review_flow.tool`・許可の `codex_task`/`managed_session:*`、旧YAML・scalar review_flowは受け付けず、[移行手順](plugins/shinaps-claude/references/linear/configuration.md#config_version-1-からの移行)に従います。
18
-
19
- 0.35.0から通常設定の `review_flow.mode` に `ask` を追加しました（パス別ルールは `auto`・`manual` だけ）。既存の設定は変更不要です。
20
-
21
- CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.38.0` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。Managed Agentsの `.shinaps/managed.json` も `shinaps-skills validate-managed-config <明示ファイル>` で同じ方式で検証します。0.38.0から `config_version: 2`（リポジトリとアカウント別のvault）になり、lockはアカウントごとの管理ディレクトリへ移ります（[Managedの設定と移行](plugins/shinaps-claude/references/managed/configuration.md)）。
22
-
23
- ```sh
24
- npm install -g @shinaps/skills@0.38.0
25
- shinaps-skills --version
26
- shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
27
- shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
28
- ```
29
-
30
- ## スキル
31
-
32
- | 名前 | 用途 |
33
- |---|---|
34
- | `explore` | 対話しながら既存挙動と変更影響を調べる |
35
- | `spec` | 目的・仕様・実現方法を詰める |
36
- | `dev-claude` (Claudeのみ) | メインが計画・実装・検証・採否を行い、選んだ体制（LITE・BASIC・ULTRA）の担当が独立した別案と独立レビューを行う |
37
- | `debug` | 不具合の原因を検証する |
38
- | `review` | 差分や既存コードをレビューする |
39
- | `refine` | Shinaps AIのruleと実ファイルを照合する |
40
- | `extract-rules` | PRレビューからruleを抽出する |
41
- | `simplify` | 目的から見直して不要な構造や手順を削る |
42
- | `commit` | 各単位のreview_flowに従い、autoはAIがレビュー・コミット、manualは人の開始依頼で分割案を示し、人が単位ごとに依頼したコミットを行う |
43
- | `create-pr` | リポジトリの規約に合わせてPRを作成する |
44
- | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
45
- | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
46
- | `linear-execute` | Issue単体・Cycle全体・バックログ消化を選び、設定に従って実装・QA・許可された公開を進める |
47
- | `managed-setup` | Claude Managed Agentsの共通dev構成を1つ以上のアカウントへ一コマンドで導入・更新する。アカウントごとのlockを使い、重複して作らない |
48
- | `managed-execute` | Managed Agentsのleadへdevを依頼し、観測・質問の取り次ぎ・出力のローカル回収とdraft PRの確認を行う |
49
-
50
- コミット・PR・リリースは、利用者の依頼またはLinear進行で合意済みの継続許可に従う。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md)・[終了と待機](plugins/shinaps-claude/references/linear/execution.md)を参照し、必要な前工程が揃えば再確認せずに進む。単独スキル利用にはLinear進行や新しいゴールを必須にしない。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
51
-
52
- `linear-execute` は初版では利用者本人の環境向けで、Codexが進行役として進行・Agent QA・Issueの記録・人への窓口を担当し、Claude Codeが実装・修正・コミットを行う。主フローは着手・実装・差分確定・公開確認・結果報告の5工程。運用項目は明示必須で、未記載を既定値で補わない。経路は着手時に通常の `review_flow.mode` で決まり、`ask` ではIssueごとに着手時の人の回答で決まる。autoはCodexがローカル `claude -p` を起動して同じsessionをresumeし（許可 `claude_cli`、[CLI手順](plugins/shinaps-claude/references/linear/claude-cli.md)）、CLIの既存権限・effort・pluginsを保持する。メインのモデルは経路で分ける（[経路](plugins/shinaps-claude/references/linear/configuration.md#経路)）。manualはWebStorm内の対話Claude CodeセッションへBridgeで依頼する（許可 `bridge_request`、[Bridge](plugins/shinaps-claude/references/linear/bridge.md)）。manualではQA後もCodexはcommitを依頼せず、人の依頼でClaudeがcommitする。体制はCodexが確認して依頼に書き、BASIC・ULTRAでは追加の担当をClaudeのメインが判断の材料と現物から決めて報告する。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
53
-
54
- `review_flow: { "mode": "auto" }` はAIが自然な単位を決め、独立レビュー・QA後にstage・commitする。`review_flow: { "mode": "manual" }` はAIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人がその単位のコミットを依頼したらAIが単位外を安全に退避して単位をstage・検証・commitする。`review_flow: { "mode": "ask" }` は着手時に進行役が作業内容と推奨理由を添えてautoかmanualかを一問で確認し、回答を同じIssueの通常flowとして使う。パス別ルールには書けない。各modeのstage・AI commit権限は利用者との明示合意に含まれ、未合意ファイルからは得ない。`path_policy_overrides` は `paths` と `review_flow` だけを持つ。全変更が一つのルールで覆われる単位だけ適用し、改名は旧新両パスを判定する。競合時は止める。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・パス別ai_commitは明示移行が必要。[共通設定](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
55
-
56
- 0.29.0では旧 `document_only_changes: ai_commit` を廃止した。利用先では依存工程を止め、具体的なパス例外への移行または例外廃止を合意する。説明だけの変更の許可とは同値でないため自動変換しない。旧 `none` もJSONへ明示移行し、新規設定は `path_policy_overrides: []` にする。
57
-
58
- `permissions` の `development_operations` を明示すると、既存アカウントのログイン・環境準備・依存導入・起動・テスト・QAを継続的に許可できる。コミット・公開・破壊的操作の許可や人レビューは別に扱う。
59
-
60
- 旧 `linear` の入口は廃止した。相談・Issue整理・設定変更は `linear-plan`、実行は `linear-execute` を使う。設定は0.32.0からJSONへ移行する。実行範囲は毎回の依頼で確定し、バックログではブロッカー到達と報告を終了条件にできる。人レビュー・Human QA待ちは予定工程として待機する。
61
-
62
- ### dev の入口と体制
63
-
64
- ローカルの実装の入口は Claude Code の `dev-claude` だけで、Codexに実装の入口はない。Claude Managed Agentsは別runtimeで、`managed-setup`・`managed-execute` から使う。「[Claude Managed Agents](#claude-managed-agents)」節で扱う。メインのモデルは[経路](plugins/shinaps-claude/references/linear/configuration.md#経路)で決まる（単独devは利用者のセッション設定のまま）。メインは調査・設計・実装・指摘の採否を自分で行うので、メインのモデルと effort がそのまま設計・実装のモデルになる。担当は登録エージェントの定義（Opus / medium）で動く。
65
-
66
- devの体制は、実装後の独立コードレビューの担当1名だけのLITE、計画レビュー担当1名と独立コードレビューの担当1名を置くBASIC、メインの案を見ない独立設計担当1名・計画レビュー担当2名・実装後の独立レビュー（A: 独立コードレビューの担当1名、B: 技術領域ごとの規約照合・可読性・慣習の担当1名）を置くULTRAの3段階で、BASIC・ULTRAは必須担当を下限にメインが追加できる（[実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)）。3体制の違いは独立確認の対象・人数・深さだけで、共有する文脈が必要な作業はどの体制でもメインが行う。同じ対象を読む確認の観点（計画の簡素化、規約照合、実装の簡素化など）は少数の担当にまとめて依頼する。体制・経路（auto・manual）・メインのモデルは別の軸である。体制は各Issueの着手時と人の指摘の一括修正の開始時に、推奨を添えて人に確認する。人数を増やすだけで許可・予算・品質条件は変えない。
67
-
68
- - 工程と体制基準はClaude版を編集元としてCodexへ複製する。起動手順だけはruntimeごとに異なる。
69
- - Managedの `staffing.md`・`workflow.md`・`launch.md` はClaude版を編集元に写した適応版で、一致はテストしない。Claude版の工程・体制基準を変えたらManagedへの適用可否を判断する。
70
- - Claudeは登録エージェント、Codexは名前付きサブエージェントを使う。担当のモデル・推論の設定は人数判断で変更しない。
71
- - Claudeのexplore・spec・review・debugからは `dev-claude` へ引き継ぐ。ClaudeのdevはSkillツールからの起動も許可する。Codexのスキルは実装へ引き継がず、Linear進行では `linear-execute` でClaudeへ依頼する。
72
- - テスト方針は各版の `references/testing.md` を正本とし、役割定義に同じ段落を複製して検証する。設計の観点は `references/dev/design.md` を正本とし、独立設計担当（`shinaps-architect`）の定義とManagedのskillの `references/design.md` に本文を複製して検証する。
73
-
74
- ## Claude Code
16
+ Claude Code:
75
17
 
76
18
  ```text
77
19
  /plugin marketplace add sh1n4ps/shinaps-skills
78
20
  /plugin install shinaps@shinaps-skills
79
21
  ```
80
22
 
81
- ユーザースコープで利用する。呼び出しは `/shinaps:dev-claude`、`/shinaps:create-pr` など。ローカル開発中はmarketplaceにこのcheckoutの絶対パスを登録し、変更後にpluginを更新する。pluginキャッシュへ直接編集しない。更新後は新しいセッションで確認する。
82
-
83
- ## Codex
84
-
85
- Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Codexのスキルだけを使う場合、Claude Codeのインストールは不要。`linear-execute` の開発進行には、autoではローカルClaude Code CLI、manualではWebStorm内のClaude CodeとBridgeが必要になる。
86
-
87
- 導入・更新・削除:
23
+ Codex:
88
24
 
89
25
  ```sh
90
26
  npx @shinaps/skills@latest install codex
91
- npx @shinaps/skills@latest update codex
92
- npx @shinaps/skills@latest uninstall codex
93
- npx @shinaps/skills@latest recover codex
94
- ```
95
-
96
- `recover codex`は、中断した更新の記録が残っている場合に復元だけを行う。記録が無ければ何もしない。
97
-
98
- ローカル開発では、このcheckoutから `node bin/skills.ts install codex` のように同じ操作を実行できる。Node.js 22.18以上なら型除去でTypeScriptをそのまま実行する (ビルド不要)。
99
-
100
- CLIはスキルをCodex pluginとして登録し、10個のカスタムエージェントを`${CODEX_HOME:-~/.codex}/agents/`へ配置する。新しいセッションで`shinaps:review`、`shinaps:linear-execute`等が読み込まれる。Codexに実装の入口はなく、review・debug・spec等のスキルが担当を使う。担当のモデルと推論設定は親セッションから継承する。調査・レビュー担当は読み取り専用を既定にする。0.33.1 まで配置していた dev 専用の役割（設計・実装・計画レビュー・指摘検証・簡素化・分割レビュー）は、更新時に管理済みエージェントとして削除される。親セッションの実行時設定が優先される場合もあるため、権限の強制境界とは扱わない。
101
-
102
- 配布物は`~/.local/share/shinaps-ai/skills/codex/`へ保持し、一時的なnpxキャッシュに依存しない。同じ親ディレクトリの`state.json`に配置したエージェントと内容のハッシュを記録する。管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せず停止する。必要な変更を退避・整理してから再実行する。`CODEX_HOME`を変更する場合は元の配置先で先にuninstallする。
103
-
104
- uninstallはこのCLIのplugin・marketplace・管理済みエージェントを取り除く。個人用スキルと、別途登録したMCP接続・認証情報は保持する。
105
-
106
- ### 自動更新（Codex / macOS）
107
-
108
- ```sh
109
- npx @shinaps/skills@latest auto-update enable codex
110
- npx @shinaps/skills@latest auto-update status codex
111
- npx @shinaps/skills@latest auto-update check codex
112
- npx @shinaps/skills@latest auto-update disable codex
113
- ```
114
-
115
- 初期状態は無効。導入済みの利用者が`enable`するとmacOSのユーザーLaunchAgentを登録し、ログイン中に1日1回（12:00）確認する。スリープ中に12:00を過ぎた場合は起床時に1回だけ実行する。電源が切れていた回は実行しない。確認のたびにnpmから`latest`のパッケージを取得して実行し、導入版より新しい安定版の場合だけ更新する。古い版への自動ダウングレードはしない。更新内容は新しいCodexセッションから反映される。
116
-
117
- `enable`は通常のログインシェルから実行する。CodexやClaude Codeのセッション内からは実行しない。登録時のPATH、npmの場所、`CODEX_HOME`が記録され、以後の確認でもそのまま使われる。ツールの場所を変えた場合は再度`enable`する。npmの設定は`~/.npmrc`のものが使われる。
118
-
119
- 登録直後に次の手順で動作を確認できる。`kickstart`はすぐに戻るので、npmの取得が終わるまで待ってから残りを実行する。
120
-
121
- ```sh
122
- launchctl kickstart -k gui/$(id -u)/io.shinaps.skills.update
123
- launchctl print gui/$(id -u)/io.shinaps.skills.update | grep 'last exit code'
124
- npx @shinaps/skills@latest auto-update status codex
125
- ```
126
-
127
- 更新前に新版を準備し、旧スキル・エージェント・管理情報を退避する。更新中のエラー時は旧内容とCodexのプラグイン登録を復元する。強制終了などで復元できなかった場合は、次の更新確認時または`recover codex`の実行時に、`~/.local/share/shinaps-ai/skills/transaction/`に残った記録から復元する。復元にも失敗した場合は同じ場所にバックアップを保持して停止するので、エラーの原因を直してから`recover codex`を実行する。導入後のユーザー編集や同時更新は上書きせず停止する。
128
-
129
- `status`は設定と最終確認結果を表示する。失敗の詳細は`~/.local/share/shinaps-ai/skills/auto-update-error.log`、通常ログは同じ場所の`auto-update.log`に記録する。npmがパッケージを取得できなかった場合は最終確認結果は更新されず、エラーログだけに記録される。通知ポップアップは出さない。`disable`は予定実行を停止し、導入したスキルは保持する。`uninstall codex`は予定実行も停止する。
130
-
131
- macOS以外では予定実行の登録に対応していないため手動更新を使う。
132
-
133
- Claude Codeは標準のmarketplace自動更新機能を使う。`/plugin` のMarketplacesから対象marketplaceのauto-updateを有効にする。GitHubから自動取得するにはリモートmarketplaceを登録する必要があり、ローカルcheckout登録ではソースのgit pullまで自動実行しない。
134
-
135
- ## Claude Managed Agents
136
-
137
- 両pluginの `managed-agents/` は、Claude Managed Agentsでdev工程を進めるための共通定義である。lead `shinaps-dev-managed-cc`、devの3役割、skill `dev-managed-cc`、環境 `shinaps-dev` を置く。クラウドのIDを記録する `claude-lock.json` は利用者のアカウント（APIキーの組織・workspace）ごとのものなので、マシン単位の管理ディレクトリに置き、公開する定義には含めない。予定実行はこの構成に含めない。
138
-
139
- - leadと3役割はOpus 5.5（`claude-opus-5-5` / medium）で動く。全agent定義に `speed: standard` を明示する（既存リソースに残るfastを戻すため）。leadのモデルは定義で決まり、Linear進行の経路ごとのメインのモデルとは別に扱う。
140
- - 体制はLITE・BASIC・ULTRAを初回メッセージで受け、`dev-claude` と同じ体制の表に従い、BASIC・ULTRAではleadが追加の担当を決める。leadがメインとして調査・設計・実装・採否を行い、独立設計（ULTRAでは必須）・計画レビュー・実装後の独立レビューだけを登録した3役割（architect・plan-reviewer・reviewer）へ委任する。Managedで設計・実装を行うモデルはleadのOpusになる。廃止したdev-ultraなどの入口・explorer・refine専用の役割は置かず、探索はleadと独立設計担当が行う。
141
- - Shinaps AIのMCPとruleを使わない。規約はマウントしたリポジトリの `AGENTS.md`・`CLAUDE.md` と参照先、添付された利用者CLAUDE.mdだけで、最終報告ではShinaps AI ruleを未照合とする。
142
- - 初回メッセージにリポジトリ・base・head・範囲と受入条件・体制・許可・予算が揃わなければ、leadは作業を始めず欠落を質問する。許可はそのメッセージで明示された操作だけで、構成の導入からは生じない。
143
- - 終了地点は範囲を限ったコミット・headブランチへのpush・draft PR。merge・deploy・release・Issueの更新はしない。CodexのQAはセッションの外で、PRの後に行う。push前に最終QAを行うLinear進行とは順序が違う。
144
-
145
- ### CLI
146
-
147
- 導入・依頼・観測・回収は配布CLIの `shinaps-skills managed` で行い、クラウドの操作は公式の `ant` CLI（2.4.0以上。コマンド・フラグ・stdin・出力はこの版のソースで照合した）へ委ねる。各アカウントのAPIキーは環境変数 `SHINAPS_MANAGED_API_KEY_<NAME>` か引数 `--api-key <name>=<key>` で渡し、CLIは保存・表示しない。lock・セッション記録・回収した出力は `~/.local/share/shinaps-ai/skills/managed/<account>/` にアカウントごとに分かれる。
148
-
149
- ```sh
150
- shinaps-skills managed setup --account personal --account work # 計画の表示だけ
151
- shinaps-skills managed setup --account personal --account work --apply # 合意後に適用
152
- shinaps-skills managed run .shinaps/managed.json --account work --base main --base-sha <SHA> --head feat/x \
153
- --staffing BASIC --allow commit,push,draft_pr --budget-cents 4000 --task-file task.md
154
- shinaps-skills managed status --account work --session <ID>
155
- shinaps-skills managed reply --account work --session <ID> --message-file answer.md
156
- shinaps-skills managed collect --account work --session <ID>
157
- ```
158
-
159
- - setupはアカウントごとのlockで既存のリソースを更新し、lockが無いのに同名のリソースがあれば作らずに止まる。`--apply` を付けない限りクラウドを変更しない。
160
- - runはリポジトリ・base・head・範囲・体制・許可・予算を毎回明示し、同じ入力の再実行では新しいセッションを作らない。
161
- - collectはセッションの出力を保存するだけで、差分を適用しない。CLIはgitを呼ばず、pushしない。
162
-
163
- 手順・安全上の注意・止める条件は[設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)・[導入と更新の手順](plugins/shinaps-claude/references/managed/setup.md)・[依頼と観測の手順](plugins/shinaps-claude/references/managed/execute.md)にある。これらはpluginに含まれ、どちらのruntimeからも読める。
164
-
165
- ### 定義の更新と適用
166
-
167
- 共通定義は `plugins/shinaps-claude/managed-agents/` を編集元とし、`plugins/shinaps-codex/managed-agents/` へ同じ内容を複製する。一致はテストで確認する。定義を変えたら `managed setup` で計画を確かめてから `--apply` で適用する。`--prune`・`--force` は使わず、リソースを削除しない。
168
-
169
- ### このリポジトリのlock
170
-
171
- shinaps-skills自身のlockは0.34.0から0.37.0まで `.shinaps/managed/claude-lock.json`（Git対象外）に置いていた。0.38.0では[version 1 からの移行](plugins/shinaps-claude/references/managed/configuration.md#version-1-からの移行)に従い、アカウントの `definitions/claude-lock.json` へ移してから適用する。それ以前の内容は `git show 8679d8f:managed-agents/claude-lock.json` で取り出せる。旧CC Ultraのleadと専用skill、旧explorerと旧review-verifierはクラウドでアーカイブ済みで、lockでも追跡しない。
172
-
173
- GitHub MCP（`https://api.githubcopilot.com/mcp`）の資格情報はアカウントの組織のvaultに登録し、セッション作成時に渡す。vaultの資格情報はMCPサーバーのURLで照合されるので、lead定義のURLと末尾のスラッシュまで揃える。leadは最後のメッセージの1行目に `状態: 完了`・`状態: 質問`・`状態: 未完了` を書き、`changes.patch` と作業記録のtarを `/mnt/session/outputs/` に置く（[起動手順](plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/launch.md)）。CLIの実クラウドでの実行、マウントしたリポジトリへのpushとdraft PRの作成は、実際のセッションで確かめるまで未検証である。
174
-
175
- ## 開発と配布
176
-
177
- - Claude版: `plugins/shinaps-claude/`、marketplaceは`.claude-plugin/marketplace.json`
178
- - Codex版: `plugins/shinaps-codex/`、marketplaceは`.agents/plugins/marketplace.json`
179
- - Codexカスタムエージェント: `plugins/shinaps-codex/agents/`
180
- - Claude Managed Agents版: 両pluginの `managed-agents/`（Claude版が編集元）。pluginと一緒に配布され、npmパッケージの `plugins/` にも含まれる。適用は `shinaps-skills managed setup` がアカウントごとの管理ディレクトリへコピーしてから行い、`--prune`・`--force` を使わない
181
- - 配布CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build` (`tsc`) で `dist/` にJSを出力し、npmにはそれを配布する。Node.jsは`node_modules`配下の`.ts`に型除去を適用しないため、ソースのままは配布できない。checkoutでは型除去で直接実行するので、`enum`など型除去で消せない構文は使わない (`tsconfig.json` の `erasableSyntaxOnly`)
182
-
183
- 品質基準とプロジェクト設定の方針は揃えつつ、クライアント固有の実行手順・エージェント形式は別々に管理する。Codex版の工程の資料（`references/` の、`dev/launch.md` を除くもの）はClaude版と一致させ、テストで確認する。Codex版は役割の本文とスキルを書き分け、Claude向けのエージェント呼び出しをCodexに読み替えさせる方式は使わない。スキルを追加・変更した場合は各版への適用可否を判断する。
184
-
185
- ```sh
186
- npm test
187
- npm run check
188
- npm pack --dry-run
189
27
  ```
190
28
 
191
- 公開前にはnpmスコープ`@shinaps`の利用権限とtarball内容を確認する。CLIのバージョンと両pluginのバージョンを揃える。開発中の同一バージョンも`update codex`で再配置できる。
192
-
193
- ### manualのレビュー待ちとコミットの依頼
194
-
195
- manualではWebStorm内の対話Claude Codeセッションで、作業が終わるとClaudeが短く報告して「ユーザーのレビュー待ち」と明示します。人はWebStormの差分表示で全体を確認し、Claudeと修正を相談します。人がコミットの開始を依頼すると、Claudeが自然なコミット分割案を示します。分割案への合意はコミットの承認ではありません。人がその単位のコミットを依頼すると、Claudeが単位外を退避して単位をstage・検証し、stage時のtreeと一致することを確かめてコミットします。stage時のtreeを記録した後に単位の差分が変われば再提示と改めての依頼が必要です。会話には差分本文を貼らず、単位名・目的・検証結果・推奨メッセージなど必要最小限だけを示します。手順は[共通手順](plugins/shinaps-claude/references/human-review.md)に従います。autoには人レビュー待ちを追加しません。
196
-
197
- ### CIとnpm自動公開
29
+ どちらも、新しいセッションから使えます。更新・削除と、Codex の自動更新は [導入と更新](docs/install.md) を参照してください。
198
30
 
199
- `.github/workflows/publish.yml` はmainへのpush・PR・手動実行でテストと配布内容を検証する。通常のGitHub Releaseを公開すると、検証成功後に同じtagのパッケージをnpmへpublic公開する。prereleaseは公開しない。手動実行は検証専用で、npmへの公開は行わない。
31
+ ## 使い方
200
32
 
201
- リリース時は`package.json`と両plugin manifestのバージョンを揃えてコミットし、`v<version>` tagを対象にGitHub Releaseを公開する。tagとバージョンが不一致なら停止する。既存のnpmバージョンは再公開できないため、次の変更には新しいバージョンを使う。
33
+ Claude Code では `/shinaps:<スキル名>`（例 `/shinaps:review`）で呼び出します。Codex では、新しいセッションで `shinaps:review` などのスキルが読み込まれます。
202
34
 
203
- npmの`@shinaps/skills`にGitHub ActionsのTrusted Publisherを登録する。GitHub ownerは`sh1n4ps`、repositoryは`shinaps-skills`、workflow filenameは`publish.yml`、direct publishを許可する。CIはGitHub-hosted Ubuntu・Node.js 24を使い、publish jobだけに`id-token: write`を付与する。`NPM_TOKEN` secretは不要。初回の信頼設定には本人認証が必要だが、その後のCI公開に毎回のセキュリティキー操作は不要。
35
+ よく使う流れ:
204
36
 
205
- ローカルで同じ配布検証を行うには`npm run verify:package`を使う。`RELEASE_TAG=v<version>`を付ければtag整合性も確認できる。npmのprovenanceは公開リポジトリからのTrusted Publishingが対象で、privateリポジトリでは生成されない。
37
+ 1. `explore` で今の挙動と変更の影響を調べる。要件が曖昧なら `spec` で仕様を詰める。
38
+ 2. Claude Code の `dev-claude` で実装する。体制（LITE・BASIC・ULTRA）を選ぶと、実装とは別の担当が計画や実装をレビューします。
39
+ 3. `simplify` で不要な構造を削り、`review` で差分を確かめる。
40
+ 4. `commit`・`create-pr`・`release` で、コミット・PR・公開を行う。これらは依頼されたとき、または合意した許可の範囲でだけ実行します。
206
41
 
207
- ### コード整形
42
+ スキルは、対象プロジェクトの `AGENTS.md`・`CLAUDE.md`・README・CI・既存のスクリプトから、対象の環境・必要な検証・公開の条件を読み取ります。書かれていない条件は、結果を左右するものだけを確認します。Linear と Claude Managed Agents 以外のスキルは、専用の設定ファイル無しで使えます。`linear-execute` での開発の進行には `.shinaps/linear.json`、Managed Agents への依頼には `.shinaps/managed.json` が必要です（下の「機能別の資料」）。
208
43
 
209
- `npm ci` で開発依存を導入し、`npm run format` でBiomeによる整形を行う。`npm run check` は整形と型 (`tsc --noEmit`) を検証する。`npm pack` と `npm publish` は `prepack` で自動的に `npm run build` を実行する。`npm run verify:package` は配布物の一覧を比較したうえで、tarballを一時ディレクトリにinstallして起動できることを確認する。Biomeは整形用途で使用し、lintとimportの自動整理は無効。Markdown・TOMLのエージェント定義は整形対象外。
44
+ ## スキル
210
45
 
211
- ## Shinaps AIとの接続
46
+ | 名前 | 用途 |
47
+ |---|---|
48
+ | `explore` | 対話しながら今の挙動と変更の影響を調べる |
49
+ | `spec` | 目的・仕様・実現方法を詰める |
50
+ | `dev-claude`（Claude のみ） | 選んだ体制で実装し、別の担当が独立にレビューする |
51
+ | `debug` | 不具合の原因を調べて確かめる |
52
+ | `review` | 差分や既存のコードをレビューする |
53
+ | `refine` | Shinaps AI の rule と実際のファイルを照合する |
54
+ | `extract-rules` | PR のレビューから rule を抽出する |
55
+ | `simplify` | 目的から見直して、不要な構造や手順を削る |
56
+ | `commit` | 変更を単位に分けてコミットする |
57
+ | `create-pr` | リポジトリの規約に合わせて PR を作る |
58
+ | `release` | 公開条件を確かめて公開し、対象の版を使えることを確かめる |
59
+ | `linear-plan` | 相談・Issue の作成と整理・プロジェクト設定を行う（実装はしない） |
60
+ | `linear-execute` | Linear の Issue を、設定に従って実装・QA・許可された公開まで進める |
61
+ | `managed-setup` | Claude Managed Agents の共通構成をアカウントへ導入・更新する |
62
+ | `managed-execute` | Claude Managed Agents へ実装を依頼し、結果を回収する |
63
+
64
+ ## 機能別の資料
65
+
66
+ | 知りたいこと | 資料 |
67
+ |---|---|
68
+ | 更新・削除・macOS での Codex の自動更新 | [導入と更新](docs/install.md) |
69
+ | `dev-claude` の体制と工程 | [実装体制の判断](plugins/shinaps-claude/references/dev/staffing.md)・[dev の工程](plugins/shinaps-claude/references/dev/workflow.md) |
70
+ | Linear での開発進行（`.shinaps/linear.json` の書き方・許可・auto と manual） | [プロジェクト設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md) |
71
+ | Claude Managed Agents（必要なもの・導入・依頼） | [設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)・[導入と更新](plugins/shinaps-claude/references/managed/setup.md)・[依頼と観測](plugins/shinaps-claude/references/managed/execute.md) |
72
+ | スキルが使う担当（サブエージェント）の一覧 | [サブエージェント](docs/agents.md) |
73
+ | 作業記録の保存先 | [作業記録](plugins/shinaps-claude/references/work-records.md) |
74
+ | このリポジトリの開発と npm への公開 | [開発と配布](docs/development.md) |
212
75
 
213
- rule照合・抽出が必要な工程には `shinaps-ai` MCPを登録する。サービスURLは `https://app.shinaps.ai/mcp`。ClaudeとCodexそれぞれのMCP設定形式・ログイン手順に従う。開発用localhostはローカルサーバーを利用する場合だけ追加する。
76
+ 旧版の設定は自動では変換しません。Linear は [config_version 1 からの移行](plugins/shinaps-claude/references/linear/configuration.md#config_version-1-からの移行)、Managed Agents は [version 1 からの移行](plugins/shinaps-claude/references/managed/configuration.md#version-1-からの移行)に従ってください。
214
77
 
215
- MCP設定・認証はインストールと独立して行う。既存登録があれば再利用し、同じサーバーをpluginとグローバル設定の両方に登録しない。認証情報はCLIで独自に管理しない。
78
+ ## Shinaps AI との接続
216
79
 
217
- Claude Code:
80
+ `refine`・`extract-rules` など rule を使う工程に必要です。導入とは別に設定し、既存の登録があれば再利用します。同じサーバーを plugin とグローバル設定の両方に登録しないでください。認証情報は各クライアントの認証で管理し、このリポジトリの CLI では扱いません。
218
81
 
219
82
  ```sh
83
+ # Claude Code（登録後、Claude Code 内の /mcp から認証）
220
84
  claude mcp add --transport http shinaps-ai https://app.shinaps.ai/mcp --scope user
221
- ```
222
-
223
- Claude Code内の`/mcp`から認証する。
224
-
225
- Codex:
226
85
 
227
- ```sh
86
+ # Codex
228
87
  codex mcp add shinaps-ai --url https://app.shinaps.ai/mcp
229
88
  codex mcp login shinaps-ai
230
89
  ```
231
90
 
232
- 未登録の利用者は[Shinaps AI](https://app.shinaps.ai)でアカウントを作成する。未認証でもスキルの導入は完了できる。MCPが使えないときに照合済みと報告しない。`simplify`・`commit`・`create-pr`・`release`・`linear-plan`・`linear-execute` の基本手順はMCP接続を必須としない。
233
-
234
- ## Subagents (Claude: 14 / Codex: 10)
235
-
236
- | Subagent | 配布 | 役割 |
237
- |---|---|---|
238
- | `shinaps-explorer` | 両方 | コードベース探索、必読ファイル抽出 |
239
- | `shinaps-investigator` | 両方 | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
240
- | `shinaps-architect` | Claudeのみ | dev で独立設計担当を置く場合（ULTRA、または追加した BASIC）の独立設計。メインの案を見ずに、要件・制約・規約・引き継いだ成果物から別案を返す |
241
- | `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70) と計画の簡素化。体制に応じて1〜2名で独立に指摘・修正案・削減の提案を返す |
242
- | `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。Claude の dev では、「可読性・慣習レビュー」「規約照合」「実装の簡素化」も同じ役割の種類として担う |
243
- | `shinaps-review-validator` | 両方 | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
244
- | `shinaps-simplifier` | Claudeのみ | `shinaps:simplify` の計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
245
- | `shinaps-refine-agent` | 両方 | rule 照合 (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
246
- | `shinaps-spec-writer` | 両方 | ヒアリング + 調査結果を spec.md 構造化 |
247
- | `shinaps-tech-surveyor` | 両方 | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
248
- | `shinaps-survey-validator` | 両方 | tech-surveyor の出典を WebFetch で再確認 |
249
- | `shinaps-debugger` | 両方 | 症状から根本原因の仮説立案 (コードトレース + WebSearch + GitHub Issue) |
250
- | `shinaps-debug-validator` | 両方 | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
251
- | `shinaps-split-reviewer` | Claudeのみ | `shinaps:commit` のmanualの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
252
-
253
- Claude版はMarkdown、Codex版はTOMLで役割を定義する。Managed Agents版（両pluginの `managed-agents/agents/`）はdevの3役割だけを、Claude版の `name`・`description`・本文に `ant apply` 用の frontmatter を付けたMarkdownで定義する。
254
-
255
- Claude版は全14エージェントが `opus / medium`。Codex版の役割定義はモデルを書かず、モデルと推論は親セッションから継承する。dev での担当の割り当ては[dev の工程](plugins/shinaps-claude/references/dev/workflow.md)にある。
256
-
257
- **subagent 内では shinaps MCP を直接呼び出さず、rule 全文は Skill 側から prompt 経由で渡す** 原則を全 system prompt に明記する。MCP呼び出しの利用量が重複しないようにするため。
258
-
259
-
260
- ## 作業成果物
261
-
262
- 作業記録は現在の作業先の `.shinaps/work/` に保存する。[作業記録の共通手順](plugins/shinaps-claude/references/work-records.md)に従い、既存の共有例外を保持し、workの除外が不足する場合だけ `/work/` を追加する。設定の共有方式は記録作成では変更しない。共通手順はClaude版を編集元としてCodex版へ複製し、テストで一致を確認する。
263
-
264
- ```text
265
- .shinaps/
266
- ├── .gitignore # 保存方式に応じた除外・共有対象の例外
267
- ├── linear.json # linear のプロジェクト設定（任意）
268
- ├── linear/ # linear の補足（任意）
269
- ├── managed.json # Managed Agents の依頼先リポジトリとアカウント別のvault（任意・Git対象外）
270
- └── work/
271
- ├── {日時}-{作業名}/
272
- ├── explorations/
273
- ├── specs/
274
- ├── reviews/
275
- └── debug/
276
- ```
277
-
278
- Managed Agentsのアカウントごとのlock・セッション記録・回収した出力は、リポジトリではなく `~/.local/share/shinaps-ai/skills/managed/<account>/` に置く（[設定とアカウント](plugins/shinaps-claude/references/managed/configuration.md)）。
279
-
280
- 旧 `.claude/shinaps/` の成果物はパスを指定して引き継げる。既存記録を自動移動・削除しない。共有する仕様書などの明示された納品先は尊重し、作業記録に秘密情報を含めない。
91
+ 接続していなくても、他のスキルは使えます。接続できないときに、rule を照合したとは報告しません。
281
92
 
282
93
  ## 対応範囲
283
94
 
284
- 各クライアント向けの実行手順を提供する。形式検証や配置確認と、各CLIで実際にワークフローを完走したことは区別する。CLI・MCP・ブラウザ・デバイスの有無に依存する工程は実行時に確認する。環境別の網羅的な動作保証は行わず、実際の利用で見つかった問題を改善する。
95
+ 各クライアント向けの手順を提供します。`linear-execute` は利用者本人の環境（ローカルの CLI や WebStorm）で使う前提です。CLI・MCP・ブラウザ・端末の有無に依存する工程は実行時に確かめ、環境ごとの網羅的な動作保証はしません。
285
96
 
286
97
  ## License
287
98
 
package/docs/agents.md ADDED
@@ -0,0 +1,24 @@
1
+ # サブエージェント
2
+
3
+ スキルが内部で起動する担当（サブエージェント）の一覧です。概要は [README](../README.md) を参照してください。
4
+
5
+ Claude 版は 14、Codex 版は 10 の担当を配布します。
6
+
7
+ | 担当 | 配布 | 役割 |
8
+ |---|---|---|
9
+ | `shinaps-explorer` | 両方 | コードベース探索、必読ファイル抽出 |
10
+ | `shinaps-investigator` | 両方 | `shinaps:explore` の現在の質問をコード・テスト・設定・履歴から調べ、確実性を分けて回答 |
11
+ | `shinaps-architect` | Claudeのみ | dev で独立設計担当を置く場合（ULTRA、または追加した BASIC）の独立設計。メインの案を見ずに、要件・制約・規約・引き継いだ成果物から別案を返す |
12
+ | `shinaps-plan-reviewer` | Claudeのみ | 計画レビュー (confidence 閾値 70) と計画の簡素化。体制に応じて1〜2名で独立に指摘・修正案・削減の提案を返す |
13
+ | `shinaps-reviewer` | 両方 | logic / design / security / performance / maintainability / rule 統合レビュー (confidence 閾値 80)。Claude の dev では、「可読性・慣習レビュー」「規約照合」「実装の簡素化」も同じ役割の種類として担う |
14
+ | `shinaps-review-validator` | 両方 | reviewer 指摘の実コード検証 (confirmed / false positive / partial / out-of-scope 分類) |
15
+ | `shinaps-simplifier` | Claudeのみ | `shinaps:simplify` の計画・実装の簡素化の提案。仕様・構造・処理の削減を読み取り専用で提案 |
16
+ | `shinaps-refine-agent` | 両方 | rule 照合 (ファイル現状全文と照合、Violation / Improvement / Question 分類 + changed / pre-existing 切り分け) |
17
+ | `shinaps-spec-writer` | 両方 | ヒアリング + 調査結果を spec.md 構造化 |
18
+ | `shinaps-tech-surveyor` | 両方 | 外部技術調査 (WebSearch + WebFetch で 3-5 候補比較) |
19
+ | `shinaps-survey-validator` | 両方 | tech-surveyor の出典を WebFetch で再確認 |
20
+ | `shinaps-debugger` | 両方 | 症状から根本原因の仮説立案 (コードトレース + WebSearch + GitHub Issue) |
21
+ | `shinaps-debug-validator` | 両方 | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
22
+ | `shinaps-split-reviewer` | Claudeのみ | `shinaps:commit` のmanualの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
23
+
24
+ Claude 版は全エージェントが `opus / medium` で動きます。Codex 版はモデルを指定せず、親セッションの設定を引き継ぎます。調査・レビューの担当は読み取り専用を既定にしますが、親セッションの実行時設定が優先される場合もあるため、権限の強制境界としては扱いません。
package/docs/development.md ADDED
@@ -0,0 +1,49 @@
1
+ # 開発と配布
2
+
3
+ このリポジトリを開発・公開する人向けの資料です。利用方法は [README](../README.md) を参照してください。
4
+
5
+ ## 構成と複製の方針
6
+
7
+ - Claude 版: `plugins/shinaps-claude/`、marketplace は `.claude-plugin/marketplace.json`
8
+ - Codex 版: `plugins/shinaps-codex/`、marketplace は `.agents/plugins/marketplace.json`。サブエージェントは `plugins/shinaps-codex/agents/`
9
+ - Claude Managed Agents 版: 両 plugin の `managed-agents/`。plugin と一緒に配布され、npm パッケージの `plugins/` にも含まれる
10
+ - 配布 CLI: ソースは `bin/skills.ts` と `lib/*.ts`。`npm run build`（`tsc`）で `dist/` に JS を出力し、npm にはそれを配布する。Node.js は `node_modules` 配下の `.ts` に型除去を適用しないため、ソースのままは配布できない。checkout では型除去で直接実行するので、`enum` など型除去で消せない構文は使わない（`tsconfig.json` の `erasableSyntaxOnly`）
11
+
12
+ 品質基準とプロジェクト設定の方針は両版で揃え、クライアント固有の実行手順とエージェントの形式は別々に管理する。スキルを追加・変更したら各版への適用可否を判断する。
13
+
14
+ - `references/`（`dev/launch.md` を除く）は Claude 版を編集元として Codex 版へ同じ内容を複製し、テストで一致を確認する。`SKILL.md` と役割の本文は版ごとに書き分け、Claude 向けの呼び出しを Codex に読み替えさせる方式は使わない。
15
+ - Managed の共通定義は `plugins/shinaps-claude/managed-agents/` を編集元として Codex 版へ複製し、テストで一致を確認する。Managed の skill の `staffing.md`・`workflow.md`・`launch.md` は Claude 版を写した適応版で一致はテストしないため、Claude 版の工程・体制の基準を変えたら Managed への適用可否を判断する。
16
+ - テスト方針は各版の `references/testing.md` を正本とし、その段落を役割定義と Managed の lead の定義に複製する。設計の観点は `references/dev/design.md` を正本とし、本文を独立設計担当（`shinaps-architect`）の定義と Managed の skill の `references/design.md` に複製する。どちらもテストで一致を確認する。
17
+ - 役割の定義は Claude 版が Markdown、Codex 版が TOML、Managed 版が `ant apply` 用の frontmatter を付けた Markdown。サブエージェント内では shinaps MCP を直接呼ばず、rule の全文はスキル側から渡す（MCP の利用量が重複しないようにするため）。この原則を全ての役割定義に書く。
18
+ - `autonomous-commit-review` の役割は `commit` に統合した。旧 `linear` の入口は廃止し、`linear-plan`・`linear-execute` に分けた。個人用の別 AI 呼び出し・ブラウザ管理・ゴール管理・動画制作はこの plugin に含めない。Bridge 本体は同梱せず、導入済みの MCP と WebStorm プラグインを使う。
19
+
20
+ ## ローカル開発
21
+
22
+ - Claude Code: marketplace にこの checkout の絶対パスを登録し、変更後に plugin を更新する。plugin のキャッシュは直接編集しない。更新後は新しいセッションで確認する。checkout を登録した場合はソースの git pull まで自動では行わない。
23
+ - Codex: checkout から `node bin/skills.ts install codex` のように同じ操作を実行できる。Node.js 22.18 以上なら型除去で TypeScript をそのまま実行する（ビルド不要）。開発中の同じ版も `update codex` で再配置できる。
24
+
25
+ ```sh
26
+ npm ci
27
+ npm test
28
+ npm run check
29
+ npm pack --dry-run
30
+ npm run verify:package
31
+ ```
32
+
33
+ `npm run format` で Biome による整形を行う。`npm run check` は整形と型（`tsc --noEmit`）を検証する。`npm pack` と `npm publish` は `prepack` で `npm run build` を実行する。`npm run verify:package` は配布物の一覧を比較したうえで、tarball を一時ディレクトリに install して起動できることを確かめる。`RELEASE_TAG=v<version>` を付けると tag との整合も確かめる。Biome は整形だけに使い、lint と import の自動整理は無効にしている。Markdown・TOML のエージェント定義は整形の対象外。
34
+
35
+ ## Managed Agents の定義の適用
36
+
37
+ 定義を変えたら `shinaps-skills managed setup` で計画を確かめてから `--apply` で適用する。`--prune`・`--force` は使わず、リソースを削除しない。lock はアカウントごとの管理ディレクトリ（`definitions/claude-lock.json`）に置き、リポジトリには置かない。古い置き場所からの移行は [version 1 からの移行](../plugins/shinaps-claude/references/managed/configuration.md#version-1-からの移行)に従う。
38
+
39
+ ## CI と npm への公開
40
+
41
+ `.github/workflows/publish.yml` は main への push・PR・手動実行でテストと配布内容を検証する。通常の GitHub Release を公開すると、検証の成功後に同じ tag のパッケージを npm へ公開する。prerelease と手動実行では公開しない。
42
+
43
+ - リリース時は `package.json` と両 plugin の manifest のバージョンを揃えてコミットし、`v<version>` の tag で GitHub Release を公開する。tag とバージョンが一致しなければ止まる。既存の npm の版は再公開できないため、次の変更には新しいバージョンを使う。`docs/install.md` の配布 CLI の導入コマンドと、`references/linear/configuration.md`（両版）の CLI の版も新しい版に揃える。設定例の `$schema` と同梱 schema の `$id`（Linear・Managed、両版）は、schema の契約を変えた版でだけ上げる。公開前に npm スコープ `@shinaps` の権限と tarball の内容を確認する。
44
+ - npm の `@shinaps/skills` には GitHub Actions の Trusted Publisher（owner `sh1n4ps`、repository `shinaps-skills`、workflow `publish.yml`、direct publish を許可）を登録している。publish job だけに `id-token: write` を付け、`NPM_TOKEN` secret は使わない。CI は GitHub-hosted の Ubuntu と Node.js 24 を使う。初回の信頼設定には本人認証が必要だが、その後の公開に毎回のセキュリティキー操作は不要。
45
+ - npm の provenance は公開リポジトリからの Trusted Publishing で生成される。
46
+
47
+ ## 公開物に書かない情報
48
+
49
+ このリポジトリと npm パッケージは公開される。個人の連絡先（plugin の manifest の author・owner には名前だけを書く）、秘密値、実在の Linear の project や Issue の URL、Managed Agents の組織・workspace・リソースの ID、端末の絶対パスを、配布物・資料・テストの例に書かない。例には架空の値を使う。運用に使う `.shinaps/linear.json` は対象の Linear project を記す必要があるため例外とする。
package/docs/install.md ADDED
@@ -0,0 +1,59 @@
1
+ # 導入と更新
2
+
3
+ Claude Code 版の更新と、Codex 版の導入・更新・削除・macOS での自動更新、配布 CLI の導入の詳細です。概要は [README](../README.md) を参照してください。
4
+
5
+ ## 導入・更新・削除
6
+
7
+ Node.js 22 以上と、`plugin marketplace add` / `plugin add` に対応した Codex CLI が必要です。Codex のスキルだけを使う場合、Claude Code のインストールは不要です。
8
+
9
+ ```sh
10
+ npx @shinaps/skills@latest install codex
11
+ npx @shinaps/skills@latest update codex
12
+ npx @shinaps/skills@latest uninstall codex
13
+ npx @shinaps/skills@latest recover codex
14
+ ```
15
+
16
+ `install` はスキルを Codex plugin として登録し、10 個のサブエージェントを `${CODEX_HOME:-~/.codex}/agents/` へ配置します。新しいセッションから使えます。
17
+
18
+ - 配布物は `~/.local/share/shinaps-ai/skills/codex/` に保持し、一時的な npx のキャッシュに依存しません。同じ親ディレクトリの `state.json` に、配置したエージェントと内容のハッシュを記録します。
19
+ - 管理対象外の同名ファイルや、導入後に編集されたエージェントは上書き・削除せずに止まります。必要な変更を退避してから再実行してください。`CODEX_HOME` を変える場合は、元の配置先で先に `uninstall` します。
20
+ - `update codex` は、配布されなくなった管理済みのエージェント（0.33.1 まで配置していた dev 専用の役割など）を削除します。
21
+ - `recover codex` は、中断した更新の記録が残っている場合に復元だけを行います。記録が無ければ何もしません。
22
+ - `uninstall` はこの CLI の plugin・marketplace・管理済みエージェントを取り除きます。個人のスキルと、別に登録した MCP の接続・認証情報は残します。
23
+
24
+ ## 配布 CLI
25
+
26
+ 設定の検証（`validate-linear-config`・`validate-managed-config`）と Managed Agents の操作（`managed`）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
27
+
28
+ ```sh
29
+ npm install -g @shinaps/skills@0.39.1
30
+ shinaps-skills --version
31
+ ```
32
+
33
+ ## Claude Code の更新
34
+
35
+ Claude Code は標準の marketplace の自動更新を使います。`/plugin` の Marketplaces から対象 marketplace の auto-update を有効にします。GitHub から自動で取得するには、GitHub のリポジトリを marketplace として登録します（[README のインストール](../README.md#インストール)）。
36
+
37
+ ## Codex の自動更新（macOS）
38
+
39
+ ```sh
40
+ npx @shinaps/skills@latest auto-update enable codex
41
+ npx @shinaps/skills@latest auto-update status codex
42
+ npx @shinaps/skills@latest auto-update check codex
43
+ npx @shinaps/skills@latest auto-update disable codex
44
+ ```
45
+
46
+ 初期状態は無効です。`enable` すると macOS のユーザー LaunchAgent を登録し、ログイン中に 1 日 1 回（12:00）、npm の `latest` が導入版より新しい安定版の場合だけ更新します。スリープ中に 12:00 を過ぎた場合は起床時に 1 回だけ実行し、電源が切れていた回は実行しません。古い版へは戻しません。更新は新しい Codex セッションから反映されます。
47
+
48
+ - `enable` は通常のログインシェルから実行します（Codex や Claude Code のセッション内からは実行しない）。登録時の PATH・npm の場所・`CODEX_HOME` を記録して以後も使うため、ツールの場所を変えたら再度 `enable` します。npm の設定は `~/.npmrc` のものを使います。
49
+ - 更新中にエラーが起きたら旧内容と Codex の plugin 登録を復元します。強制終了などで復元できなかった場合は、次の確認時か `recover codex` の実行時に `~/.local/share/shinaps-ai/skills/transaction/` の記録から復元します。復元にも失敗した場合は同じ場所にバックアップを残して止まるので、原因を直してから `recover codex` を実行します。導入後に編集されたファイルや、同時に実行中の別の更新があるときは、上書きせずに止まります。
50
+ - `status` は設定と最終確認結果を表示します。失敗の詳細は `~/.local/share/shinaps-ai/skills/auto-update-error.log`、通常のログは同じ場所の `auto-update.log` にあります。npm から取得できなかった場合は最終確認結果を更新せず、エラーログだけに記録します。通知は出しません。
51
+ - `disable` は予定実行を止め、導入したスキルは残します。`uninstall codex` も予定実行を止めます。macOS 以外では手動で更新します。
52
+
53
+ 登録直後の動作確認（`kickstart` はすぐ戻るので、npm の取得が終わるまで待ってから残りを実行）:
54
+
55
+ ```sh
56
+ launchctl kickstart -k gui/$(id -u)/io.shinaps.skills.update
57
+ launchctl print gui/$(id -u)/io.shinaps.skills.update | grep 'last exit code'
58
+ npx @shinaps/skills@latest auto-update status codex
59
+ ```
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@shinaps/skills",
3
- "version": "0.38.0",
3
+ "version": "0.39.1",
4
4
  "description": "Install Shinaps AI workflows and custom agents for Codex",
5
5
  "type": "module",
6
6
  "bin": {
@@ -8,6 +8,7 @@
8
8
  },
9
9
  "files": [
10
10
  "dist/",
11
+ "docs/",
11
12
  "plugins/",
12
13
  ".agents/plugins/marketplace.json",
13
14
  "README.md",
package/plugins/shinaps-claude/.claude-plugin/plugin.json CHANGED
@@ -1,10 +1,9 @@
1
1
  {
2
2
  "name": "shinaps",
3
3
  "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
4
- "version": "0.38.0",
4
+ "version": "0.39.1",
5
5
  "author": {
6
- "name": "shinaps",
7
- "email": "ryuta@shinaps.jp"
6
+ "name": "shinaps"
8
7
  },
9
8
  "homepage": "https://github.com/sh1n4ps/shinaps-skills",
10
9
  "repository": "https://github.com/sh1n4ps/shinaps-skills",
package/plugins/shinaps-claude/references/dev/launch.md CHANGED
@@ -7,5 +7,5 @@
7
7
  - 並行する担当はバックグラウンドで起動し、全担当の完了を待つ。同時に起動できなかった担当は、実行中の担当の完了後に起動する。
8
8
  - 同じ担当の継続は、同じ ID へ SendMessage で依頼する。
9
9
  - 対話セッションの質問は `AskUserQuestion` で一問ずつ行う。CodexからローカルCLIで受けた依頼（auto経路）では質問・障害・再開点を最終resultへ返してターンを終了し（CLI内で `AskUserQuestion` や入力待ちを行わない）、同じsessionのresumeで回答を受ける（[CLI手順](../linear/claude-cli.md)）。Bridgeで受けた依頼（manual経路の対話セッション）では人へ `AskUserQuestion` で確認し、決定を依頼元Codexへの報告に含める（[Bridge](../linear/bridge.md)）。進捗は `TaskCreate`・`TaskUpdate` で管理する。他スキル（`commit`・`create-pr`・`release`）への引き継ぎは `Skill` を使う。現在のセッションで提供されていないツールは仮定しない。
10
- - `EnterPlanMode` は使わない。bypassPermissions モード（リモート実行など）と両立させるため。
10
+ - `EnterPlanMode` は使わない。bypassPermissions モード（Linear auto経路のローカルCLI、リモート実行など）と両立させるため。
11
11
  - 起動・再開できない、または完了しない担当は未完了として記録し、[工程](workflow.md)の「役割と継続」の交代へ進む。交代もできなければ未完了として必要な判断を返す。他のモデルや Fable へ切り替えず、メインがその独立確認を代わりに行わない。
package/plugins/shinaps-claude/references/linear/claude-cli.md CHANGED
@@ -1,17 +1,17 @@
1
1
  # ローカルClaude CLIによる実装
2
2
 
3
- 通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で使うコマンドの許可を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
3
+ 通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` と `claude_cli_bypass_permissions` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で許可・禁止する操作を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
4
4
 
5
5
  パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位が生じた場合は[経路](configuration.md#経路)に従う。
6
6
 
7
7
  ## 起動と観測
8
8
 
9
- 通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
9
+ 通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。権限モードも同じ理由で、起動とすべてのresumeで `--permission-mode bypassPermissions` を指定する（下の「操作権限」）。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
10
10
 
11
- 依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
11
+ 依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。
12
12
 
13
13
  ```sh
14
- claude -p --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
14
+ claude -p --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
15
15
  ```
16
16
 
17
17
  途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待つ。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。通知を受け取れない場合だけ、起動または前回の確認から5分おきに同じprocessの終了だけを確認する。この5分は確認の間隔で、進行役の1回の待機の長さ（[実行](execution.md) の「待機の手順（進行役）」）とは別に扱い、短い待機から戻るたびには確認しない。終了を待つ間は、stream-json・stderr・出力ファイルなどのログや途中成果を読まない。異常の根拠がある場合と利用者に依頼された場合だけ、必要な範囲で調べる。新しいCLIを並行起動せず、終了したら終了コードを取得して結果を会話へ返す。
@@ -20,18 +20,24 @@ jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、
20
20
 
21
21
  ## 依頼・質問・修正・コミット
22
22
 
23
- promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作と起動時に渡す `--allowedTools` の個別エントリ、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
23
+ promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
24
24
 
25
25
  回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
26
26
 
27
27
  ```sh
28
- claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
28
+ claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
29
29
  ```
30
30
 
31
31
  resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠（askでは解決したmodeと回答の記録）を含める。完了報告は体制（必須担当の完了・未完了と合意による未実施を含む）と途中の増員、変更範囲、検証、未解決事項、単位案と予定差分、Local Agent QAの後に修正があった場合は変更記録（[qa.md](qa.md#qaの時点対象最終qa)）、commitした場合はSHA・単位照合・残差分・stash復元結果・修正サイクルで確定した変更を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
32
32
 
33
33
  ## 操作権限
34
34
 
35
- `review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
35
+ `review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動と同じsessionのresumeでは `--permission-mode bypassPermissions` を明示する。依頼で必要になる操作を個別のallowで事前に列挙しきれず、非対話では足りない許可を求められないまま作業が止まるためである。`--allowedTools` で個別の許可を足したり、dontAskなど別のモードで起動したりしない。`--permission-prompts none` は、bypassでも残る確認を入力待ちにせず拒否としてresultへ返すために付け、許可を付与しない。
36
36
 
37
- CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。
37
+ bypassでの起動には、`claude_cli` に加えて利用者が明示的に同意した `claude_cli_bypass_permissions`（または今回の明示依頼）が必要で、`claude_cli` だけをbypassへの同意とみなさない。同意が無ければCodexは起動前に人へ一問で確認し、回答まで起動しない。回答は同じIssueの起動とすべてのresumeに引き継ぐ。同意が得られなければauto経路では起動せず、許可不足のブロッカー（[実行](execution.md)）として報告する。manual経路で進めるかは利用者が決め、その場合は[経路](configuration.md#経路)のとおり設定（通常設定がaskなら同じIssueの選択）を見直してから着手する。
38
+
39
+ bypassはCLIの権限チェックを省くだけで、操作の許可ではない。Claudeが行う操作は依頼の範囲と、[共通設定](configuration.md)の `permissions`・合意済みの `review_flow` に限る。stage・commitは、QA後の差分確定の依頼を受けたときだけ `shinaps:commit` に従って行う。push・公開・外部への送信・破壊的操作は、それぞれの許可と工程に従う。CLIで実行できることや会話上の許可を、依頼の範囲外の操作の許可とは扱わない。
40
+
41
+ permission_denialsがあれば操作と理由を報告し、拒否を隠すsilent retryをしない。bypassでも残る拒否（deny設定・保護されたパス・組織の設定など）は、同じ指定で再依頼しても解消しない。依頼の範囲内で別の手段を指示できる場合だけ同じsessionへ再依頼し、それ以外や新しい許可が必要な場合はCodexが人へ確認する。
42
+
43
+ CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応、またはbypassPermissionsが組織の設定などで無効なら、状態を報告して停止し、別の権限モードへ切り替えて進めない。
package/plugins/shinaps-claude/references/linear/configuration.md CHANGED
@@ -4,10 +4,12 @@
4
4
 
5
5
  ## 検証CLIと契約版
6
6
 
7
- 利用中のskillとCLIの版を確認し、0.38.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.38.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
7
+ 利用中のskillとCLIの版を確認し、0.39.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.39.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
8
8
 
9
9
  0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
10
10
 
11
+ 0.39.0から許可 `claude_cli_bypass_permissions` を受理する。`config_version` は2のままで、0.33.0〜0.38.xのCLIと `$schema` のURLはこの許可を拒否するため、使う設定では `$schema` も0.39.0以降のURLにする。
12
+
11
13
  ```sh
12
14
  shinaps-skills --version
13
15
  shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
@@ -15,7 +17,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
15
17
 
16
18
  ローカル開発では `node bin/skills.ts validate-linear-config <file>` を使える。CLIは指定された一つのJSONを読み、同梱schemaで検証する。ネットワーク取得、正本探索、Git操作、入力変更、型変換、既定値の補完、未知キーの除去はしない。未知キーはroot・下位とも拒否する。成功は構造が有効なことだけを表し、許可の合意やLinearの状態・参照ファイルの存在は保証しない。
17
19
 
18
- `config_version` が欠落または旧版なら移行、未来版ならskillとCLIの更新、不正型なら設定修正を案内する。JSONコメントは使わず、運用条件は補足へ書く。`$schema` は公開npmパッケージの固定バージョンURLでエディタを補助する。sourceリポジトリは非公開のため、認証が必要なGitHub raw URLは使わない。CLIは外部のschemaを取得しない。
20
+ `config_version` が欠落または旧版なら移行、未来版ならskillとCLIの更新、不正型なら設定修正を案内する。JSONコメントは使わず、運用条件は補足へ書く。`$schema` は公開npmパッケージの固定バージョンURLでエディタを補助する。CLIは外部のschemaを取得しない。
19
21
 
20
22
  ## 配置と保存方式
21
23
 
@@ -70,12 +72,12 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
70
72
  | `$schema` | 任意のエディタ補助。固定URLは下記。CLIはこのURLを取得しない |
71
73
  | `config_storage` | `shared`（Git共有）または `local`（メインの作業ツリーだけに保存）。保存・読取規則は上記に従う |
72
74
  | `target.workspace` | Linearのworkspace |
73
- | `target.team` | チームのキー（例 `SHINAPS`） |
75
+ | `target.team` | チームのキー（例 `ENG`） |
74
76
  | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
75
77
  | `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） |
76
78
  | `statuses` | 状態キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
77
79
  | `stop_after` | 終了地点（下の「終了地点」） |
78
- | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli`、manual: `bridge_request`）も含む。許可なしは `[]` |
80
+ | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）も含む。許可なしは `[]` |
79
81
  | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
80
82
  | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
81
83
  | `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人が単位ごとに依頼したらAIがstage・commit）、または `{ "mode": "ask" }`（着手時に進行役が人へautoかmanualかを一問で確認し、回答を同じIssueの通常flowとして使う）。開始時の値（askでは回答）で経路も決まる（下の「経路」） |
@@ -92,7 +94,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
92
94
 
93
95
  | 通常設定 | 経路 | 必要な許可 | メインのモデル |
94
96
  | --- | --- | --- | --- |
95
- | `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli` | Opus。起動とすべてのresumeで `--model opus` を指定する |
97
+ | `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli`・`claude_cli_bypass_permissions` | Opus。起動とすべてのresumeで `--model opus` を指定する |
96
98
  | `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
97
99
  | `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 | 回答した経路のモデル |
98
100
 
@@ -152,7 +154,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
152
154
 
153
155
  1. 現在の設定・許可・補足・進行中Issueを確認する。
154
156
  2. `config_version: 2` にし、`implementation_skill`、`review_flow.tool`、`path_policy_overrides[].review_flow.tool` を削除する。
155
- 3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
157
+ 3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli` と `claude_cli_bypass_permissions`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
156
158
  4. `statuses` は変更しない。補足からCodex実装タスク・Managed・tool・人がコミットする条件の記述とそれらの資料へのリンクを除き、合意日付を残す。
157
159
  5. `$schema` を利用中の公開版のURLへ更新し、CLIで検証して読み戻す。
158
160
 
@@ -177,7 +179,8 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
177
179
  | --- | --- |
178
180
  | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
179
181
  | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
180
- | `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）の指定のほかは既存CLI設定を保持し、個別の操作権限を維持する（[手順](claude-cli.md)） |
182
+ | `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）と権限モードの指定のほかは既存CLI設定を保持する（[手順](claude-cli.md)）。bypassPermissionsでの起動への同意は含まない |
183
+ | `claude_cli_bypass_permissions` | auto経路のClaudeのローカルCLIを、起動と同じsessionのすべてのresumeで `--permission-mode bypassPermissions` にすることへの、利用者の継続的な同意。CLIの権限チェックを省くだけで、操作の許可を追加しない。Claudeの操作は依頼の範囲と他の許可・合意済みの `review_flow` に限る（[手順](claude-cli.md#操作権限)） |
181
184
  | `bridge_request` | manual経路で、CodexがBridgeで対話Claude Codeセッションへ行う依頼と報告の受け取り、および別会話との任意の進行の引き渡し。報告は照合材料であり、操作許可を変更しない（[手順](bridge.md)） |
182
185
  | `push` | 対象Issueの作業ブランチの通常のpush |
183
186
  | `pr_create` | 対象IssueのPRの作成と更新 |
@@ -187,7 +190,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
187
190
  | `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合、入口のメインは担当の作業を代わりに行わず、必要な許可を求める。worktreeの作成は含まない |
188
191
  | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
189
192
 
190
- - 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
193
+ - 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli`・`claude_cli_bypass_permissions` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
191
194
  - `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
192
195
  - この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、stage・commitは合意済みflow、その他はそれぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
193
196
  - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
@@ -214,13 +217,13 @@ manualの設定例。同じprojectを複数のリポジトリがそれぞれの
214
217
 
215
218
  ```json
216
219
  {
217
- "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.35.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
220
+ "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
218
221
  "config_version": 2,
219
222
  "config_storage": "shared",
220
223
  "target": {
221
- "workspace": "shinaps",
222
- "team": "SHINAPS",
223
- "project": "https://linear.app/shinaps/project/shinaps-ai-76ed13db8314"
224
+ "workspace": "your-workspace",
225
+ "team": "ENG",
226
+ "project": "https://linear.app/your-workspace/project/your-project-0123456789ab"
224
227
  },
225
228
  "team_settings": "existing_only",
226
229
  "statuses": {
package/plugins/shinaps-claude/references/linear/configuration.schema.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "$schema": "http://json-schema.org/draft-07/schema#",
3
- "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.35.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
3
+ "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
4
4
  "title": "Shinaps Linear configuration v2",
5
5
  "type": "object",
6
6
  "properties": {
@@ -142,6 +142,7 @@
142
142
  "issue_update",
143
143
  "development_operations",
144
144
  "claude_cli",
145
+ "claude_cli_bypass_permissions",
145
146
  "bridge_request",
146
147
  "dev_delegation",
147
148
  "push",
package/plugins/shinaps-claude/references/linear/workflow.md CHANGED
@@ -23,7 +23,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
23
23
 
24
24
  | 工程 | 状態キー | 内容と次へ進む条件 |
25
25
  | --- | --- | --- |
26
- | 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
26
+ | 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
27
27
  | 実装 | `coding`, `local_agent_qa` | Claudeのメインが依頼の体制の担当（BASIC・ULTRAでは追加の担当を含む）を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。manualでは人へユーザーのレビュー待ちと明示する。CodexがLocal Agent QA（判定記録と経路の整合、必須担当の照合を含む）を行う。依頼に書いた体制の必須担当（[実装体制の判断](../dev/staffing.md)）は、完了または合意の記録付きの未実施を合格とする。不合格（必須担当のそれ以外の未完了や代替を含む）なら同じsessionへ戻し、再QAは[初回QAの一部](qa.md#qaの時点対象最終qa)として合格まで続ける |
28
28
  | 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualではCodexはcommitを依頼せず、渡した後は報告を待つ。人のコミット開始依頼でClaudeが分割案を示し、人が単位ごとに依頼したcommitを行う。Codexは各コミットの単位照合と全体照合を行う。差分確定中の実装の修正は、devの修正サイクル（[工程](../dev/workflow.md)の「役割と継続」）で行い、ステータスは `code_review` のままにする。修正やコミットのたびにCodexのQAへ戻さない（[最終QA](qa.md#qaの時点対象最終qa)） |
29
29
  | 公開確認 | `post_commit`, `staging_agent_qa`, `staging_human_qa`, `release`, `production_agent_qa`, `production_human_qa` | 受入条件と許可に応じて必要なものだけ行う: push前の最終Agent QAとpushするHEADの照合（[最終QA](qa.md#qaの時点対象最終qa)）、push・PR作成、環境配備とStaging/ProductionのAgent QA、必要なHuman QA、merge・配備・公開。適用しない項目は理由を記録する |
package/plugins/shinaps-claude/references/managed/execute.md CHANGED
@@ -63,7 +63,7 @@ shinaps-skills managed collect --account <name> --session <ID>
63
63
  ```
64
64
 
65
65
  - セッションに紐づく Files（`changes.patch` と作業記録の tar）を、そのアカウントの `sessions/<ID>/outputs/` へ保存し、保存したパスを表示する。同じ名前のファイルは最新のものだけを保存する（lead は毎ターン `changes.patch` を比較元からの全体の差分で置き換える）。名前がファイル名だけでないものは保存せずに止まる。保存したサイズは一覧の値と比べる。
66
- - CLI は差分を適用しない。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
66
+ - CLI は差分を適用しない。ローカルの CLI は git を呼ばず、自分では push しない。push と draft PR の作成は、許可した場合にセッション内の lead が行う。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
67
67
  - `コミット:` と push 先がある場合は `git fetch origin <head>` で head ブランチを取得し、base の SHA からのコミットと差分を確かめる。
68
68
  - `PR:` がある場合は `gh pr view <PR の URL> --json isDraft,baseRefName,headRefName` または GitHub MCP の読み取りで、draft であること・base と head が合意どおりであることを確かめる。
69
69
 
package/plugins/shinaps-codex/.codex-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "shinaps",
3
- "version": "0.38.0",
3
+ "version": "0.39.1",
4
4
  "description": "Shinaps AIのCodex向け開発ワークフロー",
5
5
  "skills": "./skills/"
6
6
  }
package/plugins/shinaps-codex/references/linear/claude-cli.md CHANGED
@@ -1,17 +1,17 @@
1
1
  # ローカルClaude CLIによる実装
2
2
 
3
- 通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で使うコマンドの許可を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
3
+ 通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` と `claude_cli_bypass_permissions` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で許可・禁止する操作を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
4
4
 
5
5
  パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位が生じた場合は[経路](configuration.md#経路)に従う。
6
6
 
7
7
  ## 起動と観測
8
8
 
9
- 通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
9
+ 通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。権限モードも同じ理由で、起動とすべてのresumeで `--permission-mode bypassPermissions` を指定する（下の「操作権限」）。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
10
10
 
11
- 依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
11
+ 依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。
12
12
 
13
13
  ```sh
14
- claude -p --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
14
+ claude -p --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
15
15
  ```
16
16
 
17
17
  途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待つ。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。通知を受け取れない場合だけ、起動または前回の確認から5分おきに同じprocessの終了だけを確認する。この5分は確認の間隔で、進行役の1回の待機の長さ（[実行](execution.md) の「待機の手順（進行役）」）とは別に扱い、短い待機から戻るたびには確認しない。終了を待つ間は、stream-json・stderr・出力ファイルなどのログや途中成果を読まない。異常の根拠がある場合と利用者に依頼された場合だけ、必要な範囲で調べる。新しいCLIを並行起動せず、終了したら終了コードを取得して結果を会話へ返す。
@@ -20,18 +20,24 @@ jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、
20
20
 
21
21
  ## 依頼・質問・修正・コミット
22
22
 
23
- promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作と起動時に渡す `--allowedTools` の個別エントリ、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
23
+ promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
24
24
 
25
25
  回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
26
26
 
27
27
  ```sh
28
- claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
28
+ claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
29
29
  ```
30
30
 
31
31
  resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠（askでは解決したmodeと回答の記録）を含める。完了報告は体制（必須担当の完了・未完了と合意による未実施を含む）と途中の増員、変更範囲、検証、未解決事項、単位案と予定差分、Local Agent QAの後に修正があった場合は変更記録（[qa.md](qa.md#qaの時点対象最終qa)）、commitした場合はSHA・単位照合・残差分・stash復元結果・修正サイクルで確定した変更を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
32
32
 
33
33
  ## 操作権限
34
34
 
35
- `review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
35
+ `review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動と同じsessionのresumeでは `--permission-mode bypassPermissions` を明示する。依頼で必要になる操作を個別のallowで事前に列挙しきれず、非対話では足りない許可を求められないまま作業が止まるためである。`--allowedTools` で個別の許可を足したり、dontAskなど別のモードで起動したりしない。`--permission-prompts none` は、bypassでも残る確認を入力待ちにせず拒否としてresultへ返すために付け、許可を付与しない。
36
36
 
37
- CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。
37
+ bypassでの起動には、`claude_cli` に加えて利用者が明示的に同意した `claude_cli_bypass_permissions`（または今回の明示依頼）が必要で、`claude_cli` だけをbypassへの同意とみなさない。同意が無ければCodexは起動前に人へ一問で確認し、回答まで起動しない。回答は同じIssueの起動とすべてのresumeに引き継ぐ。同意が得られなければauto経路では起動せず、許可不足のブロッカー（[実行](execution.md)）として報告する。manual経路で進めるかは利用者が決め、その場合は[経路](configuration.md#経路)のとおり設定（通常設定がaskなら同じIssueの選択）を見直してから着手する。
38
+
39
+ bypassはCLIの権限チェックを省くだけで、操作の許可ではない。Claudeが行う操作は依頼の範囲と、[共通設定](configuration.md)の `permissions`・合意済みの `review_flow` に限る。stage・commitは、QA後の差分確定の依頼を受けたときだけ `shinaps:commit` に従って行う。push・公開・外部への送信・破壊的操作は、それぞれの許可と工程に従う。CLIで実行できることや会話上の許可を、依頼の範囲外の操作の許可とは扱わない。
40
+
41
+ permission_denialsがあれば操作と理由を報告し、拒否を隠すsilent retryをしない。bypassでも残る拒否（deny設定・保護されたパス・組織の設定など）は、同じ指定で再依頼しても解消しない。依頼の範囲内で別の手段を指示できる場合だけ同じsessionへ再依頼し、それ以外や新しい許可が必要な場合はCodexが人へ確認する。
42
+
43
+ CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応、またはbypassPermissionsが組織の設定などで無効なら、状態を報告して停止し、別の権限モードへ切り替えて進めない。
package/plugins/shinaps-codex/references/linear/configuration.md CHANGED
@@ -4,10 +4,12 @@
4
4
 
5
5
  ## 検証CLIと契約版
6
6
 
7
- 利用中のskillとCLIの版を確認し、0.38.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.38.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
7
+ 利用中のskillとCLIの版を確認し、0.39.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.39.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
8
8
 
9
9
  0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
10
10
 
11
+ 0.39.0から許可 `claude_cli_bypass_permissions` を受理する。`config_version` は2のままで、0.33.0〜0.38.xのCLIと `$schema` のURLはこの許可を拒否するため、使う設定では `$schema` も0.39.0以降のURLにする。
12
+
11
13
  ```sh
12
14
  shinaps-skills --version
13
15
  shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
@@ -15,7 +17,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
15
17
 
16
18
  ローカル開発では `node bin/skills.ts validate-linear-config <file>` を使える。CLIは指定された一つのJSONを読み、同梱schemaで検証する。ネットワーク取得、正本探索、Git操作、入力変更、型変換、既定値の補完、未知キーの除去はしない。未知キーはroot・下位とも拒否する。成功は構造が有効なことだけを表し、許可の合意やLinearの状態・参照ファイルの存在は保証しない。
17
19
 
18
- `config_version` が欠落または旧版なら移行、未来版ならskillとCLIの更新、不正型なら設定修正を案内する。JSONコメントは使わず、運用条件は補足へ書く。`$schema` は公開npmパッケージの固定バージョンURLでエディタを補助する。sourceリポジトリは非公開のため、認証が必要なGitHub raw URLは使わない。CLIは外部のschemaを取得しない。
20
+ `config_version` が欠落または旧版なら移行、未来版ならskillとCLIの更新、不正型なら設定修正を案内する。JSONコメントは使わず、運用条件は補足へ書く。`$schema` は公開npmパッケージの固定バージョンURLでエディタを補助する。CLIは外部のschemaを取得しない。
19
21
 
20
22
  ## 配置と保存方式
21
23
 
@@ -70,12 +72,12 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
70
72
  | `$schema` | 任意のエディタ補助。固定URLは下記。CLIはこのURLを取得しない |
71
73
  | `config_storage` | `shared`（Git共有）または `local`（メインの作業ツリーだけに保存）。保存・読取規則は上記に従う |
72
74
  | `target.workspace` | Linearのworkspace |
73
- | `target.team` | チームのキー（例 `SHINAPS`） |
75
+ | `target.team` | チームのキー（例 `ENG`） |
74
76
  | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
75
77
  | `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） |
76
78
  | `statuses` | 状態キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
77
79
  | `stop_after` | 終了地点（下の「終了地点」） |
78
- | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli`、manual: `bridge_request`）も含む。許可なしは `[]` |
80
+ | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）も含む。許可なしは `[]` |
79
81
  | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
80
82
  | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
81
83
  | `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人が単位ごとに依頼したらAIがstage・commit）、または `{ "mode": "ask" }`（着手時に進行役が人へautoかmanualかを一問で確認し、回答を同じIssueの通常flowとして使う）。開始時の値（askでは回答）で経路も決まる（下の「経路」） |
@@ -92,7 +94,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
92
94
 
93
95
  | 通常設定 | 経路 | 必要な許可 | メインのモデル |
94
96
  | --- | --- | --- | --- |
95
- | `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli` | Opus。起動とすべてのresumeで `--model opus` を指定する |
97
+ | `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli`・`claude_cli_bypass_permissions` | Opus。起動とすべてのresumeで `--model opus` を指定する |
96
98
  | `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
97
99
  | `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 | 回答した経路のモデル |
98
100
 
@@ -152,7 +154,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
152
154
 
153
155
  1. 現在の設定・許可・補足・進行中Issueを確認する。
154
156
  2. `config_version: 2` にし、`implementation_skill`、`review_flow.tool`、`path_policy_overrides[].review_flow.tool` を削除する。
155
- 3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
157
+ 3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli` と `claude_cli_bypass_permissions`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
156
158
  4. `statuses` は変更しない。補足からCodex実装タスク・Managed・tool・人がコミットする条件の記述とそれらの資料へのリンクを除き、合意日付を残す。
157
159
  5. `$schema` を利用中の公開版のURLへ更新し、CLIで検証して読み戻す。
158
160
 
@@ -177,7 +179,8 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
177
179
  | --- | --- |
178
180
  | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
179
181
  | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
180
- | `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）の指定のほかは既存CLI設定を保持し、個別の操作権限を維持する（[手順](claude-cli.md)） |
182
+ | `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）と権限モードの指定のほかは既存CLI設定を保持する（[手順](claude-cli.md)）。bypassPermissionsでの起動への同意は含まない |
183
+ | `claude_cli_bypass_permissions` | auto経路のClaudeのローカルCLIを、起動と同じsessionのすべてのresumeで `--permission-mode bypassPermissions` にすることへの、利用者の継続的な同意。CLIの権限チェックを省くだけで、操作の許可を追加しない。Claudeの操作は依頼の範囲と他の許可・合意済みの `review_flow` に限る（[手順](claude-cli.md#操作権限)） |
181
184
  | `bridge_request` | manual経路で、CodexがBridgeで対話Claude Codeセッションへ行う依頼と報告の受け取り、および別会話との任意の進行の引き渡し。報告は照合材料であり、操作許可を変更しない（[手順](bridge.md)） |
182
185
  | `push` | 対象Issueの作業ブランチの通常のpush |
183
186
  | `pr_create` | 対象IssueのPRの作成と更新 |
@@ -187,7 +190,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
187
190
  | `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合、入口のメインは担当の作業を代わりに行わず、必要な許可を求める。worktreeの作成は含まない |
188
191
  | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
189
192
 
190
- - 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
193
+ - 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli`・`claude_cli_bypass_permissions` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
191
194
  - `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
192
195
  - この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、stage・commitは合意済みflow、その他はそれぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
193
196
  - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
@@ -214,13 +217,13 @@ manualの設定例。同じprojectを複数のリポジトリがそれぞれの
214
217
 
215
218
  ```json
216
219
  {
217
- "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.35.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
220
+ "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
218
221
  "config_version": 2,
219
222
  "config_storage": "shared",
220
223
  "target": {
221
- "workspace": "shinaps",
222
- "team": "SHINAPS",
223
- "project": "https://linear.app/shinaps/project/shinaps-ai-76ed13db8314"
224
+ "workspace": "your-workspace",
225
+ "team": "ENG",
226
+ "project": "https://linear.app/your-workspace/project/your-project-0123456789ab"
224
227
  },
225
228
  "team_settings": "existing_only",
226
229
  "statuses": {
package/plugins/shinaps-codex/references/linear/configuration.schema.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "$schema": "http://json-schema.org/draft-07/schema#",
3
- "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.35.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
3
+ "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
4
4
  "title": "Shinaps Linear configuration v2",
5
5
  "type": "object",
6
6
  "properties": {
@@ -142,6 +142,7 @@
142
142
  "issue_update",
143
143
  "development_operations",
144
144
  "claude_cli",
145
+ "claude_cli_bypass_permissions",
145
146
  "bridge_request",
146
147
  "dev_delegation",
147
148
  "push",
package/plugins/shinaps-codex/references/linear/workflow.md CHANGED
@@ -23,7 +23,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
23
23
 
24
24
  | 工程 | 状態キー | 内容と次へ進む条件 |
25
25
  | --- | --- | --- |
26
- | 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
26
+ | 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
27
27
  | 実装 | `coding`, `local_agent_qa` | Claudeのメインが依頼の体制の担当（BASIC・ULTRAでは追加の担当を含む）を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。manualでは人へユーザーのレビュー待ちと明示する。CodexがLocal Agent QA（判定記録と経路の整合、必須担当の照合を含む）を行う。依頼に書いた体制の必須担当（[実装体制の判断](../dev/staffing.md)）は、完了または合意の記録付きの未実施を合格とする。不合格（必須担当のそれ以外の未完了や代替を含む）なら同じsessionへ戻し、再QAは[初回QAの一部](qa.md#qaの時点対象最終qa)として合格まで続ける |
28
28
  | 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualではCodexはcommitを依頼せず、渡した後は報告を待つ。人のコミット開始依頼でClaudeが分割案を示し、人が単位ごとに依頼したcommitを行う。Codexは各コミットの単位照合と全体照合を行う。差分確定中の実装の修正は、devの修正サイクル（[工程](../dev/workflow.md)の「役割と継続」）で行い、ステータスは `code_review` のままにする。修正やコミットのたびにCodexのQAへ戻さない（[最終QA](qa.md#qaの時点対象最終qa)） |
29
29
  | 公開確認 | `post_commit`, `staging_agent_qa`, `staging_human_qa`, `release`, `production_agent_qa`, `production_human_qa` | 受入条件と許可に応じて必要なものだけ行う: push前の最終Agent QAとpushするHEADの照合（[最終QA](qa.md#qaの時点対象最終qa)）、push・PR作成、環境配備とStaging/ProductionのAgent QA、必要なHuman QA、merge・配備・公開。適用しない項目は理由を記録する |
package/plugins/shinaps-codex/references/managed/execute.md CHANGED
@@ -63,7 +63,7 @@ shinaps-skills managed collect --account <name> --session <ID>
63
63
  ```
64
64
 
65
65
  - セッションに紐づく Files（`changes.patch` と作業記録の tar）を、そのアカウントの `sessions/<ID>/outputs/` へ保存し、保存したパスを表示する。同じ名前のファイルは最新のものだけを保存する（lead は毎ターン `changes.patch` を比較元からの全体の差分で置き換える）。名前がファイル名だけでないものは保存せずに止まる。保存したサイズは一覧の値と比べる。
66
- - CLI は差分を適用しない。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
66
+ - CLI は差分を適用しない。ローカルの CLI は git を呼ばず、自分では push しない。push と draft PR の作成は、許可した場合にセッション内の lead が行う。`changes.patch` は合意した base の SHA のチェックアウトで `git apply --check` してから、範囲と受入条件に対する差分を確かめる。適用するかは利用者と決める。
67
67
  - `コミット:` と push 先がある場合は `git fetch origin <head>` で head ブランチを取得し、base の SHA からのコミットと差分を確かめる。
68
68
  - `PR:` がある場合は `gh pr view <PR の URL> --json isDraft,baseRefName,headRefName` または GitHub MCP の読み取りで、draft であること・base と head が合意どおりであることを確かめる。
69
69
 
package/plugins/shinaps-codex/skills/linear-execute/SKILL.md CHANGED
@@ -11,7 +11,7 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
11
11
 
12
12
  着手時に作業先設定の通常の `review_flow.mode` で経路を決め、Issueの途中で切り替えない（[経路](../../references/linear/configuration.md#経路)）。
13
13
 
14
- - auto: [ローカルClaude CLI](../../references/linear/claude-cli.md)を起動し、質問への回答・修正・差分確定を同じsessionのresumeで依頼する。許可は `claude_cli`。
14
+ - auto: [ローカルClaude CLI](../../references/linear/claude-cli.md)を起動し、質問への回答・修正・差分確定を同じsessionのresumeで依頼する。許可は `claude_cli` と、起動・resumeを `--permission-mode bypassPermissions` にする同意の `claude_cli_bypass_permissions`。
15
15
  - manual: WebStorm内の対話Claude Codeセッションへ[Bridge](../../references/linear/bridge.md)で依頼する。人とClaudeの作業中は同じIssueへ指示を送らず（Claudeが依頼した途中確認への応答と、[UIの微調整](../../references/linear/workflow.md#codexによるuiの微調整)の人と調整したうえでの一時停止の依頼・返却を除く）、報告を待つ。QA合格後もcommitを依頼せず、QA結果と判定記録を渡して人の依頼によるcommitの報告を待つ。許可は `bridge_request`。
16
16
  - ask: Claudeへ依頼する前に、Issueの作業内容と推奨する経路の理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。記録・再質問しない条件・許可は[経路](../../references/linear/configuration.md#経路)に従う。Claudeへの依頼には解決したmodeと回答の記録を添える。
17
17