docdd

要望や不具合を docs/ の正本と照合し、着手できるタスクとして tasks/BACKLOG.md へ起票する。要望を受け取ったとき、実装の前に使う。実装はしない。

tasks/BACKLOG.md のタスクを1件選び、実装・検証・docs 同期・コミットまで完了させる。起票済みのタスクを進めるときに使う。引数でタスク ID を指定できる。

コードの変更を docs/ の該当文書へ反映し、docs の検査を回す。コミットの前に使う。引数で git diff の範囲を指定でき、--full で実装全体と docs のずれを監査する。

開発キットの雛形（CLAUDE.md・.claude/rules/docdd-kit.md・docs/・tasks/・scripts/ など）をいまのプロジェクトへ置き、検証コマンドは推定で埋め、分からない欄だけをまとめて聞いて、検査を通してからコミットする。導入するとき、または途中で止まった導入をやり直すときに使う。既存ファイルは上書きしない（何度実行しても安全）。

コードを変えていないのに時間の経過で壊れる部分（外部APIの仕様変更・脆弱性・溜まったデータ・費用）を点検する。週1回の定期点検に使う。引数なしは週次、/docdd:maintenance monthly で月次も回す。

ブラウザ操作の道具箱。画面を開く・操作する・スクショを撮る・コンソールや通信を確かめるときに使う。ui-polish・verify-e2e・release から使う。接続先はローカル（公開先の確認は release のときだけ）。Web 以外のプロジェクト（ゲーム・ネイティブアプリなど）では使わない。

動きを変えずにコードの中身を整える（重複・複雑さ・命名・使われていないコード）。コードが読みにくい、直すたびに壊れると感じたときに使う。1 回に 1 か所ずつ。単体テストが無ければ監査だけ。--audit は監査のみ。

依頼を全部終えたあと、変更を本番へ出す。CLAUDE.md「反映コマンド」表の方式に従い、本番へ出す前に必ず運営者の「はい」を得る。/docdd:release staging で staging まで。

セキュリティの穴を探して報告し、直すのは 1 件ずつ運営者の「はい」を得てから。公開前や、ログイン・課金・外部連携を触ったあとに使う。--audit は報告のみ。

画面の表示や移動が遅いと感じたときに、計測してから 1 か所ずつ速くする（サーバー描画の Web アプリ向け）。Web 以外のプロジェクト（ゲーム・ネイティブアプリなど）では使わない。単体テストが無ければ計測と候補出しだけ。--audit は計測と候補出しのみ。

PRD の機能一覧から最初のタスク群を下書きし、承認後に BACKLOG へ起票する。実装はしない。PRD に機能を複数書いたあと、最初の /docdd:dev-loop の前に使う。

Web アプリの画面・UI 部品を作る／直すときに、既存のデザインに合わせた実装から、主要な状態・画面幅・アクセシビリティ・実ブラウザでの確認まで一貫して行う。Web アプリの画面向け。ユーザー向け画面の実装・改善・レビューのときに使う。Web 以外のプロジェクト（ゲーム・ネイティブアプリなど）では使わない。

プラグインを新しい版に更新したあと、プロジェクトに置いた雛形（検査スクリプト・.claude/rules/docdd-kit.md・CLAUDE.md の表・docs の節）を新しい版へ追随させる。手付かずのキットのファイルは承知を得て置き換え、手を入れたファイルは差分を見せて1件ずつ聞く。v0.1 系で導入したプロジェクトの移行にも使う。

主要なユーザー操作を、開始から最終状態（画面・DB・ジョブ。ゲームならシーンの状態）まで安全に通して確かめる（E2E）。Web はローカルのブラウザで、Web 以外（ゲーム・ネイティブアプリなど）は『E2E（実際に動かす）』行の自動テストで確かめる。ユーザー向けの操作の流れを追加・変更したあと、または E2E・通し確認・ブラウザでの動作確認を求められたときに使う。

DB・移行（migration）・DB の権限・サーバー側の処理（API など）など、複数の境界をまたぐ変更を、テスト用 DB で安全に統合検証する。これらを実装したあと、または統合テスト・結合テスト・DB テストを求められたときに使う。