mcpField
C
chief-grill

chief-grill

github.com/thaitypeエージェントワークフロー66131 回インストール5 週間前に更新
リポジトリ

chief-grill について

chief-grillは、コードベースの確認と記録を伴う設計議論向けのエージェントスキルです。質問ごとの自己点検、バックグラウンド検証、再開可能なセッションログを組み合わせます。

主な機能

  1. 01設計上の質問を一つずつ提示
  2. 02自己点検付きの推奨案
  3. 03バックグラウンドでのコードベース検証
  4. 04再開可能な永続セッションログ
  5. 05終了前の最終レビュー

活用シーン

  1. 01重要度の高い設計判断の検討
  2. 02複数回にわたる意思決定の再開

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/thaitype/chief --skill chief-grill

インストール後、Claude Code で/chief-grillを入力して読み込まれたか確認します。

詳細

検証済みのグリルセッションを実行しています。これは /grill-design に、次の 2 つを追加したものです。

  1. 質問ごとのセルフレビュー(スキル内)。 回答を推奨する前に、自分の選択を批評します。ユーザーが回答した後は、その回答をストレステストします。
  2. 質問ごとのバックグラウンド検証(answer-verifier-agent)。 ユーザーが次の質問を考えている間に、エージェントが前の回答を実際のコードベースと照合します。検証結果はサイドバーに表示されます。
  3. 永続的なセッションログ。 すべての状態は .chief/_grill/opened/NNNN-topic.md に保存されます。コンパクションや /clear の後も維持されます。

質問は一度に 1 つずつ行います。ユーザーの回答を待ってください。各質問には推奨回答を添えてください。

手順

1. 事前確認

次を確認します(まだ作成しないでください)。

  • .chief/ — 存在しますか?
  • .chief/_grill/ — 存在しますか?
  • .chief/_grill/opened/ と .chief/_grill/closed/ — 存在しますか?
  • .chief/_grill/opened/ に未解決のセッションはありますか?
2. 再開するか、新規に開始する

.chief/_grill/opened/ にファイルがある場合は、各ファイルのトピック(H1 を読み取る)とともに一覧表示し、次のように尋ねます。

未完了のグリルセッションが N 件見つかりました。いずれかを再開しますか、それとも新規に開始しますか?

  1. 0003-payment-sdk を再開(解決済み 12 件、未解決 3 件)
  2. 0007-auth を再開(解決済み 5 件、未解決 0 件 — 最終レビューの準備完了)
  3. 新規に開始

ユーザーが再開を選んだ場合 → そのファイルをセッションログとして読み込み、手順 5 に進みます。 ユーザーが新規を選んだ場合 → 手順 3 に進みます。 opened/ が空、または存在しない場合 → 手順 3 に進みます。

3. トピックとスラッグ

/chief-grill の実行後にユーザーが最初に送ったメッセージ(またはグリルする内容を説明した最新のメッセージ)を使います。そこからケバブケースのトピックスラッグを導きます(最大 3~5 語)。ユーザーに次のように提示します。

トピック:payment-sdk。このまま進めますか、それとも別のスラッグを指定しますか?

ユーザーが変更する場合は、そのスラッグを使います。

4. セッションログの作成(足場作成を遅延)

存在しないディレクトリを作成します。

  1. 必要に応じて .chief/_grill/、.chief/_grill/opened/、.chief/_grill/closed/ を作成します。

  2. 次の連番を計算します。opened/ と closed/ 内のファイル数を数え、1 を加え、4 桁になるようゼロ埋めします。

  3. 次の初期内容で .chief/_grill/opened/NNNN-<slug>.md を作成します。

    # Grill: <topic title-cased>
    
    ## Open Questions
    
    ## Resolved
    
    ## Final Review
    
5. グリルループ

質問ごとに、次の手順を実行します。

5a. 次の質問を選ぶ

質問がキューにある場合は 未解決の質問 セクションから選びます。キューにない場合は、現在の位置から設計ツリーをたどって次の質問を生成します。

5b. 推奨回答をセルフクリティークする

質問をユーザーに提示する前に、内部で次を行います。

  • 推奨回答を考えます。

  • 自分に問いかけます。この選択でどのような前提を置いているか。この選択のどこが誤っている可能性があるか。他にどのような選択肢があるか。

  • セルフクリティークを添えて推奨回答を提示します。形式は次のとおりです。

    Q:<質問>

    選択肢:

    • (A) ...
    • (B) ...

    推奨: (A) — <理由を一文で>

    セルフチェック: <推奨回答に対する率直な批評を一文で記述します。例:「チームに Postgres の運用経験があることを前提としています。確定する前に確認してください。」>

    A/B/C を選ぶ、変更案を出す、または異議を唱えてください。

5c. 保留中のサイドバーを表示する

前の質問のバックグラウンド検証で結果(判定 concern または conflict)が返っている場合は、新しい質問の前にサイドバーとして表示します。

サイドバー(Q): <検証結果> 推奨される対応: <推奨アクション> 根拠:

  • <根拠の行>

今すぐ対応しますか、それとも続行しますか?

ユーザーが「今すぐ対応する」を選んだ場合は、Q を再度開きます。それ以外の場合は続行します。

判定が ok の場合は何も表示しません。

5d. ユーザーの回答

ユーザーの回答を待ちます。選択肢または変更案を受け付けます。

5e. 回答をストレステストする(スキル内、即時)

ログに書き込む前に、次の点を簡潔にストレステストします。

  • このセッションログ内の過去の確定済み決定と矛盾していませんか?
  • まだ必要になる可能性のある分岐を閉ざしていませんか?
  • 指摘すべき隠れた前提はありませんか?

問題があれば、記録する前にその場で提起します。問題がなければ続行します。

5f. セッションログに記録する

セッションログを更新します。

  • 質問を 解決済み に移し、次の形式で記録します:Q<n>: <question> → <decision>. Why: <reason>.
  • 新たに追加されたフォローアップの質問があれば、関連する場合は (depends on: Q<n>) の注記を付けて 未解決の質問 に追加します。
5g. バックグラウンド検証エージェントを起動する

次の内容で、バックグラウンドで answer-verifier-agent を起動します。

  • question: 質問文
  • answer: ユーザーが決定した回答
  • prior-context: ログの 解決済み セクション(今回の質問を除く)
  • session-log-path: セッションログファイルのフルパス

Agent ツールを使い、subagent_type: "answer-verifier-agent" と run_in_background: true を指定します。エージェントは YAML 形式の判定結果を返します。次のターンの冒頭(5c)で読み込み、サイドバーに表示してください。

5c を表示する時点で前のターンのバックグラウンド検証エージェントがまだ結果を返していない場合は、待たずにサイドバーなしで進めてください。結果が届いたら確認し、conflict の場合は、その質問が後になっていてもサイドバーに表示してください。

5h. 繰り返す

ユーザーがまとめを求めない限り、5a に戻ります。

6. セッションを終了する(明示的な操作)

ユーザーが「done」/「close this grill」/「wrap up」などと言った場合:

  1. 最終レビューを実行します。セッションログのパスを指定して、mode: final で answer-verifier-agent を呼び出します。判定結果が返るまで待ちます(このときはフォアグラウンドで実行します)。
  2. 判定結果の finding と evidence をログの 最終レビュー セクションに追記します。
  3. 最終レビューの判定が concern または conflict の場合は、その内容を提示して、「これに対処してセッションを続けますか、それともこのまま終了しますか?」と尋ねます。ユーザーの選択に従ってください。
  4. 終了の確認後、.chief/_grill/opened/NNNN-<slug>.md を .chief/_grill/closed/NNNN-<slug>.md に移動します。
  5. 終了したファイルのパスをユーザーに伝えます。そこで停止します。

ユーザーが「stop」/「pause」と言った場合、または終了せずに会話を離れた場合は、ファイルを opened/ に残してください。ユーザーは後で再開できます。

重要なルール

  • 必ず回答を推奨してください。質問だけで終わらせないでください。
  • 推奨の横に、必ずセルフチェックを表示してください。
  • 一度に扱う質問は一つです。複合的な質問は禁止です。
  • セッションログの更新を決して省略しないでください。会話ではなく、そのファイルを信頼できる情報源として扱います。
  • バックグラウンド検証エージェントの結果を待ってはいけません。未着の場合は、サイドバーなしで続行してください。
  • セッションを自動で終了してはいけません。終了は必ずユーザーが開始する必要があります。
  • 古い未終了セッションを移動してはいけません。ユーザーが手動で終了または削除するまで、opened/ に残してください。
  • エージェントの判定結果は YAML です。言い換えずに解析してください。サイドバーを表示するのは concern と conflict の場合だけです。

/grill-design との違い

  • /grill-design は、会話内での自己批評とストレステストを追加します。軽量で、ファイルやサブエージェントは使いません。
  • /chief-grill は、コードベースの検証(バックグラウンドのサブエージェント)と、.chief/_grill/ 配下の永続的なセッションログを追加します。より大がかりなため、重要度が高い場合や、相互に検証する必要のある複数の判断にまたがる話題で使用してください。

コメント