do-in-steps

do-in-steps skill の概要

do-in-steps skill は、複雑な作業を順序立てたサブタスクに分解し、順番に実行しながら、各ステップを次へ進む前に検証できるようにすることで、エージェントの処理を支援します。依存関係がある作業、複数のファイルやシステムをまたぐ作業、あるいは各段階を確認しないと静かに失敗しやすい作業で特に効果を発揮します。

この do-in-steps skill は、リポジトリ変更、複数段階のリファクタリング、移行作業、エージェントのオーケストレーション、そして仮定を減らしてステップ間の受け渡しをより制御したいあらゆるタスクに向いています。最大の差別化ポイントは、組み込みの meta-judge → LLM-as-a-judge フローで、実行と次工程への進行のあいだに品質ゲートを挟めることです。

この skill は何のためのものか

do-in-steps は、1回で安全に終えられず、各結果が次の判断材料になるタスクで使います。コンテキストを絞り込み、順序を守り、複雑な実行での連鎖ミスを減らすよう設計されています。

何が際立っているのか

単に「step by step で考えて」と言うだけの汎用プロンプトとは違い、do-in-steps は Agent Orchestration 向けのワークフロー skill です。タスク分解、サブタスクごとのモデル選択、コンテキストの受け渡し、独立した検証を重視しているため、長いタスクでも信頼性が高くなります。

どんな人に向いているか

この do-in-steps ガイドは、コードベースで作業するエージェント、自動化の設計者、あるいは発想よりも構造化された実行を求めるユーザーに最適です。各ステップ後に確認を挟みながら進めるオーケストレーション済みの計画が欲しいなら、単発のプロンプトよりこの skill が合っています。

do-in-steps skill の使い方

skill をインストールして読み込む

do-in-steps install では、利用環境で使うリポジトリのパスから skill を追加し、SKILL.md を主な指示 स्रोतとして読み込みます。この repo では skill は plugins/sadd/skills/do-in-steps にあるため、重要なのは作業を始める前に skill ファイルをエージェントのアクティブな skills セットへ入れておくことです。

あいまいな目標を使える入力に変える

do-in-steps usage のパターンは、目的、対象の repo やシステム、制約、そして完了条件をプロンプトに含めると最も機能します。良い入力では、テーマだけでなく成果物とリスクの高い部分まで明示します。

より強いプロンプトの例:
Refactor UserService to remove duplicated validation, update all callers, keep public APIs stable, and verify behavior with tests.
これは次よりも良いです:
Improve the service layer.

最初に読むファイル

まず SKILL.md を読んでオーケストレーションのロジックを把握し、必要なら関連するプロジェクト文書や隣接する skill ファイルも確認します。この repository には rules/、resources/、scripts/ フォルダがないため、実務上の案内の大半は skill ファイル本体にまとまっています。

順序立てた段階で実行する

この skill は連続するワークフローとして使います。タスクを分析し、依存関係を分解し、最初のサブタスクを実行し、検証し、その後は必要なコンテキストだけを次のステップへ渡します。品質が上がるのは、後続の作業が先行する判断からずれないように、ステップの境界を保てるからです。

do-in-steps skill の FAQ

do-in-steps は通常のプロンプトより優れているか？

はい、タスクに依存関係がある場合や、ステップ間の検証が必要な場合は優れています。小さな作業なら通常のプロンプトでも十分ですが、do-in-steps は制御されたオーケストレーション、サブタスクごとのモデル選択、見えにくい失敗の削減が必要なときに向いています。

使わない方がいいのはどんなときか？

単純な修正、単発の質問、あるいは直接回答で十分なタスクには do-in-steps を使わないでください。オーケストレーションのオーバーヘッドは、順序付けと検証が成果に実質的な改善をもたらす場合にだけ見合います。

初心者向けですか？

はい、タスクをはっきり説明できるなら使えます。主な学習ポイントは、分解に必要なだけのコンテキストを与えることと、続行前に途中証拠を求められる場合があることを受け入れることです。

Agent Orchestration ではどう位置づけられますか？

これは明確に do-in-steps for Agent Orchestration のために作られています。監督役が専門化したサブエージェントを調整し、要約を次へ渡し、独立した judge を使ってステップ単位のエラーを減らします。そのため、マルチエージェントのコーディングや運用ワークフローで特に有用です。

do-in-steps skill を改善する方法

境界条件をもっと明確にする

do-in-steps の結果を最短で良くする方法は、変更してはいけないもの、検証が必要なもの、そして最終成果物がどうあるべきかを明確にすることです。制約がはっきりしているほど、オーケストレーターは適切なサブタスクを選びやすくなり、手戻りも減ります。

判断に直結するコンテキストを与える

出力をより強くしたいなら、影響を受けるファイル、対象環境、テストの期待値、互換性要件を最初に入れてください。この skill は、後から推測するのではなく、実際の制約をもとに分解できるときに最も力を発揮します。

よくある失敗パターンに注意する

最大のリスクはタスク定義が甘すぎることです。すると分解が弱くなったり、検証が浅くなったりします。もう1つの失敗は、最初のステップにコンテキストを詰め込みすぎることです。計画を決めるのに必要な分だけを先に与え、各サブタスクには必要最小限だけを引き継がせる方がうまくいきます。

1回目の実行後に反復する

初回の結果がかなり近いが不完全なら、欠けている点を具体的に補ってタスクを詰め直します。たとえば、テスト不足、依存関係の順序が不明確、変更範囲が広すぎる、といった点です。do-in-steps では、改善は「もっと長く書くこと」よりも、タスクの切り方を良くすることで生まれることがほとんどです。