mcpField
P
plan-it

plan-it

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

plan-it について

plan-itは、リポジトリ作業を公開済みの仕様と承認済みチケットにまとめるワークフロー調整スキルです。spec-itとticket-itを連携させ、各段階で検証とユーザー承認を行います。

主な機能

  1. 01spec-itとticket-itの連携
  2. 02リポジトリとトラッカー設定の確認
  3. 03公開された仕様課題の検証
  4. 04チケット分割案の承認要求
  5. 05ユーザー入力待ちでの一時停止
  6. 06ブロッカーと課題URLの報告

活用シーン

  1. 01リポジトリの状況に基づく仕様作成
  2. 02承認済み仕様のチケット分割
  3. 03ユーザーフィードバック後のチケット作業再開

インストール

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

$npx skills add https://github.com/goncalvesjoao/ship-it --skill plan-it

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

詳細

計画する

ユーザーからの質問

ユーザーからの質問を尋ねたり伝えたりする前に、ユーザー質問のルールを読んで従ってください。

spec-it、ticket-it、それらの前提条件、およびサブエージェントのサポートが必要です。

このスキルを呼び出すと、これらのスキルを通じて仕様と承認済みチケットを公開することが許可されます。ユーザーへの確認と承認の手順は必ず維持してください。このスキルを作成または編集しても、公開は開始されません。

オーケストレーション

  1. リポジトリの指示を読み、絶対パスでのリポジトリパス、対象のGitHubリポジトリ、トラッカーの設定、および両方のローカルスキルのパスを特定します。公開前に、不足している前提条件を解決するか、対象の曖昧さを解消します。
  2. 親チャットで、spec-it とその上流の依存関係を直接読み、従ってください。利用可能な場合はSkillツールを使用します。これにより、現在の議論とコードベースへの理解をto-specで活用できます。テスト用シームの確認を維持し、検証済みのイシューURLとラベルが示され、公開が正常に完了するまで待ちます。
  3. 返されたイシューを独自に取得し、対象リポジトリに属していること、プルリクエストではなくイシューであること、specとstatus/ラベルが付いていることを確認します。spec-itが成功を報告し、この確認に合格してから次の段階を開始します。
  4. 会話の継承を無効にして、新しいワーカーでticket-itを開始します。対応している場合は、fork_turns="none"などを指定します。ワーカーには、スキルの絶対パス、リポジトリパス、検証済みの親イシューURL、トラッカーの設定、および公開済み仕様に含まれていないユーザーの制約や決定を渡します。そのスキルと上流の依存関係を読み、従うよう指示し、親イシューの本文全体とコメントを取得させます。同じ分割案がすでに承認済みでない限り、公開前に提案された分割案についてユーザーの承認を得るよう求めます。以下の説明に従って入力を処理し、検証済みの完了報告が届くまで待ちます。
  5. 親イシューと子イシューのURLに加え、ブロッカーと検証結果を返します。両方の段階が成功し、承認されたすべてのスライスに検証済みチケットがある場合にのみ、完了したと報告してください。

ユーザー入力

委任先のスキルでユーザーの回答や承認が必要になった場合は、質問、関連する草案や選択肢、現在の進捗、既存の成果物URLを添えて親チャットに戻るよう、チケット作成ワーカーに指示してください。親からユーザーの回答が提供されるまで、依存する作業は一時停止します。

User questionsの手順に従って親チャットで質問し、ユーザーの回答を待ちます。実際の回答とその適用範囲を同じワーカーに伝え、利用可能なフォローアップツールで作業を再開します。追加の質問や修正がある場合は、これを繰り返します。to-ticketsの分割案のレビューは必ず維持してください。委任してもレビューは不要になりません。plan-itを実行する依頼は、未確認の分割案への承認を意味しません。

リカバリー

代わりのワーカーが必要になった場合は、ユーザーがこれまでに示した決定、制約、承認をそれぞれの正確な適用範囲とともに、保存済みの進捗や成果物へのポインターと併せて引き継ぎます。以前の草案への承認を、修正版への承認として扱わないでください。

失敗、中断、または検証できない結果が発生した場合は、ワークフローを未完了のままにし、完了した段階、既存のイシューURL、未完了の操作、残りの作業を報告します。ユーザーとのやり取りをまたいで、チケット作成ワーカーの識別子と成果物へのポインターを保持します。可能な場合は、親チャットまたは既存のチケット作成ワーカーで仕様作成の段階を再開します。ワーカーを利用できない場合は、記録された進捗を代わりのワーカーに渡し、続行前にGitHubの状態を確認させます。重複を作成するのではなく、公開済みのイシューを再利用し、関連スキルに従って未完了の操作を修復します。検証済みの仕様作成段階が完了したら、その親イシューに対して直接チケット作成を再開します。

コメント