@shinaps/skills 0.24.0 → 0.25.0

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 CHANGED
@@ -30,7 +30,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
30
30
 
31
31
  コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
32
32
 
33
- `linear` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。未記載なら `dev-claude-ultra` で、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、Codexが自分で実装・QA指摘の修正・許可されたコミットを行う。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/` に置く。`references/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
33
+ `linear` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。運用項目はすべて明示必須で、未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude`・`dev-claude-ultra` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、Codexが自分で実装・QA指摘の修正・許可されたコミットを行う。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/` に置く。`references/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
34
34
 
35
35
  ### dev の入口
36
36
 
@@ -60,7 +60,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
60
60
 
61
61
  ## Codex
62
62
 
63
- Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear` の開発進行をClaudeの入口(`implementation_skill` の既定)で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。
63
+ Node.js 22以上と、`plugin marketplace add` / `plugin add` に対応したCodex CLIを使う。Claude Codeのインストールは不要。ただし `linear` の開発進行をClaudeの入口で行う場合は、Claude CodeとAI Terminal Bridgeが必要になる。
64
64
 
65
65
  導入・更新・削除:
66
66
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@shinaps/skills",
3
- "version": "0.24.0",
3
+ "version": "0.25.0",
4
4
  "description": "Install Shinaps AI workflows and custom agents for Codex",
5
5
  "type": "module",
6
6
  "bin": {
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "shinaps",
3
3
  "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
4
- "version": "0.24.0",
4
+ "version": "0.25.0",
5
5
  "author": {
6
6
  "name": "shinaps",
7
7
  "email": "ryuta@shinaps.jp"
@@ -19,14 +19,14 @@ description: 許可された差分を依存順のローカルコミットにし
19
19
 
20
20
  ## 範囲と進め方
21
21
 
22
- コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された(条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」)。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`(Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある)に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。設定がない、または値がこの2つ以外なら、利用可能な入力ツール(なければ文章)で「今回のコミットはどちらで進めますか?」と一問だけ聞く。
22
+ コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された(条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」)。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`(Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある)に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linearの開発進行では設定の不足・不正値を解消してから進む。linear以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール(なければ文章)で「今回のコミットはどちらで進めますか?」と一問だけ聞く。
23
23
 
24
24
  - **通常(推奨)**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
25
25
  - **自律**: エージェントが検証できる単位を選び(許可された一連の変更をまとめてよい)、検証・レビューして個別の承認を求めずコミットする。
26
26
 
27
27
  質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
28
28
 
29
- `commit_mode` は進め方の既定値であり、コミットの許可ではない。人のコードレビューの要否(`human_code_review`)や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード(単位ごとに承認を得る)で、人が自分でgit操作をする工程を指すものではない。
29
+ `commit_mode` は進め方の設定であり、コミットの許可ではない。人のコードレビューの要否(`human_code_review`)や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード(単位ごとに承認を得る)で、人が自分でgit操作をする工程を指すものではない。
30
30
 
31
31
  どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
32
32
 
@@ -5,7 +5,7 @@ description: Codexが進行するLinearの開発で、AI Terminal Bridge経由
5
5
 
6
6
  # Linearの開発でClaudeが行うこと
7
7
 
8
- 初版では、Codexが進行・Agent QA・人への窓口を担当する。作業先リポジトリの設定の `implementation_skill` がClaudeの入口(未記載を含む)のとき、ClaudeはAI Terminal Bridge(以下Bridge)経由の依頼で、技術調査と実装・修正を担当する。担当を入れ替えない。
8
+ 初版では、Codexが進行・Agent QA・人への窓口を担当する。作業先リポジトリの設定の `implementation_skill` がClaudeの入口のとき、ClaudeはAI Terminal Bridge(以下Bridge)経由の依頼で、技術調査と実装・修正を担当する。担当を入れ替えない。
9
9
 
10
10
  ## 再確認せず進める条件
11
11
 
@@ -28,23 +28,25 @@
28
28
 
29
29
  ## 項目
30
30
 
31
- | キー | 内容 | 未記載のとき |
32
- | --- | --- | --- |
33
- | `target.workspace` | Linearのworkspace | 開発進行を始めない |
34
- | `target.team` | チームのキー(例 `SHINAPS`) | 開発進行を始めない |
35
- | `target.project` | 使うprojectのURL。projectを使わない運用では `null` | 未決として扱い、project未使用とは推測しない。projectに依存する操作の前で止める |
36
- | `team_settings` | `existing_only`(既存の定義に合わせ、変更しない)または `manage_on_setup`(初期設定・設定変更のときだけ変更案を示し、合意後に整備できる) | `existing_only` |
37
- | `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる | そのキーの状態更新の前で止める |
38
- | `stop_after` | 終了地点(下の「終了地点」) | 開発進行を始めない |
39
- | `permissions` | 継続的に許可した操作の一覧(下の「許可」) | 何も許可していない |
40
- | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` ごとに、既存資料のパスまたはURLの一覧 | 各リポジトリのAGENTS.md・README・CIから読む |
41
- | `cycle_report` | Cycle報告の設定(下の「Cycle報告」) | Cycle報告を書き込まない |
42
- | `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`(CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する)、または `dev-codex`・`dev-codex-ultra`(Codexが自分でその入口を実行する) | `dev-claude-ultra`。値が4つ以外のときは、`coding` の工程の前で止めて一問確認する |
43
- | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`(単位ごとに承認を得る)または `autonomous`(個別の承認なしで単位ごとに検証してコミットする) | `shinaps:commit` が開始時に一問確認する。値が2つ以外のときも同じ |
44
- | `human_code_review` | 人のコードレビューの要否。`required`(人がレビューする)または `skip`(人のレビューを行わない) | `required`。値が2つ以外のときも同じ |
45
- | `document_only_changes` | 文書だけの変更(下の説明)の扱い。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする(Claudeの入口ではCodexの依頼でClaudeが行う) | 例外を使わない。値が `ai_commit` 以外のときも同じ |
46
-
47
- - `commit_mode` は進め方の既定値であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`(条件は下の「許可」)、または `document_only_changes: ai_commit` による文書だけの変更のコミットのときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程(`code_review`)とは別のもの。
31
+ 以下の項目はすべて明示必須。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
32
+
33
+ | キー | 内容 |
34
+ | --- | --- |
35
+ | `target.workspace` | Linearのworkspace |
36
+ | `target.team` | チームのキー(例 `SHINAPS`) |
37
+ | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
38
+ | `team_settings` | `existing_only`(既存の定義に合わせ、変更しない)または `manage_on_setup`(初期設定・設定変更のときだけ変更案を示し、合意後に整備できる) |
39
+ | `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
40
+ | `stop_after` | 終了地点(下の「終了地点」) |
41
+ | `permissions` | 継続的に許可した操作の一覧(下の「許可」)。許可なしは `[]` |
42
+ | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
43
+ | `cycle_report` | Cycle報告の設定(下の「Cycle報告」)。報告を使わない場合は `null` |
44
+ | `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`(CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する)、または `dev-codex`・`dev-codex-ultra`(Codexが自分でその入口を実行する) |
45
+ | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`(単位ごとに承認を得る)または `autonomous`(個別の承認なしで単位ごとに検証してコミットする) |
46
+ | `human_code_review` | 人のコードレビューの要否。`required`(人がレビューする)または `skip`(人のレビューを行わない) |
47
+ | `document_only_changes` | 文書だけの変更(下の説明)の扱い。`none` は例外なし。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする(Claudeの入口ではCodexの依頼でClaudeが行う) |
48
+
49
+ - `commit_mode` は進め方の設定であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`(条件は下の「許可」)、または `document_only_changes: ai_commit` による文書だけの変更のコミットのときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程(`code_review`)とは別のもの。
48
50
  - `implementation_skill` が決めるのは、実装・修正の担当と実行方式だけである。`permissions`・`stop_after`・`human_code_review`・`commit_mode`・`document_only_changes` の意味と、`dev_delegation`・worktreeの作成・別セッションの作成の許可を変えない。その場の明示的な指定は設定に優先する。既存の設定にキーがなくても、自動で書き加えない。担当と工程の対応は [workflow.md](workflow.md) の「担当と窓口」にある。
49
51
  - `human_code_review: skip` は人のレビューの工程だけを省く。devの入口内のレビュー、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。`human_code_review`・`commit`・`stage`・`commit_mode`・`document_only_changes` は互いに独立しており、一つから他を推測しない。
50
52
  - `document_only_changes: ai_commit` は、文書だけの変更について、`human_code_review: required` でも人のレビューを省き、`commit` の許可がなくてもAIのコミットを認める。`stage` の許可は通常のコミットと同じく必要で、ほかのキーの意味と許可は変えず、push以降の操作、利用中のツールの権限、利用者の停止・撤回(「設定の読み方」)を上書きしない。
@@ -81,20 +83,22 @@
81
83
  | `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
82
84
  | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する(LinearのIssueへの添付は `issue_update` に含む) |
83
85
 
84
- - 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口(未記載を含む)のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する(Codexの入口を選ぶ場合は `bridge_request` を除く)。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
86
+ - 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する(Codexの入口を選ぶ場合は `bridge_request` を除く)。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
85
87
  - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする(マージで本番へ自動配備される場合は `merge` と `deploy:production`)。
86
88
  - 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
87
89
  - 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
88
90
 
89
91
  ## Cycle報告
90
92
 
93
+ 報告を使う場合は次のサブキーをすべて記載する。使わない場合は `cycle_report: null` とする。
94
+
91
95
  | サブキー | 内容 |
92
96
  | --- | --- |
93
97
  | `qa_scope` | 全体QAの対象となる環境・端末の一覧 |
94
98
  | `destination` | 報告本文の保存先(例 `linear_cycle_document`) |
95
99
  | `index` | 索引のURL、または `null` |
96
100
  | `audience` | 読み手 |
97
- | `format` | 既存の書式や直近の報告への参照(任意) |
101
+ | `format` | 既存の書式や直近の報告への参照。個別の書式指定なしは `null`(共通テンプレートを使う) |
98
102
 
99
103
  書き込むのは `destination` と `index` だけ。記載のない報告先や送信先には、補足ファイルに書かれていても書き込まない。
100
104
 
@@ -122,12 +126,20 @@ statuses:
122
126
  done: Done
123
127
  stop_after: pre_push_qa
124
128
  implementation_skill: dev-claude-ultra # CodexがBridgeでClaudeへ依頼する。Codexが実装する場合は dev-codex-ultra など
129
+ human_code_review: required
130
+ commit_mode: autonomous
131
+ document_only_changes: none
132
+ cycle_report: null
125
133
  permissions:
126
134
  - issue_update
127
135
  - bridge_request
128
136
  - stage
129
137
  - dev_delegation
130
138
  references:
139
+ specifications:
140
+ - README.md
141
+ environments: []
142
+ deployment: []
131
143
  validation:
132
144
  - README.md#開発と配布
133
145
  - package.json
@@ -144,7 +156,7 @@ Codexが行う。
144
156
  1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
145
157
  2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。
146
158
  3. 設定案を一つ作る。チーム設定を管理できる場合だけ、FamilyStayを基にした工程の分離([workflow.md](workflow.md) の工程表に対応するステータス)を変更案として示す。利用者のプロジェクトらしいという推測で `manage_on_setup` にしない。
147
- 4. 既存の情報で決まらない運用上の決定(`stop_after`、`permissions`(`commit` を含む)、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`(既定値 `dev-claude-ultra` を示す))だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲(「項目」の説明)を示して、設定するかを確認する。
159
+ 4. 既存の情報で決まらない運用上の決定(`stop_after`、`permissions`(`commit` を含む)、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`)だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲(「項目」の説明)を示して、`ai_commit` を設定するかを確認する。例外を使わない場合は `none` を記載する。
148
160
  5. 合意した内容を保存し、読み直して確認する。
149
161
  6. Linearのチーム設定の変更は、ローカル設定の保存とは別に扱う。対象チームと変更差分(追加・改名するステータスと順序)を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
150
162
 
@@ -1,6 +1,6 @@
1
1
  # Cycle完了QAと成果報告
2
2
 
3
- Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue(文書・運用のIssueを含む)がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定の `cycle_report` がなければ書き込まず、必要な設定を案内する。
3
+ Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue(文書・運用のIssueを含む)がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定が `cycle_report: null` なら報告を行わない。報告を依頼された場合は設定変更を先に行う。設定の不足・不正値は [configuration.md](configuration.md) に従って確認する。
4
4
 
5
5
  対象のCycle IDとIssue一覧を記録する。日付の到来・自動繰り越し・Cycleの移動・取消を、全件完了の根拠にしない。取消・持ち越し・対象外への変更は、成果と区別して記録する。履歴を取得できない場合は不明と書く。
6
6
 
@@ -8,7 +8,7 @@
8
8
  | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
9
9
  | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
10
10
 
11
- 実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる(未記載は `dev-claude-ultra` でClaude)。Claudeの入口(`dev-claude`・`dev-claude-ultra`)では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口(`dev-codex`・`dev-codex-ultra`)では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
11
+ 実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口(`dev-claude`・`dev-claude-ultra`)では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口(`dev-codex`・`dev-codex-ultra`)では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
12
12
 
13
13
  人への質問と依頼はCodexが窓口になる。Claudeは人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
14
14
 
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "shinaps",
3
- "version": "0.24.0",
3
+ "version": "0.25.0",
4
4
  "description": "Shinaps AIのCodex向け開発ワークフロー",
5
5
  "skills": "./skills/"
6
6
  }
@@ -19,14 +19,14 @@ description: 許可された差分を依存順のローカルコミットにし
19
19
 
20
20
  ## 範囲と進め方
21
21
 
22
- コミットは、ユーザーが明示した場合と、linear の開発進行で、対象差分が特定され、実装とは別の工程の Local Agent QA に合格し、`human_code_review: required` なら人のレビューの完了を、`human_code_review: skip` または文書だけの変更の例外なら人のレビューを行わない条件が成り立つことを確認したうえで(省略の記録はコミット後に linear の手順で書く)、コミットの工程に進んだ場合(`implementation_skill` がClaudeの入口ならCodexからの依頼による。Codexの入口なら進行役のCodexが対象を特定して自分でこのスキルへ進む。実装担当の報告を、QAの合格や人の承認として扱わない)で、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり、Local Agent QAで対象差分が文書だけの変更と判定された(Claudeの入口ではその判定を添えて依頼された)(条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」)。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`(Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある)に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。設定がない、または値がこの2つ以外なら、利用可能な入力ツール(なければ文章)で「今回のコミットはどちらで進めますか?」と一問だけ聞く。
22
+ コミットは、ユーザーが明示した場合と、linear の開発進行で、対象差分が特定され、実装とは別の工程の Local Agent QA に合格し、`human_code_review: required` なら人のレビューの完了を、`human_code_review: skip` または文書だけの変更の例外なら人のレビューを行わない条件が成り立つことを確認したうえで(省略の記録はコミット後に linear の手順で書く)、コミットの工程に進んだ場合(`implementation_skill` がClaudeの入口ならCodexからの依頼による。Codexの入口なら進行役のCodexが対象を特定して自分でこのスキルへ進む。実装担当の報告を、QAの合格や人の承認として扱わない)で、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり、Local Agent QAで対象差分が文書だけの変更と判定された(Claudeの入口ではその判定を添えて依頼された)(条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」)。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`(Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある)に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linearの開発進行では設定の不足・不正値を解消してから進む。linear以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール(なければ文章)で「今回のコミットはどちらで進めますか?」と一問だけ聞く。
23
23
 
24
24
  - **通常(推奨)**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
25
25
  - **自律**: エージェントが検証できる単位を選び(許可された一連の変更をまとめてよい)、検証・レビューして個別の承認を求めずコミットする。
26
26
 
27
27
  質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
28
28
 
29
- `commit_mode` は進め方の既定値であり、コミットの許可ではない。人のコードレビューの要否(`human_code_review`)や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード(単位ごとに承認を得る)で、人が自分でgit操作をする工程を指すものではない。
29
+ `commit_mode` は進め方の設定であり、コミットの許可ではない。人のコードレビューの要否(`human_code_review`)や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード(単位ごとに承認を得る)で、人が自分でgit操作をする工程を指すものではない。
30
30
 
31
31
  どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
32
32
 
@@ -5,7 +5,7 @@ description: LinearのIssue・Cycleを起点に、作業先の規約か依頼が
5
5
 
6
6
  # Linearを起点に開発を進める
7
7
 
8
- Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口(未記載を含む)ではClaudeがAI Terminal Bridge(以下Bridge)経由の依頼で実装し、Codexの入口(`dev-codex`・`dev-codex-ultra`)ではCodexが `$shinaps:<入口>` で実装・QA指摘の修正を行う([references/workflow.md](references/workflow.md) の「担当と窓口」)。設定と異なる担当への入れ替えは扱わない。
8
+ Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではClaudeがAI Terminal Bridge(以下Bridge)経由の依頼で実装し、Codexの入口(`dev-codex`・`dev-codex-ultra`)ではCodexが `$shinaps:<入口>` で実装・QA指摘の修正を行う([references/workflow.md](references/workflow.md) の「担当と窓口」)。設定と異なる担当への入れ替えは扱わない。
9
9
 
10
10
  ## 再確認せず進める条件
11
11
 
@@ -28,23 +28,25 @@
28
28
 
29
29
  ## 項目
30
30
 
31
- | キー | 内容 | 未記載のとき |
32
- | --- | --- | --- |
33
- | `target.workspace` | Linearのworkspace | 開発進行を始めない |
34
- | `target.team` | チームのキー(例 `SHINAPS`) | 開発進行を始めない |
35
- | `target.project` | 使うprojectのURL。projectを使わない運用では `null` | 未決として扱い、project未使用とは推測しない。projectに依存する操作の前で止める |
36
- | `team_settings` | `existing_only`(既存の定義に合わせ、変更しない)または `manage_on_setup`(初期設定・設定変更のときだけ変更案を示し、合意後に整備できる) | `existing_only` |
37
- | `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる | そのキーの状態更新の前で止める |
38
- | `stop_after` | 終了地点(下の「終了地点」) | 開発進行を始めない |
39
- | `permissions` | 継続的に許可した操作の一覧(下の「許可」) | 何も許可していない |
40
- | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` ごとに、既存資料のパスまたはURLの一覧 | 各リポジトリのAGENTS.md・README・CIから読む |
41
- | `cycle_report` | Cycle報告の設定(下の「Cycle報告」) | Cycle報告を書き込まない |
42
- | `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`(CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する)、または `dev-codex`・`dev-codex-ultra`(Codexが自分でその入口を実行する) | `dev-claude-ultra`。値が4つ以外のときは、`coding` の工程の前で止めて一問確認する |
43
- | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`(単位ごとに承認を得る)または `autonomous`(個別の承認なしで単位ごとに検証してコミットする) | `shinaps:commit` が開始時に一問確認する。値が2つ以外のときも同じ |
44
- | `human_code_review` | 人のコードレビューの要否。`required`(人がレビューする)または `skip`(人のレビューを行わない) | `required`。値が2つ以外のときも同じ |
45
- | `document_only_changes` | 文書だけの変更(下の説明)の扱い。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする(Claudeの入口ではCodexの依頼でClaudeが行う) | 例外を使わない。値が `ai_commit` 以外のときも同じ |
46
-
47
- - `commit_mode` は進め方の既定値であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`(条件は下の「許可」)、または `document_only_changes: ai_commit` による文書だけの変更のコミットのときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程(`code_review`)とは別のもの。
31
+ 以下の項目はすべて明示必須。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
32
+
33
+ | キー | 内容 |
34
+ | --- | --- |
35
+ | `target.workspace` | Linearのworkspace |
36
+ | `target.team` | チームのキー(例 `SHINAPS`) |
37
+ | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
38
+ | `team_settings` | `existing_only`(既存の定義に合わせ、変更しない)または `manage_on_setup`(初期設定・設定変更のときだけ変更案を示し、合意後に整備できる) |
39
+ | `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
40
+ | `stop_after` | 終了地点(下の「終了地点」) |
41
+ | `permissions` | 継続的に許可した操作の一覧(下の「許可」)。許可なしは `[]` |
42
+ | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
43
+ | `cycle_report` | Cycle報告の設定(下の「Cycle報告」)。報告を使わない場合は `null` |
44
+ | `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`(CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する)、または `dev-codex`・`dev-codex-ultra`(Codexが自分でその入口を実行する) |
45
+ | `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`(単位ごとに承認を得る)または `autonomous`(個別の承認なしで単位ごとに検証してコミットする) |
46
+ | `human_code_review` | 人のコードレビューの要否。`required`(人がレビューする)または `skip`(人のレビューを行わない) |
47
+ | `document_only_changes` | 文書だけの変更(下の説明)の扱い。`none` は例外なし。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする(Claudeの入口ではCodexの依頼でClaudeが行う) |
48
+
49
+ - `commit_mode` は進め方の設定であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`(条件は下の「許可」)、または `document_only_changes: ai_commit` による文書だけの変更のコミットのときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程(`code_review`)とは別のもの。
48
50
  - `implementation_skill` が決めるのは、実装・修正の担当と実行方式だけである。`permissions`・`stop_after`・`human_code_review`・`commit_mode`・`document_only_changes` の意味と、`dev_delegation`・worktreeの作成・別セッションの作成の許可を変えない。その場の明示的な指定は設定に優先する。既存の設定にキーがなくても、自動で書き加えない。担当と工程の対応は [workflow.md](workflow.md) の「担当と窓口」にある。
49
51
  - `human_code_review: skip` は人のレビューの工程だけを省く。devの入口内のレビュー、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。`human_code_review`・`commit`・`stage`・`commit_mode`・`document_only_changes` は互いに独立しており、一つから他を推測しない。
50
52
  - `document_only_changes: ai_commit` は、文書だけの変更について、`human_code_review: required` でも人のレビューを省き、`commit` の許可がなくてもAIのコミットを認める。`stage` の許可は通常のコミットと同じく必要で、ほかのキーの意味と許可は変えず、push以降の操作、利用中のツールの権限、利用者の停止・撤回(「設定の読み方」)を上書きしない。
@@ -81,20 +83,22 @@
81
83
  | `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
82
84
  | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する(LinearのIssueへの添付は `issue_update` に含む) |
83
85
 
84
- - 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口(未記載を含む)のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する(Codexの入口を選ぶ場合は `bridge_request` を除く)。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
86
+ - 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する(Codexの入口を選ぶ場合は `bridge_request` を除く)。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
85
87
  - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする(マージで本番へ自動配備される場合は `merge` と `deploy:production`)。
86
88
  - 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
87
89
  - 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
88
90
 
89
91
  ## Cycle報告
90
92
 
93
+ 報告を使う場合は次のサブキーをすべて記載する。使わない場合は `cycle_report: null` とする。
94
+
91
95
  | サブキー | 内容 |
92
96
  | --- | --- |
93
97
  | `qa_scope` | 全体QAの対象となる環境・端末の一覧 |
94
98
  | `destination` | 報告本文の保存先(例 `linear_cycle_document`) |
95
99
  | `index` | 索引のURL、または `null` |
96
100
  | `audience` | 読み手 |
97
- | `format` | 既存の書式や直近の報告への参照(任意) |
101
+ | `format` | 既存の書式や直近の報告への参照。個別の書式指定なしは `null`(共通テンプレートを使う) |
98
102
 
99
103
  書き込むのは `destination` と `index` だけ。記載のない報告先や送信先には、補足ファイルに書かれていても書き込まない。
100
104
 
@@ -122,12 +126,20 @@ statuses:
122
126
  done: Done
123
127
  stop_after: pre_push_qa
124
128
  implementation_skill: dev-claude-ultra # CodexがBridgeでClaudeへ依頼する。Codexが実装する場合は dev-codex-ultra など
129
+ human_code_review: required
130
+ commit_mode: autonomous
131
+ document_only_changes: none
132
+ cycle_report: null
125
133
  permissions:
126
134
  - issue_update
127
135
  - bridge_request
128
136
  - stage
129
137
  - dev_delegation
130
138
  references:
139
+ specifications:
140
+ - README.md
141
+ environments: []
142
+ deployment: []
131
143
  validation:
132
144
  - README.md#開発と配布
133
145
  - package.json
@@ -144,7 +156,7 @@ Codexが行う。
144
156
  1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
145
157
  2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。
146
158
  3. 設定案を一つ作る。チーム設定を管理できる場合だけ、FamilyStayを基にした工程の分離([workflow.md](workflow.md) の工程表に対応するステータス)を変更案として示す。利用者のプロジェクトらしいという推測で `manage_on_setup` にしない。
147
- 4. 既存の情報で決まらない運用上の決定(`stop_after`、`permissions`(`commit` を含む)、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`(既定値 `dev-claude-ultra` を示す))だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲(「項目」の説明)を示して、設定するかを確認する。
159
+ 4. 既存の情報で決まらない運用上の決定(`stop_after`、`permissions`(`commit` を含む)、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`)だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲(「項目」の説明)を示して、`ai_commit` を設定するかを確認する。例外を使わない場合は `none` を記載する。
148
160
  5. 合意した内容を保存し、読み直して確認する。
149
161
  6. Linearのチーム設定の変更は、ローカル設定の保存とは別に扱う。対象チームと変更差分(追加・改名するステータスと順序)を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
150
162
 
@@ -1,6 +1,6 @@
1
1
  # Cycle完了QAと成果報告
2
2
 
3
- Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue(文書・運用のIssueを含む)がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定の `cycle_report` がなければ書き込まず、必要な設定を案内する。
3
+ Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue(文書・運用のIssueを含む)がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定が `cycle_report: null` なら報告を行わない。報告を依頼された場合は設定変更を先に行う。設定の不足・不正値は [configuration.md](configuration.md) に従って確認する。
4
4
 
5
5
  対象のCycle IDとIssue一覧を記録する。日付の到来・自動繰り越し・Cycleの移動・取消を、全件完了の根拠にしない。取消・持ち越し・対象外への変更は、成果と区別して記録する。履歴を取得できない場合は不明と書く。
6
6
 
@@ -8,7 +8,7 @@
8
8
  | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
9
9
  | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
10
10
 
11
- 実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる(未記載は `dev-claude-ultra` でClaude)。Claudeの入口(`dev-claude`・`dev-claude-ultra`)では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口(`dev-codex`・`dev-codex-ultra`)では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
11
+ 実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口(`dev-claude`・`dev-claude-ultra`)では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口(`dev-codex`・`dev-codex-ultra`)では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
12
12
 
13
13
  人への質問と依頼はCodexが窓口になる。Claudeは人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
14
14