jackleh/claude-skills

作業項目の開始

ペーストされたADOチケットを、新しい（または正しく再開された）ブランチ、後続のセッションで再開可能なコンテキストメモリ、根拠のあるコードベース探索、そして根本原因分析または機能レイアウトに変換します。これはチェックポイントで終了します。調査結果を提示して待機します。このスキルでは修正や機能コードは一切書きません。誤ったRCAを素早く出荷すると、QAのフルラウンドトリップが必要になるため、ユーザーが方向性を先に承認します。

0. ローカル設定の読み込み

まず、このスキルのフォルダにある config.local.md を読み込みます。チケットの解析前に行います。このファイルには、このスキルが意図的にハードコードしない名詞（ブランチプレフィックス、ベースブランチ、プロジェクトのレイヤリングドキュメント、調査結果の保存場所、コードインデックスのブラインドスポット、参照する価値のある過去のメモリなど）が保持されています。探索の品質はこれらの詳細に依存するため、スキップしないでください。

設定ファイルがない場合（新規インストール）、推測できるものから推測します。ベースブランチは git remote show origin（HEADブランチ）、プレフィックスはユーザーの既存ブランチ（git branch --list "*/*"）から推測し、推測した内容をユーザーに伝え、config.local.md として保存するよう提案します（config.example.md を参照）。

メモリディレクトリは、システムプロンプトがこのプロジェクトに対して指定しているディレクトリです。リポジトリは、あなたが作業しているリポジトリです。どちらも設定は必要ありません。

1. チケットの解析

ペーストされた内容から抽出します。ADOのページのコピーペーストはノイズが多いです。最初の行はタイプとIDを大文字で含みます（USER STORY 12345、BUG 12346）。各フィールドラベルは独自の行にあり、値は次の行にあります（State / Dev In Progress）。タグは上部近くのベアラインとして表示されます。無視すべきUIクロムもあります（Save、Follow、Click to add …、switch to HTML editor、空のTestRailセクション）。画像や添付ファイルはペーストには残りません。

• ID（数値）と作業項目の種類 — バグ vs. ユーザーストーリー / 機能 / PBI / タスク。タイプが明示されていない場合、推測します（再現手順＋期待される/実際の結果 ⇒ バグ; 「〜として、私は〜したい」または受入基準 ⇒ 機能）そして、推測した内容を伝えます。
• タイトル、状態、エリア/イテレーション（存在する場合）
• バグ: 再現手順、期待される結果 vs. 実際の結果、ビルド番号、プラットフォーム/デバイス/OS、ディープリンク、添付されたログ名、言及されたスクリーンショット
• 機能: 説明、受入基準、リンクされたデザイン、機能フラグ/実験名
• ディスカッション/コメント: 以前の試行、QAノートとその日付、PR番号

IDがない場合は、何かを作成する前にIDを尋ねます。IDはブランチとメモリ名を駆動します。表示されていないが参照されているもの（スクリーンショット、ログ）に注意し、その内容を推測するのではなく、チェックポイントで尋ねられるようにします。

2. ブランチ

作業中のリポジトリでgitを実行します（セッションがワークツリーや別のクローンにある場合は、それを使用します。決して cd で移動しないでください）:

git status --porcelain

ツリーがダーティな場合は停止します。 ファイルと現在のブランチをリストし、どう進めるか（引き継ぐ、スタッシュする、古いブランチにコミットする）を尋ねます。ある項目の未コミットファイルが次の項目のコミットに漏れ込む可能性があります。これはあなたではなくユーザーが決定します。

クリーンな場合:

git fetch origin
git branch --list "<プレフィックス>/<ID>*"; git branch -r --list "origin/<プレフィックス>/<ID>*"

IDのブランチが存在しない場合は、origin/<ベース> から <プレフィックス>/<ID> を切り、短いSHAを記録します（git rev-parse --short HEAD）。

<プレフィックス>/<ID> または <プレフィックス>/<ID>-N が既に存在する場合（ローカルまたはリモート）、決定する前に最新のものを確認します。同じIDが3つの非常に異なるタイミングで届く可能性があります:

git log --oneline origin/<ベース>..<プレフィックス>/<ID>[-N]   # マージされていないコミット?
git log --oneline origin/<ベース> --grep=<ID>           # "Merged PR NNNN: ... <ID>" = ランディング済み

ADOは squash マージを行うため、マージされたブランチでもコミットがベースより「先」に表示されます。ベースブランチの Merged PR 行がランディングしたことを示します。これをチケットの状態、および最新のQAコメントの日付とブランチの最終コミット日付と合わせて読み取ります。

最新の既存ブランチ	典型的なチケット状態	対処方法
origin/<ベース> を超えるコミットがない（多くの場合、現在のブランチ — ユーザーがペーストする前にブランチを切った）	新規 / 開発中	再利用します。 チェックアウトし、git merge --ff-only origin/<ベース> を実行します。
マージ済み（このIDの Merged PR がベースにある）であり、QAがその後失敗させている	アクティブ / 再オープン、マージより新しい失敗QAコメントがある	次のサフィックスを切ります（-1、-2、…）origin/<ベース> から。以前の試行は主要な探索資料になります。
未マージのコミット（プッシュされているかどうか）、またはPRがまだオープン	PRレビュー / テスト準備完了 / 進行中	進行中 — ブランチは切りません。 何があるか（コミット、プッシュされているか、ベースからどれだけ遅れているか）を報告し、それを探索の主題とし、再開するか新しい試行を開始するかを尋ねます。

シグナルが矛盾する場合（例: 状態が新規だが未マージのブランチがある）、進行中として扱い、尋ねます。重複ブランチを切るのは高くつく間違いです。git fetch が失敗した場合（VPN / 認証）、その旨を伝え、ローカルの origin/<ベース> を使用します。ベースが古い可能性があることに注意してください。

プッシュもコミットもしません。ユーザーが依頼していません。

3. コンテキストメモリ（今書き、後で更新する）

探索の前にメモリを書き、ステータスを ⏳ にします。これにより、セッションが調査中に死んでも項目を再開可能にできます。references/memory-template.md を使用します。

• バグ → bug-<ID>-context.md、機能/ストーリー/タスク → feature-<ID>-context.md
• このIDに対して既に存在する場合は、新しいものを作成せずに更新します。git状態が矛盾するものがあれば修正します。
• MEMORY.md への一行のポインタを追加します。これがないと、後のセッションがメモリを見つけられません。

4. コードベース探索

目標は、チケットが触れる実際のコードパスとその周辺の履歴を見つけることです。RCA/レイアウトが推測ではなく ファイル:行 を引用できるように十分な情報を得ることです。

• コードインデックスがあればそれを使用します（CodeGraph、LSP）: チケットの名詞（ページ、コントロール、サービス、DTO）に関するコンテキストクエリから始め、次にそれが明らかにしたものに対して1つのexplore呼び出しを行います。疑わしいシンボルの呼び出し元/インパクトを確認します。設定でインデックスのブラインドスポット（解析しないファイルタイプ）を確認し、代わりにそれらをgrepします。
• ルートとUI名: ページルート、コンポーネント名、CSSクラス、チケットからのディープリンクスキームは良いgrep用語です。
• 以前の作業: git log --oneline --all --grep=<ID>、git log --oneline -20 -- <疑わしいファイル>、プロジェクトのdocs/investigationsフォルダ（設定）、および同じ領域のレポート用のメモリディレクトリ。同じ症状に対する以前の修正でQAに失敗したものは、見つけられる中で最も価値のあるものです。
• 合格ケースと不合格ケースを比較します。 QAが合格ケースと1つの不合格ケースをリストしている場合、コード内で実際に何が異なるか（ホストページ、データパス、タイミング）をメカニズムを特定する前に調べます。
• すべてのホスト/プラットフォーム: UIが複数のホスト（モバイルシェル、ウェブ）で共有されている場合、チケットがプラットフォーム固有かどうか、コードがそうかどうかを確認します。
• 探索中はビルドしません。 ここではコードを読むだけで十分です。ビルドは遅く、実装に属します。

多くのフォルダにわたる広範なスイープには、Exploreサブエージェントで問題ありません。既知の領域の場合は、直接行います。

5a. バグ → 根本原因分析

メソッドとしては、superpowers:systematic-debugging スキルが利用可能であればそれを使用します。基準は測定され、推測されていないことです。メカニズムと正確な ファイル:行 を挙げ、なぜそれが報告された症状を正確に生成し、他の症状ではないのか（なぜ不合格ケースが失敗し、合格ケースが成功するのか）を説明します。

• 再現手順のユーザーアクションから障害状態までのパスをトレースします。関連する行を引用します。
• デバイスなしで可能な範囲で再現します。状態/マークアップのコンポーネントテスト、レイアウト/スクロール/CSS問題のヘッドレスブラウザ静的レプリカ（設定は既存のハーネスを説明するメモリを指している場合があります）。再現できない場合は、その旨を明確に述べ、自信度を示し、それを確認する証拠（例: QAからの特定のログ行やスクリーンショット）を示します。
• 根本原因を、貢献要因や他のチケットに属する隣接問題から分離します。
• 修正の方向性（または2〜3のオプションと推奨）と、それを特定する回帰テストを提案します。ただし、まだ書かないでください。
• 進行中の項目（ステップ2）: RCAは、ブランチに既にある修正のレビューになります。最新のQA障害に対処しているか、デバイスで失敗させる残存リスクは何か。再開を推奨し、どのQA結果が新しい試行を正当化するかを述べます。

5b. 機能 → レイアウトと詳細化

デザインの対話には、superpowers:brainstorming スキルが利用可能であればそれを使用します。

最初に、受入基準が十分かどうかを判断します。以下の場合に十分です:

• すべてのACを具体的なテストアサーションに変換でき、タッチするファイルにマッピングできる。
• UI状態（ローディング、空、エラー、無効）、プラットフォームごとの動作、分析イベント、機能フラグが指定されているか、明らかに該当しない。

十分な場合は、質問のために質問しません。機能をレイアウトします。不十分な場合は、詳細化が必要です。ギャップについてのみ、1回の AskUserQuestion でバッチで質問します（最大4つの質問、具体的な選択肢、最初に推奨デフォルト）。推測された曖昧なACは手戻りを生みます。

質問する前に各ギャップを分類します。答えがデザインを変える場合（何が表示されるか、データの出所、タップ時にユーザーが見るもの）、それは質問です。明白なハウスコンベンションがあるもの（機能フラグキー、分析イベント名、DI登録など）は、従来の値を選び、レイアウトに Assumed: と書き、ユーザーが一目で修正できるようにし、質問しません。4つの質問バッチが全体の問い合わせです。その後に「また、〜を確認してください…」という末尾は付けません。それらは選択肢のない単なる追加質問だからです。

レイアウトは以下をカバーします:

• 追加/変更するファイル。プロジェクトのレイヤリングに従って配置します（設定はそれを定義するドキュメントを指します）。各ホストでのDI登録を含みます。
• データフロー: データの出所、どのサービスが状態を所有するか、どのようにコンポーネントに到達するか。
• AC → テストマッピング。それぞれのテストプロジェクトに名前を付けます。
• プラットフォームの違い、分析/フラグ、リスクと未解決の質問。

6. チェックポイント

見つけた内容でメモリファイルを更新し（ステータス 🔄、根本原因またはレイアウトの要約、未解決の質問）、ユーザーに提示します:

バグ:

## バグ <ID>: <タイトル>
ブランチ: <プレフィックス>/<ID> (origin/<ベース> @ <SHA> から)   — または: <ブランチ>で進行中、新しいブランチなし
メモリ: bug-<ID>-context.md

### 根本原因
<メカニズム、ファイル:行、症状と一致する理由> — 自信度: <高/中/低 + それを高めるもの>

### 証拠
<コード引用、再現結果、履歴: 以前のPR/試行>

### 提案される修正
<方向性またはオプション+推奨; 追加する回帰テスト; タッチするファイル>

### あなたからの必要なもの
<不足しているスクリーンショット/ログ、決定事項>

機能:

## 機能 <ID>: <タイトル>
ブランチ / メモリ: ...

### ACの内容と不足しているもの
### 提案されるレイアウト（ファイル、データフロー、AC→テスト、すべてのプラットフォーム、Assumed: …）
### 質問（または「なし — ACは十分です」）

その後、停止し承認を待ちます。RCAまたはレイアウトが5ファイル以上に及ぶ場合、またはアーキテクチャを変更する場合は、プロジェクトのdocs/investigationsフォルダ（設定）にそれを書くことを提案します。提案するだけで、自動作成はしません。