[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71ADMDD1JFD6A222FVJ8ZS7":3,"skill-same:01M71ADMDD1JFD6A222FVJ8ZS7":51},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":20,"linkOnly":21,"markdownContent":22,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":13,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M71ADMDD1JFD6A222FVJ8ZS7","diagnosing-bugs",null,"難しいバグやパフォーマンス劣化のための診断ループ。ユーザーが「調査して」「デバッグして」と言ったとき、または「壊れている・エラーが出る・失敗する・遅い」といった報告をしたときに使う。","love-dabimas\u002Fdabimas-factor","love-dabimas","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F277394005?v=4","01M71ADGN0AVQ90MBZFJWM1KA6","01M71ADGNSJW9EJPBRH8VZP57Y",0,"MIT","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fdiagnosing-bugs\u002FSKILL.md",[],[18,19],"diagnosing bugs","bugs","2026-11-10 10:12:30",false,"---\nname: diagnosing-bugs\ndescription: 難しいバグやパフォーマンス劣化のための診断ループ。ユーザーが「調査して」「デバッグして」と言ったとき、または「壊れている・エラーが出る・失敗する・遅い」といった報告をしたときに使う。\n---\n\n# バグの診断\n\n難しいバグに立ち向かうための規律。フェーズを飛ばすのは、明確な理由を説明できるときだけ。\n\nコードベースを探索するときは、関連モジュールの正確なメンタルモデルを得るために、プロジェクトのドキュメント（`CLAUDE.md` や `docs\u002F` 配下の設計メモなど、あれば）を読むこと。\n\n## フェーズ 1 — フィードバックループを作る\n\n**これがこのスキルの本体。** それ以外はすべて機械的な作業にすぎない。バグに対する**タイトな** pass\u002Ffail シグナル — 「_この_バグでだけ赤になる」もの — が手に入れば、原因は必ず見つかる。二分探索も、仮説検証も、計測も、すべてこのシグナルを消費するだけだ。逆にシグナルがなければ、いくらコードを眺めても救われない。\n\nここに不釣り合いなほどの労力をかけること。**攻めろ。工夫しろ。絶対に諦めるな。**\n\n### ループの作り方 — おおむねこの順で試す\n\n1. **失敗するテスト** — バグに届く継ぎ目（seam）ならどこでもいい。ユニット、統合、E2E。\n2. **curl \u002F HTTP スクリプト** — 起動中の開発サーバーに対して実行する。\n3. **CLI 実行** — フィクスチャ入力を与え、stdout を既知の正しいスナップショットと diff する。\n4. **ヘッドレスブラウザスクリプト**（Playwright \u002F Puppeteer）— UI を操作し、DOM・コンソール・ネットワークに対してアサートする。\n5. **キャプチャしたトレースの再生。** 実際のリクエスト \u002F ペイロード \u002F イベントログをディスクに保存し、対象のコードパスに単独で流し込む。\n6. **使い捨てハーネス。** システムの最小サブセット（1 サービス＋モック依存）を立ち上げ、バグのあるコードパスを関数呼び出し 1 回で叩けるようにする。\n7. **プロパティ \u002F ファズループ。** 「たまに出力がおかしい」系のバグなら、ランダム入力を 1000 件流して失敗パターンを探す。\n8. **二分探索ハーネス。** 既知の 2 つの状態（コミット、データセット、バージョン）の間でバグが発生したなら、「状態 X で起動 → 確認 → 繰り返し」を自動化して `git bisect run` できるようにする。\n9. **差分ループ。** 同じ入力を旧バージョンと新バージョン（または 2 つの設定）に流し、出力を diff する。\n10. **HITL（human-in-the-loop）bash スクリプト。** 最終手段。人間がクリックするしかない場合は、`scripts\u002Fhitl-loop.template.sh` で_人間の方を_駆動し、ループの構造だけは保つ。取得した出力は自分にフィードバックさせる。\n\n正しいフィードバックループさえ作れれば、バグは 90% 直ったも同然。\n\n### ループを締める\n\nループを製品として扱うこと。_とりあえずの_ループができたら、**締める**：\n\n- もっと速くできないか？（セットアップのキャッシュ、無関係な初期化のスキップ、テストスコープの絞り込み）\n- シグナルをもっと鋭くできないか？（「クラッシュしなかった」ではなく、具体的な症状に対してアサートする）\n- もっと決定的にできないか？（時刻の固定、乱数シードの固定、ファイルシステムの分離、ネットワークの遮断）\n\n30 秒かかる不安定なループは、ループなしと大差ない。2 秒で決定的なループはタイトだ — デバッグの超能力になる。\n\n### 非決定的なバグ\n\n目標はきれいな再現手順ではなく、**再現率を上げること**。トリガーを 100 回ループさせる、並列化する、負荷をかける、タイミングの窓を狭める、sleep を差し込む。再現率 50% のバグはデバッグできるが、1% では無理だ — デバッグ可能になるまで再現率を上げ続けること。\n\n### どうしてもループが作れないとき\n\n立ち止まって、そのことを明示的に伝えること。試したことを列挙する。ユーザーには次のいずれかを依頼する：(a) 再現する環境へのアクセス、(b) キャプチャ済みの成果物（HAR ファイル、ログダンプ、コアダンプ、タイムスタンプ付き画面録画）、(c) 一時的な本番計測コードを入れる許可。ループなしで仮説立てに進んでは**いけない**。\n\n### 完了基準 — 赤になれるタイトなループ\n\nフェーズ 1 の完了条件は、ループが**タイト**かつ**赤になれる**こと：**1 つのコマンド** — スクリプトパス、テスト実行、curl — を名指しでき、それを**すでに 1 回以上実行済み**（実行コマンドと出力を貼ること）で、かつ次を満たすこと：\n\n- [ ] **赤になれる** — 実際のバグのコードパスを通り、**ユーザーが訴えたそのままの症状**に対してアサートしている。つまり、このバグで赤になり、修正すれば緑になる。「エラーなく動いた」ではダメ — _この特定のバグを捕まえられる_必要がある。\n- [ ] **決定的** — 毎回同じ判定になる（不安定なバグの場合は、上記の通り高い再現率を固定できていること）。\n- [ ] **速い** — 分単位ではなく秒単位。\n- [ ] **エージェント単独で実行可能** — 無人で回せる。人間を挟むのは `scripts\u002Fhitl-loop.template.sh` 経由のみ。\n\nこのコマンドが存在しないうちにコードを読んで理論を組み立てている自分に気づいたら、**止まれ — いきなり仮説に飛びつくのは、このスキルがまさに防ごうとしている失敗そのものだ。** 赤になれるコマンドなくして、フェーズ 2 なし。\n\n## フェーズ 2 — 再現＋最小化\n\nループを回す。赤になるのを見届ける — バグが姿を現す。\n\n確認事項：\n\n- [ ] ループが再現しているのは**ユーザー**が説明した失敗モードである — 近くにある別の失敗ではない。違うバグ＝違う修正。\n- [ ] 失敗が複数回の実行で再現する（非決定的なバグなら、デバッグに足る再現率で再現する）。\n- [ ] 正確な症状（エラーメッセージ、誤った出力、遅いタイミング）を記録済みで、後のフェーズで「修正が本当にその症状を解消したか」を検証できる。\n\n### 最小化\n\n赤になったら、再現ケースを**赤のままでいられる最小のシナリオ**まで削る。入力・呼び出し元・設定・データ・手順を**1 つずつ**削り、削るたびにループを回し直す — 失敗の成立に必要なものだけを残す。\n\nなぜやるのか：最小の再現ケースはフェーズ 3 の仮説空間を縮める（疑うべき可動部が減る）し、フェーズ 5 のきれいな回帰テストになる。\n\n**残っている要素すべてが必要不可欠**になったら完了 — どれか 1 つでも取り除くとループが緑になる状態。\n\n再現**と**最小化の両方が済むまで先に進まないこと。\n\n## フェーズ 3 — 仮説を立てる\n\nどれかを検証し始める前に、**順位付きの仮説を 3〜5 個**生成する。仮説を 1 つしか出さないと、最初に思いついたもっともらしい案に錨を下ろしてしまう。\n\n各仮説は**反証可能**でなければならない：その仮説が導く予測を明文化すること。\n\n> 形式：「もし \u003CX> が原因なら、\u003CY を変える> とバグが消える／\u003CZ を変える> と悪化するはずだ。」\n\n予測を言語化できない仮説は、ただの雰囲気だ — 捨てるか、研ぎ直すこと。\n\n**検証前に、順位付きリストをユーザーに見せること。** ユーザーはドメイン知識で瞬時に順位を入れ替えられることが多い（「#3 の箇所、ちょうどデプロイしたばかりだよ」）し、すでに除外済みの仮説を知っていることもある。安いチェックポイントで大きな時間の節約になる。ただしブロックはしない — ユーザーが離席中なら自分の順位付けで進める。\n\n## フェーズ 4 — 計測する\n\nすべてのプローブは、フェーズ 3 の特定の予測に対応していなければならない。**一度に変えるのは 1 変数だけ。**\n\nツールの優先順位：\n\n1. **デバッガ \u002F REPL での調査** — 環境が対応していれば。ブレークポイント 1 個はログ 10 個に勝る。\n2. **狙い撃ちのログ** — 仮説同士を区別できる境界に置く。\n3. 「全部ログに出して grep」は絶対にやらない。\n\n**デバッグログには必ず一意のプレフィックスを付ける**（例：`[DEBUG-a4f2]`）。最後の掃除が grep 一発で済む。タグなしのログは生き残ってしまう。タグ付きのログは死ねる。\n\n**パフォーマンス分岐。** パフォーマンス劣化に対しては、ログはたいてい間違ったツールだ。代わりに：ベースライン計測（タイミングハーネス、`performance.now()`、プロファイラ、クエリプラン）を確立してから二分探索する。まず測り、それから直す。\n\n## フェーズ 5 — 修正＋回帰テスト\n\n回帰テストは**修正より先に**書く — ただし、それにふさわしい**正しい継ぎ目（seam）**がある場合に限る。\n\n正しい継ぎ目とは、**実際のバグのパターン**を、それが起きた呼び出し箇所と同じ形で再現できる場所のこと。使える継ぎ目が浅すぎる場合（複数の呼び出し元が絡むバグに単一呼び出しのテスト、バグを引き起こした連鎖を再現できないユニットテスト）、そこに置いた回帰テストは偽の安心にしかならない。\n\n**正しい継ぎ目が存在しないなら、それ自体が発見だ。** 記録すること。コードベースの構造が、バグの封じ込めを妨げているということだ。次のフェーズ用にフラグを立てる。\n\n正しい継ぎ目があるなら：\n\n1. 最小化した再現ケースを、その継ぎ目の失敗するテストにする。\n2. 失敗するのを見届ける。\n3. 修正を当てる。\n4. 通るのを見届ける。\n5. 元の（最小化前の）シナリオに対してフェーズ 1 のフィードバックループを回し直す。\n\n## フェーズ 6 — 掃除＋振り返り\n\n完了を宣言する前の必須項目：\n\n- [ ] 元の再現手順で再現しなくなった（フェーズ 1 のループを回し直す）\n- [ ] 回帰テストが通る（または継ぎ目が存在しないことを文書化した）\n- [ ] `[DEBUG-...]` の計測コードをすべて除去した（プレフィックスで grep する）\n- [ ] 使い捨てプロトタイプを削除した（または明確にデバッグ用と分かる場所に移した）\n- [ ] 正しかった仮説をコミット \u002F PR メッセージに明記した — 次にデバッグする人への学びになる\n\n**最後に問うこと：このバグを防げたものは何だったか？** 答えがアーキテクチャ上の変更（良いテストの継ぎ目がない、呼び出し元のもつれ、隠れた結合）を含むなら、その具体的な内容を改善提案としてユーザーに報告する。この提案は修正が入った**後に**行うこと — 着手前より今の方が多くの情報を持っているのだから。\n","# バグの診断\n\n難しいバグに立ち向かうための規律。フェーズを飛ばすのは、明確な理由を説明できるときだけ。\n\nコードベースを探索するときは、関連モジュールの正確なメンタルモデルを得るために、プロジェクトのドキュメント（`CLAUDE.md` や `docs\u002F` 配下の設計メモなど、あれば）を読むこと。\n\n## フェーズ 1 — フィードバックループを作る\n\n**これがこのスキルの本体。** それ以外はすべて機械的な作業にすぎない。バグに対する**タイトな** pass\u002Ffail シグナル — 「_この_バグでだけ赤になる」もの — が手に入れば、原因は必ず見つかる。二分探索も、仮説検証も、計測も、すべてこのシグナルを消費するだけだ。逆にシグナルがなければ、いくらコードを眺めても救われない。\n\nここに不釣り合いなほどの労力をかけること。**攻めろ。工夫しろ。絶対に諦めるな。**\n\n### ループの作り方 — おおむねこの順で試す\n\n1. **失敗するテスト** — バグに届く継ぎ目（seam）ならどこでもいい。ユニット、統合、E2E。\n2. **curl \u002F HTTP スクリプト** — 起動中の開発サーバーに対して実行する。\n3. **CLI 実行** — フィクスチャ入力を与え、stdout を既知の正しいスナップショットと diff する。\n4. **ヘッドレスブラウザスクリプト**（Playwright \u002F Puppeteer）— UI を操作し、DOM・コンソール・ネットワークに対してアサートする。\n5. **キャプチャしたトレースの再生。** 実際のリクエスト \u002F ペイロード \u002F イベントログをディスクに保存し、対象のコードパスに単独で流し込む。\n6. **使い捨てハーネス。** システムの最小サブセット（1 サービス＋モック依存）を立ち上げ、バグのあるコードパスを関数呼び出し 1 回で叩けるようにする。\n7. **プロパティ \u002F ファズループ。** 「たまに出力がおかしい」系のバグなら、ランダム入力を 1000 件流して失敗パターンを探す。\n8. **二分探索ハーネス。** 既知の 2 つの状態（コミット、データセット、バージョン）の間でバグが発生したなら、「状態 X で起動 → 確認 → 繰り返し」を自動化して `git bisect run` できるようにする。\n9. **差分ループ。** 同じ入力を旧バージョンと新バージョン（または 2 つの設定）に流し、出力を diff する。\n10. **HITL（human-in-the-loop）bash スクリプト。** 最終手段。人間がクリックするしかない場合は、`scripts\u002Fhitl-loop.template.sh` で_人間の方を_駆動し、ループの構造だけは保つ。取得した出力は自分にフィードバックさせる。\n\n正しいフィードバックループさえ作れれば、バグは 90% 直ったも同然。\n\n### ループを締める\n\nループを製品として扱うこと。_とりあえずの_ループができたら、**締める**：\n\n- もっと速くできないか？（セットアップのキャッシュ、無関係な初期化のスキップ、テストスコープの絞り込み）\n- シグナルをもっと鋭くできないか？（「クラッシュしなかった」ではなく、具体的な症状に対してアサートする）\n- もっと決定的にできないか？（時刻の固定、乱数シードの固定、ファイルシステムの分離、ネットワークの遮断）\n\n30 秒かかる不安定なループは、ループなしと大差ない。2 秒で決定的なループはタイトだ — デバッグの超能力になる。\n\n### 非決定的なバグ\n\n目標はきれいな再現手順ではなく、**再現率を上げること**。トリガーを 100 回ループさせる、並列化する、負荷をかける、タイミングの窓を狭める、sleep を差し込む。再現率 50% のバグはデバッグできるが、1% では無理だ — デバッグ可能になるまで再現率を上げ続けること。\n\n### どうしてもループが作れないとき\n\n立ち止まって、そのことを明示的に伝えること。試したことを列挙する。ユーザーには次のいずれかを依頼する：(a) 再現する環境へのアクセス、(b) キャプチャ済みの成果物（HAR ファイル、ログダンプ、コアダンプ、タイムスタンプ付き画面録画）、(c) 一時的な本番計測コードを入れる許可。ループなしで仮説立てに進んでは**いけない**。\n\n### 完了基準 — 赤になれるタイトなループ\n\nフェーズ 1 の完了条件は、ループが**タイト**かつ**赤になれる**こと：**1 つのコマンド** — スクリプトパス、テスト実行、curl — を名指しでき、それを**すでに 1 回以上実行済み**（実行コマンドと出力を貼ること）で、かつ次を満たすこと：\n\n- [ ] **赤になれる** — 実際のバグのコードパスを通り、**ユーザーが訴えたそのままの症状**に対してアサートしている。つまり、このバグで赤になり、修正すれば緑になる。「エラーなく動いた」ではダメ — _この特定のバグを捕まえられる_必要がある。\n- [ ] **決定的** — 毎回同じ判定になる（不安定なバグの場合は、上記の通り高い再現率を固定できていること）。\n- [ ] **速い** — 分単位ではなく秒単位。\n- [ ] **エージェント単独で実行可能** — 無人で回せる。人間を挟むのは `scripts\u002Fhitl-loop.template.sh` 経由のみ。\n\nこのコマンドが存在しないうちにコードを読んで理論を組み立てている自分に気づいたら、**止まれ — いきなり仮説に飛びつくのは、このスキルがまさに防ごうとしている失敗そのものだ。** 赤になれるコマンドなくして、フェーズ 2 なし。\n\n## フェーズ 2 — 再現＋最小化\n\nループを回す。赤になるのを見届ける — バグが姿を現す。\n\n確認事項：\n\n- [ ] ループが再現しているのは**ユーザー**が説明した失敗モードである — 近くにある別の失敗ではない。違うバグ＝違う修正。\n- [ ] 失敗が複数回の実行で再現する（非決定的なバグなら、デバッグに足る再現率で再現する）。\n- [ ] 正確な症状（エラーメッセージ、誤った出力、遅いタイミング）を記録済みで、後のフェーズで「修正が本当にその症状を解消したか」を検証できる。\n\n### 最小化\n\n赤になったら、再現ケースを**赤のままでいられる最小のシナリオ**まで削る。入力・呼び出し元・設定・データ・手順を**1 つずつ**削り、削るたびにループを回し直す — 失敗の成立に必要なものだけを残す。\n\nなぜやるのか：最小の再現ケースはフェーズ 3 の仮説空間を縮める（疑うべき可動部が減る）し、フェーズ 5 のきれいな回帰テストになる。\n\n**残っている要素すべてが必要不可欠**になったら完了 — どれか 1 つでも取り除くとループが緑になる状態。\n\n再現**と**最小化の両方が済むまで先に進まないこと。\n\n## フェーズ 3 — 仮説を立てる\n\nどれかを検証し始める前に、**順位付きの仮説を 3〜5 個**生成する。仮説を 1 つしか出さないと、最初に思いついたもっともらしい案に錨を下ろしてしまう。\n\n各仮説は**反証可能**でなければならない：その仮説が導く予測を明文化すること。\n\n> 形式：「もし \u003CX> が原因なら、\u003CY を変える> とバグが消える／\u003CZ を変える> と悪化するはずだ。」\n\n予測を言語化できない仮説は、ただの雰囲気だ — 捨てるか、研ぎ直すこと。\n\n**検証前に、順位付きリストをユーザーに見せること。** ユーザーはドメイン知識で瞬時に順位を入れ替えられることが多い（「#3 の箇所、ちょうどデプロイしたばかりだよ」）し、すでに除外済みの仮説を知っていることもある。安いチェックポイントで大きな時間の節約になる。ただしブロックはしない — ユーザーが離席中なら自分の順位付けで進める。\n\n## フェーズ 4 — 計測する\n\nすべてのプローブは、フェーズ 3 の特定の予測に対応していなければならない。**一度に変えるのは 1 変数だけ。**\n\nツールの優先順位：\n\n1. **デバッガ \u002F REPL での調査** — 環境が対応していれば。ブレークポイント 1 個はログ 10 個に勝る。\n2. **狙い撃ちのログ** — 仮説同士を区別できる境界に置く。\n3. 「全部ログに出して grep」は絶対にやらない。\n\n**デバッグログには必ず一意のプレフィックスを付ける**（例：`[DEBUG-a4f2]`）。最後の掃除が grep 一発で済む。タグなしのログは生き残ってしまう。タグ付きのログは死ねる。\n\n**パフォーマンス分岐。** パフォーマンス劣化に対しては、ログはたいてい間違ったツールだ。代わりに：ベースライン計測（タイミングハーネス、`performance.now()`、プロファイラ、クエリプラン）を確立してから二分探索する。まず測り、それから直す。\n\n## フェーズ 5 — 修正＋回帰テスト\n\n回帰テストは**修正より先に**書く — ただし、それにふさわしい**正しい継ぎ目（seam）**がある場合に限る。\n\n正しい継ぎ目とは、**実際のバグのパターン**を、それが起きた呼び出し箇所と同じ形で再現できる場所のこと。使える継ぎ目が浅すぎる場合（複数の呼び出し元が絡むバグに単一呼び出しのテスト、バグを引き起こした連鎖を再現できないユニットテスト）、そこに置いた回帰テストは偽の安心にしかならない。\n\n**正しい継ぎ目が存在しないなら、それ自体が発見だ。** 記録すること。コードベースの構造が、バグの封じ込めを妨げているということだ。次のフェーズ用にフラグを立てる。\n\n正しい継ぎ目があるなら：\n\n1. 最小化した再現ケースを、その継ぎ目の失敗するテストにする。\n2. 失敗するのを見届ける。\n3. 修正を当てる。\n4. 通るのを見届ける。\n5. 元の（最小化前の）シナリオに対してフェーズ 1 のフィードバックループを回し直す。\n\n## フェーズ 6 — 掃除＋振り返り\n\n完了を宣言する前の必須項目：\n\n- [ ] 元の再現手順で再現しなくなった（フェーズ 1 のループを回し直す）\n- [ ] 回帰テストが通る（または継ぎ目が存在しないことを文書化した）\n- [ ] `[DEBUG-...]` の計測コードをすべて除去した（プレフィックスで grep する）\n- [ ] 使い捨てプロトタイプを削除した（または明確にデバッグ用と分かる場所に移した）\n- [ ] 正しかった仮説をコミット \u002F PR メッセージに明記した — 次にデバッグする人への学びになる\n\n**最後に問うこと：このバグを防げたものは何だったか？** 答えがアーキテクチャ上の変更（良いテストの継ぎ目がない、呼び出し元のもつれ、隠れた結合）を含むなら、その具体的な内容を改善提案としてユーザーに報告する。この提案は修正が入った**後に**行うこと — 着手前より今の方が多くの情報を持っているのだから。\n",{"name":5,"description":7},"main","7d7373bc5573e8ea335bda7a1c38524ae624267f","skills\u002Fengineering\u002Fdiagnosing-bugs","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor","https:\u002F\u002Fgithub.com\u002Flove-dabimas","2026-11-10 10:58:01",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add love-dabimas\u002Fdabimas-factor --skill diagnosing-bugs",{"tool":37,"command":38},"bunx","bunx skills add love-dabimas\u002Fdabimas-factor --skill diagnosing-bugs",{"tool":40,"command":41},"pnpm","pnpm dlx skills add love-dabimas\u002Fdabimas-factor --skill diagnosing-bugs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fdiagnosing-bugs\u002FSKILL.md",true,[45],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"scripts\u002Fhitl-loop.template.sh","SCRIPT","脚本",1164,"https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fdiagnosing-bugs\u002Fscripts\u002Fhitl-loop.template.sh",[52,60,68,77,88,102],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":20},"01M71AE2GF6PEQF66WEBJEFK9J","handoff","現在の会話を、別のエージェントが引き継げる引き継ぎドキュメントに圧縮する。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[54,59],"true",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":20},"01M71AE1KHVHJK399D9YFPK25T","grilling","計画や設計についてユーザーを徹底的にインタビューする。作る前に計画をストレステストしたいとき、または「grill」「詰めて」「壁打ちして」等のトリガーフレーズが使われたときに使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[62,67],"grill",{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":20},"01M71AE04AN4AY0S13FYQ8DD5P","grill-me","計画や設計を研ぎ澄ますための徹底的なインタビュー。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[75,67,76,59],"me","grill me",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":20},"01M71ADXVZS3N8DD4QB9CC5NBK","dabifaku-manual","統合版ダビふぁくのnote向け取扱説明書(note-article\u002F配下)を作成・更新する。ユーザーが「取説」「マニュアル」「note記事」の作成・更新、仕様変更のマニュアルへの反映、スクショの撮り直しを求めたときに使う。影山優佳さん風の文体ガイドとスクリーンショット自動撮影スクリプトを含む。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fdabifaku-manual\u002FSKILL.md",[],[84,85,86,87],"dabifaku manual","manual","article","note",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":20},"01M71ADV895JA69KJJJ0Z0QTW7","codex-implement","実装作業を OpenAI Codex に委譲しつつ、Sonnet\u002FOpus が自分で実装するのと同等の品質を担保する。Claude が設計して作業指示書を書き、別セッションの Codex が実装し、Claude が検収する。ユーザーが「Codexにやらせて」「Codexと分担して」「Codexに依頼して」「Codex用の指示書を作って」と言ったとき（依頼モード）、および「Codexが終わった」「Codexの実装を検収・レビューして」と言ったとき（検収モード）に必ず使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fcodex-implement\u002FSKILL.md",[],[95,96,97,98,99,100,101],"codex","implement","codex implement","opus","sonnet","openai codex","openai",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":20},"01M71ADT7H1BK92WRHTPDQRV0K","tdd","テスト駆動開発（TDD）。ユーザーがテストファーストで機能開発やバグ修正をしたいとき、「red-green-refactor」に言及したとき、または統合テストを書きたいときに使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd\u002FSKILL.md",[],[104,109,110,111,112],"red","green","red-green-refactor","refactor"]