Thitic9203/tc-review-workflow

TCレビューワークフロー

目次

• 進捗チェックリスト
• 規範
• 鉄の掟
• 最初に拒否（前提条件ゲート）
• ステップ 1 — 両方のソースを逐語的に読み込む [中程度の自由度]
• ステップ 2 — トレーサビリティマトリックスを作成する [中程度の自由度]
• ステップ 3 — 行品質チェック [中程度の自由度]
• ステップ 3b — 「PO/報告者に確認」の前のソーススイープ（必須）[低い自由度]
• ステップ 4 — Good vs Need Improve を報告 [中程度の自由度]
• ステップ 5 — プロジェクトのTC-reviewチャンネルに通知 [低い自由度]
• QAクロージング（「完了」前に必須）[低い自由度]
• スキル構成
• 対象外
• MUST / NEVER
• 必読ファイル
• 依存関係

誰かがすでに書いたテストケースドキュメントを評価します。このワークフローはそれ自体でテストケースを設計したり編集したりしません。それは「このドキュメントは、書かれている通り、チケットのAC/ECおよびビジネスルールがチェックされることを証明できるか？」という1つの質問に答えます。

スラッシュコマンドショートカット（コマンドをサポートするランタイムの場合）：/tc-review → commands/tc-review.md。

進捗チェックリスト

実行開始時にこのブロックをレスポンスにコピーし、各ラインが完了するたびにチェックを入れます。失敗したゲートは、そのステップの Go back: 行に指定された名前のステップに戻ります — 該当箇所からチェックを外します。

TCレビュー進捗:
- [ ] 最初に拒否（前提条件ゲート）
- [ ] ステップ 1 — 両方のソースを逐語的に読み込む
- [ ] ステップ 2 — トレーサビリティマトリックスを作成する
- [ ] ステップ 3 — 行品質チェック
- [ ] ステップ 3b — 「PO/報告者に確認」の前のソーススイープ（必須）
- [ ] ステップ 4 — Good vs Need Improve を報告
- [ ] ステップ 5 — プロジェクトのTC-reviewチャンネルに通知（スレッドのみを確認）
- [ ] QAクロージング（「完了」前に必須）

規範

shared-preamble.md と shared-must-never.md に従います。

鉄の掟

両側に引用されたソースがない限り、所見なし

すべての所見は、このセッションで実際に開かれた2つのもの、すなわちTCドキュメント自体のテキストと、チケット自体のAC/EC/ビジネスルールのテキスト（またはFigma/PRDなどのデザインソース。ただし実際に開かれた場合のみ）を比較します。一般的な品質感覚から「TCが不完全に見える」というのは、それにチケット自身の文言が隣接して引用されていなければ、所見ではありません — チケットを読んでから判断してください。このセッションで実際に開かれていないソースに対するデザインソースの主張（正確なコピーテキスト、正確なUI状態）も所見ではありません — 推測する代わりに「未検証 — {ソース} を開けませんでした」と述べてください。

これは catch-ai-workflow が完了した作業に対して一般的に実行するのと同じ規律です。このワークフローはそのTC固有のインスタンスであり、実行後ではなく実行前に実行されます。

最初に拒否（前提条件ゲート）

以下両方なしでは開始してはなりません (MUST NOT)：

• TCドキュメント — シート、CSV、またはMarkdownファイルであり、このセッションで到達可能かつ読み取り可能であること。
• 管理チケット — AC/ECを持つJira課題キーまたはURL（またはユーザーが明示的に指定する同等の仕様ソース）。

🔴 停止 — いずれかが不足している場合、skill-rules-style.mdに従って1メッセージで停止します。

組織間 / サイト間チケット: チケットが、接続されたMCPがアクセスを許可されていないAtlassianサイト上にある場合、その旨を伝え、ユーザーにアクセスを許可するよう依頼します（またはAC/ECを直接貼り付けてもらいます）— クラウドIDを推測したり、ブラウザログインにフォールバックして読んだりしてはいけません。

---

ステップ 1 — 両方のソースを逐語的に読み込む [中程度の自由度]

1. TCドキュメント — 実際の状態のまま読み込みます。読み込み中に言い換えたり、要約したり、「きれいに」したりしないでください。後続のすべての引用がそれを指し示せるように、正確なソース（シートID＋タブ/gid、ファイルパス、またはURL）をメモします。
2. チケット — チケットの独自フィールド（説明、カスタムフィールド — 一部のプロジェクトではコンテンツを description から完全に外しています。両方を確認してください）からAC、EC、およびビジネスルール/再チェックリストセクションを取得します。AC/ECラベルとテキストを正確に引用します。類似のチケットの記憶から言い換えてはいけません。 どちらの場所にもAC/ECが見つからない → 最初に拒否ゲートに従って停止します。 仕様テキストは見つかったが、その項目にAC/ECラベルがない → 🔴 停止 — 見つかったテキストを表示し、ステップ2の前にどのように番号を振るかユーザーに尋ねます。ラベルをでっち上げてはいけません。 チケットまたはTCドキュメントの取得でエラー、タイムアウト、または部分的なコンテンツ（切り詰められたテキスト、欠落したフィールド、読み込まれないタブ）が返される → 正確なエラーまたは不足している内容をユーザーに伝え、部分的なAC/ECまたは部分的なTCドキュメントからマトリックスを構築せず、失敗を superpowers:systematic-debugging に委ね、完全なテキストが読み込まれてからステップ1を再開します。
3. デザインソース（Figma、PRD）がリンクされており、ユーザーがそれをクロスチェックしたい場合、このセッションで開きます。開くことができない場合（セッションなし、アクセスなし、レンダリングされたコンテンツなしの表示専用）、それを明確に記録します — 関連する所見の隣に「未検証」のメモとなり、黙ってスキップすることはありません。

---

ステップ 2 — トレーサビリティマトリックスを作成する [中程度の自由度]

チケット上のすべてのACとECについて、それをカバーすると主張するTC行をリストします。

AC/EC	主張元	ステータス
AC_01	TC_003	covered
AC_05	—	no TC — gap
AC_02	TC_007	mis-tagged — TC_007 Expected Result が AC_04 と一致
EC_01	TC_010, TC_011	inconsistent tag — 兄弟行 TC_012 が同じ要素をタグなしでテスト

ステータスはクローズドリストです — 行ごとにこれら4つの値のうち正確に1つを、示されているようにIDを指定して使用します： covered · no TC — gap · mis-tagged — <TC> matches <AC/EC> · inconsistent tag — <TC ids>。 複数の問題がある行は、covered の後にその順序で最初に該当するものを採用します。チケット自身のACリストの穴は仕様レベルのギャップであり、マトリックス行ではありません — Need Improve の下で仕様質問として報告します（MUST / NEVERを参照）。

取り消し線のあるAC/ECはカウントしません。 チケットで打ち消された行（例：-AC_07-、重複としてマークされることが多い）は対象外です：マトリックスおよびレポートから完全に除外します。「正しくカバーされていない」としても言及してはいけません。

ビジネスルールとチケットコメントはコンテキストであり、追加のACではありません。 AC/ECが何を意味するかを理解するためにそれらを読み、TCが正しいものをテストしているかどうかを判断するために使用します。ビジネスルールまたはコメント項目は、それがAC/ECと矛盾する場合のみ報告し、矛盾するAC/ECを指定します。TCがなくてもAC/ECと矛盾しないルールまたはコメントは所見ではありません。Need Improveから除外し、「仕様メモ」セクションを追加しないでください。

以下を、行/AC IDを指定してフラグします：

• TCがゼロのAC/EC。
• Expected Resultが、タグ付けされているものとは異なるACと検証可能に一致するTC。
• 同じテーマ（例：共有UI要素）が兄弟行間で一貫性なくタグ付けされている — 一部はACを持ち、一部は持たず、述べられた理由がない。

---

ステップ 3 — 行品質チェック [中程度の自由度]

tc-quality-standards.md をすべての行に適用し、以下のレビュー固有の失敗パターンについて読み取ります（オーサリング品質とは異なります — これは他人が書いたドキュメントに関するものであり、問題はそれが洗練されているかではなく、信頼できるかどうかです）：

シグナル	なぜ重要なのか
手順がタイトルが主張する状態に到達しない。 「学習者がXを表示する」というタイトルの行の手順がメインページで停止し、決してXを開かない。	そのケースは、それが検証すると言っていることを検証できません。
期待結果がACの文そのものを逐語的にコピーしており、分解されていない。 チケットがそのACの下にいくつかの具体的なサブ項目（フィールド、状態、ボタンバリアント）をリストしている場合、AC文を繰り返すだけの期待結果は、テスターに行ごとにチェックするものを何も提供しません。	合格/不合格は推測になります。
ACが名前付きのケース/状態を列挙している（例：「ケース1～6」、「ローディング/空/フィルター」状態）が、ドキュメントにはそれらすべてに対して1つの汎用的な行しかない。	列挙された状態のほとんどは、行が完了とマークされていてもテストされないままになります。
テストデータに、ACが必要とする具体的な値がない（境界値、特定の日付関係、名前付きフィルターオプション）。	行は書かれたままでは実行できません — テスターは不足している値を発明しなければなりません。
行がACの文言とは異なる条件をテストしている。 ACが「すでにスクロールパスした」と言っているのに、行は「最後まで見た」を使用している。ACが「公開されたアイテムのみ」と言っているのに、期待結果はステータスをチェックしていない。	行は合格する一方で、AC自身の条件はテストされないままになる可能性があります。
期待結果が、行自身のテストデータが許容するよりも曖昧である。 テストデータが答え（スコア、カウント、数式）を計算するために必要なすべての入力を与えているが、期待結果は「正しくソートされている」とだけ言っている。	テスターは実行中に期待値を計算しなければならないため、間違った順序でも合格とマークされる可能性があります。
行の列が互いに矛盾している。 前提条件が「4つのアイテム」と言っているのに、テストデータは3つをリストしている。タイトルが「ステータス」と言っているのに、期待結果は順序のみをチェックしている。	テスターがどの列に従っても、もう一方の列は間違っています。
チケットの前提条件がすべての行から欠落している（例：「ユーザーはサインインしている」）。	すべての行が、述べられていないセットアップステップを引き継ぎます。
セットアップがメソッドを名前のみで挙げている（「リクエストを失敗させる方法がある」、「十分なデータを準備する」）。	2人のテスターが2つの異なる方法でセットアップすることになります。

ケースの信頼性に影響を与えないテストケーススタイルの選択（命名規則、列順序、優先度ラベル）は、ユーザーが特にスタイルレビューを要求しない限り、フラグしないでください。これはここでの tc-quality-standards.md をオーバーライドします：ユーザーがスタイルレビューを要求しない限り、その Priority 属性とレビューゲート「Priorities assigned」行を無視します。

---

ステップ 3b — 「PO/報告者に確認」の前のソーススイープ（必須）[低い自由度]

このワークフローは製品の判断を下すことはありませんが、仕様レベルのギャップや質問は提起します。所見が「PO/報告者に確認」または「仕様が不明瞭」になる前に、result-quality-gate.md のレイヤー14のソーススイープを実行します：デフォルトブランチの製品コードを path:line で、そのインラインコメントと git log -L / blame; メインチケットとすべてのコメント; 周辺のチケット（親/エピック、リンクされたもの、同じ画面またはAPI上の兄弟、およびコミットメッセージが名前を挙げているチケット）; 回帰結果; そしてデザインノード。所見の横に読んだ内容を引用します。ソースがすでに答えている質問は、そのソース付きの所見であり、質問ではありません。

製品クローンがない、または読み取り不可能（dependencies.md の {MONOREPO} チェックが失敗する）：レビューを停止したり、コードレイヤーを黙ってスキップしたりしないでください。コードレイヤーが答えていたであろうすべての質問の横に code not checked — no clone と書き、残りのソースでスイープを続け、そのような質問をスイープ完了として提示しないでください — そのメモを持ってステップ4に進みます。

出力は項目ごとに：所見（または残った質問）+ 引用されたソースとその場所（path:line、チケットキー＋コメント、回帰行、デザインノード）、またはコードレイヤーが実行できなかった場合の code not checked — no clone メモ。

Go back: スイープが回答した質問は、ソース付きの所見としてステップ2または3に戻ります。どのソースも回答しない質問のみが「dev/POに確認」としてステップ4に進みます。

---

ステップ 4 — Good vs Need Improve を報告 [中程度の自由度]

2つの短いリスト。各箇条書きは行ID、AC ID、または引用テキストに固定されます — 固定されていない意見は決してありません。

**Good**
- {所見、TC/AC IDまたは引用付き}

**Need Improve**
- {所見、TC/AC IDまたは引用付き}
  → Suggest: {修正方法}

すべての「Need Improve」箇条書きは「→ Suggest:」行を持ちます — 修正方法を示します。修正方法のない問題は、TC作成者を推測のままにします。各提案はソースから来なければならず、発明された値であってはなりません：

• 行自身のデータから計算: テストデータがすでに入力を保持している場合、値を計算して与えます（例：各計算スコア付きの期待される順序）。作成者が確認できるように数値を示します。
• AC/ECの文言から取得: 例えば、間違った条件をAC自身のフレーズに置き換えるか、AC自身のテキストを使用して欠落している期待結果節を追加します。
• 値を与えるソースがない（チケットが決して述べていないしきい値、カウント、またはタイミング）：値を追加することを提案し、誰が確認するかを述べます（「dev/POにカウントを確認」）。数字をでっち上げないでください。

各箇条書きは簡潔に保ちます。提案は何を変更するかを示し、書き直された行ではありません。ユーザーがスコープを絞り込むように要求した場合（例：「Xに関するすべてを削除」）、そのカテゴリを削除してステップ2〜3からリストを再生成します — そうしないと、同じカテゴリが次回異なる文言で再浮上するため、散文を受動的に手編集しないでください。

言語: デフォルトでチケット/TCドキュメント自身の言語に一致させます。混合 = チケットのAC/ECとTCドキュメントが異なる言語で書かれている場合 → レビューをどの言語で書くか一度ユーザーに尋ねます。Helixメニューとインテーク質問は、user-communication.md に従い英語のままです。レビューコンテンツ自体は、宛先ドキュメントの言語に従います。これは、そのドキュメントがすでに持っているのと同じ例外です。

ステップ5の送信前にレビューをチャットに投稿します — 外部メッセージはチャットメッセージのように送信取消しができません。ステップ5のスレッド質問がゴーサインです。別途「送信しますか？」という質問を追加しないでください。

---

ステップ 5 — プロジェクトのTC-reviewチャンネルに通知 [低い自由度]

すべての実行は、完成したレビューをプロジェクトのTC-reviewチャンネルに送信します…

[翻訳のため省略]

QAクロージング（「完了」前に必須）[低い自由度]

result-quality-gate.md を適用します。各所見が引用され、各提案が出典を持ち、マトリックスが4つのステータス値のみを使用し、ソーススイープが実行され、コードレイヤーに失敗がある場合は注記され、すべての所見が固定されていることを確認します。

再実行ゲート： これらのチェックのいずれかが失敗した場合は、QAクロージングに戻ります。

---

スキル構成

このワークフローは、skill-map.md にリストされているTCレビューワークフローの実装です。

対象外

• 新しいテストケースの起草（tc-fe-prep-workflow / tc-api-prep-workflow を使用）
• チケットの実行（testing-ticket-workflow）
• 記録された証拠クリップのレビュー（review-result-workflow）
• 修正の再テスト（retest-bug-workflow）

MUST / NEVER

MUST

• すべての所見を、引用されたソースで固定します。
• 常にチケットとTCドキュメントを開きます。
• マトリックスに4つのステータスのみを使用します。
• コードレイヤーの失敗を注記します。
• ステップ5の前にチャットに投稿します。

NEVER

• ラベルをでっち上げます。
• 新しいACを発明します。
• PO/確認なしに値を推測します。
• コードレイヤーを黙ってスキップします。
• 外部メッセージを送信取消し不可能なものとして扱います。

必読ファイル

• shared-preamble.md
• shared-must-never.md
• tc-quality-standards.md
• result-quality-gate.md
• user-communication.md
• dependencies.md
• skill-rules-style.md

依存関係

• Jira MCP（チケット読み取り用）
• シート/ファイル読み取りMCP
• {MONOREPO} チェック（コードレイヤーアクセス用）
• デザインツールMCP（該当する場合）