テスト駆動開発のための私のエージェントスキル

私もそう思うけど、モックに偏りすぎてるのが嫌だな（これはトレーニングデータに過剰に表れてるのは認めるけど）。

プロンプトエンジニアリングはすぐに古くなっちゃうね。今どき「あなたはエキスパートのソフトウェアエンジニアです。間違いを犯さないでください」なんて言わないよね（笑）。個人的な体験として、大きなプロンプトやスキルはコンテキストウィンドウの予算を消費しちゃうことが多いし、エージェントは現在のタスクにあまり関係ないスキルでも使おうとすることが多い。だから、スキルが多すぎると、どれが必要かをチェックボックスで確認するのに時間がかかっちゃうんだよね。

これが今週のAGENTS.mdの一部だよ（FDEをプレイ中で、クライアントのためにカスタムワークフローを実装して、20倍の生産性を実現した）。# Pythonツール - uvを使ってPython環境と依存関係を管理する。 - uv runでPythonスクリプトやコマンドを実行する。 - コードのテストにはpytestを使う。 - 複雑な入力空間やエッジケースをテストする必要があるときは、hypothesisライブラリを使ってプロパティベースのテストを行う。 - pyproject.tomlを直接編集しない。代わりに、依存関係を管理するためにuv addやuv add --devを使う。 - コードの品質とリンティングにはruff、ty、prek、wilyを使う。 - 過度なキャスティングは避ける。頻繁に型をキャストする必要があるなら、もっと適切な型を使うようにコードをリファクタリングすることを考えてみて。キャスティングは外部システムとインターフェースする境界層でのみ行うべき。 - コードに変更を加えた後は、適切なツールを実行して品質基準を満たしているか確認する。 - バグやリグレッションに遭遇したら、テストを書くことや、将来的に同じことが起こらないようなコードを作ることについて真剣に考える。 - コマンドラインインターフェースを作成するときは、デバッグに役立つログ出力を提供する--verboseフラグを追加する。 - コードを作成する前に、問題を解決するための5つの異なるアプローチを考えて、それらを効果的な順に並べる。その後、最適なアプローチを選んで実装する。 - 書くコードにはすべてテスト駆動開発（TDD）を使う。実装コードを書く前にテストを書く。 - 重複を避けるために、conftest.pyファイルにpytestフィクスチャを集める。 - 可能な限り実際のコードをテストすることを優先する。絶対に必要なときだけダブルやmonkeypatchを使う。モックはできるだけ避ける。 - pytestのmonkeypatchを好む。 - テストが失敗したら、まずuv run pytest --last-failedを使って最後に失敗したテストを実行する。 - 作成するすべての関数やクラスにはnumpyスタイルのドックストリングを使う。 - 関数のドックストリングには例を提供するためにドクトテストを含める。 - すべての関数パラメータと戻り値の型ヒントを使う。 - 失敗の洞察を提供するためにロギングを使う。デバッグにはprintを使わない。スタックトレースを隠すためにロギングを使わない。

参考までに、レスポンスヘッダーには以下が含まれています: Last-Modified: Fri, 22 May 2026 19:08:09 GMT

すべての記事には日付を入れるべきだよね！

いい指摘だね！日付を追加するよ。

https://github.com/jasonswett/llm-skills/blob/main/tdd/SKILL... にはタイムスタンプがあるね（2026年3月14日現在）

スキルはただのマークダウンファイルだってことをみんな忘れがちで、TDDが意味を持つとは思わない。これはカスタムコードベースやあまり使われない道を進むときに特定のニッチ向けのものだと思うし、今後の教訓を保存するためのものだよね。でも、みんな自分のやり方を選ぶ自由があるし、私たちが知らない方法で必要になることもあるかもしれない。

私の経験では、確かにLLMはTDDやOOPについて知ってるけど、教えない限りその知識に基づいて行動するわけじゃないんだよね。もちろん、互いに矛盾することをたくさん「知っている」わけだし。