tracer-setup について
tracer-setupは、Tracerスキルが参照するリポジトリ規約を設定するプロンプト駆動型スキルです。既存のトラッカーやドメイン文書を調べ、設定案を確認してから、合意した内容を書き込みます。
主な機能
- 01リモートと既存文書を調査
- 02課題トラッカーの規約を設定
- 03ドメイン文書の配置を定義
- 04単一・複数コンテキスト構成に対応
- 05エージェントスキルの案内を更新
活用シーン
- 01GitHub、GitLab、ローカルMarkdownでの追跡設定
- 02リポジトリの文脈とADRの配置記録
- 03リポジトリ内のエージェント規約の明文化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ scottwater/ skills --skill tracer-setupインストール後、Claude Code で/tracer-setupを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
domain.mdissue-tracker-github.mdissue-tracker-gitlab.mdissue-tracker-local.mdagents/openai.yaml詳細
トレーサーのセットアップ
トレーサーのスキルが読み取る、リポジトリごとの設定を作成します。
- 課題トラッカー —
/tracer-wayfinderが意思決定マップを作成し、/tracer-to-specと/tracer-to-ticketsが公開し、/tracer-code-reviewが仕様を取得する場所(GitHub、GitLab、ローカル Markdown、または説明するワークフロー) - ドメインドキュメント —
CONTEXT.mdと ADR の配置場所、およびそれらを読み取る際の利用側のルール
セットアップを省略しても問題ありません。すべてのスキルは .tracer/ 内のローカル Markdown にフォールバックします。実際のトラッカーを使いたい場合や、このリポジトリで作業するほかのエージェント向けに規約を明示したい場合に実行してください。
これはプロンプト主導のスキルであり、決定論的なスクリプトではありません。調査し、見つかった内容を提示し、ユーザーに確認してから書き込みます。
プロセス
1. 調査する
存在するものを確認してください。決めつけないでください。
git remote -v— GitHub ですか?GitLab ですか?リモートはありませんか?- リポジトリのルートにある
CLAUDE.md/AGENTS.md— どちらか存在しますか?すでに## Agent skillsセクションがありますか? docs/agents/— このスキルが以前に出力したファイルはすでにありますか?CONTEXT.md、CONTEXT-MAP.md、docs/adr/— 既存のドメインドキュメント.tracer/— ローカル Markdown の規約がすでに使われていることを示すもの- モノレポの兆候 —
pnpm-workspace.yaml、workspacesフィールド、独自のsrc/を持つ中身のあるpackages/*。兆候がなければ単一コンテキストとみなします。ほとんどのリポジトリが該当します。
2. 調査結果を提示して質問する
各セクションの冒頭に推奨する回答を示し、ユーザーがひと言で承認できるようにします。
セクション A — 課題トラッカー。 リモートが GitHub を指している場合は GitHub、GitLab のホストを指している場合は GitLab、それ以外はローカル Markdown を提案します。選択肢は次のとおりです。
- GitHub — GitHub Issues の課題(
ghCLI)→ issue-tracker-github.md をひな形にします - GitLab — GitLab Issues の課題(
glabCLI)→ issue-tracker-gitlab.md をひな形にします - ローカル Markdown —
.tracer/内のファイル(リモートのないプロジェクト)→ issue-tracker-local.md をひな形にします - その他(Jira、Linear、…)— ワークフローを1段落で説明してもらい、それをもとに
docs/agents/issue-tracker.mdを一から作成します。実装チケットの作成と取得方法、ブロッキングの関係の表現方法、チケットをエージェント対応済みにする方法を記載する必要があります。また、Wayfinding の操作として、マップの作成/更新、意思決定チケットの作成と親設定、マップの範囲内のフロンティアの照会、並列ディスパッチの前に1人のコーディネーターがチケットを確保する方法、作業者が自分の子チケットのみを解決する方法、コーディネーターがマップインデックスの更新を直列に適用する方法も記載する必要があります。
セクション B — ドメインドキュメント。 デフォルトは単一コンテキストとし、リポジトリのルートに CONTEXT.md 1つと docs/adr/ を置きます。これは質問せずに作成します。調査でモノレポの兆候が見つかった場合に限り、ルートの CONTEXT-MAP.md からコンテキストごとの CONTEXT.md を参照する複数コンテキストを提案します。domain.md をひな形にします。
3. 確認して書き込む
docs/agents/issue-tracker.md、docs/agents/domain.md、および以下の ## Agent skills ブロックの下書きをユーザーに見せ、書き込む前に編集してもらいます。既存のトラッカードキュメントを更新するときは、ユーザーによるカスタマイズを維持し、ファイル全体を置き換えるのではなく、Wayfinding の操作を追加または更新します。ユーザーがローカル Markdown を選んだ場合は、.tracer/ が無視されていることを確認し、必要に応じてルートの .gitignore に /.tracer/ を追加します。
## Agent skills
### Issue tracker
[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.
### Domain docs
[one-line summary — "single-context" or "multi-context"]. See `docs/agents/domain.md`.
ブロックを追加するファイルを選択します: CLAUDE.md が存在する場合はそれを編集し、そうでなければ AGENTS.md を編集します。どちらも存在しない場合は、どちらを作成するかユーザーに尋ねます。片方がすでに存在する場合、もう片方は決して作成しません。## Agent skills ブロックがすでに存在する場合は、その場所で更新します。
4. 完了
どのスキルがこれらのファイルを読み取るようになったか(/tracer-wayfinder、/tracer-to-spec、/tracer-to-tickets、/tracer-code-review、/tracer-implement。ドメインドキュメントについてはすべてのスキル)をユーザーに伝えます。また、後から調整する場合は docs/agents/*.md を直接編集するのが通常の方法であることも伝えます。トラッカーを切り替えるとき、または古いトラッカードキュメントに Wayfinding の操作を追加する必要があるときは、このスキルを再実行します。