القائمة
アプリケーション実装の一気通貫ワークフロー。実装→コードレビュー→CI→設計書整合性チェックまでを人間への確認なしに自律実行する。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill code-devيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
| name | code-dev |
| description | アプリケーション実装の一気通貫ワークフロー。実装→コードレビュー→CI→設計書整合性チェックまでを人間への確認なしに自律実行する。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。 |
| argument-hint | <Issue番号> |
Issue番号: $ARGUMENTS
実装 → コードレビュー → レビュー指摘修正 → CI実行 → CI指摘修正 → 設計書整合性チェック → 設計書修正 を順次自律実行する。 全フェーズを人間への確認なしに自律実行すること。
code-reviewer-agent を Task ツールで起動し、完了を待つcode-ci-runner-agent を Task ツールで起動し、完了を待つdesign-validator-agent を Task ツールで起動し、完了を待つTDD はテストを起点に実装を駆動する手法であり、テストの新規作成・変更を伴うタスクでこそ価値を発揮する。逆に、テスト変更を伴わないタスク（設定値変更・型定義の調整・ログ追加・既存テストを壊さない軽微な修正など）に TDD を適用すると、無意味な Red フェーズを挟むだけで非効率になる。そのため、まずタスク内容からテスト変更の要否を判定し、方式を分岐する。
gh issue view $ARGUMENTS --json title,body,labels で Issue を取得し、タスク一覧（## タスク一覧 のチェックリスト）のうち アプリケーションコードに関するタスク を対象に、テストの新規作成・変更を伴うかを判定する。
| 判定 | 該当するタスクの例 | 実装方式 |
|---|---|---|
| テスト変更あり | 新規関数・ハンドラーの実装、新しい振る舞いの追加、テストコード作成が明記されている | ステップ 1-2A（TDD） |
| テスト変更なし | 設定値・定数の変更、型定義の調整、ログ追加、リネーム、コメント修正など既存テストに影響しない変更のみ | ステップ 1-2B（直接実装） |
判定が曖昧な場合（新しい振る舞いが加わる可能性がある）は、安全側に倒して TDD（1-2A） を選択する。
判定結果と根拠を明示してから、対応するステップへ進む。
tdd スキルを Skill ツールで Issue番号 $ARGUMENTS を渡して起動し、TDDサイクル（Red-Green-Refactor）をこの場（インライン）で実行する。AskUserQuestion が必要な箇所は全て最初の選択肢（デフォルト）で自動選択し、人間への確認なしに最後まで自律実行すること。完了後、Phase 2 へ進む。
tdd スキルは起動しない。Issue のタスク一覧（アプリケーションコードタスクのみ）を1つずつ実装する。
app/ 配下のみ。CDK/インフラのディレクトリ（infra/）は変更しないdocs/policy/code-comment-policy.md に従う（実装コメントは WHY、doc comment は契約を書く。コードが語る WHAT/HOW は書かない）gh issue edit $ARGUMENTS でチェックリストを更新するunit-test-runner を Task ツールで起動して回帰確認する（既存テストが存在しない場合はスキップ）完了後、Phase 2 へ進む。
/tdd $ARGUMENTS で個別実行を案内する/code-review で個別実行を案内する/code-ci で個別実行を案内する/validate-design で個別実行を案内する