一键导入
tdd-workflow
Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
ユーザー固有の、長期的に再利用できる解釈・説明・対話方法をコミュニケーションメモリへ保存し、現在の依頼に関係する項目だけを応答へ適用する。 Triggers: `$adapt-to-user` の明示呼び出し、保存済みの好みに合わせた返答の依頼、応答方法の好みや過去の訂正・教訓の記憶・参照・確認の依頼。及びそれらの変更・削除の明示的な依頼。 Do not Trigger: 明示呼び出しのない一回限りの文体・長さ・形式指定、一般的なユーザー情報や会話内容の記憶、案件固有情報やプロジェクト規約の保存、秘密情報の保存、沈黙や反応から好みを推測する場合。
GitHub PR の変更内容を先に解説し、ユーザーの理解確認を挟みながら対話的に レビューを進めるワークフロー。 Trigger: ユーザーが `$aota-review` を明示した場合、PR の URL または番号を 提示して「まず変更内容を理解したい」「解説を受けてから一緒にレビューしたい」 など段階的・対話的な進行を求めた場合、またはこのスキルで開始したレビューの 続行を明示した場合に使用する。 Do not trigger: PR の URL または番号とともに単にレビュー、merge 可否、問題点、 特定観点での検証、または最終結論までの自律的な作業を求められた場合には 使用しない。PR を既に理解した後の単発の説明・要約・質問回答、PR 説明文の 作成・更新、コード修正、レビューコメントへの対応、CI 修正、または PR を 対象としない一般的なコードレビューにも使用しない。
会話全体と現在の理解・方針・成果物を照合し、ユーザーの意図とのずれ、局所的な指示への没入、抽象度の取り違えを点検する。メインエージェントでは点検結果を作業方針へ反映し、subagent では独立レビューだけを行う。ユーザーが認識のすれ違いを指摘したとき、重要な方針を決める前、現在の進め方をメタ的に点検するとき、または subagent にユーザー視点のレビューを委ねるときに使用する。
Create or update a visual keymap for a shortcut device, and keep it synchronized with Karabiner-Elements mappings. Triggers: a user asks to visualize shortcut assignments, create or update a keypad/keyboard/controller cheat sheet, show assigned versus unassigned keys, create a shortcut diagram, or prepare a keymap for a desktop overlay. Do not trigger: ordinary Karabiner shortcut changes that do not require a visual, general brainstorming about shortcut assignments, or a request to inspect an existing mapping without creating or updating its visual representation.
Behavioral guidelines for cautious, minimal, and verifiable code changes. Triggers: The user explicitly requests this skill's application, for example by using `$karpathy-guidelines`, saying "apply karpathy-guidelines", or asking to use Karpathy Guidelines. Do not trigger: Any request that does not explicitly request this skill's application, including ordinary implementation, review, refactoring, design, or testing work. Questions about this skill's content, configuration, triggering conditions, or edits also do not trigger it unless the user explicitly asks to apply it.
対象文書 (設計資料・要求からの設計・調査報告・原因切り分け案・対策案・命名・ 推論順序の要約) を書く前に、対応表 (referent table) を独立成果物として先に提出し、 語より先に指示対象と役割を固定する生成手順。 Triggers: 設計資料を書く, 設計文書作成, 調査報告を書く, 対策案を書く, 命名する, 状態名・条件名・型名・メソッド名を決める, 推論順序を要約する, referent table, 対応表. DO NOT TRIGGER: ユーザー原文の引用、単純な機械編集、既存名の再利用、定型出力、雑談、 確立した用語だけで書ける短文。
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
| description | Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle. |
| metadata | {"github-path":"tdd-workflow","github-ref":"refs/heads/main","github-repo":"https://github.com/xfstudio/skills","github-tree-sha":"9193495284b2df768d3b1e95ae346eedf8c23e4d"} |
| name | tdd-workflow |
Write tests first, code second.
🔴 RED → Write failing test
↓
🟢 GREEN → Write minimal code to pass
↓
🔵 REFACTOR → Improve code quality
↓
Repeat...
| Focus | Example |
|---|---|
| Behavior | "should add two numbers" |
| Edge cases | "should handle empty input" |
| Error states | "should throw for invalid data" |
| Principle | Meaning |
|---|---|
| YAGNI | You Aren't Gonna Need It |
| Simplest thing | Write the minimum to pass |
| No optimization | Just make it work |
| Area | Action |
|---|---|
| Duplication | Extract common code |
| Naming | Make intent clear |
| Structure | Improve organization |
| Complexity | Simplify logic |
Every test follows:
| Step | Purpose |
|---|---|
| Arrange | Set up test data |
| Act | Execute code under test |
| Assert | Verify expected outcome |
| Scenario | TDD Value |
|---|---|
| New feature | High |
| Bug fix | High (write test first) |
| Complex logic | High |
| Exploratory | Low (spike, then TDD) |
| UI layout | Low |
| Priority | Test Type |
|---|---|
| 1 | Happy path |
| 2 | Error cases |
| 3 | Edge cases |
| 4 | Performance |
| ❌ Don't | ✅ Do |
|---|---|
| Skip the RED phase | Watch test fail first |
| Write tests after | Write tests before |
| Over-engineer initial | Keep it simple |
| Multiple asserts | One behavior per test |
| Test implementation | Test behavior |
| Agent | Role |
|---|---|
| Agent A | Write failing tests (RED) |
| Agent B | Implement to pass (GREEN) |
| Agent C | Optimize (REFACTOR) |
Remember: The test is the specification. If you can't write a test, you don't understand the requirement.