@shinaps/skills 0.34.2 → 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 +2 -2
- package/plugins/shinaps-claude/references/linear/configuration.md +1 -1
- package/plugins/shinaps-claude/references/linear/execution.md +11 -1
- package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
- package/plugins/shinaps-codex/references/linear/bridge.md +2 -2
- package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
- package/plugins/shinaps-codex/references/linear/execution.md +11 -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
|
@@ -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` のまま、Claude
|
|
32
|
+
- Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待ち方は [execution.md](execution.md) の「待機の手順（進行役）」に従う。報告の通知を受け取れるかは現物のツールで確認し、受け取れない場合は繰り返しの取得で代えず、下の「Bridgeが必要な工程で使えない場合」と同じく扱う。定期監視は別の依頼なしに始めない。
|
|
33
33
|
- 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
|
|
34
34
|
- Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
|
|
35
35
|
- Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにせず、経路を切り替えず、状態と必要な準備を利用者へ伝える（履歴）。
|
|
@@ -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
|
|
@@ -29,12 +29,22 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
|
|
|
29
29
|
原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
|
|
30
30
|
|
|
31
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)
|
|
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の手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。
|
|
@@ -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` のまま、Claude
|
|
32
|
+
- Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待ち方は [execution.md](execution.md) の「待機の手順（進行役）」に従う。報告の通知を受け取れるかは現物のツールで確認し、受け取れない場合は繰り返しの取得で代えず、下の「Bridgeが必要な工程で使えない場合」と同じく扱う。定期監視は別の依頼なしに始めない。
|
|
33
33
|
- 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
|
|
34
34
|
- Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
|
|
35
35
|
- Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにせず、経路を切り替えず、状態と必要な準備を利用者へ伝える（履歴）。
|
|
@@ -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
|
|
@@ -29,12 +29,22 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
|
|
|
29
29
|
原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
|
|
30
30
|
|
|
31
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)
|
|
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の手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。
|
|
@@ -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
|
|