quick-do

Quick Do：理解 → 実行 → 検証

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

• 検証方法が明確で、内容を十分に把握できている小規模な変更：局所的な修正、機械的な編集、設定の調整、短いスクリプト。
• ユーザーが明示的に選んだ方法を優先します。ワークフローを黙って切り替えてはいけません。選択されたワークフローがタスクに適さない場合は、その理由を伝えて確認してください。設計、互換性、受け入れ基準の判断に行き詰まった場合は、作業を止めて steady-do を提案してください（quick と steady のどちらにするか迷った場合は、steady を使用します）。別セッションへの引き継ぎが必要な場合は、plan-brief を提案してください。
• これらのワークフローが対象とするのは、依頼された開発作業であり、あらゆる説明や読み取り専用の質問ではありません。スキルの指示は英語ですが、返信と成果物はユーザーの言語に合わせます（デフォルトは中国語です）。

作業する

• 編集する前に、依頼内容、適用されるプロジェクトのルール、影響を受けるファイルを確認します。共有動作を変更する場合は、関連する呼び出し元も調べます。無関係な調査は避けてください。
• まず現在の状態を確認します（数秒で済み、承認も不要です）： 環境が有効か、依存関係を実際にインポートできるか、ファイルと呼び出し元が想定どおりかを確認します。ひと目確認するだけで、避けられる手戻りを防げます。余計な手続きを省くことがこのワークフローの目的ですが、この確認を省くことではありません。
• 報告された症状ではなく、根本原因を修正します。変更対象を呼び出す箇所を grep で調べ、すべての呼び出し元が通る場所で修正してください。呼び出し元ごとにガードを繰り返すと差分が大きくなり、関連する箇所の不具合も残ります。
• 一般的な実装の詳細については、明白な解釈を優先します。通常の quick パスで確認する質問は、焦点を絞ったものを最大1つまでにしてください。調査によって大きな曖昧さやリスクが判明した場合は、質問の上限を守るために推測するのではなく、作業を止めて steady-do を提案してください。
• 計画書を作成したり、質問攻めにしたり、サブエージェントを使ったりしてはいけません。作業内容またはホストの指示上必要な場合に限り、todo を使ってください。計画のための儀式を作らないでください。
• 動作する変更を最小限に保ちます。既存コード、標準ライブラリやネイティブ機能、インストール済みの依存関係の順に再利用してください。過度なカプセル化、推測に基づく抽象化、防御的な定型コード、冗長なチェック、無関係な整理は避けます。必要な信頼境界の検証、セキュリティ、アクセシビリティ、データ保護は維持してください。
• 破壊的または取り消せない操作を行う前に、影響を示し、明示的な許可を得てください。quick ワークフローであっても、秘密情報の上書きや無関係な環境の変更は認められません。

検証して完了する

• 原則として、最小限の実際の実行経路と変更内容の再確認を行います。エラーがないことだけでなく、依頼された動作を確認してください。ドキュメントのみの変更では、内容と該当するフォーマットチェックを確認します。
• デフォルトでは、テスト、TDD、検証スクリプトを追加しないでください。ユーザーからの明示的な依頼と必須のプロジェクトチェックには従ってください。このワークフローを理由に省略してはいけません。
• 実際に実行した内容だけを報告してください。静的チェック、正常な読み込み、入力の注入は、エンドツーエンドの動作を証明するものではありません。実行できない場合は、未検証の事項と、ユーザーが行うべき具体的な確認を伝えてください。
• 作業を妨げられている場合も、正当な結果です： 残っている作業と、ユーザーが実行すべき正確な確認内容を伝えてください。完了したふりをしたり、手順を黙って省略したりしてはいけません。
• 変更内容と検証状況を、阻害要因やユーザーに必要な確認があればそれも含めて、短い1行で締めくくってください。別途の報告書や要約文は不要ですが、必須の製品ドキュメントとプロジェクトのメモには従ってください。