Guide the user through starting a new web application project — elicit requirements (MoSCoW scoping), create architecture and requirements documents, break work into tasks, and register them as a GitHub Project kanban board. Use when the user says "新しいWebアプリを作りたい", "Webアプリの立ち上げを手伝って", "start a new web app project", "プロジェクトの要件を整理したい", or "GitHub Projectにタスクを登録したい".
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
新規Webアプリプロジェクトの立ち上げをサポートするウィザード。 ヒアリング → 設計ドキュメント作成 → タスク分解 → GitHub Project登録 の順に進める。
gh CLI がインストール・認証済みであることスキル起動直後に、以下の順で既存の作業状態を確認する:
docs/requirements.md、docs/architecture.md、CLAUDE.md の存在を確認する続きから再開する場合は、完了済みのPhase/Stepをスキップして未完のところから始める。 最初からやり直す場合は、既存ドキュメントを上書きすることをあらかじめ伝える。
各ステップを順番に実施する。各ステップ終了時に「この内容で進めますか？」と確認を取ってから次へ進む。
以下を質問して記録する:
以下を質問して記録する:
各機能については「誰が・どの権限で・どのデバイスで使うか」まで掘り下げて確認する。 抽象的な回答（例: 「ログイン機能が欲しい」）に対しては詳細を引き出す追加質問をする:
あると嬉しいが必須でない機能も聞いておく。
まず 既存の制約を確認する:
制約がない場合、要件・好みを確認しながら候補を提示して選択してもらう。 各候補のメリット・デメリットを簡潔に説明し、ベストプラクティスを反映した構成を推薦する。 ユーザーが迷っている場合は、要件に照らした推薦理由を明示して決断をサポートする。 判断を先送りしたい項目は「TBD Issue」として記録し、後で決定できるようにする。
選定する観点:
以下の観点について方針を確認する:
未決定事項は「調査: 〇〇を決定する」タスクとしてIssue登録候補に追加する。
Step 2で洗い出した機能を MoSCoW法 で整理する:
ユーザーと合意した Must のみをファーストリリーススコープとする。
確定時に スコープロック日（確定した日付）を docs/requirements.md に記録する。
スコープロック後に Must を増やす場合は必ず「スコープ影響の確認」を行う（後述）。
ここまでのヒアリングで「まだ決まっていない」「要調査」の項目をリストアップし、 それぞれ「調査タスク」としてIssue登録候補に追加する。 TBD として先送りした技術スタックもここで Issue 化する。
ヒアリング内容をもとに以下のドキュメントを作成・更新する。
テンプレートは references/doc-templates.md を参照。
作成するファイル:
CLAUDE.md — プロジェクト概要・技術スタック・開発規約・よく使うコマンドdocs/architecture.md — 設計方針・主要コンポーネント・データモデルdocs/requirements.md — 要件一覧・MoSCoWスコープ・スコープロック日ドキュメント更新のルール: 設計・要件が変わったら、同じタイミングで関連ドキュメントも更新する。 実装PRでは「関連ドキュメントを更新したか」を確認する。
gh project create --owner "@me" --title "[プロジェクト名] ロードマップ"
gh project list --owner "@me"
1タスク = 1PRで完結できる粒度を守る。
必ず含めるタスクカテゴリ:
環境・基盤セットアップ
chore: プロジェクト初期セットアップ（リンター・フォーマッター・TypeScript）
→ このタスクは /node-project-setup スキルで実行できるchore: CI/CDパイプラインの構築（GitHub Actions）chore: テスト環境のセットアップ認証 — feat: 認証機能の実装（[選択した認証方式]）
→ このタスクは /feature-dev スキルで実装できる
データベース — chore: DBスキーマ設計とマイグレーション初期設定
Must機能 — 各機能ごとにIssueを作成
調査タスク — 未決事項・TBDごとにIssueを作成
Issue の body テンプレートは references/issue-templates.md を参照。
# body には references/issue-templates.md の該当テンプレートを使用する
ISSUE_URL=$(gh issue create \
--title "chore: プロジェクト初期セットアップ" \
--body "$(cat <<'EOF'
[references/issue-templates.md の「環境セットアップタスク」テンプレートを貼り付ける]
EOF
)")
gh project item-add [PROJECT_NUMBER] --owner "@me" --url "$ISSUE_URL"
GitHub Project のカラムはデフォルト（Todo / In Progress / Done）をそのまま使用する。
開発が進むにつれ、以下の状況でタスクを追加・変更する。
追加のタイミング:
追加前に必ずユーザーに確認する。
技術スタックや設計方針が変わった場合:
gh issue list で特定するdocs/architecture.md または docs/requirements.md を同時に更新するShould 機能を Must に昇格させる、または新機能を Must に追加する場合は必ず以下を確認する:
確認後、docs/requirements.md のスコープロック日を更新し、変更理由を記録する。
references/doc-templates.md — CLAUDE.md / architecture.md / requirements.md のテンプレートreferences/issue-templates.md — 機能タスク・調査タスク・TBDのIssue bodyテンプレートまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
This skill should be used when the user asks to "プロジェクトを解析して", "コードベースを調べてドキュメント化して", "移行作業の準備をして", "新機能実装の前にプロジェクトを整理して", "analyze this codebase", "document the project structure", "既存プロジェクトのCLAUDE.mdを作って", or wants to prepare CLAUDE.md and architecture docs before a migration, feature development, or onboarding.
This skill should be used when the user asks to "このエラーを直して", "help me debug this", "fix this stack trace", "なぜこのエラーが出るの", "CI が落ちた", or pastes an error message or stack trace and wants help diagnosing it. Classifies the error type, identifies related files, and proposes up to three root-cause hypotheses with concrete fix plans.
This skill should be used when the user asks to "ドキュメントを更新して", "sync the docs", "update CLAUDE.md after this change", "実装に合わせてドキュメントを直して", or notices that docs have drifted from the codebase. Diffs git history to identify what changed, proposes targeted updates to CLAUDE.md, docs/architecture.md, docs/requirements.md, and README.md, then applies only approved changes.
Explain selected code or a specified file/function in plain language, including what it does, why it exists, and potential pitfalls
日本語の概要は準備中です。原文の説明を表示しています。
This skill should be used when the user asks to "このファイルを変えたら何が壊れる？", "what depends on this function", "影響範囲を調べて", "show me what imports this module", or wants to understand the blast radius before modifying a shared utility, exported type, or public API. Traces import/require references up to two levels deep and lists affected test files.
This skill should be used when the user asks to "このIssueを実装して", "implement this issue", "fix this bug", "このタスクをやって", "Issue