steady-do

Steady Do：理解 → уточ明 → ここで実装 → 検証

このスキルを適用する場合

• 既存プロジェクトで、このセッション中に実装と検証を行う通常の機能、プラグイン、拡張機能、モジュール間の作業。
• ユーザーが明示的に選んだワークフローを優先します。黙って別のワークフローに切り替えてはいけません。選択されたワークフローがタスクに適さない場合は、その理由を伝えて確認してください。範囲が限定され明確な作業には quick-do、長期にわたる作業で、永続的な計画と別セッションへの引き継ぎが必要な場合には plan-brief を使います（引き継ぎが役立ちそうでも依頼されていない場合は、提案してください）。
• これらのワークフローが対象とするのは、依頼された開発作業であり、あらゆる説明や読み取り専用の質問ではありません。スキルの指示は英語ですが、返答と成果物はユーザーの言語に従います（デフォルトは中国語です）。

1. 依頼とプロジェクトを理解する

• 要件全体と、この会話ですでに確定した判断を読みます。明示された要件と未解決の疑問を分け、ファイルを変更する前に調査します。
• プロジェクトのルール、README、関連するエントリーポイントとモジュールを読みます。実際の処理フロー、再利用できるもの、影響を受ける呼び出し元、互換性の境界をたどります。関連性に応じて調査範囲を広げ、リポジトリ全体を無差別に調べたり、単一の関数だけで判断したりしないでください。
• まず現在稼働中の環境を確認します（数秒で済み、承認は不要です）。 有効化コマンドとインタープリター、現在実際にインポートされる依存関係のバージョン、起動コマンド、入出力形式、設定ファイルのパス、関連するものがすでに実行中かどうかを確認します。インタープリターやシステム Python を決めつけず、実際に調べてください。少し確認するだけで、避けられるミスを丸ごと防げます。形式的な手順を省くことが目的であり、この確認を省くことではありません。
• 目標、範囲、対象外の事項、観察可能な完了条件をチャットで簡潔に伝えます。計画書は作成しません。

2. 未解決の判断事項を確認する

以下の、範囲を絞ってラウンドごとに確認する方法を使います。独立して完結しており、別のスキルやドキュメントのワークフローは必要ありません。

• 事実は自分で調べ、判断はユーザーに尋ねます。 推測を制約として提示するのではなく、コード、設定、プロジェクトのメモ、ドキュメントを先に確認します。不確かな外部 API やプラットフォームの制限については、上流のドキュメント、ソース、課題を確認します。
• 動作、範囲、互換性、リスク、受け入れ条件に影響する質問だけをします。それぞれに推奨案と簡潔なトレードオフを添えます。通常の実装の詳細は、プロジェクトの慣例に従って決めます。
• 独立して回答できる質問は同じラウンドにまとめ、未回答の質問に依存する質問は後回しにします。利用可能であれば構造化された質問を使い、そうでなければチャットで番号付きの質問をして、回答を待ちます。
• 各ラウンドの後、回答によって解決した事項を再評価し、次のラウンドで質問します。さらに質問することで動作、範囲、互換性、リスク、受け入れ条件が変わる可能性がある限り、ラウンドを続けます。終了の基準は、重要な未解決事項がなくなったことです。1 ラウンド実施したことではありません。
• 確定済みの質問を繰り返したり、質問数のノルマを設けたりしないでください。依頼と状況から判断がすでに確定している場合は、要約に進みます。
• 検証モード — 必ず判断し、要約で明記して、その理由を 1 行で説明します。
  • TDD モード — フィードバックループが速く、テストが低コストな場合に限ります（フロントエンド／UI、プロダクトサービス、即時に単体テストを実行できるライブラリコード）。tdd スキルを使います。
  • スモークテストと読み直し（調査、長時間実行、または高負荷計算を伴う作業ではデフォルト）：実際の処理経路を最小限実行し、自分の変更を読み直して、影響を受ける隣接動作を確認します。その後、ユーザーが実際のワークロードを実行します。テスト用の足場やラッパーハーネスは作成しません。
  • 目安：テストの作成と実行にかかるコストが、そのテストで検出できる失敗のコストを上回る場合は、テストを作成しません。
• 受け入れ条件と責任 — 何を確認するか、期待される結果、最後に誰が実行・検証するかを明確にします。合意済みの検証方法を再利用し、再度質問しません。
• 実装と受け入れに不可欠な曖昧さが解消され、認識が共有できたら終了します。推測に基づく将来の要件を問い詰めたり、各関数の設計をユーザーに求めたりしないでください。

3. 要点を振り返り、ここで実装する

• 合意したスコープ、アプローチ、検証方法を簡潔に振り返り、追加の計画承認を待たずに着手します。振り返りの中で未解決の重要な選択事項が明らかになった場合は、その回答を待ちます。
• 主な実装はこのセッション内で行います。新しいセッションや実行サブエージェントに引き継いではいけません。必要に応じて読み取り専用の調査やレビューを委任してもかまいませんが、デフォルトで複数エージェントのパイプラインにはしません。
• 計画書、ランチャーのプロンプト、開発レポート、レビューレポートは作成しません。複数ステップの作業はセッションの ToDo で管理します。必要な製品ドキュメントとプロジェクトメモリは引き続き適用されます。
• 新しい証拠によって合意したアプローチが無効になった場合や、スコープの拡大または外部動作の変更が必要になった場合は、影響を受ける作業を中断して方針を再調整します。通常のローカルな実装上の問題は自分で解決します。
• 破壊的または取り消せない操作の前に、その影響を示し、明示的な許可を得ます。着手の許可は、シークレットの上書きや無関係な環境の変更を許可するものではありません。

4. ポニーテールらしい好みを保つ

• 動作する変更を最小限に抑えます。既存コード、標準ライブラリやネイティブ機能、インストール済みの依存関係の順に再利用します。単純な問題のために依存関係を追加してはいけません。
• 過剰なカプセル化、推測に基づく抽象化、防御的な定型コード、冗長なチェック、将来のための足場作り、無関係な整理は行いません。
• 報告された症状だけでなく、実際の呼び出し経路に沿って根本原因を修正します。共有ロジックを呼び出す他の箇所も確認します。
• データ損失を防ぐために必要な信頼境界の検証、セキュリティ、アクセシビリティ、データ保護、エラー処理を維持します。

5. 検証して完了する

• 原則として、実際に動かす範囲を最小限にし、変更内容と影響を受ける周辺動作を読み直します。単にエラーがないことではなく、合意した観測可能な結果を確認します。ドキュメントのみの変更では、内容と該当するフォーマットチェックを確認します。
• テスト、TDD、検証スクリプトは、原則として追加しません。明示的なユーザーの要望と必須のプロジェクトチェックには従います。機能追加だからといって、自動的に TDD を適用するわけではありません。
• 静的チェック、正常な読み込み、ローカルでの呼び出し、ユーザー操作全体を区別します。読み込み可能なプラグインが機能として動作しているとは限りません。入力を注入しただけでは、実際の端末操作を検証したことにはなりません。
• 実行にユーザーの環境が必要な場合や実行が妨げられている場合は、未検証の内容と、具体的な手順および期待される結果を示します。**実行できない場合も正当な結果です。**ユーザーが実行すべきチェックを正確に伝え、完了したと偽ったり、実行できなかった作業を黙って省いたりしてはいけません。
• 変更内容、実際に実行したこと、ユーザーの確認が必要なことを簡潔に報告します。1 行で十分なら 1 行にし、別途レポートや長い要約文は作成しません。