エンジニアリングの規律Claude Code and agents that support the skills CLI
Matt Pocock / grill-me
難しい質問を、エージェントの側からされるとしたら
口頭で説明しきれない計画は、3 週目に破綻する計画です。
押さえておく点
- 助言されるより質問されるほうが、穴は速く出ます。
- 圧力の下で作った答えこそ、後で裏取りすべき箇所です。
- 前段の brainstorming と後段の writing-plans と組み合わさります。
- 持っていない専門知識は補えません。欠けている場所を示すだけです。
01実務で何が変わるか
計画の多くは、誰も議論したがらなかった部分で失敗します。移行、エラー経路、データの所有者、既存顧客の扱い。友好的なレビューが飛ばすのは、まさにその部分です。
問い詰める形式ならそこが表に出ます。形を承認するのではなく、分岐を引っ張り続けるからです。居心地の悪さは副作用ではなく仕組みです。
02期待に届かない点
しつこくなり得ます。すべての分岐を実装前に決める必要はなく、意図的な先送りは正当な回答です。ただし明示的に言う必要があります。
自組織の事実確認もできません。自信をもって述べられた誤りは、そのまま受け入れられます。
導入と最初の実行
- mattpocock/skills から skills CLI 経由で MIT ライセンスで導入します。
- 話題ではなく実際の計画を持ち込みます。問われるのは意図ではなく判断です。
- その場で作った答えをすべて書き留めます。それが本当の穴です。
実際によくある質問
- レビューを頼むのと何が違いますか
- レビューは書いたものを評価します。これは、計画の未決部分が表に出るまであなたに質問します。
- いつ使うべきですか
- 実装前、そして誤った判断を戻すのが高くつく事柄について使ってください。
- 書かれた計画は必要ですか
- 必要です。話題だけでは、曖昧な質問と曖昧な答えしか出ません。
出典
このページの機械可読版