要件から納品へ
まずユーザーが何を変えたいのか、完了とは何かを明確にし、その後実行する。承認された作業を継続的に完了させる。判断が必要な場合は、その判断に依存しない部分を先に完了させる。「計画を書いた」「コードがコンパイルできる」「自動マージが有効になった」を最終納品とみなさない。
作業の取り決め
- 目標、リスク、フィードバックコストに基づいて開発手法を選択する。仕様を先に書くことも、明確なパブリックインターフェースでテストファーストを行うことも、直接実装してから検証することもできる。手法は組み合わせ可能。常に観測可能な完了条件を明確にし、実際の振る舞いの証拠を得ること。特定のプロセスをすべてのタスクに強制しない。
- 現在のコード、実行結果、実際のリリース成果物を使って「現在どうなっているか」を説明し、ユーザーが確認した目標を使って「何になるべきか」を説明する。差異を見つけたら実装または期限切れの記録を修正し、古いドキュメントでユーザーの目標を上書きしない。
- 規模に応じてプロセスを選択する。小さな変更は仕様を数行で済ませる。モジュール横断的な要件の場合にのみ、スライスに分割し、設計し、記録する。毎回の編集にすべての知識を読み込んだり、固定の承認チェーンを確立したり、空のテンプレートを記入したりしない。
- ユーザーがすでに承認した範囲は継続して有効。調査、実装、可逆的な検証については再確認しない。外部公開はユーザーの明確な目標に従って実行する。それでも本番目標や承認が不足している場合は、成果物、差分、ロールバック、チェックを準備してから、何が不足しているかを説明する。
- このスキルは単独で使用できる。以下の表のスキルがインストールされている場合は必要に応じて呼び出す。インストールされていない場合は、その段階の結果を直接完了させ、ユーザーにスキル一式を揃えるよう要求しない。
- 1つのタスクは現在の担当者が継続的に推進する。専門的な手法は現在の段階の証拠と成果物を補完し、確認済みの決定と同一の記録を引き継ぎ、別の競合するプロセスを開始しない。
次のステップの選択
| 現在の状況 | 推進方法 | 呼び出し可能なスキル |
|---|---|---|
| どの機能を使うべきかわからない、または使用方法を知りたいだけ | タスクに応じて最小の入り口を選択。最初に使用方法を説明し、コンサルテーションを実施の承認と誤解しない | dev-help |
| 初回の環境設定、ロールモデル、推論予算の設定 | 実際に利用可能なツールとモデルを確認し、短い設定を保存。固定のベンダーやバックエンド機能を仮定しない | dev-setup |
| 繰り返し作業を徐々に自分の習慣に合わせたい | 読み取りが許可された履歴から安定したパターンを抽出し、簡潔でメンテナンス可能なプロジェクトスキルを形成する | dev-personalize |
| ユーザーがタスクの進捗を尋ねる、または引き継ぎ報告が必要 | 完了したこと、現在の証拠、未決事項をまとめる。回答後は元のタスクを続行。明示的に中断が要求された場合を除く | dev-status |
| 入力がチャット、Issue、スクリーンショット、ログ、または複数のフィードバックから来ている | 元の証拠、実際の振る舞い、目標、範囲を見つけ、重複する要求を統合する | dev-intake |
| レポートの統合やソースによる要件の監視を設定する必要がある | ソース、トラッカー、リポジトルート、制御方法、実際のトリガーを個別に選択し、承認範囲内で初期化を完了する | dev-issue-setup |
| 設定済みのソースアダプターからのレポートを分類、重複排除、または振り分ける必要がある | ネイティブレポート、ID、トラッカー契約に従って証拠を処理。ソースはチャット、チケット、メール、アラート、手動入力の可能性がある。この段階では再現や修正は行わない | dev-issue-triage |
| 設定済みのレポートパイプライン、信頼できるトリアージ、実際のUI制御条件がすべて揃っている | 帰属を確認し、完全なプロトコルに従って既存のパッチを再現または検証。必要な場合で承認されていれば修正し、ドラフトPRを納品する | dev-issue-fix |
| プロダクトルールに重要な曖昧さがある | まずコードから事実を回答し、計画を変更する可能性のある質問についてラウンドごとに明確化する | dev-grill |
| 要件は明確だが、まだ直接受け入れられない | ユーザーの振る舞い、境界、非目標、成功条件を書く | dev-spec |
| ユーザーが実行待ちのリクエストを深掘りまたは書き直したい | 4つの質問を使って専門的な欠落、元の資料、具体的な方法、独立した証拠を確認し、使用可能なプロンプトを納品する | dev-sharpen |
| 見知らぬモジュールを引き継ぐ | 1つの実際のユースケースに沿って、エントリ、ビジネスロジック、ストレージ、フィードバック、障害パスを全て通してみる | dev-learn |
| 過去の設計がなぜ存在するのか理解できない | 現在の振る舞い、当時の理由、推測を区別し、コードと入手可能な決定の証拠を遡る | dev-why |
| 境界やインターフェースに実質的なトレードオフがある | 異なる構造を比較。呼び出し元の体験、状態の所有権、ドメイン用語から判断する | dev-architecture |
| TLA+ モデルがすでにある、または構築することが明確で、チェック結果付きの状態図が必要 | TLC を実行し、ルールマーカーと最短反例を生成し、実際のコードと段階的に照合する | dev-statechart |
| 重要なプロパティのチェック、形式手法ツールの選択、モデルのメンテナンスが必要 | プロパティ、前提、境界を明確にし、チェックを実行し、モデルのドリフトを特定。通常の説明図は自動的にこのフローに入らない | dev-formal-verify |
| ページ、インタラクション、デザインシステム、ビジュアル検収に関わる | 実際のコードのコンポーネントとトークンを流用。プロダクトまたはマーケティングシナリオに応じてデザイン仕様を読み取る。デザインツールのアカウントは要求しない | dev-ui-design |
| 要件を一度で確実に納品できない | 受け入れ可能な垂直機能スライスに分割し、明示的な依存関係を持たせ、最小の完全なパスを最初に動作させる | dev-plan |
| 互いに衝突しない作業、または比較する価値のある異なる案がある | 割り当て範囲と受け入れルールを書き、統合して最終結果を検証する | dev-parallel |
| 仕様またはスライスが実装の条件を満たしている | 既存のエンジニアリング規約に従って実装し、実際の振る舞いを接続し、現在の成果物を検証する | dev-build |
| 通常のIssue、CLI/API/UI機能のバグ、または検収失敗 | 実際のエントリに沿って再現し、根本原因を特定。パフォーマンス指標のみを目標とする場合は測定フローに入る | dev-debug |
| ユーザーがテストファーストを指定している、または現在の実装がTDDを選択している | パブリックインターフェースごとに失敗テストと最小実装を順に完了。すでに正しい振る舞いがある場合のテスト追加は自動的に赤-緑実装に入らない | dev-tdd |
| 同じ種類のエラーが繰り返し発生する、または重要な制約が簡単に回避される | 型、インターフェース、状態の所有権を優先的に改善。実際の価値がある場合に実行可能なルールを追加する | dev-guardrails |
| 実装完了 | 仕様の適合性とエンジニアリング品質を別々にチェック。実際の問題を修正する | dev-review |
| 実際のユーザーパスが機能することを証明する必要がある | 実際のアプリケーションを駆動し、結果と副作用を確認し、再現可能な検証方法を維持する | dev-verify |
| 目標がレイテンシ、スループット、リソース、またはその他の測定指標の改善である | ワークロードと測定基準を固定し、証拠収集、最適化、または公正な比較を実行し、同じベースラインを再利用する | dev-benchmark |
| 目標にリリースが含まれる | 環境とバージョンを確認し、承認されたデプロイを実行し、実際のサービスを検証して記録する | dev-deploy |
| 明確なドキュメント、コミットメッセージ、PR概要が必要 | 読者の質問に沿って情報を整理し、具体的な振る舞い、証拠、必要なトレードオフを提示する | dev-writing |
| 要件が納品された、または明確に中止された | 新しい知識を整理し、競合を修正し、価値のある理由を保持し、プロセスをアーカイブする | dev-archive |
既存の仕様は直接実施する。設計のみ要求されたら設計を納品する。説明のみ要求されたら説明で止める。推進と再開 を読んで並行処理と中断を扱う。要件を洗練する必要がある場合は要件から実装への段階的接続を読み、選択したタスクを実行する場合はエンジニアリング実行方法を読む。これらは現在の段階を補完するものであり、すでに完了した段階を再選択しない。
複雑なタスクに適切な既存のフローがない場合は、カスタム実行方法を使用して検証可能なユニットを形成し、承認された作業を継続する。長時間のタスクの記録と事後レビューには決定証拠方法を使用し、決定、代替案、実際の証拠が対応しているかを確認する。レビューのみが要求された場合は監査結果を納品し、自動的に移行や実装を継続しない。ある設計が当時なぜ採用されたかを追跡するのは dev-why が担当する。ユーザーが運用可能なステータスパネルを構築することを明確に要求した場合は、それを実装タスクとして扱う。進捗の問い合わせのみには dev-status を使用する。
作業を継続可能にする
このスキルセットが新たに作成するプロジェクト資料は、一律で .agents/wtadev/ をルートとし、必要に応じて以下の区分を使用する。既存の資料は実際の場所を参照し、必要な参照を保持する。明示的に移行が要求された場合のみ移動し、内容、識別子、有効なリンクを保持する。ユーザーが今回明示的に別の場所を指定した場合はその指示に従う。
.agents/wtadev/changes/<日付-トピック>/：現在の要件の Brief、Spec、Plan、Progress、Evidence。必要に応じて作成。.agents/wtadev/notes/：検証済みの用語、背景、決定、エラー経験、モジュールの理解。入口index.mdは案内のみ。.agents/wtadev/deploy/<環境>/：デプロイマニュアルとreleases/下のリリース履歴。.agents/wtadev/archive/changes/、.agents/wtadev/archive/notes/：終了した作業と過去の知識。現在の振る舞いを表さないことを明示。
これらは対象プロジェクトの資料であり、インストールパッケージ .agents/skills/ に書き込んではならない。再開が必要な場合は、引き継ぎテンプレートを使用し、現在の結果、証拠、未解決問題、次のステップのみを残す。
収束
最初の納品目標と照らし合わせ、実際の変更、現在のバージョンの検証証拠、納品先またはコミット、そして確かに未完了の部分を提示する。リリースが必要だがまだデプロイされていない場合は、「実装は完了、デプロイは未完了」と明確に書く。デプロイ成功後は、再利用可能な知識と最新のコード参照をプロジェクトに整理し、チャットのログ全体を AGENTS.md に詰め込まないこと。
完全なローカル資料
資料索引 に従い、このスキル内の完全なフロー、チェックルール、例、テンプレートを選択する。すべての実行に必要なリソースはこのパッケージ内にあり、他のスキルのインストールに依存しない。現在のタスクブランチに必要な内容のみを読み取ること。