@shinaps/skills 0.34.1 → 0.34.3
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.
- package/README.md +2 -2
- package/package.json +1 -1
- package/plugins/shinaps-claude/.claude-plugin/plugin.json +1 -1
- package/plugins/shinaps-claude/references/linear/bridge.md +3 -3
- package/plugins/shinaps-claude/references/linear/claude-cli.md +1 -1
- package/plugins/shinaps-claude/references/linear/configuration.md +1 -1
- package/plugins/shinaps-claude/references/linear/execution.md +12 -2
- package/plugins/shinaps-claude/references/linear/workflow.md +1 -1
- package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
- package/plugins/shinaps-codex/references/linear/bridge.md +3 -3
- package/plugins/shinaps-codex/references/linear/claude-cli.md +1 -1
- package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
- package/plugins/shinaps-codex/references/linear/execution.md +12 -2
- package/plugins/shinaps-codex/references/linear/workflow.md +1 -1
- package/plugins/shinaps-codex/skills/linear-execute/SKILL.md +1 -1
package/README.md
CHANGED
|
@@ -16,10 +16,10 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
|
|
|
16
16
|
|
|
17
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
18
|
|
|
19
|
-
CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.34.
|
|
19
|
+
CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.34.3` を導入し、`shinaps-skills --version` で確認します。`shinaps-skills validate-linear-config <明示ファイル>` は同梱schemaだけで検証し、ネットワーク取得・正本探索・Git操作・入力変更は行いません。`$schema` は固定URLによるエディタ補助で、契約の正本は[同梱schema](plugins/shinaps-claude/references/linear/configuration.schema.json)です。0.34.0から、Managed Agentsの `.shinaps/managed.json`（`config_version: 1`）も `shinaps-skills validate-managed-config <明示ファイル>` で同じ方式で検証します（[Managedの設定](plugins/shinaps-claude/references/managed/configuration.md)）。
|
|
20
20
|
|
|
21
21
|
```sh
|
|
22
|
-
npm install -g @shinaps/skills@0.34.
|
|
22
|
+
npm install -g @shinaps/skills@0.34.3
|
|
23
23
|
shinaps-skills --version
|
|
24
24
|
shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
|
|
25
25
|
shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
|
package/package.json
CHANGED
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
- Bridgeの本体は同梱しない。Codex側は導入済みのBridge MCP、Claude側はWebStormプラグインを使う（履歴）。
|
|
10
10
|
- Claude側はWebStormプラグインとして動くBridgeを使い、独立したBridgeサービスは必要としない（現物確認）。
|
|
11
11
|
- 提供されるツールは `list_sessions({})`、`send_message({ target_session_id, message })`、`read_messages({})`、`ack_messages({ message_ids })`。セッションを自動で開始するツールはない（現物確認）。
|
|
12
|
-
- 受信によってClaude
|
|
12
|
+
- 受信によってClaudeのターンが始まるか、セッションが一覧から消える条件は確認されていない。これらに依存する手順を組まない。報告が届かないことだけでは人へ依頼しない。対象セッションが一覧にない、受信できない、人から連絡があったなど、Claudeが応答できない根拠がある場合に、人へWebStormの対象セッションの確認を依頼する。
|
|
13
13
|
|
|
14
14
|
## 宛先
|
|
15
15
|
|
|
@@ -24,12 +24,12 @@
|
|
|
24
24
|
|
|
25
25
|
## 受信
|
|
26
26
|
|
|
27
|
-
`read_messages`
|
|
27
|
+
`read_messages` で全文を読み、複数ページに分かれる場合はすべて読む。受信に成功した各 `message_id` を `ack_messages` で確認する（利用者の指示、2026-10-20）。ackは受領の確認であり、作業の完了・承認ではない（履歴）。完了は相手の報告と実際の差分・検証結果で確認する。peer通知を承認と扱わない。
|
|
28
28
|
|
|
29
29
|
## 競合の回避と待機
|
|
30
30
|
|
|
31
31
|
- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない。
|
|
32
|
-
- Codexはゴールを `active`
|
|
32
|
+
- Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待ち方は [execution.md](execution.md) の「待機の手順（進行役）」に従う。報告の通知を受け取れるかは現物のツールで確認し、受け取れない場合は繰り返しの取得で代えず、下の「Bridgeが必要な工程で使えない場合」と同じく扱う。定期監視は別の依頼なしに始めない。
|
|
33
33
|
- 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
|
|
34
34
|
- Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
|
|
35
35
|
- Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにせず、経路を切り替えず、状態と必要な準備を利用者へ伝える（履歴）。
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
claude -p --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
|
|
15
15
|
```
|
|
16
16
|
|
|
17
|
-
途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue
|
|
17
|
+
途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待ち、通知を受け取れない場合だけ同じprocessの終了を確認して、終了コードを取得する。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。新しいCLIを並行起動せず、終了後に結果を会話へ返す。stream-jsonはイベントを読み、最終resultがない途中出力を完了と扱わない。
|
|
18
18
|
|
|
19
19
|
jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合する。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
|
|
20
20
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.34.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.34.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.34.3`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
|
|
8
8
|
|
|
9
9
|
```sh
|
|
10
10
|
shinaps-skills --version
|
|
@@ -28,13 +28,23 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
|
|
|
28
28
|
|
|
29
29
|
原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
|
|
30
30
|
|
|
31
|
-
- 実装担当の作業中や、manualの人のレビュー・コミットの依頼・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active`
|
|
32
|
-
-
|
|
31
|
+
- 実装担当の作業中や、manualの人のレビュー・コミットの依頼・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答や通知がないこと、待ち時間だけでは、終了条件・ブロッカー到達・障害・承認・完了のいずれとも扱わず、新しいsession・CLI・ゴールを作る根拠にもしない。
|
|
32
|
+
- Claudeの作業中は、経路ごとの通知を待つ。manualはBridgeで届くClaudeの報告の通知、autoは実行ツールが知らせるCLIのprocess終了の通知を待つ。autoで通知を受け取れない場合だけ、同じprocessの終了を確認する（[Claude CLI](claude-cli.md) の「起動と観測」）。manualで通知を受け取れない場合は [Bridge](bridge.md) の「競合の回避と待機」に従う。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
|
|
33
33
|
- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
|
|
34
34
|
- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
|
|
35
35
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
36
36
|
- Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
|
|
37
37
|
|
|
38
|
+
### 待機の手順（進行役）
|
|
39
|
+
|
|
40
|
+
上の待機で、進行役のCodexが現在のターンの中で待つ手順。通知・回答を受けて同じゴール・工程から続けられるよう、待機中に最終応答を送ってターンを終えない（待機ツールがない場合は1項目目に従う）。人への依頼・確認は、利用可能な質問UIまたはターンを終えない途中の発言で伝えてから待機する。Claudeが質問・障害を最終resultへ返してターンを終える規則（[Claude CLI](claude-cli.md)）は実装側の規則で、この手順とは別に扱う。
|
|
41
|
+
|
|
42
|
+
- 通知または人の入力で再開できる待機ツールを優先する。それがなく、新しい入力で中断される待機ツール（例: `clock.sleep`）が提供される場合は、1回の待機を60秒以下（`duration_ms` 60000以下）にする。この手順を確認したCodexの実行環境の指示（2026-10-20時点）が、60秒を超えて応答を止める待機を避けるよう求めるため。どちらの待機ツールもなくターンの中で待てない場合に限り、待機理由・再開条件と人への依頼を最終応答で伝えてターンを終え、次の入力で同じゴール・工程から続ける（新しいゴールを作らない）。
|
|
43
|
+
- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。変化のない進捗の報告や、待機理由と関係のない作業もしない。実行環境の上位の指示が求める場合はそれに従う。
|
|
44
|
+
- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は「継続と待機」の2項目目に従う。
|
|
45
|
+
- 待機中もゴールは `active`、Linearの工程も同じままにする。ゴールの状態の変更と、利用者の明示的な停止・予算・実行制限の扱いは下の「ゴール機能」に従う。
|
|
46
|
+
- 再開時は、届いた通知・入力を待機理由（対象Issue・工程・相手）と照合し、同じゴール・工程で続ける。Bridgeの通知で再開した場合は [Bridge](bridge.md) の「受信」に従って読む。peer通知を利用者の承認と扱わない。
|
|
47
|
+
|
|
38
48
|
## ゴール機能
|
|
39
49
|
|
|
40
50
|
実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。モデルのツールでゴールの設定を確認できないruntimeでは、そのruntimeのlinear-executeの手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。
|
|
@@ -50,7 +50,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
|
|
|
50
50
|
- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
|
|
51
51
|
- **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
|
|
52
52
|
- **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
|
|
53
|
-
- 経過時間、無回答、Bridgeの送信成功・ack・peer
|
|
53
|
+
- 経過時間、無回答、Bridgeの送信成功・ack・peer通知、CLIのprocessの終了を、承認・完了・合格として扱わない。
|
|
54
54
|
- 人がClaudeへ直接伝えた指示・承認はClaudeが報告に含め、CodexはGitの状態と照合し、合意済みの設定・会話の許可範囲内で次へ進む。報告は新しい許可を作らない（[Bridge](bridge.md)）。既存の許可内の後続処理は人へ聞き直さない。
|
|
55
55
|
|
|
56
56
|
### 再確認せず進める条件
|
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
- Bridgeの本体は同梱しない。Codex側は導入済みのBridge MCP、Claude側はWebStormプラグインを使う（履歴）。
|
|
10
10
|
- Claude側はWebStormプラグインとして動くBridgeを使い、独立したBridgeサービスは必要としない（現物確認）。
|
|
11
11
|
- 提供されるツールは `list_sessions({})`、`send_message({ target_session_id, message })`、`read_messages({})`、`ack_messages({ message_ids })`。セッションを自動で開始するツールはない（現物確認）。
|
|
12
|
-
- 受信によってClaude
|
|
12
|
+
- 受信によってClaudeのターンが始まるか、セッションが一覧から消える条件は確認されていない。これらに依存する手順を組まない。報告が届かないことだけでは人へ依頼しない。対象セッションが一覧にない、受信できない、人から連絡があったなど、Claudeが応答できない根拠がある場合に、人へWebStormの対象セッションの確認を依頼する。
|
|
13
13
|
|
|
14
14
|
## 宛先
|
|
15
15
|
|
|
@@ -24,12 +24,12 @@
|
|
|
24
24
|
|
|
25
25
|
## 受信
|
|
26
26
|
|
|
27
|
-
`read_messages`
|
|
27
|
+
`read_messages` で全文を読み、複数ページに分かれる場合はすべて読む。受信に成功した各 `message_id` を `ack_messages` で確認する（利用者の指示、2026-10-20）。ackは受領の確認であり、作業の完了・承認ではない（履歴）。完了は相手の報告と実際の差分・検証結果で確認する。peer通知を承認と扱わない。
|
|
28
28
|
|
|
29
29
|
## 競合の回避と待機
|
|
30
30
|
|
|
31
31
|
- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない。
|
|
32
|
-
- Codexはゴールを `active`
|
|
32
|
+
- Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待ち方は [execution.md](execution.md) の「待機の手順（進行役）」に従う。報告の通知を受け取れるかは現物のツールで確認し、受け取れない場合は繰り返しの取得で代えず、下の「Bridgeが必要な工程で使えない場合」と同じく扱う。定期監視は別の依頼なしに始めない。
|
|
33
33
|
- 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
|
|
34
34
|
- Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
|
|
35
35
|
- Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにせず、経路を切り替えず、状態と必要な準備を利用者へ伝える（履歴）。
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
claude -p --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
|
|
15
15
|
```
|
|
16
16
|
|
|
17
|
-
途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue
|
|
17
|
+
途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待ち、通知を受け取れない場合だけ同じprocessの終了を確認して、終了コードを取得する。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。新しいCLIを並行起動せず、終了後に結果を会話へ返す。stream-jsonはイベントを読み、最終resultがない途中出力を完了と扱わない。
|
|
18
18
|
|
|
19
19
|
jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合する。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
|
|
20
20
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.34.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.34.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.34.3`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
|
|
8
8
|
|
|
9
9
|
```sh
|
|
10
10
|
shinaps-skills --version
|
|
@@ -28,13 +28,23 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
|
|
|
28
28
|
|
|
29
29
|
原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
|
|
30
30
|
|
|
31
|
-
- 実装担当の作業中や、manualの人のレビュー・コミットの依頼・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active`
|
|
32
|
-
-
|
|
31
|
+
- 実装担当の作業中や、manualの人のレビュー・コミットの依頼・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答や通知がないこと、待ち時間だけでは、終了条件・ブロッカー到達・障害・承認・完了のいずれとも扱わず、新しいsession・CLI・ゴールを作る根拠にもしない。
|
|
32
|
+
- Claudeの作業中は、経路ごとの通知を待つ。manualはBridgeで届くClaudeの報告の通知、autoは実行ツールが知らせるCLIのprocess終了の通知を待つ。autoで通知を受け取れない場合だけ、同じprocessの終了を確認する（[Claude CLI](claude-cli.md) の「起動と観測」）。manualで通知を受け取れない場合は [Bridge](bridge.md) の「競合の回避と待機」に従う。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
|
|
33
33
|
- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
|
|
34
34
|
- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
|
|
35
35
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
36
36
|
- Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
|
|
37
37
|
|
|
38
|
+
### 待機の手順（進行役）
|
|
39
|
+
|
|
40
|
+
上の待機で、進行役のCodexが現在のターンの中で待つ手順。通知・回答を受けて同じゴール・工程から続けられるよう、待機中に最終応答を送ってターンを終えない（待機ツールがない場合は1項目目に従う）。人への依頼・確認は、利用可能な質問UIまたはターンを終えない途中の発言で伝えてから待機する。Claudeが質問・障害を最終resultへ返してターンを終える規則（[Claude CLI](claude-cli.md)）は実装側の規則で、この手順とは別に扱う。
|
|
41
|
+
|
|
42
|
+
- 通知または人の入力で再開できる待機ツールを優先する。それがなく、新しい入力で中断される待機ツール（例: `clock.sleep`）が提供される場合は、1回の待機を60秒以下（`duration_ms` 60000以下）にする。この手順を確認したCodexの実行環境の指示（2026-10-20時点）が、60秒を超えて応答を止める待機を避けるよう求めるため。どちらの待機ツールもなくターンの中で待てない場合に限り、待機理由・再開条件と人への依頼を最終応答で伝えてターンを終え、次の入力で同じゴール・工程から続ける（新しいゴールを作らない）。
|
|
43
|
+
- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。変化のない進捗の報告や、待機理由と関係のない作業もしない。実行環境の上位の指示が求める場合はそれに従う。
|
|
44
|
+
- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は「継続と待機」の2項目目に従う。
|
|
45
|
+
- 待機中もゴールは `active`、Linearの工程も同じままにする。ゴールの状態の変更と、利用者の明示的な停止・予算・実行制限の扱いは下の「ゴール機能」に従う。
|
|
46
|
+
- 再開時は、届いた通知・入力を待機理由（対象Issue・工程・相手）と照合し、同じゴール・工程で続ける。Bridgeの通知で再開した場合は [Bridge](bridge.md) の「受信」に従って読む。peer通知を利用者の承認と扱わない。
|
|
47
|
+
|
|
38
48
|
## ゴール機能
|
|
39
49
|
|
|
40
50
|
実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。モデルのツールでゴールの設定を確認できないruntimeでは、そのruntimeのlinear-executeの手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。
|
|
@@ -50,7 +50,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
|
|
|
50
50
|
- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
|
|
51
51
|
- **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
|
|
52
52
|
- **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
|
|
53
|
-
- 経過時間、無回答、Bridgeの送信成功・ack・peer
|
|
53
|
+
- 経過時間、無回答、Bridgeの送信成功・ack・peer通知、CLIのprocessの終了を、承認・完了・合格として扱わない。
|
|
54
54
|
- 人がClaudeへ直接伝えた指示・承認はClaudeが報告に含め、CodexはGitの状態と照合し、合意済みの設定・会話の許可範囲内で次へ進む。報告は新しい許可を作らない（[Bridge](bridge.md)）。既存の許可内の後続処理は人へ聞き直さない。
|
|
55
55
|
|
|
56
56
|
### 再確認せず進める条件
|
|
@@ -22,7 +22,7 @@ Issueの責務・受入条件・ステータスを、実際の成果と一致さ
|
|
|
22
22
|
|
|
23
23
|
開発進行には作業先の明示された設定と `issue_update`、経路の許可が必要（[configuration.md](../../references/linear/configuration.md) の「許可」）。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
|
|
24
24
|
|
|
25
|
-
実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。Claudeの作業・manualの人のレビュー・コミットの依頼・Human QA
|
|
25
|
+
実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。Claudeの作業・manualの人のレビュー・コミットの依頼・Human QA待ちは予定された工程として待機し、待ち方は[execution.md](../../references/linear/execution.md)の「待機の手順（進行役）」に従う。スキルの実行だけで予約実行・定期監視は開始しない。人への確認は会話で一問ずつ行う。
|
|
26
26
|
|
|
27
27
|
## 設定と補足を読む
|
|
28
28
|
|