コードベース全体のレビュー・監査。perf/sec/test/arch/cq/docs の6観点を並列委譲し、優先度付き issue ファイルと観点サマリをメモリディレクトリに生成する。コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review 実行時に使用。境界: PR 単位は pr-review、自ブランチの提出前確認は self-review。
taskboard-adopt
taskboard を使わずに動いていたセッションを taskboard のタスクに移す。今の作業(作業ディレクトリ・ブランチ・PR・メモリディレクトリの計画)を確かめ、紐づくタスクを探すか起票してこのセッションを結び、列の説明つきの案内を読み、手元の計画を作業項目に写す。
/taskboard-adopt 実行時、「taskboard に移して」「このセッションをタスクに結んで」「taskboard 仕様にして」等の依頼時、taskboard より前から動いているセッション・普段使いの herdr やターミナルで起こしたセッション・古い会話を再開したセッションで SessionStart の taskboard の案内が無いときに使用。
境界: 結んだ後の列・作業項目・文書の日々の扱いは /taskboard、pane・agent の操作は /herdr。
含まれるファイル(1)
- SKILL.md6.0 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Taskboard Adopt
taskboard の外で始まった作業を、taskboard のタスク 1 件に載せ替える。終わった後は、このセッションが taskboard から起動したセッションと同じに扱える(task_id を省いた tool、Stop hook の回答とレビューの注入、SessionStart の案内)。
前提
ツール一覧に mcp__taskboard__* があること。無ければ「taskboard の MCP が繋がっていない(claude mcp list で確認)」と伝えて止まる。
このセッションは、taskboard の herdr の pane なら pane で、それ以外は Claude Code が MCP に渡すセッション ID で見分けられる。どちらでもないセッション(Codex、claude -p の単発)は結べないので、以後の tool に毎回 task_id を渡すよう伝えて、手順 2 までで止める。
手順
1. 今の作業を確かめる
結ぶ先を決める材料を、推測でなく実物から取る。
- 作業ディレクトリ・ブランチ(
git branch --show-current)・未コミットの変更の有無 - そのブランチの PR(
gh pr view --json url,title,state,isDraft)と、会話で扱ったチケット・Issue の URL - メモリディレクトリの記録があれば、計画ファイル(
30_plan.md等)と05_log.md。状態欄は書いた時点の観測なので、項目の済・未済は手順 5 で実物と突き合わせる
2. 紐づくタスクを探す
board_overview で全部の案件のタスクを見る。同一性は URL で判断する(PR の短縮名が行に出る。タイトルでは照合しない)。
- 同じ PR・チケットの URL のタスクがあれば、それが結ぶ先
- URL が無い作業(調査・運用)は、題と備考が同じ完了判定を指すタスクがあればそれ。迷ったら、候補の番号と題を並べてユーザーに聞く(推測で既存のタスクに結ばない)
- 見つからなければ手順 3 で起票する
3. 結ぶ
- 既存のタスクに結ぶ:
task_updateにtask_idとlink_session: true - 起票する:
task_create(titleは何が終われば完了かが読める形、linksに URL、noteにセッションをまたいで要る文脈だけ)。起票するとこのセッションが結ばれる。粒度は「1 タスク = 1 つの完了判定」
応答に「このセッション(…)を結んだ」が出れば結べている。「結べなかった」が出たら、その文の理由を伝えて止まる。
/clear の後の会話では、MCP は /clear の前の会話の ID を持ったまま動く。/clear の後に結ぶと、前の会話を結んでしまう。そのときは /exit して claude --continue で開き直してから結ぶよう伝える。
4. 案内を読み、列を合わせる
session_guide で、SessionStart と同じ案内(今の列と、案件の全部の列の id・名前・説明)を読む。以後、列はこの説明に従って選ぶ(列は案件ごとに違い、既定の列を消した案件もある)。
今の列が実際の状態と違えば、確認できた事実に対応する列へ task_update で移す(例: 実装を進めているなら作業中の列、PR を出してレビュー待ちなら daemon が PR の状態で進めるので手で動かさない)。根拠が無ければ動かさない。
5. 計画を作業項目に写す
work_list で既にある作業項目を見てから、足りない分だけ足す(同じ項目を二重に登録しない)。
- 計画の項目を計画順に
work_add(1 項目 = PR 1 本か、PR 内の 1 段階)。順序の依存はdepends_on - 済んだ項目は
state: doneと成果物(PR の URL、コミットの SHA、ファイルのパス)。済んだかは、コミット・PR・ファイルを開いて確かめる - 進めている項目は
doing、待ちはwaitとblocker_kind・blocker_text - ユーザーが後から見返す計画書があれば
doc_publishで載せる。セッションをまたいで要る文脈(決めた方針・詰まっている点・再開の条件)はtask_updateのnoteに書く
6. 報告する
結んだタスクの番号と題、今の列、登録した作業項目の数(済・作業中・待ち)を短く伝える。以後は /taskboard スキルに従う。
Gotchas
- taskboard から起動したセッションには使わない。 SessionStart の案内(「このセッションは taskboard のタスク #…に紐づいています」)が既にあれば、結ばれている。
task_getで確かめるだけでよい - 1 つのセッションを 2 つのタスクに結ばない。 別のタスクへ移したいときは、ユーザーに確かめる(daemon は同じ会話を複数のタスクに結べてしまい、
task_idを省いた tool がどちらを指すか分からなくなる) - ほかのセッションのタスクの列・作業項目は変えない。 結ぶ先が別のセッションの動いているタスクでも、自分が足すのは自分の作業の分だけ
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
変更をコミットする。/commit 実行時、「コミットして」「pushして」等の依頼時に使用。--push 引数または「pushして」の依頼で push も行う。
PR を Draft で作成する。PR テンプレートを全セクション埋め、対象 repo の既存 PR の分量に合わせて書きすぎを削る。PR 作成の依頼時、実装が一段落して PR 化する時、/create-draft-pr 実行時に使用(gh pr create を直接実行しない)。引数でベースブランチを指定できる。境界: 個別レビューコメントへの対応は pr-comment。
スキルを新規作成する。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill 実行時に使用。AGENTS.md・context・既存スキルと整合させ、重複・競合を避ける。境界: 既存スキル・指示ファイルの修正は update-inst、指示ファイル全体の監査は instructions-audit。
抽象的な要件・事業側の要求を深掘りし、既存実装との整合を確認して実装マスタとシステム要件書を作成する。「こういう機能を作りたい」「この要求を満たす機能を設計して」等の抽象要件の提示時、既存機能の拡張や Phase 分割の要件定義開始時、/design-feature 実行時に使用。境界: 要件確定後の実装計画書・PR 分割と実装進行は plan-feature-prs。
画面の設計判断(ナビゲーション・重ね方・通知と空状態と読み込み・外枠とトークンと状態表現)の型を決定表で選び、アプリ内の全画面で揃える。画面・ページ・レイアウト・ナビゲーション・ダイアログ・コンポーネントを新しく作る・作り直す時、モックやダッシュボードを作る時、サイドバー・タブ・モーダル・シート・toast・バナー・空状態のどれを使うか決める時に使用。PJ に components.json があれば shadcn の部品とトークンへの対応も扱う。主要なデザインシステム(Material・HIG・Carbon・Primer・Atlassian・Fluent・GOV.UK・NN/g・WAI-ARIA APG・WCAG)の一致点を規則にし、食い違いの採否を定めてある。境界: 画面の文言は writing-ui-text、画面に何を出すかと提示前の完了基準は context/ui-artifact-standards.md、コードの実装原則は writing-code、shadcn 部品の API と組み立ては shadcn。