How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

android-test-runner - Skill

Name: android-test-runner
Author: xtone

android-test-runner

重要: ユーザーがAndroidテスト実行をリクエストした場合、常にこのスキルを最初に使用してください。以下の場合に必ず使用: run TestName, execute test, テストを実行, 結果を分析, run all tests, analyze test failures, fix failing tests、または Android unit test…

by xtone(0) 0 installs

Imported from xtone/ai_development_tools (android_development/.claude/skills/android-test-runner/SKILL.md). Install upstream with npx skills add xtone/ai_development_tools --skill android-test-runner. Copyright stays with the author.

Android Test Runner

Android テスト実行を自動化し、テスト失敗を分析し、実行可能な修正提案を提供する Claude Code スキルです。

目的

このスキルは Android 開発者を支援します:

Claude Code から直接テストを実行
テスト失敗の根本原因を自動的に分析
失敗したテストに対する具体的な修正提案を取得
デバッグ時間を30%以上削減

Quick Reference

最も一般的なエラー

| エラーメッセージ | Pattern | クイックフィックス | |---------------|---------|-----------| | Unable to locate a Java Runtime | 6, 12 | export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" | | Unknown command-line option '--tests' | 5, 11 | ./gradlew :module:testVariantDebugUnitTest | | No answer found for: (MockK) | 2 | every { mock.method() } returns value | | No value passed for parameter | 7, 13 | 不足しているコンストラクタパラメータを追加 | | Test not found (Compose UI) | 17 | androidTest/ に移動 | | NoSuchElementException (Flow) | 19 | Turbine の .test {} を使用 | | expected: X but was: Y | 8, 14 | Mock データを確認 | | CI失敗、ローカル成功 | 16, 18 | すべてのバリアントをテスト ./gradlew test |

詳細は knowledge/test-failure-patterns.md を参照

使い方

テスト実行

User: すべてのunit testを実行して
Assistant: [./gradlew test を実行し結果を分析]

User: UserRepositoryのテストを実行して
Assistant: [./gradlew test --tests "*UserRepositoryTest" を実行し結果を分析]

失敗分析

テストが失敗すると、このスキルは自動的に:

テスト出力ログを解析
失敗パターンを特定（NullPointerException, Mock設定問題等）
コード例付きの具体的な修正提案を提供

修正提案の取得

User: LoginViewModelTestが失敗した理由は?
Assistant: [テスト失敗ログを分析し以下を提供:
- 根本原因の説明
- 関連するコードスニペット
- コード例付きの具体的な修正]

System Instructions

ユーザーが Android テストの実行やテスト失敗の分析をリクエストした場合、以下の手順に従ってください:

0. 環境セットアップ & プロジェクト検出（必須 - 常に最初に実行）

テストを実行する前に、環境を確認・設定してください:

ステップ1: JAVA_HOME 確認

# JAVA_HOMEが設定されているか確認
if [ -z "$JAVA_HOME" ]; then
    # macOS: Android Studio JBR を自動検出
    export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
fi

# 確認
$JAVA_HOME/bin/java -version

エラー検出:

"Unable to locate a Java Runtime" が表示された場合 → JAVA_HOMEを設定して再試行

ステップ2: プロジェクト構造検出

# ビルドバリアントを検出（存在する場合）
./gradlew tasks --all | grep "test.*UnitTest"

# 出力例（multi-variantプロジェクト）:
# :app:testDevelopDebugUnitTest
# :app:testDevelopReleaseUnitTest
# :app:testProductionDebugUnitTest

ビルドバリアント検出:

複数の testXxxDebugUnitTest タスクが存在 → プロジェクトにビルドバリアントあり
Unknown command-line option '--tests' エラー → バリアント固有タスクを使用する必要あり

BuildType認識: 本番プロジェクトには複数のBuild Typeが存在することが多い:

Debug: 通常のテスト実行（最も一般的）
Release: リリースビルド
CiRelease: CI専用リリースビルド
Minified: 難読化テストビルド

総バリアント数 = Product Flavors × Build Types

例: 4 flavors × 3 build types = 12 variants
日常開発: Debug ビルドタイプのみテスト
コミット前: すべてのflavorsを Debug でテスト（./gradlew :module:testDebug）
リリース前: すべてのバリアントをテスト（./gradlew :module:test）

ステップ3: テストタスク決定

ビルドバリアントありのプロジェクト:

# 単一バリアント（最速、クイックチェック用）
./gradlew :module:testVariantDebugUnitTest

# すべてのバリアント（CI相当、コミット前推奨）
./gradlew :module:test

ビルドバリアントなしのプロジェクト:

# 標準コマンドが動作
./gradlew test
./gradlew test --tests "*TestClass"

1. テスト実行（拡張版）

Bashツールを使用してGradleテストコマンドを実行してください。重要: 常に最初にJAVA_HOMEを設定してください（ステップ0から）。

パターンA: 標準プロジェクト（ビルドバリアントなし）

# すべてのunit test
./gradlew test

# 特定のテストクラス
./gradlew test --tests "*UserRepositoryTest"

# 特定のテストメソッド
./gradlew test --tests "*UserRepositoryTest.testGetUser"

# 詳細出力付き
./gradlew test --info

パターンB: Multi-Variantプロジェクト（本番環境で一般的）

# JAVA_HOME設定 + 単一バリアントテスト
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && \
./gradlew :module:testVariantDebugUnitTest

# すべてのバリアント（CI相当、コミット前推奨）
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && \
./gradlew :module:test

# 特定モジュールの特定バリアント
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && \
./gradlew :data:testProductionDebugUnitTest

エラーハンドリング & 自動再試行

エラー1: Unknown command-line option '--tests'

原因: プロジェクトに複数のビルドバリアントあり
修正: バリアント固有タスクに切り替え

# バリアントを検出
./gradlew tasks --all | grep "test.*UnitTest"

# バリアントタスクを使用
./gradlew :module:testVariantDebugUnitTest

エラー2: Unable to locate a Java Runtime

原因: JAVA_HOME未設定
修正: JAVA_HOMEを設定して再試行

export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
./gradlew :module:testVariantDebugUnitTest

重要:

常にプロジェクトルートディレクトリから実行
常にAndroidプロジェクトでJAVA_HOMEを設定
テストコマンドを選択する前にビルドバリアントを検出
標準出力と標準エラー出力の両方をキャプチャ
コミット前にすべてのバリアントのテストを推奨（CIパリティ）

2. テスト結果の解析

テスト実行後、出力を分析:

成功インジケータ:

"BUILD SUCCESSFUL"
"X tests completed, X passed"

失敗インジケータ:

"BUILD FAILED"
"X tests completed, X failed"
出力中のスタックトレース

抽出:

失敗したテストクラス名
失敗したテストメソッド名
例外タイプとメッセージ
スタックトレースの場所

3. 失敗パターン分析

失敗を一般的なパターンと照合（完全なリストは knowledge/test-failure-patterns.md を参照）:

一般的なパターン:

Pattern 1: NullPointerException
Pattern 2: MockK: No Answer Found
Pattern 3-10: 標準的なテスト失敗
Pattern 11-16: Multi-variantプロジェクト固有の問題
Pattern 17-19: 高度なパターン（Compose UI, BuildType, Flow）

4. 修正提案の提供

レスポンスを以下の形式でフォーマット:

## テスト失敗分析

**失敗したテスト**: `UserRepositoryTest.testGetUser()`

**根本原因**: MockK mock が `userApi.getUser()` に対して設定されていない

**修正方法**:

`UserRepositoryTest.kt:45` で、mock設定を追加:

```kotlin
@Before
fun setup() {
    every { userApi.getUser() } returns Result.success(mockUser)
}

説明: テストが userApi.getUser() を呼び出していますが、MockKは何を返すべきか分かりません。 every { ... } returns ... を使用してmockの動作を定義する必要があります。


### 5. ナレッジ参照

一般的なパターンについては、以下のナレッジファイルを参照:

- `knowledge/test-failure-patterns.md` - 一般的なAndroidテスト失敗パターン（19パターン）
- `knowledge/project-template.md` - プロジェクト固有のカスタマイズ用テンプレート
- `templates/fix-suggestions.md` - 修正提案用テンプレート

## 重要事項

- 常にプロジェクトルートから実行
- ログを注意深く解析して正確な失敗場所を特定
- ファイルパスと行番号を提供（例: `UserRepository.kt:25`）
- 修正提案時に実際のテストファイルからコードスニペットを含める
- テスト修正は最小限で焦点を絞ったものに
- プロジェクト固有のパターンについては、プロジェクト固有のナレッジファイルを参照

## カスタマイズ

### プロジェクト固有版の作成

最大の精度（80% → 98%）を得るために、プロジェクト固有版を作成:

1. このスキルをプロジェクトにコピー:
   ```bash
   cp -r android-test-runner your-project/.claude/skills/

knowledge/project-specific.md を以下の内容で作成:
- ビルドバリアントとビルドタイプ
- プロジェクト標準のテストライブラリ
- アーキテクチャパターン（Result型、Flow型等）
- CI/CD設定
- プロジェクト固有の一般的な失敗パターン

開発ワークフローについては ~/.config/claude-code/AI_DEVELOPMENT_GUIDELINES.md を参照。

成功基準

✅ Gradle経由でテストを実行可能
✅ 失敗の根本原因を正確に特定（70%以上の精度）
✅ 実行可能な修正提案を提供
✅ デバッグ時間を30%以上削減

互換性

Agent Skills (Open Standard)

このスキルは Agent Skills オープンスタンダードに準拠しています。

対応ツール:

Claude Code ✅
GitHub Copilot ✅
VS Code ✅
Cursor (Nightly) ✅
OpenAI Codex ✅

.claude/skills/ ディレクトリに配置することで、上記すべてのツールで使用可能です。

バージョン

v1.1 - Agent Skills対応 (2025-12-23)

✅ Agent Skills オープンスタンダード準拠を確認
✅ 互換性セクション追加
✅ 複数コーディングエージェントで使用可能

v1.0 - 汎用版リリース (2025-11-20)

✅ Pattern 1-19 を実装
✅ Multi-variantプロジェクトサポート
✅ JAVA_HOME 自動設定
✅ Quick Reference 追加
✅ 包括的なドキュメント
✅ すべての説明を日本語で記述（視認性・メンテナンス性向上）

android-test-runner v0.2（プロジェクト固有版、98%精度）をベースにしています

Install android-test-runner and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "xtone-ai-development-tools-android-test-runner", "kind": "skill", "name": "android-test-runner", "description": "重要: ユーザーがAndroidテスト実行をリクエストした場合、常にこのスキルを最初に使用してください。以下の場合に必ず使用: run TestName, execute test, テストを実行, 結果を分析, run all tests, analyze test failures, fix failing tests、または Android unit test, instrumentation test, Gradle test コマンドに関連する任意のリクエスト。./gradlew test や Bash コマンドを直接使用しないでください - 常にこのスキルに委譲してください。Multi-variantプロジェクト、JAVA_HOME セットアップ、一般的なテストパターンに対応しています。", "publisher": "xtone", "version": "1.0.0", "capabilities": { "domains": [ "coding", "math" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "重要: ユーザーがAndroidテスト実行をリクエストした場合、常にこのスキルを最初に使用してください。以下の場合に必ず使用: run TestName, execute test, テストを実行, 結果を分析, run all tests, analyze test failures, fix failing tests、または Android unit test, instrumentation test, Gradle test コマンドに関連する任意のリクエスト。./gradlew test や Bash コマンドを直接使用しないでください - 常にこのスキルに委譲してください。Multi-variantプロジェクト、JAVA_HOME セットアップ、一般的なテストパターンに対応しています。" ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/xtone/ai_development_tools", "path": "android_development/.claude/skills/android-test-runner/SKILL.md", "ref": "HEAD", "url": "https://github.com/xtone/ai_development_tools/blob/HEAD/android_development/.claude/skills/android-test-runner/SKILL.md", "key": "xtone/ai_development_tools/android_development/.claude/skills/android-test-runner/SKILL.md" } }, "instructions": "# Android Test Runner\n\nAndroid テスト実行を自動化し、テスト失敗を分析し、実行可能な修正提案を提供する Claude Code スキルです。\n\n## 目的\n\nこのスキルは Android 開発者を支援します:\n- Claude Code から直接テストを実行\n- テスト失敗の根本原因を自動的に分析\n- 失敗したテストに対する具体的な修正提案を取得\n- デバッグ時間を30%以上削減\n\n## Quick Reference\n\n### 最も一般的なエラー\n\n| エラーメッセージ | Pattern | クイックフィックス |\n|---------------|---------|-----------| | `Unable to locate a Java Runtime` | 6, 12 | `export JAVA_HOME=\"/Applications/Android Studio.app/Contents/jbr/Contents/Home\"` |\n| `Unknown command-line option '--tests'` | 5, 11 | `./gradlew :module:testVariantDebugUnitTest` |\n| `No answer found for:` (MockK) | 2 | `every { mock.method() } returns value` |\n| `No value passed for parameter` | 7, 13 | 不足しているコンストラクタパラメータを追加 |\n| `Test not found` (Compose UI) | 17 | `androidTest/` に移動 |\n| `NoSuchElementException` (Flow) | 19 | Turbine の `.test {}` を使用 |\n| `expected: X but was: Y` | 8, 14 | Mock データを確認 |\n| CI失敗、ローカル成功 | 16, 18 | すべてのバリアントをテスト `./gradlew test` |\n\n詳細は `knowledge/test-failure-patterns.md` を参照\n\n## 使い方\n\n### テスト実行\n\n```\nUser: すべてのunit testを実行して\nAssistant: [./gradlew test を実行し結果を分析]\n\nUser: UserRepositoryのテストを実行して\nAssistant: [./gradlew test --tests \"*UserRepositoryTest\" を実行し結果を分析]\n```\n\n### 失敗分析\n\nテストが失敗すると、このスキルは自動的に:\n1. テスト出力ログを解析\n2. 失敗パターンを特定（NullPointerException, Mock設定問題等）\n3. コード例付きの具体的な修正提案を提供\n\n### 修正提案の取得\n\n```\nUser: LoginViewModelTestが失敗した理由は?\nAssistant: [テスト失敗ログを分析し以下を提供:\n- 根本原因の説明\n- 関連するコードスニペット\n- コード例付きの具体的な修正]\n```\n\n## System Instructions\n\nユーザーが Android テストの実行やテスト失敗の分析をリクエストした場合、以下の手順に従ってください:\n\n### 0. 環境セットアップ & プロジェクト検出（必須 - 常に最初に実行）\n\nテストを実行する前に、環境を確認・設定してください:\n\n#### ステップ1: JAVA_HOME 確認\n\n```bash\n# JAVA_HOMEが設定されているか確認\nif [ -z \"$JAVA_HOME\" ]; then\n # macOS: Android Studio JBR を自動検出\n export JAVA_HOME=\"/Applications/Android Studio.app/Contents/jbr/Contents/Home\"\nfi\n\n# 確認\n$JAVA_HOME/bin/java -version\n```\n\n**エラー検出**:\n- \"Unable to locate a Java Runtime\" が表示された場合 → JAVA_HOMEを設定して再試行\n\n#### ステップ2: プロジェクト構造検出\n\n```bash\n# ビルドバリアントを検出（存在する場合）\n./gradlew tasks --all | grep \"test.*UnitTest\"\n\n# 出力例（multi-variantプロジェクト）:\n# :app:testDevelopDebugUnitTest\n# :app:testDevelopReleaseUnitTest\n# :app:testProductionDebugUnitTest\n```\n\n**ビルドバリアント検出**:\n- 複数の `testXxxDebugUnitTest` タスクが存在 → プロジェクトにビルドバリアントあり\n- `Unknown command-line option '--tests'` エラー → バリアント固有タスクを使用する必要あり\n\n**BuildType認識**:\n本番プロジェクトには複数のBuild Typeが存在することが多い:\n- `Debug`: 通常のテスト実行（最も一般的）\n- `Release`: リリースビルド\n- `CiRelease`: CI専用リリースビルド\n- `Minified`: 難読化テストビルド\n\n**総バリアント数** = Product Flavors × Build Types\n- 例: 4 flavors × 3 build types = 12 variants\n- 日常開発: `Debug` ビルドタイプのみテスト\n- コミット前: すべてのflavorsを `Debug` でテスト（`./gradlew :module:testDebug`）\n- リリース前: すべてのバリアントをテスト（`./gradlew :module:test`）\n\n#### ステップ3: テストタスク決定\n\n**ビルドバリアントありのプロジェクト**:\n```bash\n# 単一バリアント（最速、クイックチェック用）\n./gradlew :module:testVariantDebugUnitTest\n\n# すべてのバリアント（CI相当、コミット前推奨）\n./gradlew :module:test\n```\n\n**ビルドバリアントなしのプロジェクト**:\n```bash\n# 標準コマンドが動作\n./gradlew test\n./gradlew test --tests \"*TestClass\"\n```\n\n### 1. テスト実行（拡張版）\n\nBashツールを使用してGradleテストコマンドを実行してください。**重要**: 常に最初にJAVA_HOMEを設定してください（ステップ0から）。\n\n#### パターンA: 標準プロジェクト（ビルドバリアントなし）\n\n```bash\n# すべてのunit test\n./gradlew test\n\n# 特定のテストクラス\n./gradlew test --tests \"*UserRepositoryTest\"\n\n# 特定のテストメソッド\n./gradlew test --tests \"*UserRepositoryTest.testGetUser\"\n\n# 詳細出力付き\n./gradlew test --info\n```\n\n#### パターンB: Multi-Variantプロジェクト（本番環境で一般的）\n\n```bash\n# JAVA_HOME設定 + 単一バリアントテスト\nexport JAVA_HOME=\"/Applications/Android Studio.app/Contents/jbr/Contents/Home\" && \\\n./gradlew :module:testVariantDebugUnitTest\n\n# すべてのバリアント（CI相当、コミット前推奨）\nexport JAVA_HOME=\"/Applications/Android Studio.app/Contents/jbr/Contents/Home\" && \\\n./gradlew :module:test\n\n# 特定モジュールの特定バリアント\nexport JAVA_HOME=\"/Applications/Android Studio.app/Contents/jbr/Contents/Home\" && \\\n./gradlew :data:testProductionDebugUnitTest\n```\n\n#### エラーハンドリング & 自動再試行\n\n**エラー1: `Unknown command-line option '--tests'`**\n- **原因**: プロジェクトに複数のビルドバリアントあり\n- **修正**: バリアント固有タスクに切り替え\n```bash\n# バリアントを検出\n./gradlew tasks --all | grep \"test.*UnitTest\"\n\n# バリアントタスクを使用\n./gradlew :module:testVariantDebugUnitTest\n```\n\n**エラー2: `Unable to locate a Java Runtime`**\n- **原因**: JAVA_HOME未設定\n- **修正**: JAVA_HOMEを設定して再試行\n```bash\nexport JAVA_HOME=\"/Applications/Android Studio.app/Contents/jbr/Contents/Home\"\n./gradlew :module:testVariantDebugUnitTest\n```\n\n**重要**:\n- 常にプロジェクトルートディレクトリから実行\n- 常にAndroidプロジェクトでJAVA_HOMEを設定\n- テストコマンドを選択する前にビルドバリアントを検出\n- 標準出力と標準エラー出力の両方をキャプチャ\n- コミット前にすべてのバリアントのテストを推奨（CIパリティ）\n\n### 2. テスト結果の解析\n\nテスト実行後、出力を分析:\n\n**成功インジケータ**:\n- \"BUILD SUCCESSFUL\"\n- \"X tests completed, X passed\"\n\n**失敗インジケータ**:\n- \"BUILD FAILED\"\n- \"X tests completed, X failed\"\n- 出力中のスタックトレース\n\n抽出:\n- 失敗したテストクラス名\n- 失敗したテストメソッド名\n- 例外タイプとメッセージ\n- スタックトレースの場所\n\n### 3. 失敗パターン分析\n\n失敗を一般的なパターンと照合（完全なリストは `knowledge/test-failure-patterns.md` を参照）:\n\n**一般的なパターン**:\n- Pattern 1: NullPointerException\n- Pattern 2: MockK: No Answer Found\n- Pattern 3-10: 標準的なテスト失敗\n- Pattern 11-16: Multi-variantプロジェクト固有の問題\n- Pattern 17-19: 高度なパターン（Compose UI, BuildType, Flow）\n\n### 4. 修正提案の提供\n\nレスポンスを以下の形式でフォーマット:\n\n```markdown\n## テスト失敗分析\n\n**失敗したテスト**: `UserRepositoryTest.testGetUser()`\n\n**根本原因**: MockK mock が `userApi.getUser()` に対して設定されていない\n\n**修正方法**:\n\n`UserRepositoryTest.kt:45` で、mock設定を追加:\n\n```kotlin\n@Before\nfun setup() {\n every { userApi.getUser() } returns Result.success(mockUser)\n}\n```\n\n**説明**:\nテストが `userApi.getUser()` を呼び出していますが、MockKは何を返すべきか分かりません。\n`every { ... } returns ...` を使用してmockの動作を定義する必要があります。\n```\n\n### 5. ナレッジ参照\n\n一般的なパターンについては、以下のナレッジファイルを参照:\n\n- `knowledge/test-failure-patterns.md` - 一般的なAndroidテスト失敗パターン（19パターン）\n- `knowledge/project-template.md` - プロジェクト固有のカスタマイズ用テンプレート\n- `templates/fix-suggestions.md` - 修正提案用テンプレート\n\n## 重要事項\n\n- 常にプロジェクトルートから実行\n- ログを注意深く解析して正確な失敗場所を特定\n- ファイルパスと行番号を提供（例: `UserRepository.kt:25`）\n- 修正提案時に実際のテストファイルからコードスニペットを含める\n- テスト修正は最小限で焦点を絞ったものに\n- プロジェクト固有のパターンについては、プロジェクト固有のナレッジファイルを参照\n\n## カスタマイズ\n\n### プロジェクト固有版の作成\n\n最大の精度（80% → 98%）を得るために、プロジェクト固有版を作成:\n\n1. このスキルをプロジェクトにコピー:\n ```bash\n cp -r android-test-runner your-project/.claude/skills/\n ```\n\n2. `knowledge/project-specific.md` を以下の内容で作成:\n - ビルドバリアントとビルドタイプ\n - プロジェクト標準のテストライブラリ\n - アーキテクチャパターン（Result型、Flow型等）\n - CI/CD設定\n - プロジェクト固有の一般的な失敗パターン\n\n開発ワークフローについては `~/.config/claude-code/AI_DEVELOPMENT_GUIDELINES.md` を参照。\n\n## 成功基準\n\n- ✅ Gradle経由でテストを実行可能\n- ✅ 失敗の根本原因を正確に特定（70%以上の精度）\n- ✅ 実行可能な修正提案を提供\n- ✅ デバッグ時間を30%以上削減\n\n## 互換性\n\n### Agent Skills (Open Standard)\n\nこのスキルは [Agent Skills](https://agentskills.io) オープンスタンダードに準拠しています。\n\n**対応ツール**:\n- Claude Code ✅\n- GitHub Copilot ✅\n- VS Code ✅\n- Cursor (Nightly) ✅\n- OpenAI Codex ✅\n\n`.claude/skills/` ディレクトリに配置することで、上記すべてのツールで使用可能です。\n\n## バージョン\n\n### v1.1 - Agent Skills対応 (2025-12-23)\n- ✅ Agent Skills オープンスタンダード準拠を確認\n- ✅ 互換性セクション追加\n- ✅ 複数コーディングエージェントで使用可能\n\n### v1.0 - 汎用版リリース (2025-11-20)\n- ✅ Pattern 1-19 を実装\n- ✅ Multi-variantプロジェクトサポート\n- ✅ JAVA_HOME 自動設定\n- ✅ Quick Reference 追加\n- ✅ 包括的なドキュメント\n- ✅ すべての説明を日本語で記述（視認性・メンテナンス性向上）\n\nandroid-test-runner v0.2（プロジェクト固有版、98%精度）をベースにしています", "cost": { "context_tokens": 1720 } }