@shinaps/skills 0.35.0 → 0.35.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/README.md +2 -2
- package/package.json +1 -1
- package/plugins/shinaps-claude/.claude-plugin/plugin.json +1 -1
- package/plugins/shinaps-claude/references/dev/workflow.md +1 -1
- package/plugins/shinaps-claude/references/linear/claude-cli.md +2 -2
- 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/qa.md +9 -0
- package/plugins/shinaps-codex/.codex-plugin/plugin.json +1 -1
- package/plugins/shinaps-codex/references/dev/workflow.md +1 -1
- package/plugins/shinaps-codex/references/linear/claude-cli.md +2 -2
- 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/qa.md +9 -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.1` を導入し、`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.1
|
|
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
|
@@ -64,7 +64,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
|
|
|
64
64
|
|
|
65
65
|
メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
|
|
66
66
|
|
|
67
|
-
実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)
|
|
67
|
+
実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げずメインへ返す。通常の判断は既存の合意と規約で解決し、仕様・範囲の変更だけ人に確認する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
|
|
68
68
|
|
|
69
69
|
実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
|
|
70
70
|
|
|
@@ -14,9 +14,9 @@
|
|
|
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、出力パスを記録する。実行中は、実行ツールがprocess
|
|
17
|
+
途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待つ。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。通知を受け取れない場合だけ、起動または前回の確認から5分おきに同じprocessの終了だけを確認する。この5分は確認の間隔で、進行役の1回の待機の長さ（[実行](execution.md) の「待機の手順（進行役）」）とは別に扱い、短い待機から戻るたびには確認しない。終了を待つ間は、stream-json・stderr・出力ファイルなどのログや途中成果を読まない。異常の根拠がある場合と利用者に依頼された場合だけ、必要な範囲で調べる。新しいCLIを並行起動せず、終了したら終了コードを取得して結果を会話へ返す。
|
|
18
18
|
|
|
19
|
-
jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終result
|
|
19
|
+
jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合し、最終resultがない出力を完了と扱わない。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
|
|
20
20
|
|
|
21
21
|
## 依頼・質問・修正・コミット
|
|
22
22
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.35.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.35.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.1`）。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
|
|
|
@@ -29,7 +29,7 @@ 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
|
|
32
|
+
- Claudeの作業中は、経路ごとの通知を待つ。manualはBridgeで届くClaudeの報告の通知、autoは実行ツールが知らせるCLIのprocess終了の通知を待つ。autoで通知を受け取れない場合だけ、[Claude CLI](claude-cli.md) の「起動と観測」の間隔と対象で同じprocessの終了を確認する。manualで通知を受け取れない場合は [Bridge](bridge.md) の「競合の回避と待機」に従う。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
|
|
33
33
|
- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
|
|
34
34
|
- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
|
|
35
35
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
@@ -41,7 +41,7 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
|
|
|
41
41
|
|
|
42
42
|
- 通知または人の入力で再開できる待機ツールを優先する。それがなく、新しい入力で中断される待機ツール（例: `clock.sleep`）が提供される場合は、1回の待機を60秒以下（`duration_ms` 60000以下）にする。この手順を確認したCodexの実行環境の指示（2026-10-20時点）が、60秒を超えて応答を止める待機を避けるよう求めるため。どちらの待機ツールもなくターンの中で待てない場合に限り、待機理由・再開条件と人への依頼を最終応答で伝えてターンを終え、次の入力で同じゴール・工程から続ける（新しいゴールを作らない）。
|
|
43
43
|
- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。変化のない進捗の報告や、待機理由と関係のない作業もしない。実行環境の上位の指示が求める場合はそれに従う。
|
|
44
|
-
- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。auto
|
|
44
|
+
- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は [Claude CLI](claude-cli.md) の「起動と観測」の間隔に従い、待機から戻るたびには行わない。
|
|
45
45
|
- 待機中もゴールは `active`、Linearの工程も同じままにする。ゴールの状態の変更と、利用者の明示的な停止・予算・実行制限の扱いは下の「ゴール機能」に従う。
|
|
46
46
|
- 再開時は、届いた通知・入力を待機理由（対象Issue・工程・相手）と照合し、同じゴール・工程で続ける。Bridgeの通知で再開した場合は [Bridge](bridge.md) の「受信」に従って読む。peer通知を利用者の承認と扱わない。
|
|
47
47
|
|
|
@@ -13,6 +13,15 @@ QAはPRごとに完結させ、複数のPRをまとめるために人の確認
|
|
|
13
13
|
- Simulator、実機、配備、一般公開を区別する。失敗・取消と、意図せず実行されなかったテストや確認項目を合格にしない。チェックは、対応する性質を確認した証拠がある場合だけ付ける。
|
|
14
14
|
- 秘密値・Cookie・個人情報を、設定・Issue・証拠に残さない。
|
|
15
15
|
|
|
16
|
+
## Simulatorの所有と再利用
|
|
17
|
+
|
|
18
|
+
Simulator等の仮想端末は、プロジェクトごとのQA専用端末を作成して再利用する。作業ごとの増設や毎回の削除を既定にしない。2ユーザーのE2Eなど複数台が必要な場合は、そのプロジェクトの専用端末として確保する。
|
|
19
|
+
|
|
20
|
+
- 使う端末をUDIDで固定し、ビルド・インストール・起動・UI操作・終了などの各操作で対象を明示する。起動中の端末や表示中の端末を暗黙に選ばない。
|
|
21
|
+
- 端末とプロジェクトの対応、使用状況（端末名・UDID・用途・使用中の作業と開始時刻）は、同じリポジトリの全作業ツリーで1つの記録を共有して調整するため、メインの作業ツリー（[Linear共通設定](configuration.md) の「設定の読み方」）の `.shinaps/work/simulators.md` に記録する。記録の初期化と保全は、メインの作業ツリーを対象に[作業記録](../work-records.md)の手順で行う。他プロジェクトや普段使いの端末を停止・初期化・削除しない。
|
|
22
|
+
- 同じプロジェクトの別の作業が使用中なら、調整して順に使い、占有を奪わない。
|
|
23
|
+
- 自動QAでは端末を不要に前面へ出さず、人の確認が必要なときに対象を表示する。表示やUI操作ツールの制約で他の作業と衝突する場合は、一方的に切り替えず調整する。
|
|
24
|
+
|
|
16
25
|
## QAコメントの書式と更新
|
|
17
26
|
|
|
18
27
|
Codexは各工程のQA結果を、対応するIssueのコメントへ残す。初回と再検証、Local・Staging・Productionを区別する。
|
|
@@ -64,7 +64,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
|
|
|
64
64
|
|
|
65
65
|
メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
|
|
66
66
|
|
|
67
|
-
実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)
|
|
67
|
+
実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げずメインへ返す。通常の判断は既存の合意と規約で解決し、仕様・範囲の変更だけ人に確認する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
|
|
68
68
|
|
|
69
69
|
実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
|
|
70
70
|
|
|
@@ -14,9 +14,9 @@
|
|
|
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、出力パスを記録する。実行中は、実行ツールがprocess
|
|
17
|
+
途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待つ。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。通知を受け取れない場合だけ、起動または前回の確認から5分おきに同じprocessの終了だけを確認する。この5分は確認の間隔で、進行役の1回の待機の長さ（[実行](execution.md) の「待機の手順（進行役）」）とは別に扱い、短い待機から戻るたびには確認しない。終了を待つ間は、stream-json・stderr・出力ファイルなどのログや途中成果を読まない。異常の根拠がある場合と利用者に依頼された場合だけ、必要な範囲で調べる。新しいCLIを並行起動せず、終了したら終了コードを取得して結果を会話へ返す。
|
|
18
18
|
|
|
19
|
-
jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終result
|
|
19
|
+
jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合し、最終resultがない出力を完了と扱わない。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
|
|
20
20
|
|
|
21
21
|
## 依頼・質問・修正・コミット
|
|
22
22
|
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
## 検証CLIと契約版
|
|
6
6
|
|
|
7
|
-
利用中のskillとCLIの版を確認し、0.35.
|
|
7
|
+
利用中のskillとCLIの版を確認し、0.35.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.1`）。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
|
|
|
@@ -29,7 +29,7 @@ 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
|
|
32
|
+
- Claudeの作業中は、経路ごとの通知を待つ。manualはBridgeで届くClaudeの報告の通知、autoは実行ツールが知らせるCLIのprocess終了の通知を待つ。autoで通知を受け取れない場合だけ、[Claude CLI](claude-cli.md) の「起動と観測」の間隔と対象で同じprocessの終了を確認する。manualで通知を受け取れない場合は [Bridge](bridge.md) の「競合の回避と待機」に従う。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
|
|
33
33
|
- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
|
|
34
34
|
- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
|
|
35
35
|
- バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
|
|
@@ -41,7 +41,7 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
|
|
|
41
41
|
|
|
42
42
|
- 通知または人の入力で再開できる待機ツールを優先する。それがなく、新しい入力で中断される待機ツール（例: `clock.sleep`）が提供される場合は、1回の待機を60秒以下（`duration_ms` 60000以下）にする。この手順を確認したCodexの実行環境の指示（2026-10-20時点）が、60秒を超えて応答を止める待機を避けるよう求めるため。どちらの待機ツールもなくターンの中で待てない場合に限り、待機理由・再開条件と人への依頼を最終応答で伝えてターンを終え、次の入力で同じゴール・工程から続ける（新しいゴールを作らない）。
|
|
43
43
|
- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。変化のない進捗の報告や、待機理由と関係のない作業もしない。実行環境の上位の指示が求める場合はそれに従う。
|
|
44
|
-
- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。auto
|
|
44
|
+
- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は [Claude CLI](claude-cli.md) の「起動と観測」の間隔に従い、待機から戻るたびには行わない。
|
|
45
45
|
- 待機中もゴールは `active`、Linearの工程も同じままにする。ゴールの状態の変更と、利用者の明示的な停止・予算・実行制限の扱いは下の「ゴール機能」に従う。
|
|
46
46
|
- 再開時は、届いた通知・入力を待機理由（対象Issue・工程・相手）と照合し、同じゴール・工程で続ける。Bridgeの通知で再開した場合は [Bridge](bridge.md) の「受信」に従って読む。peer通知を利用者の承認と扱わない。
|
|
47
47
|
|
|
@@ -13,6 +13,15 @@ QAはPRごとに完結させ、複数のPRをまとめるために人の確認
|
|
|
13
13
|
- Simulator、実機、配備、一般公開を区別する。失敗・取消と、意図せず実行されなかったテストや確認項目を合格にしない。チェックは、対応する性質を確認した証拠がある場合だけ付ける。
|
|
14
14
|
- 秘密値・Cookie・個人情報を、設定・Issue・証拠に残さない。
|
|
15
15
|
|
|
16
|
+
## Simulatorの所有と再利用
|
|
17
|
+
|
|
18
|
+
Simulator等の仮想端末は、プロジェクトごとのQA専用端末を作成して再利用する。作業ごとの増設や毎回の削除を既定にしない。2ユーザーのE2Eなど複数台が必要な場合は、そのプロジェクトの専用端末として確保する。
|
|
19
|
+
|
|
20
|
+
- 使う端末をUDIDで固定し、ビルド・インストール・起動・UI操作・終了などの各操作で対象を明示する。起動中の端末や表示中の端末を暗黙に選ばない。
|
|
21
|
+
- 端末とプロジェクトの対応、使用状況（端末名・UDID・用途・使用中の作業と開始時刻）は、同じリポジトリの全作業ツリーで1つの記録を共有して調整するため、メインの作業ツリー（[Linear共通設定](configuration.md) の「設定の読み方」）の `.shinaps/work/simulators.md` に記録する。記録の初期化と保全は、メインの作業ツリーを対象に[作業記録](../work-records.md)の手順で行う。他プロジェクトや普段使いの端末を停止・初期化・削除しない。
|
|
22
|
+
- 同じプロジェクトの別の作業が使用中なら、調整して順に使い、占有を奪わない。
|
|
23
|
+
- 自動QAでは端末を不要に前面へ出さず、人の確認が必要なときに対象を表示する。表示やUI操作ツールの制約で他の作業と衝突する場合は、一方的に切り替えず調整する。
|
|
24
|
+
|
|
16
25
|
## QAコメントの書式と更新
|
|
17
26
|
|
|
18
27
|
Codexは各工程のQA結果を、対応するIssueのコメントへ残す。初回と再検証、Local・Staging・Productionを区別する。
|