track-management

track-management スキルの概要

track-management でできること

track-management スキルは、Conductor の track を作成・更新し、その内容や進行状態を一貫して扱えるようにするためのスキルです。track は単なるタスク名ではありません。識別子、spec.md、フェーズ分けされた plan.md、そしてライフサイクル用のメタデータをひとまとめにし、アイデア段階から完了までを、より明確なスコープとステータスで前に進められる構造化された作業単位です。

このスキルが向いている人

この track-management skill は、すでに Conductor 形式のプロジェクト構成を使っているチームや、スコープを切って進める disciplined な開発フローを取り入れたい人に特に向いています。とくに有用なのは次のようなケースです。

• 要望を実装可能な作業単位に落とし込みたい PM やテックリード
• spec.md や plan.md を新規作成・更新するエンジニア
• ふわっとしたプロンプトではなく、一貫した作業単位を必要とするエージェント
• track 単位の進捗管理、レビューしやすさ、引き継ぎのしやすさを重視するチーム

このスキルが実際に解決すること

多くのユーザーが欲しいのは、一般論としてのプロジェクト管理解説ではありません。実際に必要なのは、次の判断を助けることです。

• いつ新しい track を切るべきか
• どの track type がその作業に合っているか
• spec.md と plan.md に何を書くべきか
• 文脈を失わずにライフサイクル状態をどう更新するか
• 実行可能な幅に track をどう絞るか

track-management for Project Management が本当に役立つのはここです。曖昧な依頼を、track という形に落ちた構造化された作業へ変えてくれます。

通常のプロンプトとの違い

通常のプロンプトでも、エージェントに「計画を作って」と頼むことはできます。ですが track-management は、より強い枠組みを与えます。

• 作業は場当たり的なチェックリストではなく、track として整理される
• 仕様策定と実装計画が分けて扱われる
• ライフサイクル規約やステータスマーカーが重要な前提になる
• 出力は tracks.md を含む、より広い Conductor ワークフローに合うことを前提としている

すでにリポジトリで track ファイルを使っているなら、この違いはすぐに曖昧さの削減として効いてきます。

向いているケース / 向いていないケース

track-management は、専用の spec と plan を切るだけの意味がある作業に向いています。新機能、バグ修正、リファクタリング、一定規模の保守作業にはよく合います。

一方で、次のようなケースでは相性が弱めです。

• 1 行だけの修正
• 単純なリネームだけの作業
• 実行プランに落ちない散発的なブレインストーミング
• そもそも Conductor の規約を使っていないチーム

track ファイルや track メタデータを持ちたくないなら、素直な planning prompt のほうがシンプルです。

track-management スキルの使い方

track-management の導入判断とインストール前提

リポジトリ抜粋を見る限り、SKILL.md の中に組み込みの install コマンドは公開されていません。そのため通常は、親の skill repository を skill runner 経由で追加し、その導入元から track-management を名前指定で呼び出す形になります。たとえば環境によっては次のようなコマンドを使うことがあります。

npx skills add https://github.com/wshobson/agents --skill track-management

ただし、これは実際に使っている skill loader に合わせて確認してください。導入時に本当に重要なのはコマンド文字列そのものではなく、エージェントが plugins/conductor/skills/track-management からこのスキルを正しく解決できるかどうかです。

まず読むべきファイル

最初に確認したいのは次です。

• plugins/conductor/skills/track-management/SKILL.md

このスキルは自己完結型です。skill フォルダのプレビュー上では、補助スクリプト、rules、参照ファイルは見えていません。つまり、実際に使えるガイダンスの大半はこの 1 ファイルに集約されています。導入しやすい反面、裏で自動化がある前提で読み飛ばさず、見出しごとに丁寧に読むのが大切です。

このスキルに必要な入力

質の高い track-management usage にするには、エージェントが作業を分類し、スコープを切れるだけの文脈を渡してください。

• track type: feature, bug, chore, refactor
• 課題の説明、または求める成果
• 制約、non-goals、締切
• 影響を受けるシステム、ファイル、サービス
• 成功条件
• 新規 track がほしいのか、既存 spec の改訂か、plan の改訂か
• すでに track がある場合は現在のライフサイクル状態

これらがない状態でもドラフトは作れますが、汎用的すぎる plan や、広がりすぎた spec になりやすくなります。

粗い依頼を使えるプロンプトに変える

弱いプロンプト:

Create a track for improving auth.

よりよいプロンプト:

Use the track-management skill to create a feature track for improving team SSO onboarding. Write a concise spec.md and phased plan.md. Scope includes first-login account linking, admin error messaging, and audit logging. Do not include SCIM or role sync. Success means new users can complete SSO onboarding without manual DB fixes. Assume the repo already uses tracks.md.

後者のほうが出力の質が上がるのは、type、境界、成果物、除外事項が明確だからです。

求める成果物を明示する

このスキルは複数の仕事をカバーします。何をしてほしいのかは明示してください。

• 新しい track を作る
• 既存の spec.md をレビューする
• plan.md を更新する
• track のメタデータやステータスマーカーを解釈する
• track を completed または次フェーズ準備完了としてマークする
• tracks.md の registry と track を突き合わせて整合を取る

「track を手伝って」とだけ頼むと、モデルが違うレイヤーを選ぶことがあります。

実務でのおすすめワークフロー

信頼できる track-management guide は、だいたい次の流れになります。

1. 作業を feature / bug / chore / refactor のいずれかに分類する。
2. 目標と non-goals を定義する。
3. spec.md を作成または改訂する。
4. plan.md で実装をフェーズに分解する。
5. 完了可能な幅に track が収まっているか確認する。
6. ライフサイクルメタデータと registry 参照を更新する。
7. そのあとで初めて、別の coding skill や prompt で実装に進む。

ここが重要です。質の悪い plan の多くは、実は質の悪い spec が原因です。タスク分解の前に、まずスコープを正してください。

track-management でスコープを適切に切るコツ

実務上、最も効く品質レバーは track の大きさです。よい track には、明確な境界と、見てわかる完了条件があります。悪い track は、複数システム、複数ユーザージャーニー、あるいは移行・新機能・後片付けを一緒に抱え込みます。

依頼文に “also” や “while we’re here” や “and update all related flows” が入っていたら、分割を検討してください。1 つの track が 1 つの一貫した作業単位になっているほど、このスキルの価値は上がります。

spec.md と plan.md の役割分担

spec.md に入れるべきなのは次です。

• 問題
• 期待する振る舞い
• 制約
• acceptance criteria
• スコープ境界

plan.md に入れるべきなのは次です。

• フェーズ
• タスク
• 実行順序
• 依存関係
• 実行メモ

ありがちな失敗は、実装詳細を spec に詰め込みすぎること、あるいは期待する結果が書かれていないまま plan だけを書くことです。この切り分けは曖昧にしないほうがうまくいきます。

確認しておきたいリポジトリ規約

track-management は tracks.md、ステータスマーカー、メタデータなど Conductor の概念を前提にしているため、リポジトリ側では次を確認してください。

• 既存の tracks.md
• 現在の track フォルダ命名パターン
• spec.md と plan.md の実例
• すでに使われている status annotation

このスキルは、ゼロから様式を作るより、既存の house style をエージェントが真似できるときに最も力を発揮します。

実用的なプロンプトパターン

相性のよい呼び出し方の例は次のとおりです。

• “Use track-management to create a new bug track from this incident report.”
• “Use track-management to review this spec.md for scope gaps.”
• “Use track-management to rewrite this plan.md into phased execution tasks.”
• “Use track-management to update track lifecycle state and summarize what is still blocked.”

こうした依頼は、一般的な planning prompt より優れています。なぜなら、答えをどう構造化すべきかまでエージェントに伝えられるからです。

track-management スキル FAQ

track-management は Conductor ユーザー専用ですか？

ほぼそうです。これは track type、spec.md、plan.md、ライフサイクル管理、tracks.md など、Conductor の track 概念を前提に設計されています。他の場所に考え方を流用することはできますが、track-management skill が最も価値を発揮するのは、すでにそのワークフローに近い運用をしているときです。

track-management は初心者にも向いていますか？

はい。ただし、既存の track ベースの進め方の中で作業する必要がある初心者に向いています。構造があることで、仕様化や計画立案を飛ばしにくくなります。一方で、プロダクト判断の代わりにはなりません。初心者には依然として、スコープ設定やトレードオフ判断の支援が必要です。

標準的な planning prompt より何が良いのですか？

最大の利点は一貫性です。track-management usage では、type、scope、planning phases、status conventions を備えた安定した作業単位に出力を寄せられます。標準的な prompt だと、もっともらしくは見えても、リポジトリの流儀に合わない plan が出やすくなります。

どんなときは track-management を使うべきではありませんか？

小さすぎる修正、終わりの見えないアイデア出し、あるいは最終的に track artifact として残らない作業には track-management は向きません。そういうケースでは、この構造はレバレッジではなく単なるオーバーヘッドになります。

新規 track だけでなく既存 track にも使えますか？

はい。元の説明でも、track の作成・管理・完了に加えて、spec.md の作成やレビュー、plan.md の作成や更新、メタデータやライフサイクル状態の解釈までカバーしています。

track-management は実装コードも生成しますか？

いいえ。このスキルの役割は、作業定義と管理であって、コーディングそのものではありません。実行に向けた入力の質は上げられますが、track が固まったあとは、通常は coding や repo editing のワークフローと組み合わせて使います。

track-management スキルを改善するには

目標だけでなく境界も渡す

track-management の質を上げたいなら、「何を起こしたいか」だけでなく「何を含めないか」も必ず渡してください。除外条件は、追加の野心より役に立つことが多いです。track がロードマップ級まで膨らむのを防げます。

実コードベースの根拠を添える

最良の出力は、具体的なリポジトリ文脈があるときに出ます。

• 関連ディレクトリ
• 現在のアーキテクチャメモ
• バグレポート
• ユーザーストーリー
• 既存 track の実例

抽象的な目標だけを渡すと、構造上は正しい track でも、あなたの repo には合っていない内容になりがちです。

track type は早めに指定する

feature、bug、chore、refactor を指定しないと、モデルが誤った種類の作業として推定し、spec の形を間違えることがあります。type は scope、risk の見せ方、タスク分解に影響するので、最初に決めておくべきです。

確定前にレビューを挟む

強い使い方は、2 パスで回すことです。

1. “Draft the track.”
2. “Critique the track for overscope, missing acceptance criteria, and phase ambiguity.”

このやり方は track-management for Project Management を改善します。なぜなら 2 回目で、あとから実行を止めがちな問題を先に拾えるからです。

よくある失敗パターンに注意する

よくある弱い出力には次のようなものがあります。

• track が広すぎる
• spec に測定可能な acceptance criteria がない
• plan が順不同のタスクリストでしかない
• non-goals が欠けている
• メタデータやライフサイクル状態が現実と合っていない

こうした症状が見えたら、単に「もっと詳しく」と頼まないでください。スコープを絞った改訂を求めるほうが効果的です。

改訂依頼は具体的にする

たとえば次のような依頼ではなく、

Make this better.

次のように頼んでください。

Revise this track with three changes: narrow scope to backend only, add explicit non-goals, and convert the plan into 3 phases with dependencies.

この種の改訂依頼は、弱点を直接突くので、出力品質を実質的に改善します。

実行段階に合わせて詳細度を調整する

初期段階の track では、スコープの明確さと判断ポイントを重視すべきです。後半の track では、順序、blocker、完了条件を重視すべきです。早い段階で詳細を求めすぎると、plan が見せかけの精密さになりがちです。track の成熟度に応じて詳細度を合わせてください。

リポジトリ内の良い実例を土台にする

もし repo 内に 1 つでもよくできた track があるなら、それをスタイル参照として渡してください。track-management install の判断もしやすくなります。このスキルが毎回新しい形式を発明するのではなく、既存フォーマットを再現できるとわかるからです。