[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71ADJVVMFVX3EJSEF2PAJ1S":3,"skill-same:01M71ADJVVMFVX3EJSEF2PAJ1S":55},{"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":22,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":13,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M71ADJVVMFVX3EJSEF2PAJ1S","code-review",null,"固定点（コミット、ブランチ、タグ、マージベース）以降の変更を 2 つの軸でレビューする — Standards（このリポジトリのコーディング規約に沿っているか）と Spec（元の Issue や仕様が求めたものと一致しているか）。両レビューを並列のサブエージェントで実行し、並べて報告する。ユーザーがブランチ・PR・作業中の変更のレビューを求めたときや、「X 以降をレビューして」と言ったときに使う。","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\u002Fcode-review\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[23,24,25,26,27,28,29],"code review","review","code","spec","pr","standards","issue","2026-11-10 10:12:30",false,"---\nname: code-review\ndescription: 固定点（コミット、ブランチ、タグ、マージベース）以降の変更を 2 つの軸でレビューする — Standards（このリポジトリのコーディング規約に沿っているか）と Spec（元の Issue や仕様が求めたものと一致しているか）。両レビューを並列のサブエージェントで実行し、並べて報告する。ユーザーがブランチ・PR・作業中の変更のレビューを求めたときや、「X 以降をレビューして」と言ったときに使う。\n---\n\n`HEAD` と、ユーザーが指定した固定点との diff を 2 軸でレビューする：\n\n- **Standards（規約）** — コードはこのリポジトリで文書化されたコーディング規約に沿っているか？\n- **Spec（仕様）** — コードは元となった Issue \u002F PRD \u002F 仕様を忠実に実装しているか？\n\n両軸は**並列のサブエージェント**として実行し、互いのコンテキストを汚染しないようにする。その後、このスキルが結果を集約する。\n\n## 手順\n\n### 1. 固定点を確定する\n\nユーザーが指定したものが固定点になる — コミット SHA、ブランチ名、タグ、`main`、`HEAD~5` など。指定がなければ尋ねること。\n\ndiff コマンドを一度だけ確定する：`git diff \u003C固定点>...HEAD`（3 ドット形式。マージベースとの比較になる）。あわせて `git log \u003C固定点>..HEAD --oneline` でコミット一覧も控える。\n\n先へ進む前に、固定点が解決できること（`git rev-parse \u003C固定点>`）と diff が空でないことを確認する。不正な ref や空 diff は、並列サブエージェントの中ではなく、この時点で失敗させること。\n\n### 2. 仕様（spec）の出どころを特定する\n\n元となった仕様を、次の順で探す：\n\n1. コミットメッセージ内の Issue 参照（`#123`、`Closes #45` など）— GitHub CLI（`gh issue view` など）で取得する。\n2. ユーザーが引数として渡したパス。\n3. `docs\u002F`、`specs\u002F`、`.scratch\u002F` 配下にある、ブランチ名や機能名に一致する PRD \u002F 仕様ファイル。\n4. 何も見つからなければ、仕様の場所をユーザーに尋ねる。「仕様はない」と言われたら、**Spec** サブエージェントはスキップし、「仕様なし」と報告する。\n\n### 3. 規約（standards）の出どころを特定する\n\nコードの書き方を文書化しているものすべて。例：`CODING_STANDARDS.md`、`CONTRIBUTING.md`、`CLAUDE.md` のコーディング指針など。\n\nリポジトリが文書化しているものに加えて、Standards 軸は常に下記の**スメル・ベースライン**を持つ — Fowler のコードスメル（『リファクタリング』第 3 章）の固定セットで、リポジトリに規約文書がなくても適用される。2 つのルールが縛る：\n\n- **リポジトリが優先。** 文書化されたリポジトリの規約が常に勝つ。ベースラインが指摘する書き方をリポジトリが是としているなら、そのスメルは抑制する。\n- **常に判断事項。** 各スメルはラベル付きのヒューリスティック（「Feature Envy の可能性」）であって、確定違反ではない。また、他の規約と同様、ツール（リンター等）がすでに強制しているものはスキップする。\n\n各スメルは「それは何か → どう直すか」の形式。diff と突き合わせること：\n\n- **不可解な名前（Mysterious Name）** — 何をする \u002F 何を保持するのか名前から分からない関数・変数・型。→ リネームする。正直な名前が思いつかないなら、設計が濁っている。\n- **重複コード（Duplicated Code）** — 同じロジックの形が、変更内の複数のハンクやファイルに現れる。→ 共通の形を抽出し、両方から呼ぶ。\n- **不適切な関心（Feature Envy）** — 自分のデータより他のオブジェクトのデータにばかり手を伸ばすメソッド。→ そのメソッドを、羨んでいるデータの側へ移す。\n- **データの群れ（Data Clumps）** — 同じ数個のフィールドや引数がいつも連れ立って移動する（型として生まれたがっている）。→ 1 つの型に束ねて、それを渡す。\n- **プリミティブへの執着（Primitive Obsession）** — 固有の型を持つべきドメイン概念を、プリミティブや文字列で代用している。→ その概念に小さな専用の型を与える。\n- **繰り返される switch（Repeated Switches）** — 同じ型に対する同じ `switch` \u002F `if` の連鎖が、変更のあちこちに再登場する。→ ポリモーフィズムか、両方の箇所が共有する 1 つのマップに置き換える。\n- **散弾銃手術（Shotgun Surgery）** — 1 つの論理的な変更のために、diff 内の多数のファイルに散らばった編集が必要になる。→ 一緒に変わるものを 1 つのモジュールに集める。\n- **変更の発散（Divergent Change）** — 1 つのファイルやモジュールが、無関係な複数の理由で編集されている。→ 各モジュールが 1 つの理由でだけ変わるよう分割する。\n- **投機的な一般化（Speculative Generality）** — 仕様にない将来の必要性のために追加された抽象化・引数・フック。→ 削除する。実際の必要が現れるまでインラインに戻す。\n- **メッセージの連鎖（Message Chains）** — 呼び出し側が依存すべきでない長い `a.b().c().d()` のナビゲーション。→ 最初のオブジェクトのメソッド 1 つの背後にその探索を隠す。\n- **仲介人（Middle Man）** — ほとんど委譲するだけのクラスや関数。→ 取り除き、本当の対象を直接呼ぶ。\n- **相続拒否（Refused Bequest）** — 継承したもののほとんどを無視・上書きするサブクラスや実装。→ 継承をやめてコンポジションにする。\n\n### 4. 両サブエージェントを並列で起動する\n\n1 つのメッセージで 2 つの `Agent` ツール呼び出しを送る。どちらも `general-purpose` サブエージェントを使う。\n\n**Standards サブエージェントのプロンプト** — 以下を含める：\n\n- diff コマンドの全文とコミット一覧。\n- 手順 3 で見つけた規約ソースのファイル一覧、**および手順 3 のスメル・ベースラインの全文貼り付け** — サブエージェントは他の方法でベースラインにアクセスできない。\n- 指示文：「ファイル \u002F ハンク単位で（必要に応じて）報告すること — (a) diff が文書化された規約に違反しているすべての箇所：規約を引用する（ファイル＋ルール）。(b) 見つけたベースライン・スメル：名前を挙げ、該当ハンクを引用する。確定違反と判断事項を区別すること — 文書化された規約への違反は確定になり得るが、ベースライン・スメルは常に判断事項であり、文書化されたリポジトリ規約はベースラインに優先する。ツールが強制しているものはスキップ。400 語以内。」\n\n**Spec サブエージェントのプロンプト** — 以下を含める：\n\n- diff コマンドとコミット一覧。\n- 仕様のパス、または取得済みの仕様の内容。\n- 指示文：「報告すること：(a) 仕様が求めたのに欠落・不完全な要件、(b) 求められていないのに diff に入っている振る舞い（スコープクリープ）、(c) 実装済みに見えるが実装が間違っていそうな要件。各指摘について仕様の該当行を引用すること。400 語以内。」\n\n仕様が存在しない場合は Spec サブエージェントをスキップし、最終レポートにその旨を記す。\n\n### 5. 集約する\n\n2 つのレポートを `## Standards` と `## Spec` の見出しの下に、原文のまま（または軽く整えて）提示する。指摘のマージや再ランク付けはしては**いけない** — 2 軸は意図的に分離されている（後述の「なぜ 2 軸か」参照）。\n\n最後に 1 行のまとめ：軸ごとの指摘総数と、_各軸の中で_最も重大な問題（あれば）。軸をまたいで単一の「最重要」を選ばないこと — その再ランク付けこそ、分離が防ごうとしているものだ。\n\n## なぜ 2 軸か\n\n変更は、片方の軸に合格してもう片方に落ちることがある：\n\n- すべての規約に従っているが、実装しているものが間違っている → **Standards 合格、Spec 不合格。**\n- Issue が求めたことを正確にやっているが、プロジェクトの慣習を破っている → **Spec 合格、Standards 不合格。**\n\n別々に報告することで、一方の軸がもう一方を覆い隠すのを防ぐ。\n","`HEAD` と、ユーザーが指定した固定点との diff を 2 軸でレビューする：\n\n- **Standards（規約）** — コードはこのリポジトリで文書化されたコーディング規約に沿っているか？\n- **Spec（仕様）** — コードは元となった Issue \u002F PRD \u002F 仕様を忠実に実装しているか？\n\n両軸は**並列のサブエージェント**として実行し、互いのコンテキストを汚染しないようにする。その後、このスキルが結果を集約する。\n\n## 手順\n\n### 1. 固定点を確定する\n\nユーザーが指定したものが固定点になる — コミット SHA、ブランチ名、タグ、`main`、`HEAD~5` など。指定がなければ尋ねること。\n\ndiff コマンドを一度だけ確定する：`git diff \u003C固定点>...HEAD`（3 ドット形式。マージベースとの比較になる）。あわせて `git log \u003C固定点>..HEAD --oneline` でコミット一覧も控える。\n\n先へ進む前に、固定点が解決できること（`git rev-parse \u003C固定点>`）と diff が空でないことを確認する。不正な ref や空 diff は、並列サブエージェントの中ではなく、この時点で失敗させること。\n\n### 2. 仕様（spec）の出どころを特定する\n\n元となった仕様を、次の順で探す：\n\n1. コミットメッセージ内の Issue 参照（`#123`、`Closes #45` など）— GitHub CLI（`gh issue view` など）で取得する。\n2. ユーザーが引数として渡したパス。\n3. `docs\u002F`、`specs\u002F`、`.scratch\u002F` 配下にある、ブランチ名や機能名に一致する PRD \u002F 仕様ファイル。\n4. 何も見つからなければ、仕様の場所をユーザーに尋ねる。「仕様はない」と言われたら、**Spec** サブエージェントはスキップし、「仕様なし」と報告する。\n\n### 3. 規約（standards）の出どころを特定する\n\nコードの書き方を文書化しているものすべて。例：`CODING_STANDARDS.md`、`CONTRIBUTING.md`、`CLAUDE.md` のコーディング指針など。\n\nリポジトリが文書化しているものに加えて、Standards 軸は常に下記の**スメル・ベースライン**を持つ — Fowler のコードスメル（『リファクタリング』第 3 章）の固定セットで、リポジトリに規約文書がなくても適用される。2 つのルールが縛る：\n\n- **リポジトリが優先。** 文書化されたリポジトリの規約が常に勝つ。ベースラインが指摘する書き方をリポジトリが是としているなら、そのスメルは抑制する。\n- **常に判断事項。** 各スメルはラベル付きのヒューリスティック（「Feature Envy の可能性」）であって、確定違反ではない。また、他の規約と同様、ツール（リンター等）がすでに強制しているものはスキップする。\n\n各スメルは「それは何か → どう直すか」の形式。diff と突き合わせること：\n\n- **不可解な名前（Mysterious Name）** — 何をする \u002F 何を保持するのか名前から分からない関数・変数・型。→ リネームする。正直な名前が思いつかないなら、設計が濁っている。\n- **重複コード（Duplicated Code）** — 同じロジックの形が、変更内の複数のハンクやファイルに現れる。→ 共通の形を抽出し、両方から呼ぶ。\n- **不適切な関心（Feature Envy）** — 自分のデータより他のオブジェクトのデータにばかり手を伸ばすメソッド。→ そのメソッドを、羨んでいるデータの側へ移す。\n- **データの群れ（Data Clumps）** — 同じ数個のフィールドや引数がいつも連れ立って移動する（型として生まれたがっている）。→ 1 つの型に束ねて、それを渡す。\n- **プリミティブへの執着（Primitive Obsession）** — 固有の型を持つべきドメイン概念を、プリミティブや文字列で代用している。→ その概念に小さな専用の型を与える。\n- **繰り返される switch（Repeated Switches）** — 同じ型に対する同じ `switch` \u002F `if` の連鎖が、変更のあちこちに再登場する。→ ポリモーフィズムか、両方の箇所が共有する 1 つのマップに置き換える。\n- **散弾銃手術（Shotgun Surgery）** — 1 つの論理的な変更のために、diff 内の多数のファイルに散らばった編集が必要になる。→ 一緒に変わるものを 1 つのモジュールに集める。\n- **変更の発散（Divergent Change）** — 1 つのファイルやモジュールが、無関係な複数の理由で編集されている。→ 各モジュールが 1 つの理由でだけ変わるよう分割する。\n- **投機的な一般化（Speculative Generality）** — 仕様にない将来の必要性のために追加された抽象化・引数・フック。→ 削除する。実際の必要が現れるまでインラインに戻す。\n- **メッセージの連鎖（Message Chains）** — 呼び出し側が依存すべきでない長い `a.b().c().d()` のナビゲーション。→ 最初のオブジェクトのメソッド 1 つの背後にその探索を隠す。\n- **仲介人（Middle Man）** — ほとんど委譲するだけのクラスや関数。→ 取り除き、本当の対象を直接呼ぶ。\n- **相続拒否（Refused Bequest）** — 継承したもののほとんどを無視・上書きするサブクラスや実装。→ 継承をやめてコンポジションにする。\n\n### 4. 両サブエージェントを並列で起動する\n\n1 つのメッセージで 2 つの `Agent` ツール呼び出しを送る。どちらも `general-purpose` サブエージェントを使う。\n\n**Standards サブエージェントのプロンプト** — 以下を含める：\n\n- diff コマンドの全文とコミット一覧。\n- 手順 3 で見つけた規約ソースのファイル一覧、**および手順 3 のスメル・ベースラインの全文貼り付け** — サブエージェントは他の方法でベースラインにアクセスできない。\n- 指示文：「ファイル \u002F ハンク単位で（必要に応じて）報告すること — (a) diff が文書化された規約に違反しているすべての箇所：規約を引用する（ファイル＋ルール）。(b) 見つけたベースライン・スメル：名前を挙げ、該当ハンクを引用する。確定違反と判断事項を区別すること — 文書化された規約への違反は確定になり得るが、ベースライン・スメルは常に判断事項であり、文書化されたリポジトリ規約はベースラインに優先する。ツールが強制しているものはスキップ。400 語以内。」\n\n**Spec サブエージェントのプロンプト** — 以下を含める：\n\n- diff コマンドとコミット一覧。\n- 仕様のパス、または取得済みの仕様の内容。\n- 指示文：「報告すること：(a) 仕様が求めたのに欠落・不完全な要件、(b) 求められていないのに diff に入っている振る舞い（スコープクリープ）、(c) 実装済みに見えるが実装が間違っていそうな要件。各指摘について仕様の該当行を引用すること。400 語以内。」\n\n仕様が存在しない場合は Spec サブエージェントをスキップし、最終レポートにその旨を記す。\n\n### 5. 集約する\n\n2 つのレポートを `## Standards` と `## Spec` の見出しの下に、原文のまま（または軽く整えて）提示する。指摘のマージや再ランク付けはしては**いけない** — 2 軸は意図的に分離されている（後述の「なぜ 2 軸か」参照）。\n\n最後に 1 行のまとめ：軸ごとの指摘総数と、_各軸の中で_最も重大な問題（あれば）。軸をまたいで単一の「最重要」を選ばないこと — その再ランク付けこそ、分離が防ごうとしているものだ。\n\n## なぜ 2 軸か\n\n変更は、片方の軸に合格してもう片方に落ちることがある：\n\n- すべての規約に従っているが、実装しているものが間違っている → **Standards 合格、Spec 不合格。**\n- Issue が求めたことを正確にやっているが、プロジェクトの慣習を破っている → **Spec 合格、Standards 不合格。**\n\n別々に報告することで、一方の軸がもう一方を覆い隠すのを防ぐ。\n",{"name":5,"description":7},"main","7d7373bc5573e8ea335bda7a1c38524ae624267f","skills\u002Fengineering\u002Fcode-review","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":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add love-dabimas\u002Fdabimas-factor --skill code-review",{"tool":47,"command":48},"bunx","bunx skills add love-dabimas\u002Fdabimas-factor --skill code-review",{"tool":50,"command":51},"pnpm","pnpm dlx skills add love-dabimas\u002Fdabimas-factor --skill code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fcode-review\u002FSKILL.md",true,[],[56,64,72,81,92,106],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":30},"01M71AE2GF6PEQF66WEBJEFK9J","handoff","現在の会話を、別のエージェントが引き継げる引き継ぎドキュメントに圧縮する。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[58,63],"true",{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":30},"01M71AE1KHVHJK399D9YFPK25T","grilling","計画や設計についてユーザーを徹底的にインタビューする。作る前に計画をストレステストしたいとき、または「grill」「詰めて」「壁打ちして」等のトリガーフレーズが使われたときに使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[66,71],"grill",{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":30},"01M71AE04AN4AY0S13FYQ8DD5P","grill-me","計画や設計を研ぎ澄ますための徹底的なインタビュー。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[79,71,80,63],"me","grill me",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":30},"01M71ADXVZS3N8DD4QB9CC5NBK","dabifaku-manual","統合版ダビふぁくのnote向け取扱説明書(note-article\u002F配下)を作成・更新する。ユーザーが「取説」「マニュアル」「note記事」の作成・更新、仕様変更のマニュアルへの反映、スクショの撮り直しを求めたときに使う。影山優佳さん風の文体ガイドとスクリーンショット自動撮影スクリプトを含む。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fdabifaku-manual\u002FSKILL.md",[],[88,89,90,91],"dabifaku manual","manual","article","note",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":30},"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",[],[99,100,101,102,103,104,105],"codex","implement","codex implement","opus","sonnet","openai codex","openai",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":30},"01M71ADT7H1BK92WRHTPDQRV0K","tdd","テスト駆動開発（TDD）。ユーザーがテストファーストで機能開発やバグ修正をしたいとき、「red-green-refactor」に言及したとき、または統合テストを書きたいときに使う。","https:\u002F\u002Fgithub.com\u002Flove-dabimas\u002Fdabimas-factor\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd\u002FSKILL.md",[],[108,113,114,115,116],"red","green","red-green-refactor","refactor"]