mcpField
S
settle-effort

settle-effort

github.com/yahyabedirhan開発263 回インストール1 週間前に更新
リポジトリ

settle-effort について

Settle Effort は、ユーザーがプルリクエストを承認した後の作業を進める開発スキルです。マージ、マージ後の確認、フォローアップの管理、セッションの整理を扱います。

主な機能

  1. 01プルリクエストと関連作業の特定
  2. 02必要なチェック後のマージ
  3. 03フォローアップと未実施チェックの実行
  4. 04未完了作業のチケット化
  5. 05ワークツリーとブランチの整理判定

活用シーン

  1. 01承認済みプルリクエストの完了
  2. 02CIとマージ後の作業の確認
  3. 03残作業の次の取り組みへの引き継ぎ

インストール

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

$npx skills add https://github.com/yahyabedirhan/skills --skill settle-effort

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

同梱ファイルagents/openai.yaml

詳細

作業を完了する

プルリクエストの承認が、ユーザーの最後の作業です。それ以降はすべてこちらで対応します。

手順

  1. 作業を特定します: プルリクエスト、そのブランチ、仕様書、チケット、引き継ぎ内容、およびビルドで残されたすべてのワークツリーとブランチ(委任先の残作業も含む)を確認します。
    • 作業のブランチ以外をチェックアウトしている場合: gh pr list --head と --state all を使って、ヘッドブランチごとにプルリクエストを一覧表示します。--state all を指定しないと、マージ済みのプルリクエストは表示されません。
  2. チェックが通ったらプルリクエストをマージし、マージ後にデフォルトブランチの CI が通ることを確認します。gh pr merge とプロジェクトで通常使われている方法でマージし、--delete-branch は指定しないでください。このオプションは、マージが確認される前にブランチを削除し、現在のチェックアウトをデフォルトブランチに切り替えるためです。
    • プルリクエストがスタックされている場合(別のプルリクエストのブランチをベースにしている場合): ベースのプルリクエストを先にマージしてからマージします。また、ベースブランチを削除する前に gh pr edit --base でデフォルトブランチをベースに設定してください。ベースブランチを削除すると、そのプルリクエストは完全にクローズされるためです。
    • セッションにセッションステータスツールがある場合: マージする前に、未解決の before_settling と blocked の判断事項を /settle-session > 'Steps' > Nothing undecided の指示に従って提示します。回答によってマージの判断が変わる可能性があるためです。
    • 仕様書に「QA: blocking」と記載されている場合: QA チケットがすべてクローズされてからマージします。それまでは、未完了のチケットをユーザーに伝え、そこで完了処理を止めます。チケットがクローズされると、続きから再開します。
    • マージ後にデフォルトブランチの CI が失敗した場合: 手順 5 に進む前に停止し、失敗内容をユーザーに伝えて、ユーザーの判断に従ってチケットを作成するか修正します。
    • スカッシュまたはリベース後: コミット SHA を含む画像 URL など、ブランチのコミットに固定されているものが引き続き解決できることを確認します。デフォルトブランチには、そうしたコミットが含まれないためです。
    • プルリクエストがすでにマージ済みの場合: マージは省略しますが、デフォルトブランチの CI と、スカッシュまたはリベース後の固定コミットは引き続き確認します。
  3. 引き継ぎ後に残っている作業(後続対応、未実施のチェック、ユーザーに判断を求める事項)を把握するため、プルリクエストの説明と引き継ぎ内容を読みます。
  4. 手順 3 で挙がったすべての後続対応と未実施のチェックを実施します。たとえば、変更内容をインストールしたり、マージ後にしか試せなかったことを確認したりします。報告のため、それぞれの結果を記録します。
    • マージにバージョン更新が含まれていた場合: マージ後の手順からチェックまで、プロジェクトの docs/agents/releasing.md に従い、各段階のバージョンを報告用に記録します。ユーザーの作業が必要な公開など、ページに記載されている各手順はユーザーに引き継ぎ、チェックを行う前に完了を待ちます。プロジェクトにリリースページがない場合はその旨をユーザーに伝え、作成する /set-up-project を提案します。
  5. 未完了の作業は、次の作業にチケットとして引き継ぎ、次の作業を示すラベルを付けて、それぞれの発生元にリンクします。ラベルがまだ存在しないと gh issue create --label は失敗するため、不足している effort: ラベルは先に gh label create で作成します。その後、マージによって完了した仕様書とすべてのチケットをクローズします。「closes」キーワードでクローズされなかったものは、手動でクローズします。
    • 次の作業がどれか明確でない場合: ユーザーに確認します。
    • QA チケットの場合: ユーザーがビルドを確認できる方法をコメントに記載し、チケットはオープンのままにします。
  6. /settle-session を使ってセッションを完了し、クリーンアップの評価対象として手順 1 で確認したすべてのワークツリーとブランチを指定します。呼び出し元とターミナルの構成は維持します。/settle-session の条件を満たす、マージ済みで使用されていないことが確認されたワークツリーのみを解放します。レポートには、何がマージされ、何がクローズされ、何が引き継がれたか、および手順 4 の各後続対応で何が確認できたかも記載してもらいます。

コメント