scan-automation-project

スキャン自動化プロジェクト

プロジェクトをスキャンし、QA に焦点を当てた情報をまとめます。プロジェクトの種類、言語、フレームワーク、既存のテスト、および利用可能な Testomat.io のアクセス権を確認します。

浅いスキャンのみ実施します。 インポートの完全な解決、行単位の解析、テスト実装全体の読み込みは行いません。高レベルの構造のみを確認します。

Step 1: ソースコードを特定する

• プロジェクトのルートに空でないソースフォルダーまたはファイルがある場合は、Step 2 に進みます。
• ソースファイルが見つからない場合は、停止してユーザーに次のように尋ねます。

❓ No application source code detected (folder may be empty or missing).
Where is the source code?
1. Use local project from another folder (I will create a symlink)
2. Clone from Git repo
3. I don't know yet (stop here)

• ユーザーの返信を待ちます。
• ユーザーが Git リポジトリまたは別のフォルダーを指定した場合は、.testeiya/<name>/（ソースのベース名を使用し、既に使われている場合は extra- を付けます）にクローンまたはシンボリックリンクを作成します。すでにそこにある場合は何もしません。

.testeiya/ フォルダー

永続的な QA メタデータはすべて、プロジェクトのルートにある .testeiya/ に保存します。

• <name>/：外部プロジェクトへのリンクまたはクローン。ソースにちなんだ名前を付けます。読み取り専用の参照用です。
• requirements/：ユーザーストーリーと受け入れ基準（PDF、ドキュメント、画像）。
• docs/：機能の説明、テスト計画、戦略ファイル。人が読むための文章であり、データダンプは置きません。
• test-cases/：Testomat.io から取得した Markdown 形式のテストケース。
• auto-tests/：関連する自動（e2e）テストへの参照。
• exploratory/：explorbot のセットアップ。
• project-info.json：キャッシュされている場合は、Testomat.io が報告するプロジェクト設定。

ルール：

• ドットフォルダーです。ファイル検索ツールでは既定でスキップされるため、hidden:true または明示的な .testeiya/ パスプレフィックスを指定して検索します。リンクされたフォルダーはシンボリックリンクです。ワイルドカード検索ではその中に入り込まないため、.testeiya/<name>/ 自体をプレフィックスにして検索します。
• このフォルダーは Git の対象から除外されます。.testeiya/ を作成するときは、* のみを記述した .testeiya/.gitignore も作成します。リポジトリ自体の .gitignore に .testeiya/ を追加しないでください。リポジトリレベルのエントリーがあると、検索ツールからこのフォルダーが見えなくなり、テストケースがそこにあるにもかかわらず、次のスキャンで「手動テストなし」と報告されます。

取得データの保存ルール

外部データ（手動テストケース、アプリコード、別リポジトリの e2e テスト）をこのプロジェクトに取り込む場合：

このプロジェクトにあるもの	取り込んだデータの保存先
ソースコード（src/ フォルダー）または大規模プロジェクト	.testeiya/…
テスト基盤のみ（src/ はなく、tests/、playwright/、cypress/ などの e2e ディレクトリがある）	test-cases/ または e2e-tests/
空／手動テストのみ	test-cases/

判定ロジック：

1. src/ フォルダーがある、またはモノレポである？ → .testeiya/ を使用
2. e2e テストディレクトリ（tests/、playwright/、cypress/、e2e/）がある？ → Git 管理対象のフォルダー（test-cases/、e2e-tests/）を使用
3. それ以外 → 既定で test-cases/ を使用

• このルールが対象とするのは、取り込んだデータのみです。スキルが生成し、ユーザーが必要とする出力（coverage.*.yml や新しい *.test.md ファイルなど）は、通常どおりリポジトリに保存します。
• 手動テストがないソースリポジトリでは、このスキルは Git 管理対象のファイルを変更しません。Git の対象から除外された .testeiya/ ディレクトリを作成するだけです。
• .testeiya/ と Git 管理対象のフォルダーのみを変更し、誤った場所にキャッシュを置いてリポジトリを汚さないでください。

ステップ 2：プロジェクト分析

ソースファイルのパスのみを収集してください。ファイルの内容は読まないでください。

対象：

• アプリケーションのソースファイル。
• ビュー／テンプレートファイル：.html／.htm、.vue、.svelte、.hbs／.handlebars、.ejs、.pug／.jade、.mustache、.liquid、.erb、.haml、.slim、.blade.php、.twig、.j2／.jinja／.jinja2、.cshtml／.razor、.jsp。これらはアプリケーションのソースです。カバレッジスキルは、これらを通じて UI の変更を対応付けます。

除外対象：

• 依存関係、ビルド出力、カバレッジ、レポート、キャッシュ、設定、ロックファイル、環境ファイル。
• .gitignore で無視されるパス。ただし、.testeiya/<name>/ は除きます。手動テスト用リポジトリでは、アプリのコードがここにあるため、ソースとしてスキャンしてください。
• Testeiya の内部ファイル（例：session-factory.ts、system-prompt.ts）。
• 判断に迷う場合は、除外してください。

ファイル一覧から、以下を特定してください：

• プロジェクトの種類を次のいずれかに分類します：
  • source：アプリケーションのソースコード。変更せず、調査に使用します。
  • e2e：テスト自動化プロジェクト（e2e ディレクトリ、テストフレームワークの設定があり、アプリのソースがほとんど、またはまったくない）。このプロジェクト向けのテストを作成できます。
  • manual：空、または主に *.test.md ファイルで構成されます。テストケースはプロジェクト自体に追加します。
• 言語とフレームワークを検出します。アプリケーション用とテスト用のすべてのフレームワークを含む frameworks リストを 1 つ作成します。
• プロジェクト設定ファイル（package.json、Cargo.toml、pom.xml など）からプロジェクト名を取得します。見つからない場合は、ルートディレクトリ名を使用します。
• ソースファイル数に基づいて複雑さを評価します。

ファイル数	複雑さ
1-30	small
31-150	moderate
151-500	large
500+	very-large

ステップ 3：テストの棚卸し

既存のテスト（自動・手動）を検出します。調査は浅くとどめてください。

手動テスト

*.test.md ファイルはテストスイートです。ファイル内の各テストは、`` ブロックの後に #／## 見出し（タイトル）が続く形式です。ブロック内の type: フィールドでテストの種類を指定します。

• type: manual：ここで Markdown として作成・保守される手動テストケースです。
• type: automated：自動テストへの参照です（下記を参照）。
• type: 行がない場合：手動テストとして扱います。これは一般的な形式なので、type: manual を grep して手動テストを数えないでください。件数が実際より少なくなります。

プロジェクトの範囲、カバレッジ、進捗について回答する前に、件数を把握してください。Testomat.io の解析方法に合わせ、ファイルから直接読み取ります。find . は .testeiya/test-cases/ の中も検索するため、プル後に再実行すると「手動テストなし」と誤って報告するのではなく、キャッシュされたケースも見つかります。

# one line per suite or test: SUITE <title>, or <type> <title>
find . -name "*.test.md" -exec awk '
  /^/ { in_block=0; expect=1; next }
  expect && /^#+[[:space:]]+/ {
    title=$0; sub(/^#+[[:space:]]+/, "", title)
    if (kind == "SUITE") printf "SUITE: %s\n", title
    else                 printf "|- [%s] %s\n", kind, title
    expect=0
  }
' {} +

出力を grep -c '\[manual\]' または grep -c '\[automated\]' に渡すと、それぞれの種類の件数を数えられます。

• .test.md ファイルがすべて .testeiya/test-cases/ 配下にある場合は、その旨を棚卸し結果に記載してください。これらはこのリポジトリ由来ではなく、Testomat.io から取得したものです。
• *.test.md ファイルのないソースチェックアウトには、数えるテストケースはありません。その旨を記載し、推定しないでください。

自動テスト

• 設定ファイル（jest.config.*、playwright.config.*、vitest.config.*、pytest.ini、pom.xml など）、プロジェクトの依存関係、テストファイルのパターン（*.test.*、*.spec.*、*_test.*）からフレームワークを検出します。
• 各フレームワークについて、テストファイルのパターンを特定し、一致するファイル数を数えます。
• 単体テストと統合テストは棚卸しの対象であり、QA の対象範囲ではありません。記録はしますが、QA 作業の対象となるのは e2e と受け入れテストのスイートであることを明記してください。

自動テストの参照

*.test.md 内の type: automated エントリーは参照であり、実行可能なコードではありません。これらは check-tests pull --export-automated を通じて取得されます。このコマンドは、Testomat.io が把握している自動テストを Markdown としてエクスポートします。実際の実装は別のリポジトリにある自動化プロジェクトにあり、通常はこのリポジトリではありません。

• ここで参照を見つけたというだけで、自動テストを実行したと主張しないでください。ここにあるものは何も実行しません。
• テストの動作を変更するために、参照の Markdown を編集しないでください。コードは別の場所にあり、次回の pull で編集内容は上書きされ、push すると TMS のデータを破損させる可能性があります。代わりに、自動化リポジトリで実際のテストを探してください。
• 実際に実行するには、CI プロファイルを使用します（Step 4）。プロジェクトで設定済みの場合、Testomat.io を通じて実行を開始できます。
• 参照は今も有用なコンテキストです。すでに自動化されているものと、まだ手動のものがわかるため、カバレッジの不足や自動化候補の特定に役立ちます。

Step 4: Testomat.io へのアクセス

このセッションから Testomat.io にアクセスできる方法を記録します。決めつけず、確認してください。

• トークン： 環境変数（または .env）に TESTOMATIO が設定されていること。設定されていれば、npx check-tests でテストケースを pull および push でき、REST API は $TESTOMATIO_URL/api/v2 で応答します。
• MCP： Testomat.io MCP ツールが利用可能であること（testomatio- が接頭辞のツール、tests_list や runs_list などの直接ツール、または操作を検索して呼び出す単一の mcp ツール）。MCP にはトークンだけでなく TESTOMATIO_PROJECT_ID も必要です。トークンだけではプロジェクトを特定できません。セットアップ方法は testomatio-mcp スキルに記載されています。
• プロジェクト設定： .testeiya/project-info.json がある場合は、フレームワーク、言語、環境、ラベル、タグ、CI プロファイルを確認します（CI プロファイルを通じて実行を開始できます）。

トークンが設定済みの場合、ユーザーに Testomat.io のトークンを尋ねないでください。テスト対象のアプリが必要とするシークレットは別のものであり、それが不足している場合は実行できません。

質問ごとの参照元

質問の内容	最初に行うこと
テストの内容：手順、gherkin、説明、ファイルパス、タグ	プロジェクト内で read、find、grep を実行する
スイートの階層、構成、存在するファイル	ls、find を実行する
個別テストのメタデータ：優先度、ステータスフラグ、ラベル	ファイルを確認する。記載がない場合は Testomat.io からテストを取得する
実行、テスト実行、プラン、ラベル、課題、分析	Testomat.io（MCP または REST）を使用する。これらはファイルではありません
テストまたはスイートの作成・更新	Markdown ファイルを編集し、その後 npx check-tests push を実行する（sync-test-cases-with-tms を参照）
CI で自動テストまたは混合テストを開始する	npx -y @testomatio/reporter@latest run --remote <profile> を実行する。CI プロファイルが設定されていない場合はエラーにする
自動テストをローカルで実行する	Testomat.io reporter を接続したローカルのテストランナーを使用する

Testomat.io のステータスと件数はリアルタイムで更新されます。実行によって随時変わるため、会話の前の方で確認した数値よりも、新たに取得したクエリ結果を優先してください。

ステップ 5：出力

構造化された Markdown の結果を直接返してください。ファイルには保存しないでください。

# Project Overview

- **Project Name:** acme-web-app
- **Description:** A React-based customer dashboard with an Express API.
- **Project Type:** source
- **Languages:** TypeScript, SQL
- **Frameworks:** React, Express, Jest, Playwright
- **Complexity:** small (12 files)

## Test Inventory

- **Automated Tests:** 10 files (Playwright)
- **Manual Tests:** 37 cases (`.testeiya/test-cases/`, pulled from Testomat.io)
- **Automated References:** 12 (implementation lives in another repository)

### Manual Tests (20 of 37 shown)

- SUITE: Authentication
  |- User can login
  |- User can reset password
- SUITE: Billing
  |- User can view invoice
  ...and 17 more

### Automated Tests (10 of 10 shown)

- home.page.spec.ts
...

## Testomat.io

- **Token:** set (`TESTOMATIO`)
- **MCP:** available (`testomatio-*` tools)
- **Project settings:** `.testeiya/project-info.json`, framework playwright, CI profiles: "e2e" (github)

フィールドのルール：

• 説明： 検出されたソースコードとフォルダー構造のみに基づいて、1〜2 文で記述します（該当する場合は分野も含めます）。
• プロジェクトの種類： source、e2e、manual のいずれか 1 つです。
• 複雑さ： small、moderate、large、very-large のいずれか 1 つと、ファイル数を記載します。
• 手動テスト： 階層をプレーンテキストのまま維持します。SUITE 項目を親箇条書き、テストタイトル（|-）をその子項目として記載します。テストの保存場所も記載します。
• 自動テスト： 検出されたテストファイルの一覧です。
• Testomat.io： アクセス経路ごとに 1 行で、available／not available を記載します。アクセス経路が 1 つもない場合に限り、このセクションを省略し、プロジェクトが接続されていないことを記載します。
• 値はすべて、確認可能なファイルとツールから取得してください。不足しているデータを推測したり、上記にないフィールドを追加したりしないでください。

セクション：

• ステップ 3 でテストが見つからなかった場合は、## Test Inventory を省略し、プロジェクトにテストが含まれていないことを記載します。次のステップを検討するうえで、# Project Overview セクションは引き続き役立ちます。
• テストの種類が 1 つない場合は、ブロック引用で記載します。例：> プロジェクト内に手動テスト（`.test.md`）が見つかりませんでした。

テスト一覧の省略：

• 各一覧につき、元ファイルでの順序を保ったまま、先頭から最大 20 件まで表示します。
• 見出しに省略を示し（（37 件中 20 件を表示））、...and N more と記載します。
• テスト一覧全体を省略せずに表示してはいけません。