This skill should be used when the user asks to "既存プロジェクトのタスクを整理して", "技術的負債をIssue化して", "このコードベースを改善するタスクを洗い出して", "GitHub Projectに健全化タスクを登録して", "break down what needs to be fixed in this project", "surface tech debt as issues", or "create a project board for cleanup work". Diagnoses pain points and codebase health of an existing project, then registers improvement tasks as GitHub Issues and a Project Board.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
既存プロジェクトのペインポイントとコードベースの健全性を診断し、GitHub IssuesとProject Boardに改善タスクとして登録するスキル。
gh CLI がインストール済みであること（未設定の場合は dry-run モードで代替）以下のファイルが存在するか確認する:
CLAUDE.md — 技術スタック・開発規約docs/architecture.md — アーキテクチャ概要両ファイルが存在しない場合:
プロジェクトドキュメント（CLAUDE.md / docs/architecture.md）が見つかりませんでした。
選択してください:
1. `/analyze-project` を先に実行してドキュメントを整備してから戻る（推奨）
2. このまま続行する（コードベースを直接スキャンして補完します）
gh auth status
認証エラーの場合:
GitHub CLI が未認証です。
`gh auth login` で認証後に再実行してください。
または dry-run モードで続行することもできます。
dry-run モードでは GitHub への登録を行わず、docs/task-backlog.md にタスク一覧を出力します。
続行しますか？ [dry-run で続行 / キャンセル]
gh issue list --limit 10
gh project list --owner "@me" --limit 10
結果をユーザーに提示し、既存の状況を把握する。
プロジェクトで「今、何が痛いか」を引き出すインタビュー。各ステップを順番に確認する。
以下を質問する:
1. このコードベースは最後にいつ頃から活発に開発されていますか？
2. 現在何人がこのプロジェクトに関わっていますか？
3. 新しいエンジニアがこのプロジェクトで作業を始めるときの最大の障壁は何ですか？
各カテゴリについて順番に質問する:
| カテゴリ | 質問 |
|---|---|
| ドキュメント | どのAPIや機能が一番ドキュメント不足ですか？ |
| テスト | テストがない、または壊れているエリアはどこですか？ |
| 技術的負債 | 触るのが怖い、または避けているコードやモジュールはありますか？ |
| 運用・インフラ | CIが不安定、またはデプロイに問題がある箇所はありますか？ |
| オーナーシップ | 誰もレビューできない、または担当者不明なコード領域はありますか？ |
回答内容を TodoWrite に蓄積しておく。
洗い出したペインポイントを提示し、優先度を確認する:
収集したペインポイント:
[洗い出した内容を箇条書きで列挙]
これらの優先度を教えてください:
- ブロッカー（新機能開発前に必ず解消が必要）なものはどれですか？
- まず着手したいものはどれですか？
今回のタスク整理のスコープを決めましょう:
1. ワンスプリントのクリーンアップ（3〜5件の絞り込んだタスク）
2. 中長期の健全化ロードマップ（カテゴリ別に網羅的にタスク化）
どちらを希望しますか？
ヒアリングの結果を踏まえ、コードから客観的な証拠を収集する。読んだ情報は TodoWrite に蓄積し、Phase 3 のタスク作成で参照する。
診断する観点:
.github/workflows/ と gh run list --limit 5 で直近の状態を確認password\s*=, api_key\s*= などを Grep具体的なコマンドと優先度判断の目安は references/diagnostic-scan.md を参照する。
スキャン結果をユーザーに提示し、タスク化する項目を確認する。
1タスク = 1PRで完結できる粒度を守る。
「テストを全部書く」ではなく「src/payments/ モジュールのユニットテストを追加する」のように具体的に分割する。
ドキュメント補完 (docs:)
テスト追加 (test:)
技術的負債解消 (refactor:)
CI/CD修復 (chore:)
セキュリティ修正 (fix:)
調査・決定 (調査)
オーナーシップ明確化
Issue の body は以下の構成を基本とする（詳細テンプレートが必要な場合のみ references/issue-templates.md の該当セクションを参照）:
タスク案を提示してユーザーの確認を取る:
以下のタスクを作成します:
[カテゴリ別にタスクリストを提示]
追加・削除・変更はありますか？
確認後、GitHub Issueを作成してProject Boardに登録します。
$ARGUMENTS にproject番号が指定されている場合はそれを使用する。
指定がない場合:
gh project list --owner "@me" --limit 10
既存Projectがある場合はユーザーに選択を求める。ない場合またはユーザーが新規作成を希望する場合:
gh project create --owner "@me" --title "[リポジトリ名] 健全化ロードマップ"
gh project list --owner "@me"
以下のラベルが存在しない場合は作成する:
gh label create "docs" --color "0075ca" --description "ドキュメント補完"
gh label create "test" --color "e4e669" --description "テスト追加"
gh label create "refactor" --color "d93f0b" --description "技術的負債解消"
gh label create "security" --color "ee0701" --description "セキュリティ修正"
gh label create "ci-cd" --color "bfd4f2" --description "CI/CD修復"
gh label create "research" --color "c5def5" --description "調査・決定"
# body は Phase 3 で定めた基本構成（概要 / 作業内容 / 完了条件）を使用する
ISSUE_URL=$(gh issue create \
--title "docs: [対象のAPI・機能名] のリクエスト/レスポンス仕様を追記する" \
--label "docs" \
--body "$(cat <<'EOF'
## 概要
[ペインポイント・診断結果から導出した背景]
## 作業内容
- [具体的な作業項目]
## 完了条件
- [ ] [検証可能な条件]
EOF
)")
gh project item-add [PROJECT_NUMBER] --owner "@me" --url "$ISSUE_URL"
GitHub Project のカラムはデフォルト（Todo / In Progress / Done）をそのまま使用する。新規Issueは Todo に登録される。
作成したIssueをカテゴリ別にまとめて提示する:
タスク登録が完了しました。
| カテゴリ | Issue数 | 主なタスク |
| --- | --- | --- |
| ドキュメント補完 | X | [代表的なタイトル] |
| テスト追加 | X | [代表的なタイトル] |
| ... | | |
GitHub Project: [URL]
次のステップ:
- 最も優先度の高いIssueから `/implement-task #N` で着手できます
- ドキュメントタスクは `/doc-sync` を使って実装変更と同期しながら進めることもできます
- オンボーディング目的であれば `/analyze-project onboarding` でドキュメントの整備もできます
references/issue-templates.md — ドキュメント補完・テスト追加・技術的負債解消・セキュリティ修正・CI/CD・調査タスクのIssueテンプレートreferences/diagnostic-scan.md — Phase 2 で使用する診断コマンド・Grep パターン・優先度判断の目安/analyze-project — CLAUDE.md と docs/architecture.md を生成するプロジェクト解析スキル（タスク分解の前段として推奨）/implement-task — 登録したIssueを1件ずつ実装するスキル/doc-sync — 実装変更とドキュメントを同期するスキルまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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