@shinaps/skills 0.29.0 → 0.29.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.
- package/package.json +1 -1
- package/plugins/shinaps-claude/.claude-plugin/plugin.json +1 -1
- package/plugins/shinaps-claude/references/linear/codex-task.md +12 -0
- package/plugins/shinaps-claude/references/linear/configuration.md +1 -1
- package/plugins/shinaps-claude/references/linear/execution.md +2 -0
- 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/codex-task.md +12 -0
- package/plugins/shinaps-codex/references/linear/configuration.md +1 -1
- package/plugins/shinaps-codex/references/linear/execution.md +2 -0
- package/plugins/shinaps-codex/references/linear/workflow.md +1 -0
package/package.json
CHANGED
|
@@ -24,3 +24,15 @@ Issueリンク・範囲・受入条件・仕様や調査成果物、指定devス
|
|
|
24
24
|
実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
|
|
25
25
|
|
|
26
26
|
質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。
|
|
27
|
+
|
|
28
|
+
## 完了後の整理
|
|
29
|
+
|
|
30
|
+
会話側のCodexが、合意した終了条件への到達、成果・検証結果・未実施事項の記録、その実装タスクで続ける作業がないことを確認してから、専用の実装タスクだけをアーカイブする。実装担当の完了報告や、IssueのDone・ゴールの完了だけでは、この確認の代わりにならない。修正・QA・コミットなどの続きがあるタスク、停止中・ブロッカー待ちのタスク、人との窓口や他の作業と共有しているタスクは保持する。
|
|
31
|
+
|
|
32
|
+
アーカイブには、整理まで含む今回の利用者の明示合意、または対象・条件を確認できる記録済みの継続合意が必要。`codex_task` の許可だけからは推測せず、ツール固有の明示依頼条件も満たす。合意がない場合はタスクを保持し、整理が未実施であることを報告する。
|
|
33
|
+
|
|
34
|
+
1. ローカル作業記録の確定済み `threadId`・`hostId` とIssue・checkout・branchの対応を確認する。対象を確定できなければ操作しない。
|
|
35
|
+
2. `set_thread_archived` に、その `threadId`・`hostId` と `archived: true` を明示して実行する。IDを省略して呼出元を対象にしない。
|
|
36
|
+
3. 結果を確認し、対象と成否を作業記録に残す。結果が不明なら `list_threads`・`list_archived_threads`・`read_thread` など利用可能な読取手段で同じ対象の状態を確認する。一覧に見当たらないだけで成功と扱わず、状態を確定できない場合は重複操作せず未整理として報告する。ツールが利用不能・失敗の場合も、未整理の対象と理由を報告する。
|
|
37
|
+
|
|
38
|
+
この整理はブランチやworktreeの削除を含まない。タスク整理の成否は、終了地点への到達・IssueのDone・ゴールの状態と分けて記録する。
|
|
@@ -127,7 +127,7 @@ path_policy_overrides:
|
|
|
127
127
|
| --- | --- |
|
|
128
128
|
| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
|
|
129
129
|
| `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
|
|
130
|
-
| `codex_task` | 対象IssueごとのCodex
|
|
130
|
+
| `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。アーカイブ、worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす。アーカイブの合意と手順は [完了後の整理](codex-task.md#完了後の整理) に従う |
|
|
131
131
|
| `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
|
|
132
132
|
| `stage` | レビュー・コミットの対象差分だけをステージする |
|
|
133
133
|
| `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。パス別の `ai_commit` を含む実効方針に従う（上の「パス別の方針」） |
|
|
@@ -29,6 +29,8 @@
|
|
|
29
29
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
30
30
|
- Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
|
|
31
31
|
|
|
32
|
+
合意した終了地点に達して成果を記録した後、Codexの専用実装タスクは [完了後の整理](codex-task.md#完了後の整理) の条件に従って会話側が整理する。終了地点への到達・IssueのDone・ゴールの完了と、タスク整理の成否は分けて扱う。
|
|
33
|
+
|
|
32
34
|
## ゴール機能
|
|
33
35
|
|
|
34
36
|
実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。
|
|
@@ -53,6 +53,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
|
|
|
53
53
|
|
|
54
54
|
- 工程名を使うことは、チーム設定を変更する許可ではない。専用のステータスがないQA工程は進行中の状態に対応づけ、工程・待ち理由・再開条件をコメントへ記録する。`done` と途中の工程を同じ完了状態に対応づけない。
|
|
55
55
|
- QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
|
|
56
|
+
- Codexの専用実装タスクの整理は、終了条件への到達と成果記録を確認した後、会話側が [完了後の整理](codex-task.md#完了後の整理) に従って行う。タスクのアーカイブを工程・Issue・ゴールの完了確認の代わりにしない。
|
|
56
57
|
- 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業のレビュー・コミット・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
|
|
57
58
|
- 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
|
|
58
59
|
- 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
|
|
@@ -24,3 +24,15 @@ Issueリンク・範囲・受入条件・仕様や調査成果物、指定devス
|
|
|
24
24
|
実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
|
|
25
25
|
|
|
26
26
|
質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。
|
|
27
|
+
|
|
28
|
+
## 完了後の整理
|
|
29
|
+
|
|
30
|
+
会話側のCodexが、合意した終了条件への到達、成果・検証結果・未実施事項の記録、その実装タスクで続ける作業がないことを確認してから、専用の実装タスクだけをアーカイブする。実装担当の完了報告や、IssueのDone・ゴールの完了だけでは、この確認の代わりにならない。修正・QA・コミットなどの続きがあるタスク、停止中・ブロッカー待ちのタスク、人との窓口や他の作業と共有しているタスクは保持する。
|
|
31
|
+
|
|
32
|
+
アーカイブには、整理まで含む今回の利用者の明示合意、または対象・条件を確認できる記録済みの継続合意が必要。`codex_task` の許可だけからは推測せず、ツール固有の明示依頼条件も満たす。合意がない場合はタスクを保持し、整理が未実施であることを報告する。
|
|
33
|
+
|
|
34
|
+
1. ローカル作業記録の確定済み `threadId`・`hostId` とIssue・checkout・branchの対応を確認する。対象を確定できなければ操作しない。
|
|
35
|
+
2. `set_thread_archived` に、その `threadId`・`hostId` と `archived: true` を明示して実行する。IDを省略して呼出元を対象にしない。
|
|
36
|
+
3. 結果を確認し、対象と成否を作業記録に残す。結果が不明なら `list_threads`・`list_archived_threads`・`read_thread` など利用可能な読取手段で同じ対象の状態を確認する。一覧に見当たらないだけで成功と扱わず、状態を確定できない場合は重複操作せず未整理として報告する。ツールが利用不能・失敗の場合も、未整理の対象と理由を報告する。
|
|
37
|
+
|
|
38
|
+
この整理はブランチやworktreeの削除を含まない。タスク整理の成否は、終了地点への到達・IssueのDone・ゴールの状態と分けて記録する。
|
|
@@ -127,7 +127,7 @@ path_policy_overrides:
|
|
|
127
127
|
| --- | --- |
|
|
128
128
|
| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
|
|
129
129
|
| `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
|
|
130
|
-
| `codex_task` | 対象IssueごとのCodex
|
|
130
|
+
| `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。アーカイブ、worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす。アーカイブの合意と手順は [完了後の整理](codex-task.md#完了後の整理) に従う |
|
|
131
131
|
| `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
|
|
132
132
|
| `stage` | レビュー・コミットの対象差分だけをステージする |
|
|
133
133
|
| `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。パス別の `ai_commit` を含む実効方針に従う（上の「パス別の方針」） |
|
|
@@ -29,6 +29,8 @@
|
|
|
29
29
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
30
30
|
- Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
|
|
31
31
|
|
|
32
|
+
合意した終了地点に達して成果を記録した後、Codexの専用実装タスクは [完了後の整理](codex-task.md#完了後の整理) の条件に従って会話側が整理する。終了地点への到達・IssueのDone・ゴールの完了と、タスク整理の成否は分けて扱う。
|
|
33
|
+
|
|
32
34
|
## ゴール機能
|
|
33
35
|
|
|
34
36
|
実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。
|
|
@@ -53,6 +53,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
|
|
|
53
53
|
|
|
54
54
|
- 工程名を使うことは、チーム設定を変更する許可ではない。専用のステータスがないQA工程は進行中の状態に対応づけ、工程・待ち理由・再開条件をコメントへ記録する。`done` と途中の工程を同じ完了状態に対応づけない。
|
|
55
55
|
- QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
|
|
56
|
+
- Codexの専用実装タスクの整理は、終了条件への到達と成果記録を確認した後、会話側が [完了後の整理](codex-task.md#完了後の整理) に従って行う。タスクのアーカイブを工程・Issue・ゴールの完了確認の代わりにしない。
|
|
56
57
|
- 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業のレビュー・コミット・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
|
|
57
58
|
- 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
|
|
58
59
|
- 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
|