task-run
[タスク] 3. Issue実行 + 進捗同期
Files1
View on GitHubSKILL.md.claude/skills/task-run/SKILL.md
GitHub[タスク] 3. Issue実行 + 進捗同期
入力: $ARGUMENTS
- Issue番号（例:
#123または123） - 省略時: 実行可能なIssue（依存解決済み）を一覧表示して選択
🎯 目的
- 指定されたIssue（または選択したIssue）に従って実装を行う
- 組み込みTask と GitHub Issue の進捗を同期する
- 完了時に両方を更新（Task: completed、Issue: close）
実行手順
1. Issue選択（引数省略時）
📋 実行可能なIssue（依存解決済み）
┌────┬─────────────────────┬──────────┬─────────────┬─────────────┐
│ # │ Title │ Issue │ Task Status │ blockedBy │
├────┼─────────────────────┼──────────┼─────────────┼─────────────┤
│ 1 │ API設計 │ #126 │ pending │ なし ✅ │
│ 2 │ ユーザー認証実装 │ #123 │ pending │ なし ✅ │
│ - │ ログイン画面作成 │ #124 │ pending │ #123 ⏳ │
└────┴─────────────────────┴──────────┴─────────────┴─────────────┘
→ どのIssueを実行する？ [番号を入力]
2. プレチェック
# Issue内容を取得して確認
gh issue view {ISSUE_NUMBER}
ready-for-devラベルがあるか- RDD参照セクションの存在
- 変更要求がある場合は 承認済み か確認
- 組み込みTaskの blockedBy が空か確認
2.5. 作業ブランチ作成（通常 or worktree）
ブランチ戦略:
.claude/rules/git.mdに従う。 task/* ブランチは 最新の sprint/ から作成* する。sprint/* が存在しない場合は main から作成。
ベースブランチの決定:
# sprint/* ブランチの存在を確認
SPRINT_BRANCH=$(git branch -r --list 'origin/sprint/*' --sort=-committerdate | head -1 | xargs)
if [ -z "$SPRINT_BRANCH" ]; then
BASE_BRANCH="main"
else
BASE_BRANCH="${SPRINT_BRANCH#origin/}"
fi
git switch "$BASE_BRANCH" && git pull
通常モード（単一タスク）:
git checkout -b task/{ISSUE_NUMBER}-{short-description}
並行モード（git worktree）: 複数タスクを同時に進める場合は worktree を使用:
# 親ディレクトリにworktreeを作成
git worktree add ../$(basename $(pwd))-task-{ISSUE_NUMBER} -b task/{ISSUE_NUMBER}-{short-description}
# worktreeに移動して作業
cd ../$(basename $(pwd))-task-{ISSUE_NUMBER}
Tips: 別ターミナルで別のClaude Codeセッションを起動し、異なるworktreeで並行作業が可能。 完了後は
git worktree remove ../project-task-{ISSUE_NUMBER}で削除。
3. 着手（組み込みTask + Issue同期）
組み込みTask更新:
TaskUpdate:
taskId: "{task-id}" # metadata.issueNumber で特定
status: "in_progress"
Issueコメント（⚠️ 確認あり）:
gh issue comment {ISSUE_NUMBER} --body "🚀 着手開始
## 実行計画
- [ ] {ステップ1}
- [ ] {ステップ2}
- [ ] {ステップ3}
"
4. 実装（TDD厳守）
CLAUDE.mdの規約に従い、RED → GREEN → REFACTOR で段階的に進める- 要件をToDoに分解（最小ステップ）
- 既存パターン再利用と重複回避を最優先
- UI/画面を伴う実装は、着手前に
experience-planskill のチェックリスト（状態/モーション/世界観整合/文言/進行フィードバック）を宣言してから進める
5. 検証
pnpm lint --fix && pnpm type-check
pnpm test
- 失敗時の切り分け（最小サンプル運用等）は
CLAUDE.mdの方針に従う
UI変更がある場合（Agent Browser利用可能時）:
# 開発サーバーを起動後、Agent Browserでページを確認
agent-browser open http://localhost:3000/{対象パス}
agent-browser snapshot -i # 要素一覧を取得
# 必要に応じてインタラクション確認
agent-browser click @{ref}
agent-browser fill @{ref} "テスト入力"
- 表示崩れ、状態遷移、レスポンシブを目視確認
- 問題発見時は修正後に再スナップショット
6. 進捗報告（適宜）
gh issue comment {ISSUE_NUMBER} --body "📝 進捗報告
## 完了
- [x] {完了したステップ}
## 次のステップ
- [ ] {残りのステップ}
## メモ
{気づいた点や注意点}
"
6.5. 設計書の差分更新
変更モジュールの特定:
# 変更ファイルからモジュールを特定
git diff --name-only HEAD~1 | grep "^src/" | cut -d'/' -f2 | sort -u
対応する設計書を更新:
- 変更があったモジュールの
doc/generated/reverse/modules/{module}.mdを更新 - 更新内容: 変更した関数/クラスの説明、データフロー、設計意図
- 全体再生成ではなく差分のみ（変更箇所に関連する部分だけ）
更新例:
## 変更履歴（今回の変更）
- {変更内容の要約}
- 影響範囲: {関連するモジュール/API}
💡 設計書がPRに含まれることで、レビュアーがコード変更の意図を理解しやすくなる
7. コミット + PR作成
コミット（⚠️ 確認あり）:
git add -A
git commit -m "feat: {変更概要} (#${ISSUE_NUMBER})
- {主要変更1}
- {主要変更2}
Refs #${ISSUE_NUMBER}"
リモートにプッシュ:
git push -u origin task/{ISSUE_NUMBER}-{short-description}
PR作成（⚠️ 確認あり）:
base先の決定:
.claude/rules/git.mdに従う。
- sprint/* ブランチが存在する →
--base sprint/*（task → sprint へマージ）- sprint/* が存在しない →
--base main
# base先を動的に決定
SPRINT_BRANCH=$(git branch -r --list 'origin/sprint/*' --sort=-committerdate | head -1 | xargs)
if [ -z "$SPRINT_BRANCH" ]; then
PR_BASE="main"
else
PR_BASE="${SPRINT_BRANCH#origin/}"
fi
gh pr create \
--title "feat: {変更概要}" \
--body "## 概要
{このPRで何を実現するか}
## 変更内容
- {主要変更1}
- {主要変更2}
## RDD整合
- **準拠**: OK（根拠: doc/input/rdd.md §...）
- **変更要求**: 無し / 有（承認済み）
## 検証結果
- [x] lint/type-check PASS
- [x] test PASS
## テスト手順
1. {確認手順1}
2. {確認手順2}
Closes #${ISSUE_NUMBER}" \
--base "$PR_BASE"
Note:
Closes #${ISSUE_NUMBER}により、PRマージ時にIssueが自動closeされるにゃ。
8. 完了（組み込みTask更新）
組み込みTask更新:
TaskUpdate:
taskId: "{task-id}"
status: "completed"
完了報告:
✅ TASK-{ISSUE_NUMBER} 完了
- PR: #{PR_NUMBER}
- マージ後に Issue #{ISSUE_NUMBER} が自動close
失敗時のガイド
RDD違反
gh issue comment {ISSUE_NUMBER} --body "⚠️ RDD違反検出
## 内容
{違反内容}
## 変更要求(ADR-lite)
{変更提案}
## ステータス
承認待ち（ユーザー確認後に再開）
"
制約で実現不能
gh issue comment {ISSUE_NUMBER} --body "🚫 実現不能
## 理由
{制約の内容}
## 代替案
1. {代替案1}: {影響}
2. {代替案2}: {影響}
## ロールバック方法
{戻し方}
"
品質チェックリスト
- RDD準拠（スタック/制約に一致）
- Docコメント（JSDoc/Docstring）が全関数・クラスにある
- 重複コードを作らず既存パターンを再利用
- コメントでドメイン意図と決定理由を明記
- 検証ゲート（lint/type/test）がPASS
- 必要なら最小サンプルで検証済み（削除可注記）
- 技術的負債が記録され、次スプリントに回されている
- コミットメッセージに Issue番号を含めている
- PRを作成し、
Closes #Issue番号を本文に含めている - 組み込みTask が completed に更新済み
- 変更モジュールの設計書（doc/generated/reverse/modules/）が更新済み
自己評価
- 成功自信度: (1-10)
- 一言理由: {短く理由を記載}