principle-build-the-lever

レバーを作る

作業が単純でないなら、手作業で進めるのではなく、それを実行するツールを作りましょう。

理由： 2つのメリットがあります。処理能力：codemod、ジェネレーター、スクリプトを使えば、毎回同じ方法で作業でき、何度でも無料で再実行できます。確実性：ツールは、レビュー担当者が読んで再実行し、作業を確認できる1つの成果物です。手作業で行った変更を再検証するには、作業をやり直すしかありません。決定論的なスクリプトがあれば、「信じてください」を「これを実行してください」に変えられます。

パターン： まずレバーを作ることを基本とします。タスクが本当に単純で、ひと目でわかる明らかな編集が数か所だけの場合に限り、省略します。

• 最初の単位は手作業で行い、手順を把握してからツールを作ります。その単位にツールを再実行し、手作業で行ったものと差分を比較して、ツールが正しく動くことを確認します。レバーは安全に再実行できるようにします。レビュー担当者が再実行するためです。
• 編集にはcodemodまたはスクリプト、繰り返し作成するファイルにはジェネレーター、分析にはダンプからSQLiteへのクエリ、検証には再実行可能なチェックを使います。
• 決定論的なレバーは、作業の分散より優れています。ツールで全単位を一度に処理できるなら、自分で実行しましょう。スクリプトでできることを手作業で適用するよう、作業を委任してはいけません。
• 作業をサブエージェントに分散する場合は、全員が読むスキルとしてレバーを書きます。手順、検証の契約、触れてはいけない範囲を1つの成果物にまとめ、プロンプトごとに説明し直して個々のエージェントが逸脱するのを見守るのではなく、すべての委任先が強化済みの同じバージョンを引き継げるようにします。委任先の書き込み範囲外に置き、契約をひそかに編集できないようにします。
• この原則を適用すると、ファイルが作られます。この原則を引用したのに、差分にcodemod、スクリプト、ジェネレーター、委任用スキルのいずれもないなら、適用したことにはなりません。
• 作業がセッションを越えて続く場合は、レバーをコミットしましょう。次回は作業をやり直すのではなく、レバーを再実行できます。

バランス： 基準となるのは反復性ではなく、単純さです。1回限りの作業でも、レバーによって検証可能になるなら、レバーを作る価値があります。Laziness Protocolに従い、作業を実行する、またはその正しさを証明する最小限のスクリプトを作り、フレームワークは作らないでください。

これは、繰り返し使う指示を永続的なガードレールにするEncode Lessons in Structureとは異なります。こちらは、目の前の作業の処理能力とレビュー可能性を高めるものです。検証そのものをスクリプト化する方法については、Prove It Worksを参照してください。