# Test Monitor

> ISTQB/JSTQB のテストモニタリング&コントロール（test monitoring and control）活動のうち、モニタリングの「基盤構築」を支援するスキル。進捗・カバレッジ・失敗率・flaky 率・成果物トレーサビリティ（リスク→条件カバー率・条件→ケース化率）などのメトリクスを test-plan の完了基準と紐づけて定義し、プロジェクトの CI/ツール構成を調査した上で計測基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援して test-monitoring.md と実装物を作る。「テストのメトリクスを決めたい」「CI でテスト進捗を可視化したい」「カバレッジや失敗率を計測する仕組みを作りたい」「トレーサビリティを継続計測したい」と依頼されたときに使う。**AI が継続的なモニタリングを代行することはしない（計測は基盤が行う）。集まったデータの分析・傾向判断は対…

- **Type:** Skill
- **Install:** `agentstack add skill-yasunori0418-skills-test-monitor`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [yasunori0418](https://agentstack.voostack.com/s/yasunori0418)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [yasunori0418](https://github.com/yasunori0418)
- **Source:** https://github.com/yasunori0418/skills/tree/main/skills/testing/test-monitor

## Install

```sh
agentstack add skill-yasunori0418-skills-test-monitor
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# test-monitor: モニタリング基盤の構築支援

ISTQB/JSTQB のテストプロセス 7 活動のうち、テストモニタリング&コントロール
（test monitoring and control）を担う単機能スキル。ただし担当は **モニタリングの
「基盤構築」に限定** する。メトリクスを定義し、プロジェクトの CI/ツール構成を調査した上で、
計測を自動で回すための **基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援** する。
成果物はメトリクス定義ドキュメント `test-monitoring.md` と、それを実現する実装物。

## このスキルがやらないこと（重要）

- **AI が継続的なモニタリングを代行しない**。数値を継続的に眺めて報告するのは AI の仕事では
  なく、ここで構築する **計測基盤（CI・スクリプト）が自動で行う**。このスキルは「基盤を作る」
  ところまでで、実運用のウォッチはしない。
- **集まったデータの分析・傾向判断は対象外**。「失敗率が上がっている原因は何か」「この傾向を
  どう解釈するか」といった分析は行わない。結果の評価・完了判定は **test-report** の担当。
  ここで定義するメトリクスは、test-report が評価に使う **入力を用意する** ためのもの。
- **単発のテスト作成依頼（単にユニットテストを 1 つ書きたいだけ）は対象外** — その場合は
  通常のコーディング支援で対応する。

このスキルは **モニタリング基盤の構築だけ** を行う。テスト計画（test-plan）・条件識別
（test-analyze）・設計（test-design）・実装（test-implement）・実行（test-execute）・
評価（test-report）は各専用スキルの担当で、ここでは呼び出さない。

## このスキルが従う横断原則

testing-skills 全 8 スキル共通の原則。

### 1. ファイル規約 + 任意入力

- 成果物の既定パスは **`docs/test//test-monitoring.md`**。実装物（CI 設定・
  集計スクリプト等）は **プロジェクトの慣習に沿った場所**（`.github/workflows/`・`scripts/` 等）に置く。
- **プロジェクト側（`CLAUDE.md` / `AGENTS.md` 等）に成果物・スクリプトの配置規約があれば
  そちらを優先する**。着手前にリポジトリを調べ、既存の CI 構成・ツールチェーンに合わせる。
- 前工程の成果物 **`test-plan.md`（test-plan）** が規約パスにあれば **入力として読む**。
  メトリクスは計画の **完了基準（exit criteria）** と紐づけて定義する。トレーサビリティ系
  メトリクスを採用する場合は **`test-analysis.md`・`test-case.md` も取得元の入力になる**。
- **前工程の成果物が無ければ代作しない**。完了基準の根拠が要るときは「先に `/test-plan` を
  実行してください」と **提案するに留める**。

### 2. 調査優先 + 決定のみ質問

- **事実はリポジトリ調査で埋める**。CI プロバイダ（GitHub Actions 等）・テストランナー・
  カバレッジツール・既存のバッジやレポート出力は、利用者に訊く前に自分で調べる。基盤の実装は
  この調査結果（実在するツール構成）に基づいて行う。
- **利用者にしか決められない判断だけ** を `AskUserQuestion` で確認する。test-monitor では
  主に **どのメトリクスを採用するか・しきい値・可視化の手段（バッジ/PR コメント/ダッシュボード）** が
  これに当たる（推奨案を先頭に添えて訊く）。
- 流れは **調査 → ドラフト提示 → 承認 → 規約パスへ書き込み・実装**。承認前に確定ファイルや
  CI 設定を書かない。

### 3. 改善提案と仕様反映（early testing 原則）

- 基盤構築中に見つけた **テスト対象・仕様・テスタビリティの問題**（メトリクスが取得できない
  構造、計測不能な完了基準、CI に載せられないテストなど）は、成果物の「改善提案」セクションで
  **提示** する。
- **起票前に既決事項を照合する**。前工程成果物（test-plan 等）とプロジェクトのメモリに同じ
  問題が既に記録され、対応先（詳細設計送り・作業計画送り等）が確定しているものは改善提案に
  **再掲しない**。必要なら「次のステップ」欄の参照 1 行に留める。改善提案には **この工程で
  新規に見つけた未解決の問題だけ** を載せる。
- **仕様の穴は提示で終わらせない**。基盤構築の過程で仕様の曖昧さ・矛盾が割れた場合は、利用者の
  決定を `AskUserQuestion` で確認し、決定が出たら **その内容を仕様書へ反映する作業まで行う**
  （反映先の仕様書が規約パスにある場合）。メトリクスが取得できない構造・CI に載せられない
  テストのような実装レベルで解決すべき決定は、仕様書ではなく作業計画・メモリ等へ退避する。
- **反映が済んだ提案は「改善提案」セクションから削除する**（「反映済み」注記で残さない。
  決定の記録は仕様書の改訂履歴が担う）。全提案が解消したらセクションごと削除して番号を詰め、
  未解決の提案が残っている間だけセクションを維持する。
- **スキル自身がテスト対象のコードを修正しない**。計測基盤の追加（CI・スクリプト）は行うが、
  テスト対象そのものの改変はしない。

### 4. 単機能の堅持

- test-monitor は **メトリクス定義と計測基盤だけ** を作る。他スキルを呼び出さず、相互参照もしない。
- 計測結果の評価が必要になったら、成果物末尾で **`/test-report` の実行を提案** するに留める
  （自分でデータ分析・評価を行わない。原則の「データ分析は対象外」と一致）。

### 5. Progressive disclosure

- 本文は簡潔に保ち、テンプレ・詳細は `references/` に置く。
- テンプレ: [`references/template.md`](references/template.md)（`test-monitoring.md` の雛形）。
- mini サマリ雛形: [`references/mini-template.md`](references/mini-template.md)
  （`mini-test-monitoring.md` の雛形。手順 5 で使う）。
- メトリクス早見表: [`references/metrics-catalog.md`](references/metrics-catalog.md)
  （進捗・カバレッジ・失敗率・flaky 率などの定義と取得元）。

### 6. 成果物の記述スタイル

Markdown 成果物（`test-monitoring.md`・改善提案等）に適用する。実装物（CI 設定・
集計スクリプト）はプロジェクトのコード規約・既存 CI 構成の書き方に従う（手順 3）。

- **略号・コードネームを定義なしで使わない**（例: 仕様書内の `G3` のような社内略号）。
  初出で正式名称・意味を併記するか、平易な表現に開く。成果物単体で読み返して意味が
  取れることを基準にする。
- **スキルの実行記録を成果物に含めない**。利用者との Q&A ログ・フェーズ別実行時間などは
  対話のテレメトリであって、レビュー対象の内容ではない。利用者との決定事項は本文の該当箇所
  （根拠・凡例等）へ埋め込み、実行記録が必要なら scratchpad 等へ分離する。

## 手順

### 手順 0: テスト対象の確定

- 引数 `` があればそれを対象名とする。無ければ利用者に一言で確認する。
  対象名は成果物パス `docs/test//` のディレクトリ名にも使う
  （英数字・ハイフンへ正規化）。

### 手順 1: CI/ツール構成の調査

原則 2 に従い、以下を **自分で調べる**（実装はこの結果に基づく）:

- **CI プロバイダ**: `.github/workflows/` 等の有無・既存のテスト実行ジョブ。
- **テストランナー・カバレッジツール**: 言語/フレームワーク（jest・pytest・go test・gradle 等）と、
  カバレッジ・JUnit 形式レポートの出力可否。
- **既存の可視化**: README のバッジ・PR コメント・外部ダッシュボード連携の有無。
- **完了基準**: `test-plan.md` の exit criteria（メトリクスの紐づけ先）。
- **工程成果物の ID チェーン**: `docs/test//` の `test-analysis.md`・
  `test-case.md` の有無と ID 列（リスク R# / テスト条件 TC-# / ケース CASE-#）。
  トレーサビリティ系メトリクスの取得元になる。仕様書に安定した項目 ID 体系があるかも
  ここで確認する（仕様項目→条件紐づけ率の採用可否）。

### 手順 2: メトリクスの定義

[`references/metrics-catalog.md`](references/metrics-catalog.md) を参照し、対象に適した
メトリクスを **完了基準と紐づけて** 選ぶ:

- 代表例: テスト進捗（消化率）・カバレッジ・失敗率・flaky（不安定）率・実行時間・
  トレーサビリティ（リスク→条件カバー率・条件→ケース化率）。
- 各メトリクスに **定義・取得元（どのツール出力から得るか）・しきい値・完了基準との対応** を与える。
- 採用メトリクス・しきい値・可視化手段は利用者判断を含むので、必要なら `AskUserQuestion`
  （推奨案先頭）で確認する。

### 手順 3: 計測基盤の実装支援

手順 1 の調査で判明した **実在するツール構成に基づいて** 基盤を実装する:

- **CI 設定**: テスト・カバレッジ集計ジョブの追加/拡張（既存構成を壊さない差分で）。
- **集計スクリプト**: ランナー出力（JUnit XML・カバレッジレポート等）や工程成果物
  （`test-analysis.md`・`test-case.md` の ID 列。トレーサビリティ系の場合）からメトリクスを
  算出するスクリプト。プロジェクトの言語・慣習に合わせる。
- **可視化**: バッジ・PR コメント・成果物アップロード等、承認された手段を設定する。
- 実装物は動作確認できる範囲で検証する（構文・ドライラン等）。**継続的な数値のウォッチや
  傾向分析はしない**（このスキルの範囲外。原則で明記のとおり）。

### 手順 4: ドラフト提示 → 承認 → 書き込み・実装

- [`references/template.md`](references/template.md) の構成で `test-monitoring.md` のドラフトと、
  実装（CI 設定・スクリプト）の差分方針を **本文で提示して承認を得る**（原則 2）。
- 承認後、規約パスへ `test-monitoring.md` を書き込み、実装物を配置する。
- 手順 1〜3 で見つけた問題は「改善提案」セクションに記載（原則 3）。
- 計測結果の評価が必要になったら、末尾で **`/test-report` の実行を提案** する（原則 4）。
  データ分析・評価はこのスキルでは行わない。

### 手順 5: mini サマリの作成（レビュー収束後）

- 本編 `test-monitoring.md` と実装物への利用者フィードバックが出なくなり、確認が完了したら、
  同ディレクトリに初見者向けサマリ **`mini-test-monitoring.md`** を作成する。**レビュー中は
  作らない**（フィードバックのたびに本編と同期し直すことになるため、収束後に一度だけ作る）。
- 構成は [`references/mini-template.md`](references/mini-template.md) に従う。対象ドメインに
  詳しくない人へ「何を測っていて、どこで見られるか」を短時間で説明できる状態を目指す。

### 手順 6: 終了条件の確認と完了宣言

モニタリング基盤構築の終了条件は以下。**利用者に「終わりか」と訊かれる前に、
スキル側で判定して宣言する**:

1. 採用メトリクスが定義・取得元・しきい値つきで test-plan の完了基準と紐づけて定義済み（手順 2）。
2. 計測基盤（CI 設定・集計スクリプト・可視化）が実装され、構文・ドライラン等で
   動作確認済み（手順 3）。
3. 承認済みの `test-monitoring.md` と実装物が規約パスへ配置済み（手順 4）。
4. 改善提案が空（各提案が仕様反映・対応先確定のいずれかで解消済み）。
5. test-review ゲート: `/test-review  monitor` の判定が「通過」または
   「条件付き通過」（記録 `test-review-monitor.md`）になっている、もしくは利用者がゲートの
   スキップを明示している。未実施なら完了宣言せず、利用者へ実行を促す
   （test-review は明示起動のみで、本スキルからは起動できない）。
6. mini サマリ作成済み（手順 5）。

- 全て満たしたら **「モニタリング基盤の構築は完了」と明言** して閉じる。以降の計測は基盤が
  自動で行い、数値の評価が必要になったら `/test-report ` を提案する（原則 4）。
- 満たしていない項目があれば、何が残っているかを列挙して先へ進めない。

## 用語（JSTQB 訳語 / 初出英語併記）

- テストモニタリング&コントロール（test monitoring and control）: テスト進捗を計測し、
  計画との差異に応じて是正する活動。本スキルはこのうち計測基盤の構築に限定する。
- メトリクス（metric）: テストの状態を定量化する指標（進捗・カバレッジ・失敗率 等）。
- flaky（不安定）率: 同一条件で合否が揺れるテストの割合。基盤の信頼性を測る指標。
- カバレッジ（coverage）: テストがテスト対象のどれだけを実行したかの割合。

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [yasunori0418](https://github.com/yasunori0418)
- **Source:** [yasunori0418/skills](https://github.com/yasunori0418/skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-yasunori0418-skills-test-monitor
- Seller: https://agentstack.voostack.com/s/yasunori0418
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.