fix-types

Codex 互換性に関する注意：

• Codex でリポジトリのスキルを呼び出すには、$skill-name を使用してください。このミラー版では、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーの必須事項：ワークフローまたはスキルの各ステップを実行する前に、すべてのステップについてタスクの追跡を作成または更新し、進捗に応じて同期してください。
• ユーザーへの質問プロンプトは、Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合は、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの許可：スキルがユーザーによって呼び出された場合、または AI が検出した場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化によって、このタスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが逸脱を事前に明示的に承認しない限り、プロトコルのステップを省略、並べ替え、統合しないでください。
• ワークフロースキルでは、記載された子スキルの各ステップを明示的に実行し、ステップごとの根拠を報告してください。
• 必須のステップまたはツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex でのプロジェクト参照ドキュメントの読み込み（フックなし）

Codex では、Claude のフックによるドキュメントの自動挿入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テスト設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体へのルート）
• docs/project-reference/lessons.md（常に適用されるガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイル／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC マッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：code-review-rules.md と、変更ファイルに応じたドメイン関連ドキュメント

すべてのドキュメントを無差別に読まないでください。docs-index-reference.md から始め、タスクに関連するファイルだけを開いてください。

クイックサマリー

目標： コードベース全体の TypeScript コンパイルエラーと型の不一致を修正します。

ワークフロー：

1. 収集 — tsc --noEmit または nx build を実行して型エラーを収集します
2. 分析 — エラーを分類します（型の不足、シグネチャの誤り、インポートの問題）
3. 修正 — 可能な限り any キャストを使わず、型安全な修正を適用します

主なルール：

• デバッグの姿勢：すべての主張に file:line の根拠が必要です
• any や型アサーションよりも、適切な型付けを優先します
• 症状ではなく根本原因を修正します（誤ったインターフェース、エクスポートの不足など）

⚠️ 修正前に検証（必須）： 型エラーと根本原因を特定した後、コードを変更する前に、調査結果と提案する修正をユーザーへの直接の質問で提示し、明示的な承認を得る必要があります。黙って修正してはいけません。

bun run typecheck、tsc、または npx tsc を実行し、すべての型エラーを修正してください。

デバッグの姿勢（必須）

懐疑的に、批判的思考と段階的な思考を適用してください。すべての主張には、追跡可能な証拠と信頼度（アイデアは 80％を超える必要があります）が必要です。

• 行動に移る前に、実際のコードを追跡して各仮説を検証してください。最初の仮説が正しいと決めつけないでください。理由：最初の推測は原因ではなく、注意が向きやすい箇所に惑わされている場合が多いためです
• 根本原因に関するすべての主張には file:line の根拠が必要です
• コードを追跡して根本原因を証明できない場合は、「仮説であり、未確認」と明記してください
• 前提を問い直してください：「本当にこれが原因か？」→ 実際の実行経路を追跡してください
• 網羅性を検証してください：「ほかにも要因があるか？」→ 関連するコード経路を確認してください
• 証拠なしに「これで直るはず」と言わないでください。修正が追跡によって特定した根本原因に対処していることを検証してください

⚠️ 必須：確信度と根拠のゲート

必ず注意：すべての主張について、根拠リストと file:line の証拠を添えて Confidence: X% を明記してください。 95%以上なら自由に推奨できます。 | **80～94%**なら但し書きを付けます。 | **60～79%**なら不明点を列挙します。 | 60%未満なら停止して、さらに根拠を集めます。

ルール

• すべての型エラーを修正し、型エラーがなくなるまでこのプロセスを繰り返してください。

• 各値には実際の具体的な型を指定してください（または unknown と型を絞り込むガードを使用してください）。型チェックを通すためだけに any を使わないでください。理由：any はチェッカーを黙らせ、根本の型の不具合を出荷させてしまいます。

• 修正後は必ず注意して $prove-fix を実行してください — 変更ごとに、確信度スコア付きのコード証明トレースを作成します。絶対に省略しないでください。

---

[IMPORTANT] 作業を始める前に、タスク管理を使ってすべての作業を小さなタスクに分割してください。各ファイルを読むタスクも含めます。これにより、長いファイルによるコンテキストの喪失を防げます。簡単な作業の場合、AI は省略してよいかユーザーに確認しなければなりません。

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関連、サービス間の同期（ビジネスエンティティ／モデルが関係するタスクで読みます）（該当する場合は直接読み、フックから注入された会話テキストに依存しないでください）

スキルバリアント： $fix のバリアント — TypeScript／型エラーの解決。

終点から始めるデバッガートレース — 複雑なバグ、検証の失敗、リグレッションの修正、動作を変更するコード、またはコードフローが不明瞭な場合は、修正を提案する前に、観測された最終状態から逆方向にたどってください。

1. フレーム0：観測された最終状態 — ユーザーに表示された正確な出力、失敗したアサーション、ログ行、永続化された値、API レスポンス、レンダリングされた UI、または集計バケットを明示します。それを生成したリーダー／クエリ／レンダラーを、file:line の根拠とともに記録します。
2. 一度に1ホップずつ逆方向にたどる — 最終リーダー -> プロジェクション／キャッシュ／ストレージ -> 書き込み元 -> コンシューマー／ハンドラー／ジョブ -> プロデューサー／呼び出し元 -> 元のトリガーの順に追跡します。各ホップで、入力、変換、出力、担当箇所、根拠を記録します。
3. すべての流入経路を列挙する — リトライ、非同期処理、キャッシュ、バックグラウンド処理、代替の UI／API 経路を含め、最終経路に書き込む可能性がある上流のプロデューサー／呼び出し元／イベント／ジョブをすべて特定します。各経路を、検証済み、除外済み、未確認のいずれかとして示します。
4. 仮説マトリクスを作成する — 考えられる原因ごとに、支持する根拠、反証する根拠、再現／検証方法、影響範囲、ステータス（primary、contributing、ruled out、latent）を列挙します。競合する原因が明示的に解決されるか、範囲を限定されるまでは修正しないでください。
5. 修正を担うレイヤーを選ぶ — 不変条件を所有する箇所と、下流のすべてのコンシューマーを保護する最も低い共通箇所を特定します。不変条件を所有していない限り、症状が現れる箇所での修正は却下します。
6. 順方向の収束を証明する — 修正を選んだ後、開始点 -> 終点を再度たどり、修正された状態が観測された最終出力にどう到達するかを示します。各根本原因を修正箇所に、各修正箇所をテスト／証明に対応付けます。

以下が完了するまで作業を進めないでください： 最終状態の明示・逆方向のトレースの記述・すべての流入経路の列挙・仮説マトリクスの完成・修正を担うレイヤーの正当化・テストに対応付けた順方向の収束証明。

絶対にしないでください： 最初に疑わしいコード経路から調査を始めること。複数のプロデューサーを1つの「フロー」にまとめること。読み取りモデルを検証せずに、重複した症状を重複レコードとして扱うこと。除外した仮説を省略すること。 根本原因のデバッグ — 推測や試行錯誤ではなく、体系的に取り組みます。

1. 再現 — 証拠（エラーメッセージ、スタックトレース、スクリーンショット）で問題の存在を確認します
2. 切り分け — 二分探索とグラフトレースを使い、対象のファイル／関数／行を絞り込みます
3. 追跡 — 入力から障害発生箇所までデータフローを追います。推測せず、実際のコードを読みます。
4. 仮説の立案 — 確信度（％）を添えて仮説を立てます。仮説を裏付ける、または反証する証拠を示します
5. 検証 — 対象を絞った grep／読み取りで仮説を検証します。一度に変更する変数は1つだけです。
6. 修正 — 症状ではなく根本原因に対処します。グラフの connections を使い、修正によって呼び出し元が壊れないことを確認します

絶対にしないこと： 証拠なしに推測する。原因ではなく症状を修正する。再現の手順を省略する。

ネストされたタスクの展開契約 — ワークフローのステップとして呼び出す場合、[Workflow] ... の行は親コンテナーにすぎません。子スキルは引き続き、表示されるフェーズタスクを作成します。

1. まず現在のタスクリストを取得します。一致するアクティブな親ワークフロー行がある場合は nested=true に設定し、parentTaskId を記録します。それ以外の場合は単独で実行します。
2. フェーズ作業を始める前に、宣言された各フェーズにつき1つのタスクを作成します。ネストされている場合は、件名に [N.M] $skill-name — phase のプレフィックスを付けます。
3. ネストされている場合は、TaskUpdate(parentTaskId, addBlockedBy: [childIds]) で親にリンクします。
4. オーケストレーターは、子スキルまたはサブエージェントを呼び出す前に、その子スキルのフェーズリストを事前に展開し、ワークフロー行をリンクする必要があります。
5. 作業を始める前に子タスクをちょうど1つ in_progress にし、証拠の記録後ただちに completed にします。
6. すべての子タスクが完了するか、理由を明記して明示的にキャンセルされるまで、親タスクを完了にしません。

ブロック解除の条件： 現在のタスクリストを確認済みであること、子フェーズを作成済みであること、ネストされている場合は親にリンク済みであること、最初の子タスクを in_progress にしてあること。

プロジェクト参照ドキュメントのゲート — タスク追跡の初期設定後、対象ファイルまたはソースファイルの読み取り、grep、編集、分析を行う前に実行します。プロジェクトのドキュメントは、汎用的なフレームワークの前提より優先されます。

1. 対象範囲を特定します。ファイルの種類、ドメイン領域、操作内容を確認します。
2. トリガーに応じて必要なドキュメントを確認します。常に docs/project-reference/lessons.md を確認します。ドキュメント検索では docs-index-reference.md、レビューでは code-review-rules.md、バックエンド／CQRS／API では backend-patterns-reference.md、ドメイン／エンティティでは domain-entities-reference.md、フロントエンド／UI では frontend-patterns-reference.md、スタイル／デザインでは scss-styling-guide.md と design-system/design-system-canonical.md、統合テストでは integration-test-reference.md、E2E テストでは e2e-test-reference.md、機能ドキュメント／仕様では feature-docs-reference.md、アーキテクチャ／新しい領域では project-structure-reference.md が必要です。
3. 存在する必要なドキュメントをすべて読みます。存在しないドキュメントは該当なしとしてスキップします。現在のコンテキストにドキュメントが含まれている証拠として、[Injected: <path>] のような会話テキストを信用しないでください。
4. 対象作業を始める前に、次の形式で記載します：Reference docs read: ... | Missing/not applicable: ...。

ブロック解除の条件： 対象範囲を評価済みであること、必要なドキュメントを確認・読了済みであること、lessons.md を確認済みであること、引用を提示済みであること。

タスク追跡と外部レポートの保存 — 実行を始める前にこの設定を行い、その後、対象またはソースの作業前にプロジェクト参照ドキュメントを事前に確認します。

1. 対象ファイルの読み取り、grep、編集、分析を行う前に、小規模なタスクの内訳を作成します。コンテキストが失われた場合は、まず現在のタスクリストを確認します。
2. 作業前に1つのタスクを in_progress にし、証拠を記録した直後に completed にします。状態の変更をまとめて行わないでください。
3. 計画／レビュー作業では、最初の所見を記録する前に plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md を作成します。
4. 各ファイル／セクション／判断の後に所見を追記し、最後にレポートファイルをもとに統合します。
5. 最終出力では Full report: plans/reports/{filename} を引用します。

ブロック解除の条件： タスクの内訳が作成済みであること、計画／レビュー作業ではレポートのパスが宣言済みであること、次の所見に進む前に最初の所見を保存済みであること。 クリティカルシンキングの姿勢 — クリティカルシンキングと順序立てた思考を実践してください。すべての主張について、根拠をたどって確認してください。行動に移すのは、確信度が80％を超える場合に限ります。 ハルシネーション対策： 推測を事実として示してはいけません。すべての主張に出典を示し、不確実性はためらわずに認め、出力に誤りがないか自分で確認し、独立した情報源と照合し、自分の確信度にも懐疑的でいてください。証拠のない確信こそ、あらゆるハルシネーションの根源です。

まずコードを理解する — 厳格なゲート：既存のコードを読むまでは、記述、計画、修正を行わないでください。

1. 類似するパターンを3つ以上検索し（grep／glob）、根拠となる file:line を示す
2. 対象領域の既存ファイルを読み、構造、基底クラス、規約を理解する
3. .code-graph/graph.db が存在する場合は、python .claude/scripts/code_graph trace <file> --direction both --json を実行する
4. connections または callers_of を使って依存関係を洗い出し、対象に依存しているものを把握する
5. 複雑なタスク（3ファイル以上）では、調査結果を .ai/workspace/analysis/ に記録する
6. 実装前に分析ファイルを読み直す。記憶だけを頼りに作業しない。— 理由：長いコンテキストではファイルから認識がずれていきます。ファイルが正確な情報源です
7. 既存のパターンが使える場合、新たなパターンを決して作らない。既存のものに正確に合わせるか、逸脱する理由を記録する。— 理由：異なるパターンが混在するとコードベースが断片化し、後から読む人すべての作業が遅くなります

以下が完了するまで作業不可： - [ ] 対象ファイルを読んだ - [ ] 3つ以上のパターンを grep で検索した - [ ] グラフトレースを実行した（graph.db が存在する場合） - [ ] 仮定を根拠で検証した

根拠に基づく推論 — 憶測は禁止です。すべての主張に証拠が必要です。

1. すべての主張について、file:line、grep の結果、またはフレームワークのドキュメントを根拠として示す
2. 確信度を明示する：80％超ならそのまま進め、60～80％なら先に検証し、60％未満なら推奨しない
3. アーキテクチャの変更では、サービスをまたいだ検証が必須です
4. 「証拠が足りません」は妥当であり、期待される回答です

証拠なしで使用禁止： 「明らかに」「私はそう思います」「～のはずです」「おそらく」「これは～が原因です」 未完了の場合 → 次を出力する："Insufficient evidence. Verified: [...]. Not verified: [...]."

ソース／テストの乖離チェック。 コーディング、修正、デバッグ、調査、テスト、レビューの作業では、ソースの動作が変わったとき、影響を受ける単体テスト／統合テスト／E2E テストを調べ、意図した動作に合わせてテストを変更すべきか、それともソースの変更が意図しないバグであり修正すべきかを、根拠に基づいて判断してください。マイグレーションコードのテストは作成しないでください。スキーマ／データのマイグレーションは一度だけ実行する処理であり、アプリケーションのコアロジックではありません。 AI のミス防止 — あらゆるタスクで避けるべき失敗パターン：

削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードの陳腐化が連鎖します。削除する前に、参照しているファイルをすべて洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係の全体を追跡してください。 定義を変更しても、そこから派生する下流の変数や利用箇所を見落とすことがあります。必ず依存関係の全体を追跡してください。 正しさを検証する際は、コードパスをすべて追跡してください。 コードの存在を確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ず追跡してください。 デバッグ時は、修正する前に「どちらの責任か」を確認してください。 バグが呼び出し元（データが誤っている）にあるのか、呼び出し先（処理が誤っている）にあるのかを追跡してください。責任のある層で修正し、症状が現れる箇所だけにパッチを当てないでください。 既存の値は意図的に設定されているものと考え、変更前に理由を確認してください。 定数、上限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに関わる変更では、出力をすべて検証する必要があります。1 つのチェックが成功しても、すべてのチェックが成功したことにはなりません。 全体を優先してデバッグし、目の前のものに注意を奪われないでください。 障害を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。その後、コード層の仮説を立てる前に、それぞれを証拠と照合して確認してください。 変更は最小限にし、差分テストを適用してください。 バグ修正では、変更したすべての行がバグに直接結び付いている必要があります。隣接するコードのスタイル変更や改善は行わないでください。機能改善タスクでは、改善を実装し、その内容を明示してください。 実装前に曖昧さを明らかにし、黙って決めつけないでください。 依頼に複数の解釈がある場合は、それぞれの所要時間の見積もりとともに提示し、確認してください。全レコード対象、ファイルベース、または複雑な方の経路だと決めつけないでください。

重要・必ず注意 変更を加える前に、既存のパターンを 3 つ以上検索し、コードを読んでください。graph.db が存在する場合は、グラフのトレースを実行してください。

重要・必ず注意 すべての主張に file:line の証拠を添えてください。確信度が 80% を超える場合に実行し、60% 未満の場合は推奨しないでください。

必ず注意 批判的思考を適用してください。すべての主張には追跡可能な証拠が必要であり、実行するには確信度が 80% を超えている必要があります。幻覚を防ぐため、推測を事実として提示しないでください。

必ず注意 AI のミス防止策を適用してください。全体を優先してデバッグし、責任のある層で修正し、実装前に曖昧さを明らかにし、コンテキスト圧縮後はファイルを読み直してください。

• 必須 対象の作業に着手する前にタスク追跡を初期化してください。タスクは一度に 1 つずつ状態を遷移させてください。

• 必須 計画とレビューの結果は plans/reports/ に段階的に保存し、ディスク上の内容からまとめてください。

• 必須 タスク追跡の初期化後、対象の作業やソースに着手する前に、必須のプロジェクト参照ドキュメントを読み、Reference docs read: ... と記載してください。

• 必須 常に lessons.md を含めてください。プロジェクトの規約は一般的な既定値より優先されます。

重要・必ず注意 デバッガーのトレースゲート：重要度の高いバグ修正、調査、レビューでは、観測された最終出力から開始し、reader -> storage/projection -> writer -> consumer/job -> producer/trigger の順に遡って追跡してください。修正に着手する前に、すべての入力経路と仮説を列挙してください。トレース、仮説マトリクス、修正責任のある層、前方向への収束の証明がそろうまで、作業を進めてはいけません。

• 必須 親ワークフローの行で子フェーズの追跡を代用しないでください。ネストされた場合はフェーズを展開し、親へのリンクを設定してください。
• 必須 オーケストレーターは呼び出し前に子スキルのフェーズを展開してください。[N.M] $skill-name — phase の接頭辞を使い、同時に in_progress にできるのは 1 つだけというルールを守ってください。

締めくくりの注意事項

重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください 重要・必ず注意 新しいコードを作成する前に、コードベースで類似するパターンを3つ以上検索してください 重要・必ず注意 すべての主張について file:line の根拠を示してください（確信度が80％を超える場合に実行） 重要・必ず注意 作業の品質を確認するための最終レビュー ToDo タスクを追加してください 重要・必ず注意 修正に3回失敗したら停止してください。結果を報告し、4回目に進む前にユーザーに確認してください 必須・重要・必ず注意 作業を始める前に、以下のファイルを読んでください：

[タスク計画] 作業を始める前に、タスクの範囲を分析し、タスク追跡を使って体系的に小さな ToDo タスクとサブタスクに分割してください。

フックレスプロンプトプロトコルミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず遵守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルの文面はプロジェクトに依存しないものにします。プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認してください。共有の AI-SDD には shared/sdd-artifact-contract.md を適用してください。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されたプロジェクトリファレンス文書を開いてください。共有コンテキストとローカル文書が利用可能であれば、サポート対象の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適切かどうかも評価します
3. 確認（必須形式）： ユーザーがワークフロー／スキルを明示的に呼び出し、かつローカルプロトコルでその明示的な呼び出しが確認とみなされる場合を除き、次の構成でユーザーに直接質問します：
   • 質問：「どのワークフローを有効にしますか？」
   • オプション1：「[最適なワークフロー] を有効にする（推奨）」
   • オプション2：「カスタムワークフローを有効にする：[ステップ1 → ステップ2 → ...]」（理由を1行で添える）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップは手動で順に実行します
5. タスク作成： ワークフローのすべてのステップについて、タスク追跡を使ってタスクを作成します
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。確信度が80％を超える場合に実行してください。 誤情報防止の原則： 推測を事実として提示しないでください。すべての主張について出典を示し、不確実性は率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信を懐疑的に検証してください。証拠のない確信は、あらゆる誤情報の根本原因です。 AI 注意力の原則（初頭効果と新近性効果）： 長いプロンプト／プロトコルでは、指示の遵守を長いコンテキストウィンドウでも維持できるよう、最も重要なルール3つを冒頭と末尾の両方に配置してください。 目標主導の実行： まず成功基準を定め、検証が完了するまで繰り返し、観測可能なチェックに合格した時点でのみ停止してください。 テストで意図を検証する： テストでは、現在の動作を再現するだけでなく、業務ルールや不変条件を保護し、保護対象の意図が崩れた場合に失敗するようにしてください。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分けて（タスク追跡を行って）ください。最後のタスクとして「AI のミスと教訓を分析する」を追加してください。

教訓を抽出する — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論や前提の誤り）に名前を付けます。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」。
2. 汎用性を確認します。この失敗モードは、3 つ以上の状況やコードベースに当てはまりますか？当てはまらない場合は、もう 1 段階抽象化してください。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除き、どのコードベースでも役立つ内容にしてください。
4. まとめます。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめてください。
5. 再発確認：「このリマインダーがなくても、今後のセッションで再発しますか？」いいえの場合は、$learn を省略します。
6. 自動修正確認：「$code-review／$code-simplifier／$security／$lint で検出できますか？」はいの場合は、代わりにレビューのスキルを改善してください。
7. **両方の確認を通過した場合：**ユーザーに $learn の実行を依頼してください。 [TASK-PLANNING] [MANDATORY] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。