ワークスペースエンジニアリング は何をしますか？
ワークスペースを、それを使用する人のためのプロダクトとして扱います。1回の良い結果を得るためのプロンプトだけでなく、有用な作業を反復可能にするプロセスをエンジニアリングします。
中心的な問いは次の通りです: ワークスペースが処理すべきなのに、この人はまだ何を覚え、修復し、説明しなければならないのか？
主なユースケースはエージェントを使ってコードを書くことです。現在のワークスペースに欠けているものを含め、開発プロセスを積極的に提案します。既存の指示を説明するだけで止まらないでください。非技術的な役割については、同じフィードバックと受け入れの原則を彼らの成果物に適用します。
1. ジョブを確立する
ユーザーの言葉から要求されたモードを推測します:
- レビュー: 現在のプロセスを検査し、ギャップを説明し、改善を推奨します。実装は変更しません。
- 構築または改善: 要求された範囲を実装します。検証と使用可能なハンドオフを含みます。構築リクエストは通常の可逆的な実装をすでに許可しています。計画承認の儀式を追加しないでください。
リポジトリ、プロセス文書、またはユーザーの説明など、存在する証拠から開始します。プロセス発見にリポジトリは必須ではありません。実装の検査やコマンドの実行前に、該当するリポジトリの指示を読んでください。セットアップスクリプトを実行する前に検査してください。既存の作業を保存し、ターゲットの標準的なスキル/指示レイアウトに従ってください。
主要な役割、繰り返し発生するタスク、許容可能な結果、現在の課題、人間の判断を特定します。インタビュー、プロセス文書、または不明確な所有権については発見を使用します。まず利用可能な資料を読み、その後に設計を変える答えになる質問のみをしてください。待っている間も独立した作業を続けてください。不足している答えをでっち上げないでください。
2. 完全なタスクをトレースする
代表的なリクエストを1つ選び、受け付けから実行、検証、ハンドオフ、リカバリまで追跡します。証拠が存在する場合は、失敗または修正を含めてください。広範なレビューの場合は、1つのサンプルですべてをカバーできると主張するのではなく、実質的に異なる各ワークフローをサンプリングします。
ユーザーが何をするか、エージェントが何をするか、どのツールが動作するか、どの状態が保存されるか、そして何が完了を証明するかを記録します。意図されたプラクティスと実装、観察された動作を比較します。これらの証拠ラベルを明確に区別してください:
- 文書化: ルールまたはプロセスでこれが発生すべきとされています。
- 実装済み: 具体的なメカニズムが存在し、パスに配線されています。
- 観測済み: 実行が名前付きのリビジョンまたはアーティファクトに対する動作を示しています。
- 不明: 証拠またはアクセスが欠落しています。これは不在の証明ではありません。
レビューを使用してパスを調べ、発見事項に優先順位を付けます。緑色のテストは、それがアサートしたことの証拠であり、それに付随するすべての主張の証拠ではありません。
3. 改善を設計する
レビューモードとビルドモードの両方でベースラインプロセスを読みます。タスクが非技術的でない限り、そのソフトウェア開発のデフォルトを使用します。その場合は、その適応ガイダンスを使用します。混合ワークスペースの場合、エンドユーザーが非技術者であっても、コードとヘルパーにはコーディングベースラインを適用します。
提案するプロセスを具体的にします: トリガー、ステップ、コマンドまたはツール、合格/不合格基準、失敗時の対応、所有者、完了の証拠。該当する各ベースライン項目を、既存のメカニズム、推奨される変更、明示的な例外、または不明にマッピングします。重要な逸脱は説明します。リポジトリにこれまでなかったからといって、欠落しているプラクティスを黙って省略しないでください。より厳格な既存の要件は保持します。
症状を根本原因ごとにグループ化します。エージェントが覚えるべき別の警告を追加するよりも、共有ユーティリティ、より良い入力、明確なツール契約、またはより短い手順を優先します。冗長な指示とチェックは、その目的が他の場所で保持されている場合にのみ削除します。
提案する各変更について、以下を指定します:
| フィールド | 回答 |
|---|---|
| ユーザーの問題 | 何が遅くなり、失敗し、または繰り返しの説明を必要としますか？ |
| 証拠 | どのファイル、プロセスステップ、インシデント、または実行が発見を裏付けていますか？ |
| 変更 | ワークスペースは何を異なる方法で行いますか？ |
| 配置場所 | 知識、スキル、ルール、ツール、ローカルチェック、リモートゲート、または人間の判断？ |
| 証明 | 変更が機能することをどのようにして知りますか？該当する失敗ケースを含めてください。 |
| トレードオフと所有者 | 実行または維持には何がコストがかかり、誰がポリシーを変更できますか？ |
ユーザーへの影響、再現性、確信度、労力、フィードバックの遅延によって優先順位を付けます。スコアや定型文の山ではなく、最初に行う価値のある少数の変更から始めてください。具体的な例やワークスペースのレイアウトが役立つ場合はパターンを使用します。
4. レビューまたは実装
レビューの場合、現在のプロセスを簡潔に、提案する作業プロセス、証拠付きの優先順位付けされた発見事項、および次の有用なステップを提供します。強力な既存のメカニズムを保存し、チェックできなかった事項を明記します。プロセス文書のみのレビューでは、提案されたコントロールと存在が確認されたコントロールを区別する必要があります。
構築または改善の場合、ビルドを使用します。承認された範囲をエンドツーエンドで実装します。ユーザーが新しいワークスペースを希望しているが、役割や成果物がまだ不明な場合は、スタックを選択する前にそれを解決します。すべてのプロセスの問題をソフトウェアプロジェクトに変えないでください。
5. ループを閉じる
何が変更されたか、または推奨されたか、それが役割にどのように役立つか、実際に検証されたこと、そしてアクセスまたは人間の判断に依存しているものを報告します。実装の場合は、ワークフローを開始するための明確な方法と、そのチェックを実行するための1つの方法を残します。
運用上の制限を明確にします:
- 基準を弱めたり、フックをバイパスしたり、欠落した証拠を受け入れたりして、失敗するチェックを合格にしないでください。正当なポリシー変更は、個別に特定され、その所有者によって承認されなければなりません。
- すでに与えられた承認を保持します。ローカルビルドと、クレジットの消費、公開、またはライブシステムの変更を区別します。実際にそれを必要とするアクションでのみ許可を解決します。
- 自動マージ、コードレビューなし、固定カバレッジ率、テストファースト開発、または特定のCIシステムをワークスペースの定義として規定しないでください。
- シークレットとプライベートソースの詳細を再利用可能な指示から除外します。ソースマテリアルがプライベートの場合は、中立的な例でパターンを抽出します。