mcpField
S
start

start

github.com/ulpi-ioエージェントワークフロー5152 回インストール9 週間前に更新
リポジトリ

start について

startは、タスクの進め方を振り分ける軽量なスキルです。専用スキルの利用、委任、情報収集、計画の要否を判断します。

主な機能

  1. 01より適切なスキルの選択
  2. 02委任の必要性を評価
  3. 03初期情報収集を最小化
  4. 04タスクに応じた計画深度の選択

活用シーン

  1. 01新しいタスクのワークフロー選定
  2. 02専用エージェントへの委任判断

インストール

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

$npx skills add https://github.com/ulpi-io/skills --skill start

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
agent_matching_logic.md
discovery.md
skill_discovery_patterns.md
sync-claude-md.md

詳細

このスキルは軽量なルーターであり、万能の規範ではありません。

譲れないルール:

  1. より具体的なスキルが該当する場合は、実質的なタスクへの回答を行う前に、そのスキルを呼び出してください。
  2. 最初に収集する情報は最小限にしてください。ユーザーが機能一覧を明示的に求めていない限り、すべてのスキル、エージェント、プラグインを列挙しないでください。
  3. 見当違いの編集や作業の重複を避けるために必要な、最小限のコンテキストだけを集めてください。
  4. 専門知識や作業の分離によって結果が大きく向上する場合に限り、専門エージェントに委任してください。
  5. 計画やタスク追跡は、作業が本当に複数段階にわたる場合、リスクが高い場合、または曖昧な場合にのみ使用してください。

開始

目標

タスクの開始時に、プロンプトの負担を最小限に抑えながら、次に取るべき最適な実行方法を選びます。

このスキルでは、次の4つの問いにすばやく答えます。

  1. より具体的なスキルが本来のワークフローに該当しますか?
  2. 専門エージェントへの委任が妥当ですか?
  3. 実行に着手する前に必要な最小限のコンテキストは何ですか?
  4. タスクには計画が必要ですか、それともすぐに着手できますか?

ステップ 1:より具体的なスキルを確認する

まず、ユーザーの依頼に該当するドメインスキルとワークフロースキルを確認します。

  • あるスキルが明確に該当する場合は、進め方を説明する前にそのスキルを呼び出してください。
  • 複数のスキルが該当する可能性がある場合は、依頼を満たす最小限の組み合わせを選んでください。
  • 該当するスキルがあるかどうか判断できない場合は、references/skill_discovery_patterns.md を読んでください。
  • すべてのタスクで、ファイルシステム全体からスキルを網羅的に探さないでください。Claude では利用可能なスキルがすでに表示されており、該当するスキルの呼び出しは第一級のワークフローとして扱われます。

成功基準:適切なスキルを呼び出すか、より具体的なスキルが該当しない理由を具体的に説明できます。

ステップ 2:専門エージェントに委任するか判断する

専門性や作業の分離によって結果が大きく変わる場合にのみ、エージェントを使用してください。

次の場合は委任してください。

  • ドメインに深く関わる実装、デバッグ、レビュー作業である
  • ある専門エージェントが、その技術スタックに対して明らかに優れた知見を持っている
  • 作業の規模が大きく、担当範囲を分けることが有効である

次の場合は委任しないでください。

  • 簡単な読み取り、検索、または小規模で直接的な編集である
  • タスクが機能の確認だけである
  • 次の手順が、すぐに行うローカル環境の調査に依存する

どのエージェントを選ぶべきか判断できない場合は、references/agent_matching_logic.md を読んでください。

成功基準:具体的な理由に基づいて、直接実行するか特定のエージェントに委任するかを選べています。

ステップ 3:実行に必要な最小限のコンテキストを集める

見当違いの作業を避けるため、必要なコードとファイルだけを確認してください。

  • 関連する可能性の高いファイル、モジュール、サブシステムを特定します。
  • 編集する前に、周辺のコードを読みます。
  • ゼロから作成する前に、既存の実装やパターンを検索します。
  • 依頼が曖昧な場合や、コードの範囲が不明確な場合に限り、調査範囲を広げます。

次の場合に限り、references/discovery.md を使用してください。

  • ユーザーが利用可能なスキル、エージェント、プラグインについて明示的に尋ねている
  • 環境とファイルシステムの状態が一致していないように見える
  • 機能一覧の作成自体が、実際のタスクの成果物である

成功基準:広範囲の調査や重複した読み込みを強いることなく、作業に着手できるだけのコンテキストが揃っています。

ステップ 4:計画の深さを選ぶ

安全に作業を進められる範囲で、最小限の計画手法を選んでください。

  • 直接実行:単純で範囲が明確な依頼
  • 軽量なタスク追跡:複数の段階やファイルにわたるものの、作業内容は明確な場合
  • 完全な DAG 計画:曖昧な場合、リスクが高い場合、アーキテクチャに関わる場合、または並列化できる場合

計画そのものがタスクである場合は、start を大規模なプランナーにするのではなく、plan-to-task-list-with-dag を呼び出してください。

成功基準:タスクの複雑さに合った実行方法が選ばれています。

ステップ 5:次のアクションを伝える

次の内容を述べた、簡潔な最初の状況報告を行います。

  • ユーザーが何を求めていると考えているか
  • 最初に何を確認するか
  • 別のスキルを呼び出すのか、エージェントに委任するのか、それとも直接進めるのか

委任する場合は、次の内容を伝えます。

  • 明確な範囲
  • 関連するコンテキストのみ
  • 成功基準

直接実行する場合は、状況報告の直後に、最も価値の高いコンテキスト確認に着手します。

成功基準:長い前置きを読まなくても、ユーザーが実行方針を把握できます。

ガードレール

  • 呼び出さないスキルを、呼び出すと告知してはいけません。
  • 実際のドメインスキルの代わりに start を使ってはいけません。
  • 通常のタスク受付で、すべての機能を無理に調査してはいけません。
  • 定例の起動処理の一環として CLAUDE.md を同期してはいけません。
  • 簡単な作業に、タスク追跡のノイズを生じさせてはいけません。
  • ローカルで行うべき単純な検索やファイルの確認を委任してはいけません。

参照資料を読み込むタイミング

  • references/skill_discovery_patterns.md どのスキルが当てはまるか不明な場合、または複数のスキルが該当する場合に使用します。
  • references/agent_matching_logic.md どの専門エージェントが適切か不明な場合に使用します。
  • references/discovery.md 明示的な機能一覧の確認、または環境のドリフト確認に限って使用します。
  • references/sync-claude-md.md ユーザーが CLAUDE.md の機能セクションの更新を明示的に希望し、セッションでファイル編集が許可されている場合に限って使用します。

出力の契約

通常の呼び出しでは、最初の応答を短く具体的にします。

  1. タスクの理解を述べる
  2. 次のアクションを述べる
  3. スキルを呼び出す場合、またはエージェントに委任する場合は、その名称を明示する

このスキルの役割は、適切に振り分けた後、速やかに役目を終えることです。

コメント