なぜ必要なのか
学校のクラブサイトで訪問者は集まりの日時と会場を見ます。会場名が一つ誤っており、開発者には既存の確認と確定した修正内容があります。直接作業すれば追加導入を減らせます。依存する要件を共同管理するなら記録中心の方式が向きます。
どう解決するのか
プロジェクト規則を読み、正しい会場を確定し、文言を直して既存の確認を実行します。画面と結果を確認して報告します。追加導入はせず、必要な判断・作業記録は保ちます。
確定した会場の修正に既存の規則と確認を使う学校のクラブサイト · 修正の例
明確な修正一つ、既存の確認
確定した依頼:集まりの会場は図書館です。
既存のページを修正
会場体育館→図書館
追加スキルなしでも計画・採用規則・記録・検証は必要です。範囲やリスクが増したら再検討します。
どんな考え方なのか
追加スキルなしの開始はエージェントの既存の能力を使う方式です。計画・検証は必要です。不確実性・リスク・共同作業・引継ぎが既存の方法を超えたら再検討します。
出典
さらに詳しく
任意の参考資料 · 概要の読了時間には含みません
01選択・比較
既存の指示・完了条件・確認で作業を扱えるか評価します。規模だけで区切りません。管理された大きいコードベースには追加導入が不要な場合があり、小さい権限変更には詳しい仕様が必要な場合があります。これは適合性についての編集上の判断で、道具が少ないほどモデルの結果が良くなるという証拠ではありません。要件の追跡はSpec Kit、繰り返せる実行スキルはSuperpowers、確認済みの変更記録はOpenSpecと比較します。
02応用例
クラブは次の会場を図書館に確定し、日付と申込リンクは維持します。外部エージェントはリポジトリの指示を読み、会場の文言を直し、既存の確認と実際の画面を調べます。通過した確認は結果として、使えないブラウザ確認は未検証として報告します。既存の記録を基準として保ちます。
03実装の参考・注意点
この選択には導入が不要です。既存の外部エージェントとプロジェクト設定を再利用します。「追加スキルなし」にするため有用なスキルを削除したり規則を無視したりしません。採用基準と重要な判断は既存文書に残します。共同の日程規則へ作業が広がったら全パッケージを入れず必要性を再評価します。チャットだけのAIは計画と手動確認を提供できますが、ファイル変更やテスト実行をしたとは言えません。
04根拠
比較のまとめ
続けて読む
原稿・修正提案 ↗
この選択を話し合う
コメントは全言語で共有。投稿にはGitHubログインが必要です。