@shinaps/skills 0.35.2 → 0.35.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/configuration.md +1 -1
- package/plugins/shinaps-claude/references/linear/execution.md +1 -1
- package/plugins/shinaps-claude/references/linear/issue.md +11 -18
- package/plugins/shinaps-claude/references/linear/qa.md +1 -1
- package/plugins/shinaps-claude/references/linear/workflow.md +1 -0
- package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
- package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
- package/plugins/shinaps-codex/references/linear/execution.md +1 -1
- package/plugins/shinaps-codex/references/linear/issue.md +11 -18
- package/plugins/shinaps-codex/references/linear/qa.md +1 -1
- package/plugins/shinaps-codex/references/linear/workflow.md +1 -0
package/README.md
CHANGED
|
@@ -18,10 +18,10 @@ sharedで採用する `instructions.md` は共有JSONの `references.specificati
|
|
|
18
18
|
|
|
19
19
|
0.35.0から通常設定の `review_flow.mode` に `ask` を追加しました（パス別ルールは `auto`・`manual` だけ）。既存の設定は変更不要です。
|
|
20
20
|
|
|
21
|
-
CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.35.
|
|
21
|
+
CLIはpluginに含まれないため、利用中のskillと同じ `@shinaps/skills@0.35.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)）。
|
|
22
22
|
|
|
23
23
|
```sh
|
|
24
|
-
npm install -g @shinaps/skills@0.35.
|
|
24
|
+
npm install -g @shinaps/skills@0.35.3
|
|
25
25
|
shinaps-skills --version
|
|
26
26
|
shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
|
|
27
27
|
shinaps-skills validate-managed-config /absolute/repository/.shinaps/managed.json
|
package/package.json
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.35.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.35.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.3`）。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
|
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
|
|
15
15
|
対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
|
|
16
16
|
|
|
17
|
-
作業先リポジトリは、Issue
|
|
17
|
+
作業先リポジトリは、Issue本文に記載した作業先のリポジトリ名（共通テンプレートでは「実装方針」）で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。操作の許可は作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
|
|
18
18
|
|
|
19
19
|
「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を到達点として記録する。Doneより手前という理由だけで再確認しない。具体的に指定された到達点と設定が矛盾する場合だけ、開始前に相違を解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
|
|
20
20
|
|
|
@@ -45,12 +45,14 @@ Issueの作成・紐づけは作業の記録であり、担当・人のレビュ
|
|
|
45
45
|
## 共通Issueテンプレート
|
|
46
46
|
|
|
47
47
|
```markdown
|
|
48
|
-
##
|
|
49
|
-
|
|
48
|
+
## 背景・目的
|
|
49
|
+
今の困りごとと、それを解決する理由。
|
|
50
50
|
|
|
51
|
-
##
|
|
52
|
-
|
|
53
|
-
|
|
51
|
+
## できるようになること
|
|
52
|
+
誰が何をすると、何ができるようになるか。変更前と変更後の操作・結果・制約を、技術の説明を読まなくても分かるように書く。画面のない変更は、利用する人や運用への効果として書く。
|
|
53
|
+
|
|
54
|
+
## 実装方針
|
|
55
|
+
「できるようになること」をどう実現するかの短い設計。責務の分担、データの流れ、既存構成の変更を書く。作業先のリポジトリ名もここに書く。前提、依存するIssue、根拠（仕様の正本・要件ID・詳細設計）への参照は、ここか関係する欄に書く。ファイルの一覧や作業手順だけで設計の代わりにしない。
|
|
54
56
|
|
|
55
57
|
## 受入条件
|
|
56
58
|
### Agent QA
|
|
@@ -58,22 +60,13 @@ UIがある場合は代表スクショ、動きの説明には短い動画を添
|
|
|
58
60
|
### Human QA
|
|
59
61
|
- [ ] 人が確認する性質 — AIだけでは確認できない理由・環境
|
|
60
62
|
（不要なら「不要。」だけを記載）
|
|
61
|
-
|
|
62
|
-
## 検証状況
|
|
63
|
-
最新の合否・未確認事項と、詳細なQAコメントへのリンク。
|
|
64
|
-
|
|
65
|
-
## 対象・範囲外
|
|
66
|
-
作業先のリポジトリ名、担当範囲、前提、依存するIssue、引継ぎ先。
|
|
67
|
-
|
|
68
|
-
## 決定事項・参照
|
|
69
|
-
判断と理由、仕様の正本と要件ID、未決事項。
|
|
70
63
|
```
|
|
71
64
|
|
|
72
|
-
-
|
|
65
|
+
- 「実装方針」の作業先のリポジトリ名は、同じprojectを複数のリポジトリが使うときに、適用する設定を決めるために使う。ローカルの絶対パスは書かない。
|
|
73
66
|
- Linear側のテンプレート設定を変えることは別の設定操作である。本文への適用では変更しない。
|
|
74
67
|
|
|
75
68
|
## 書き方
|
|
76
69
|
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
-
|
|
70
|
+
- 一つの欄で一つの疑問に答え、空欄や定型文で埋めず、同じ情報を複数の欄に書かない。判断の要点（採用した案と理由、未決事項）は該当する欄の本文に書き、詳細な設計は参照先に置く。途中の議論と検証の詳細はコメントへ残し、採用した結論を本文へ統合する。長いログを本文へ貼らない。
|
|
71
|
+
- Issueの範囲は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)のとおり目的・変更内容・受入条件から判断するので、範囲外の一覧は作らず、誤解されやすい境界だけを該当する欄に書く。
|
|
72
|
+
- 「できるようになること」の説明に必要なら、画面はデザインやスクショ、操作や遷移は短い動画、画面のない処理は入出力の例を添える。
|
|
@@ -40,7 +40,7 @@ Codexは各工程のQA結果を、対応するIssueのコメントへ残す。
|
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
- 失敗や中断も記録し、成功の結果で過去の失敗を消さない。送信の再試行では重複したコメントを作らない。実際に再検証した場合は、新しい対象と結果を区別して記録する。長いログは必要な箇所を要約して証拠へリンクする。
|
|
43
|
-
-
|
|
43
|
+
- 最新の合否と未確認事項は最新のQAコメントで示し、コメント・添付・リンクを読み戻して確認する。
|
|
44
44
|
- 人のQAの結果は本人の報告に基づいて対象と結果を記録し、AIが代わりに合格を決めない。
|
|
45
45
|
|
|
46
46
|
## スクショ・動画
|
|
@@ -49,6 +49,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
|
|
|
49
49
|
|
|
50
50
|
- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
|
|
51
51
|
- **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
|
|
52
|
+
- **Issueの範囲**: 範囲はIssueの目的・変更内容・受入条件から判断する。記載のない作業でも、目的の実現に必要な手段は範囲に含む。仕様や範囲の拡大が必要になったら、進める前に次の「停止と人への確認」に従って確認する。
|
|
52
53
|
- **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
|
|
53
54
|
- 経過時間、無回答、Bridgeの送信成功・ack・peer通知、CLIのprocessの終了を、承認・完了・合格として扱わない。
|
|
54
55
|
- 人がClaudeへ直接伝えた指示・承認はClaudeが報告に含め、CodexはGitの状態と照合し、合意済みの設定・会話の許可範囲内で次へ進む。報告は新しい許可を作らない（[Bridge](bridge.md)）。既存の許可内の後続処理は人へ聞き直さない。
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.35.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.35.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.3`）。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
|
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
|
|
15
15
|
対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
|
|
16
16
|
|
|
17
|
-
作業先リポジトリは、Issue
|
|
17
|
+
作業先リポジトリは、Issue本文に記載した作業先のリポジトリ名（共通テンプレートでは「実装方針」）で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。操作の許可は作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
|
|
18
18
|
|
|
19
19
|
「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を到達点として記録する。Doneより手前という理由だけで再確認しない。具体的に指定された到達点と設定が矛盾する場合だけ、開始前に相違を解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
|
|
20
20
|
|
|
@@ -45,12 +45,14 @@ Issueの作成・紐づけは作業の記録であり、担当・人のレビュ
|
|
|
45
45
|
## 共通Issueテンプレート
|
|
46
46
|
|
|
47
47
|
```markdown
|
|
48
|
-
##
|
|
49
|
-
|
|
48
|
+
## 背景・目的
|
|
49
|
+
今の困りごとと、それを解決する理由。
|
|
50
50
|
|
|
51
|
-
##
|
|
52
|
-
|
|
53
|
-
|
|
51
|
+
## できるようになること
|
|
52
|
+
誰が何をすると、何ができるようになるか。変更前と変更後の操作・結果・制約を、技術の説明を読まなくても分かるように書く。画面のない変更は、利用する人や運用への効果として書く。
|
|
53
|
+
|
|
54
|
+
## 実装方針
|
|
55
|
+
「できるようになること」をどう実現するかの短い設計。責務の分担、データの流れ、既存構成の変更を書く。作業先のリポジトリ名もここに書く。前提、依存するIssue、根拠（仕様の正本・要件ID・詳細設計）への参照は、ここか関係する欄に書く。ファイルの一覧や作業手順だけで設計の代わりにしない。
|
|
54
56
|
|
|
55
57
|
## 受入条件
|
|
56
58
|
### Agent QA
|
|
@@ -58,22 +60,13 @@ UIがある場合は代表スクショ、動きの説明には短い動画を添
|
|
|
58
60
|
### Human QA
|
|
59
61
|
- [ ] 人が確認する性質 — AIだけでは確認できない理由・環境
|
|
60
62
|
（不要なら「不要。」だけを記載）
|
|
61
|
-
|
|
62
|
-
## 検証状況
|
|
63
|
-
最新の合否・未確認事項と、詳細なQAコメントへのリンク。
|
|
64
|
-
|
|
65
|
-
## 対象・範囲外
|
|
66
|
-
作業先のリポジトリ名、担当範囲、前提、依存するIssue、引継ぎ先。
|
|
67
|
-
|
|
68
|
-
## 決定事項・参照
|
|
69
|
-
判断と理由、仕様の正本と要件ID、未決事項。
|
|
70
63
|
```
|
|
71
64
|
|
|
72
|
-
-
|
|
65
|
+
- 「実装方針」の作業先のリポジトリ名は、同じprojectを複数のリポジトリが使うときに、適用する設定を決めるために使う。ローカルの絶対パスは書かない。
|
|
73
66
|
- Linear側のテンプレート設定を変えることは別の設定操作である。本文への適用では変更しない。
|
|
74
67
|
|
|
75
68
|
## 書き方
|
|
76
69
|
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
-
|
|
70
|
+
- 一つの欄で一つの疑問に答え、空欄や定型文で埋めず、同じ情報を複数の欄に書かない。判断の要点（採用した案と理由、未決事項）は該当する欄の本文に書き、詳細な設計は参照先に置く。途中の議論と検証の詳細はコメントへ残し、採用した結論を本文へ統合する。長いログを本文へ貼らない。
|
|
71
|
+
- Issueの範囲は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)のとおり目的・変更内容・受入条件から判断するので、範囲外の一覧は作らず、誤解されやすい境界だけを該当する欄に書く。
|
|
72
|
+
- 「できるようになること」の説明に必要なら、画面はデザインやスクショ、操作や遷移は短い動画、画面のない処理は入出力の例を添える。
|
|
@@ -40,7 +40,7 @@ Codexは各工程のQA結果を、対応するIssueのコメントへ残す。
|
|
|
40
40
|
```
|
|
41
41
|
|
|
42
42
|
- 失敗や中断も記録し、成功の結果で過去の失敗を消さない。送信の再試行では重複したコメントを作らない。実際に再検証した場合は、新しい対象と結果を区別して記録する。長いログは必要な箇所を要約して証拠へリンクする。
|
|
43
|
-
-
|
|
43
|
+
- 最新の合否と未確認事項は最新のQAコメントで示し、コメント・添付・リンクを読み戻して確認する。
|
|
44
44
|
- 人のQAの結果は本人の報告に基づいて対象と結果を記録し、AIが代わりに合格を決めない。
|
|
45
45
|
|
|
46
46
|
## スクショ・動画
|
|
@@ -49,6 +49,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
|
|
|
49
49
|
|
|
50
50
|
- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
|
|
51
51
|
- **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
|
|
52
|
+
- **Issueの範囲**: 範囲はIssueの目的・変更内容・受入条件から判断する。記載のない作業でも、目的の実現に必要な手段は範囲に含む。仕様や範囲の拡大が必要になったら、進める前に次の「停止と人への確認」に従って確認する。
|
|
52
53
|
- **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
|
|
53
54
|
- 経過時間、無回答、Bridgeの送信成功・ack・peer通知、CLIのprocessの終了を、承認・完了・合格として扱わない。
|
|
54
55
|
- 人がClaudeへ直接伝えた指示・承認はClaudeが報告に含め、CodexはGitの状態と照合し、合意済みの設定・会話の許可範囲内で次へ進む。報告は新しい許可を作らない（[Bridge](bridge.md)）。既存の許可内の後続処理は人へ聞き直さない。
|