[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71ADT7H1BK92WRHTPDQRV0K":3,"skill-same:01M71ADT7H1BK92WRHTPDQRV0K":57},{"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":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":13,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M71ADT7H1BK92WRHTPDQRV0K","tdd",null,"テスト駆動開発（TDD）。ユーザーがテストファーストで機能開発やバグ修正をしたいとき、「red-green-refactor」に言及したとき、または統合テストを書きたいときに使う。","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\u002Ftdd\u002FSKILL.md",[],[5,18,19,20,21],"refactor","red-green-refactor","green","red","2026-11-10 10:12:30",false,"---\nname: tdd\ndescription: テスト駆動開発（TDD）。ユーザーがテストファーストで機能開発やバグ修正をしたいとき、「red-green-refactor」に言及したとき、または統合テストを書きたいときに使う。\n---\n\n# テスト駆動開発\n\nTDD とは red → green のループである。このスキルは、そのループが「残す価値のあるテスト」を生み出すためのリファレンスだ：良いテストとは何か、テストはどこに置くか、アンチパターン、そしてループのルール。すべてのセクションが毎サイクルに適用される — ループの前と最中に参照すること。後からではない。\n\nコードベースを探索するときは、プロジェクトのドキュメント（`CLAUDE.md` や `docs\u002F` 配下の設計メモなど、あれば）を読み、テスト名やインターフェースの語彙がプロジェクトのドメイン用語と一致するようにすること。\n\n## 良いテストとは何か\n\nテストは、実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証する。コードが丸ごと書き換わっても、テストは変わらないべきだ。良いテストは仕様書のように読める —「有効なカートを持つユーザーはチェックアウトできる」は、どんな能力が存在するかを正確に伝える — そして内部構造に無関心だからこそリファクタリングを生き延びる。\n\n例は [tests.md](tests.md) を、モックの指針は [mocking.md](mocking.md) を参照。\n\n## 継ぎ目（seam）— テストを置く場所\n\n**継ぎ目（seam）**とは、テストを当てる公開境界のこと：内部に手を突っ込まずに振る舞いを観察できるインターフェースだ。テストは継ぎ目に置く。内部に対しては決して書かない。\n\n**事前に合意した継ぎ目でのみテストする。** テストを 1 つでも書く前に、テスト対象の継ぎ目を書き出してユーザーと確認すること。未確認の継ぎ目にテストを書いてはいけない。すべてはテストできない — 継ぎ目を先に合意することで、テストの労力があらゆる端ケースではなく、クリティカルパスと複雑なロジックに集中する。\n\n問うべきこと：「公開インターフェースは何で、どの継ぎ目をテストすべきか？」\n\n## アンチパターン\n\n- **実装結合** — 内部のコラボレーターをモックする、プライベートメソッドをテストする、あるいは横道から検証する（インターフェースを使わずデータベースを直接クエリするなど）。見分け方：振る舞いが変わっていないのにリファクタリングでテストが壊れる。\n- **トートロジー** — アサーションが期待値をコードと同じやり方で再計算している（`expect(add(a, b)).toBe(a + b)`、同じ手順で手作りしたスナップショット、定数を自分自身と比較する等）。構造上必ず通ってしまい、コードと食い違うことができない。期待値は独立した真実の源から来なければならない — 既知の正しいリテラル、手計算した例、仕様書。\n- **水平スライス** — テストを全部先に書き、それから実装を全部書く。まとめて書いたテストは_想像上の_振る舞いを検証している：ユーザーに見える振る舞いではなく物事の_形_をテストしてしまい、テストは現実の変化に鈍感になり、実装を理解する前にテスト構造にコミットしてしまう。代わりに**垂直スライス**で進めること — テスト 1 つ → 実装 1 つ → 繰り返し。各テストは、直前のサイクルで学んだことに応答する**曳光弾（tracer bullet）**である。\n\n## ループのルール\n\n- **緑の前に赤。** まず失敗するテストを書き、それを通すのに必要なだけのコードを書く。将来のテストを先取りしたり、投機的な機能を足したりしない。\n- **一度に 1 スライス。** 1 サイクルにつき、1 つの継ぎ目、1 つのテスト、1 つの最小実装。\n- **リファクタリングはループの一部ではない。** それはレビュー段階（`\u002Fcode-review` スキル参照）に属するもので、red → green の実装サイクルには含めない。\n","# テスト駆動開発\n\nTDD とは red → green のループである。このスキルは、そのループが「残す価値のあるテスト」を生み出すためのリファレンスだ：良いテストとは何か、テストはどこに置くか、アンチパターン、そしてループのルール。すべてのセクションが毎サイクルに適用される — ループの前と最中に参照すること。後からではない。\n\nコードベースを探索するときは、プロジェクトのドキュメント（`CLAUDE.md` や `docs\u002F` 配下の設計メモなど、あれば）を読み、テスト名やインターフェースの語彙がプロジェクトのドメイン用語と一致するようにすること。\n\n## 良いテストとは何か\n\nテストは、実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証する。コードが丸ごと書き換わっても、テストは変わらないべきだ。良いテストは仕様書のように読める —「有効なカートを持つユーザーはチェックアウトできる」は、どんな能力が存在するかを正確に伝える — そして内部構造に無関心だからこそリファクタリングを生き延びる。\n\n例は [tests.md](tests.md) を、モックの指針は [mocking.md](mocking.md) を参照。\n\n## 継ぎ目（seam）— テストを置く場所\n\n**継ぎ目（seam）**とは、テストを当てる公開境界のこと：内部に手を突っ込まずに振る舞いを観察できるインターフェースだ。テストは継ぎ目に置く。内部に対しては決して書かない。\n\n**事前に合意した継ぎ目でのみテストする。** テストを 1 つでも書く前に、テスト対象の継ぎ目を書き出してユーザーと確認すること。未確認の継ぎ目にテストを書いてはいけない。すべてはテストできない — 継ぎ目を先に合意することで、テストの労力があらゆる端ケースではなく、クリティカルパスと複雑なロジックに集中する。\n\n問うべきこと：「公開インターフェースは何で、どの継ぎ目をテストすべきか？」\n\n## アンチパターン\n\n- **実装結合** — 内部のコラボレーターをモックする、プライベートメソッドをテストする、あるいは横道から検証する（インターフェースを使わずデータベースを直接クエリするなど）。見分け方：振る舞いが変わっていないのにリファクタリングでテストが壊れる。\n- **トートロジー** — アサーションが期待値をコードと同じやり方で再計算している（`expect(add(a, b)).toBe(a + b)`、同じ手順で手作りしたスナップショット、定数を自分自身と比較する等）。構造上必ず通ってしまい、コードと食い違うことができない。期待値は独立した真実の源から来なければならない — 既知の正しいリテラル、手計算した例、仕様書。\n- **水平スライス** — テストを全部先に書き、それから実装を全部書く。まとめて書いたテストは_想像上の_振る舞いを検証している：ユーザーに見える振る舞いではなく物事の_形_をテストしてしまい、テストは現実の変化に鈍感になり、実装を理解する前にテスト構造にコミットしてしまう。代わりに**垂直スライス**で進めること — テスト 1 つ → 実装 1 つ → 繰り返し。各テストは、直前のサイクルで学んだことに応答する**曳光弾（tracer bullet）**である。\n\n## ループのルール\n\n- **緑の前に赤。** まず失敗するテストを書き、それを通すのに必要なだけのコードを書く。将来のテストを先取りしたり、投機的な機能を足したりしない。\n- **一度に 1 スライス。** 1 サイクルにつき、1 つの継ぎ目、1 つのテスト、1 つの最小実装。\n- **リファクタリングはループの一部ではない。** それはレビュー段階（`\u002Fcode-review` スキル参照）に属するもので、red → green の実装サイクルには含めない。\n",{"name":5,"description":7},"main","7d7373bc5573e8ea335bda7a1c38524ae624267f","skills\u002Fengineering\u002Ftdd","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":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add love-dabimas\u002Fdabimas-factor --skill tdd",{"tool":39,"command":40},"bunx","bunx skills add love-dabimas\u002Fdabimas-factor --skill tdd",{"tool":42,"command":43},"pnpm","pnpm dlx skills add love-dabimas\u002Fdabimas-factor --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd\u002FSKILL.md",true,[47,53],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"mocking.md","REFERENCE","参考文档",1784,"https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd\u002Fmocking.md",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"tests.md",2864,"https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd\u002Ftests.md",[58,66,74,83,94,108],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":22},"01M71AE2GF6PEQF66WEBJEFK9J","handoff","現在の会話を、別のエージェントが引き継げる引き継ぎドキュメントに圧縮する。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[60,65],"true",{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":22},"01M71AE1KHVHJK399D9YFPK25T","grilling","計画や設計についてユーザーを徹底的にインタビューする。作る前に計画をストレステストしたいとき、または「grill」「詰めて」「壁打ちして」等のトリガーフレーズが使われたときに使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[68,73],"grill",{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":22},"01M71AE04AN4AY0S13FYQ8DD5P","grill-me","計画や設計を研ぎ澄ますための徹底的なインタビュー。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[81,73,82,65],"grill me","me",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":22},"01M71ADXVZS3N8DD4QB9CC5NBK","dabifaku-manual","統合版ダビふぁくのnote向け取扱説明書(note-article\u002F配下)を作成・更新する。ユーザーが「取説」「マニュアル」「note記事」の作成・更新、仕様変更のマニュアルへの反映、スクショの撮り直しを求めたときに使う。影山優佳さん風の文体ガイドとスクリーンショット自動撮影スクリプトを含む。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fdabifaku-manual\u002FSKILL.md",[],[90,91,92,93],"dabifaku manual","manual","note","article",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":22},"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",[],[101,102,103,104,105,106,107],"codex implement","implement","codex","opus","sonnet","openai codex","openai",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":22},"01M71ADR89HKKZCC08P58AJC6J","resolving-merge-conflicts","進行中の git マージ \u002F リベースのコンフリクトを解決する必要があるときに使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fresolving-merge-conflicts\u002FSKILL.md",[],[115,116,117,118,119],"merge","conflicts","merge conflicts","resolving merge conflicts","git"]