ask-me

Ask Me

状況に合った、最小限のワークフローを選びます。

ワークフローとは、スキルをたどる手順です。コーディングエージェントの作業の多くは、理解から始まり、計画、実装、レビューへと進みます。バグ対応では、計画の前に診断を行います。

メインフロー：コードの変更

ユーザーが動作の追加、変更、削除を求めている場合は、この手順を使います。

1. /plan-it — 目標を理解し、関連するコードを調べ、影響を受けるモジュールを特定し、方針を選び、検証方法を定めます。
2. /implement-plan — 合意した変更を小さな手順に分けて行い、適切なチェックを実行します。検証に合格するか、実際の阻害要因が見つかるまで修正を続けます。
3. /review-change — 求められた場合、または差分のリスクに応じて、独立したレビューを行います。

明確でリスクの低い実装依頼には、簡潔なインライン計画を立て、追加の承認を挟まずに進めます。範囲、設計、リスクについて判断が必要な場合は、完全な計画ワークフローを使います。調査やレビューのスキルは、タスクに必要な根拠を得られる場合にのみ読み込みます。

バグフロー：症状 → 診断 → 修正

動作やエラーが期待と食い違っており、原因が確認できていない場合に、この手順を使います。動作が壊れている、遅い、または想定外だという報告、貼り付けられたエラーやログ、「なぜこうなるのか」という質問、うまくいかなかった修正などが該当します。

1. /diagnose-bug — 症状を言い換え、それが不具合、意図された設計、環境のどれに当たるかを判断します。再現し、修正に着手する前に原因を確認します。
2. /plan-it — 原因と検証手順が明確になったら、修正を計画します。
3. /implement-plan — 修正を実装し、検証のサイクルを実行します。
4. /review-change — 求められた場合、または修正のリスクに応じて、新たなコンテキストからレビューします。

編集の前に原因を特定します。ユーザーが修正を依頼しており、原因、範囲、検証方法が明確な場合は、簡潔な計画を立てて実装まで進め、再度確認を求めません。診断のみを依頼された場合は、診断が完了した時点で止めます。

レビューフロー

作業が完了している場合、確認する差分がある場合、またはユーザーがレビューを求めている場合は、/review-change を使います。

main、ブランチ、コミット、提供された差分など、基準点を固定してレビューすることを優先します。

コンテキストの衛生管理

計画が有効な間は、計画と実装のつながりを保ちます。レビューでは、実装者の推論に引きずられないよう、新しいコンテキストまたはサブエージェントを使うことを優先します。

後で作業を続ける必要がある場合は、目標、現在の状態、検証状況、残っているリスクを簡潔にまとめ、会話内で引き継ぎます。ユーザーの承認がある場合にのみ、引き継ぎファイルを保存します。