@shinaps/skills 0.34.1 → 0.34.2
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/claude-cli.md +1 -1
- package/plugins/shinaps-claude/references/linear/configuration.md +1 -1
- package/plugins/shinaps-claude/references/linear/execution.md +2 -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 +2 -2
- 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 +2 -2
- package/plugins/shinaps-codex/references/linear/workflow.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.2` を導入し、`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.2
|
|
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
|
|
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
## 競合の回避と待機
|
|
30
30
|
|
|
31
31
|
- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない。
|
|
32
|
-
- Codexはゴールを `active`
|
|
32
|
+
- Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待機中は `read_messages` を繰り返し呼ばない（[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.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.34.2`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
|
|
8
8
|
|
|
9
9
|
```sh
|
|
10
10
|
shinaps-skills --version
|
|
@@ -28,8 +28,8 @@ 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) の「競合の回避と待機」に従う。待機中にログ・出力ファイル・Git差分・メッセージを繰り返し取得して進み具合を確かめない。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
|
|
33
33
|
- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
|
|
34
34
|
- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
|
|
35
35
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
@@ -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
|
|
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
## 競合の回避と待機
|
|
30
30
|
|
|
31
31
|
- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない。
|
|
32
|
-
- Codexはゴールを `active`
|
|
32
|
+
- Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待機中は `read_messages` を繰り返し呼ばない（[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.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.34.2`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
|
|
8
8
|
|
|
9
9
|
```sh
|
|
10
10
|
shinaps-skills --version
|
|
@@ -28,8 +28,8 @@ 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) の「競合の回避と待機」に従う。待機中にログ・出力ファイル・Git差分・メッセージを繰り返し取得して進み具合を確かめない。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
|
|
33
33
|
- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
|
|
34
34
|
- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
|
|
35
35
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
@@ -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
|
### 再確認せず進める条件
|