dev-task-loop について
dev-task-loopは、特定の課題管理ツールやVCSホストに依存しない開発バックログ向けのワークフロースキルです。最初に作業条件を確認し、実装、検証、コミット、マージ、状態更新まで各チケットを進めます。
主な機能
- 01開始前に6項目の作業条件を確認
- 02指定元からバックログを取得
- 03各チケットを順に実装・検証
- 04変更をコミットしPRを作成またはマージ
- 05タスク状態を更新して結果を確認
活用シーン
- 01開発バックログをチケットごとに処理
- 02OpenSpecやMarkdownチェックリストで作業を追跡
- 03複数の課題管理ツールやVCSホストで一貫した手順を実行
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/dev-task-loopを入力して読み込まれたか確認します。
詳細
開発タスクのループ
開発バックログに取り組むための汎用ループです。このスキルは特定のプラットフォームに依存せず、特定のトラッカー／VCS ホスト／デザインツールではなく、ワークフローを前提とします。
基本原則
まず質問し、その後ループします。 最初に6つの質問をして、作業コンテキストを確立します。その後、ユーザーが停止を指示するか、バックログが空になるまで、チケットごとの短いループを実行します。
ユーザーが回答で指定しない限り、Jira、GitHub、Figma、その他のベンダーを前提にしてはいけません。
フェーズ 0 — ワークフローのコンテキストを確立する
何かを始める前に、AskUserQuestion を呼び出し、6つの質問すべてを1回の呼び出しで提示します。すべての回答が揃うまで作業を開始しないでください。
6つの質問（繁体字中国語 — ユーザーが英語で書いている場合は翻訳してください）：
- 哪個專案？ — ルートパスまたはリポジトリ識別子。回答例：
/Users/me/Documents/myapp、org/repo、「monorepo, packages/web」。 - 在哪個分支開發？ — 作業ブランチ（新しいコミットが追加されるブランチ）。例：
tim、dev、feature/foo。 - 開發完合併到哪？ — マージ先。例：
main、develop、release/v2。 - 任務清單在哪？ — バックログの場所と、「作業可能」の項目を絞り込む方法。例：「Jira プロジェクト PROJ、ステータス = Review Failed、担当者 = 自分」、「GitHub イシューのラベル：bug」、「Notion DB X のフィルター Y」、「この
TODO.mdファイル」。 - 示意圖／設計在哪？ — デザインの参照先、または「デザイン不要」。例：「Figma ファイルの URL」、「
/docs/mocks/内のスクリーンショット」、「デザイン不要 — テキスト仕様のみ」。 - 完成後任務要怎麼標記？ — タスクページ上、またはディスク上で行う完了条件のアクション。例：「修正済み @reviewer とコメントし、ステータスを審査中に設定」、「イシューをクローズして、PR のリンクを残す」、「Markdown ファイルのチェックボックスにチェックを付ける」、「
openspec archive <change>を実行」。
AskUserQuestion の各選択肢リストには、過去のセッションでユーザーが指定した可能性が最も高い選択肢と、自由記述用のフォールバックを含めてください（ハーネスが「Other」を自動で追加します）。
6つの回答を、このセッションの残りの間のワークフロー契約として保存します。各フェーズの前に、頭の中で回答を再確認してください。
フェーズ 1 — バックログを取得する
質問4への回答を使って、ユーザーの「作業可能」フィルターに一致するチケットの一覧を取得します。
方法は、ユーザーが指定したものによって異なります。
| トラッカーの種類 | 方法 |
|---|---|
| セッション Cookie を使う REST API（Jira Cloud、Linear、Asana など） | ブラウザー MCP でトラッカーを一度開いてから、開いているタブに対して javascript_tool で REST エンドポイントを呼び出します。セッション Cookie によって認証されます。 |
| GitHub / GitLab | まずプラットフォーム CLI（gh issue list、glab issue list）を試し、利用できない場合はウェブ自動化に切り替えます。 |
OpenSpec / Spectra（リポジトリ内の openspec/ ディレクトリ） | アクティブな変更には openspec list を使います。変更1件をチケット1件として扱い、タスク1件として扱わないでください — そのチケットのチェックリストは内部の tasks.md であり、2.4 でチェックを付けます。各タスクをチケットとして扱うと、項目ごとにPRが1つ作成されます。 |
| Markdown / Google Doc / Notion テーブル | ファイルまたは URL を読み込み、フィルターに一致する行を解析します。 |
| ユーザー指定の臨時リスト | 指定された場所を読み込みます。 |
結果は、タスク ID と1行の要約からなるリストとしてキャッシュします。リストをユーザーに提示し、どの項目から始めるか（または「先頭から」）を尋ねます。
フェーズ 2 — チケットごとのループ
各チケットについて、以下の手順を順番に実行します。検証を省略してはいけません。
2.1 タスクを読む
ファイルベースのバックログ（OpenSpec の tasks.md などの Markdown チェックリスト）には、タスクページがありません。代わりにファイルを読み、この変更に含まれる proposal.md、tasks.md、および design.md があればそれも確認し、以下のブラウザー操作はスキップしてください。
それ以外の場合：
- ブラウザーでタスクページを開きます（Chrome MCP／ブラウザー自動化）。REST のみの取得に頼らないでください。QA では通常、スクリーンショット、録画、またはインライン画像が添付されており、これらは Web UI でしか表示されないため、API の呼び出しだけでは見落としてしまいます。
- ページを開いた後も、そのタブを対象に
javascript_toolを使ってトラッカーの REST エンドポイントを呼び出し、説明文をきれいに取得できます。 - トラッカーが「取り消し線」／「解決済み」の書式（Jira ADF の
strikeマークなど）に対応している場合は、それらを除外してください。すでに対応済みの項目です。 - 添付ファイルをスクロールして確認してください。QA が不具合のある UI のスクリーンショットを添付している場合は、それを確認してください。
- 対応すべき項目を、簡潔に自分の言葉でユーザーに伝えてください。
2.2 デザインを参照する
- 質問 5 でデザインの参照元が指定されている場合は、コーディングの前に開いてください。
- デザインが Figma のフレームまたはスクリーンショットの場合は、直接確認してください。似たページの記憶を頼りに実装してはいけません。
- デザインが曖昧な場合は、推測する前にユーザーに確認してください。
2.3 作業ブランチを確認する
git -C <project> status
git -C <project> branch --show-current
質問 2 で指定された作業ブランチにいることを確認してください。git status に前のタスクの未コミットの残りが表示された場合は、その内容を伝え、続行する前に確認してください。
2.4 実装する
software-engineering-guidelines に従い、必要最小限の変更を実装してください。編集範囲を絞り、既存のコンポーネントやパターンを再利用し、プロジェクトのスタイルに合わせてください。
2.5 検証する
UI の変更は、次に進む前に必ず実際のブラウザーで検証してください。型チェックに合格しただけでは不十分です。見た目はコードだけでは判断できません。
変更内容に応じて、適切な検証を実行してください。
- UI の変更（表示される HTML／CSS／コンポーネントの編集） — ブラウザーでの確認が必須です：
- 開発サーバーがすでに動作している場合は Preview MCP を使い、そうでなければユーザーが指定したデプロイ環境で Chrome MCP を使ってください。
- ホームページだけでなく、実際に影響を受けるルートに移動してください。
- 変更が表示されることを確認してください。レイアウト、色、余白、文言、インタラクション状態（ホバー、フォーカス、無効状態）を確認します。
- モバイル固有のチケットの場合は、プレビューを
mobileプリセット（375×812）にリサイズして再確認してください。 - テナント別／会社別／ロール別の動作の場合は、できれば対象のロールでログインしてください。少なくとも、そのルートでエラーが発生しないことを確認してください。
- ブラウザーセッションを開けない場合（プレビューが動作していない、ログイン済みのタブがないなど）は、作業を止めてユーザーに伝えてください。「ソースを見る限り問題なさそう」と推測してはいけません。
- TypeScript／ビルドの確認：関連するパッケージで
pnpm tsc --noEmit（またはtsc、npx tsc）を実行してください。既存のベースラインエラーは無視し、新たに発生したものだけを報告してください。UI の作業では、これは必要ですが十分ではありません。 - OpenSpec の変更：
openspec validate <change-id> --strictを実行してください。これは仕様自体の構造チェックで、型チェックと同程度の位置づけです。アーカイブ時に拒否されるような不正な変更を検出しますが、コードが動作するかどうかは確認しません。 - ユニットテスト／統合テスト：変更対象のモジュールに対するテストがプロジェクトにある場合は、
package.json／pyproject.tomlなどに記載されたテストコマンドを実行してください。 - バックエンドのみの変更：ローカル API が動作している場合は
curl／httpieで確認し、そうでなければ型チェックとテストの結果を判断材料にしてください。
2.6 コミットする
git -C <project> add <specific files only>
git -C <project> commit -m "$(cat <<'EOF'
<type>(<scope>): <short subject> (<TICKET-ID>)
Why: <one or two sentences on the problem>
Fix: <one or two sentences on the change>
EOF
)"
git -C <project> push origin <working-branch>
git add -A や git add . は決して使わないでください。秘密情報や関係のないファイルが紛れ込まないよう、パスを指定してステージしてください。
Co-Authored-By のトレーラーや、エージェントの帰属を示すフッターは追加しないでください。これは、それらを追加するグローバルなコミット規約より優先されます。これらのコミットはユーザーのプロジェクトに反映されるため、追跡に必要なのはチケット ID です。
2.7 PR／マージリクエストを作成する
プロジェクトで使用している VCS ホストに合わせてください。
- GitHub：
gh pr createがインストールされている場合は使用します。インストールされていない場合は、ブラウザー MCP でhttps://github.com/<repo>/compare/<merge-target>...<working-branch>?expand=1に移動し、フォームを送信します。 - GitLab：
glab mr createまたは同等の Web フォームを使用します。 - Bitbucket／Gitea／セルフホスト環境：Web 自動化を使用します。
タイトルにはコミットの件名を使用します。本文にはコミットの本文をそのまま使用します。
2.8 マージする
ユーザーは以前のセッションでほぼ毎回「マージして」と依頼しています。セッションごとに一度確認したら、その後はチケットごとに再確認せずに進めてください。CI が赤でも問題ないとユーザーが伝えている場合は、赤いチェックを理由に止めず、そのままマージしてください。
マージ戦略：PR がグラフに表示されるように、実際のマージコミット（--no-ff）を優先します。ローカルでは次のようにします。
git -C <project> fetch origin
git -C <project> checkout <merge-target>
git -C <project> pull origin <merge-target>
git -C <project> merge --no-ff <working-branch> -m "Merge pull request #<n> from <fork>/<working-branch>"
git -C <project> push origin <merge-target>
2.9 作業ブランチを同期する
git -C <project> checkout <working-branch>
git -C <project> rebase <merge-target>
git -C <project> push origin <working-branch> --force-with-lease
--force-with-lease を使用し、--force は決して使用しないでください。
2.10 タスクを完了としてマークする
バックログが Web トラッカーにある場合は、まずブラウザーでタスクページを開いてください。次に、質問 6 でユーザーが指定した操作を実行します。一般的なパターンは次のとおりです。
- トラッカーの REST API（Jira Cloud、Linear など）：トラッカーのタブを開いたら、
javascript_toolを使ってそのページに対して POST できます。セッション Cookie によって認証されます。API 呼び出しの後、ページを目視で確認し、コメントが表示されていて、ステータスバッジが変更されていることを確かめます。 - Web UI のみ（REST API がない、または API にアクセスできない場合）：コメント欄をクリックし、メッセージ（@メンションがある場合はそれも含む）を入力して送信します。次にステータスのドロップダウンを開き、対象の状態を選択します。スクリーンショットを撮るか、ページを読み返して確認します。
- Markdown のチェックリスト／Notion の表：ファイルまたは行を編集し、コミット（Markdown の場合）または保存（Notion の場合）します。Markdown の場合は、ドキュメントの変更を別の小さなコミットとして反映します。
- OpenSpec／Spectra：
openspec archive <change-name>を実行します。差分仕様をメイン仕様にマージし、変更をアーカイブディレクトリに移動します。ファイルの変更なので、コミットに含めます。開くページも確認するステータスバッジもありません。openspec listを再実行し、その変更がアクティブな一覧から消えていることを確認します。
何がどこに書き戻されたかを、ユーザーに一行で確認します。「コメントを投稿し、ステータスを審査中に変更しました。次のチケットに進みますか？」／「PROJ-12 をアーカイブし、openspec list に表示されなくなりました。次のチケットに進みますか？」
フェーズ 3 — チケット間の処理
各チケットの後、2 行で要約します。
- リリースした内容についての 1 行（ファイル数と変更の要点）。
- トラッカーの状態についての 1 行（「PROJ-X にコメントを残し、審査中」）。
次に、ユーザーに次に取り組むチケットを尋ねます。自動で進めたい場合は「次のチケットから」と尋ねます。
復旧／安全ルール
- UI チケットでは、ブラウザーでの確認は必須です。 確認のためにブラウザーを開けない場合は、続行する前にエスカレーションしてください。
git statusに、自分が作成していない想定外のファイルが表示された場合は、停止して報告してください。確認せずに stash や reset を実行してはいけません。- 質問 1 でユーザーが指定したプロジェクトルートの外にあるものや
.env*ファイルは、決して変更しないでください。 --forceを使ってプッシュしてはいけません（--force-with-leaseを使用してください）。- ユーザーが明示的に指示しない限り、フックをスキップしてはいけません（
--no-verify／--no-gpg-sign）。 - 修正を 2 回試して失敗した場合は、停止し、タスクの説明を声に出してユーザーに読み返してください。要件を誤解している可能性があります。ブラウザーでチケットを再度開き、添付されたスクリーンショットをもう一度確認してください。
- テストファイルや無関係なモジュールに既存のベースラインエラーがある場合、チケット対応中に修正する必要はありません。記録して先に進んでください。
スキルの停止条件
- ユーザーが「停止」「停」「夠了」と言ったとき。
- バックログのフィルターに該当する項目がなくなったとき。
- ユーザーの入力なしでチケットを完了するラウンドを 3 回行い、ペースを確認したいとき。
停止時は、次の内容を出力します。
- このセッションでリリースしたチケットの数。
- 残っているチケット（ユーザーのフィルターを適用したもの）。
- ユーザーの対応が必要な事項（例：CI が赤、未解決のデザイン上の曖昧さ、他の人の対応待ちでブロックされているチケット）。