テスト・セキュリティのスキル

ISTQB/JSTQB のテストプロセス各工程の出口ゲートとして、工程成果物（test-plan.md / test-analysis.md / test-design.md / test-case.md / テスト実装 / test-execution-log.md / test-monitoring.md / test-summary-report.md）をレビューするスキル。決定論スクリプトの機械検査（トレーサビリティ ID 突合・テンプレ準拠）と test-reviewer サブエージェントの定性レビューを行い、利用者が通過/条件付き通過/差し戻しを判定して軽量記録 test-review-<工程>.md を残す。上流の仕様・基本設計（spec / design-doc 工程。docs/dev/<対象>/spec.md・basic-design.md）は機械検査と利用者判定のみの軽量ゲートとして扱う。各工程スキル（test-plan〜test-report / feature-spec / basic-design）が完了宣言の前に本スキルの実行を促す。ソースコード diff のレビュー（diff-review）とは別物で、対象はテストプロセスの成果物のみ。成果物の修正・代作はしない。/test-review <テスト対象名> [工程] で明示的に呼び出されたときのみ使用する。

ISTQB/JSTQB のテスト計画（test planning）活動を支援するスキル。テスト対象のプロダクトリスク（product risk）を発生可能性×影響度で識別・評価し、それを根拠にテストアプローチ（どこを厚くテストするか）・開始基準（entry criteria）・完了基準（exit criteria）を定めた test-plan.md を作る。「テスト計画を立てて」「テスト戦略を決めたい」「何をどこまでテストすべきか整理して」「リスクベースでテスト範囲を決めたい」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-plan <テスト対象名> で明示的に呼び出されたときのみ使用する。

ISTQB/JSTQB のテスト完了（test completion）活動のうち、テスト実行結果の評価と完了基準（exit criteria）判定を支援するスキル。テスト実行ログ（test-execution-log.md）と test-plan の完了基準を突き合わせ、完了とみなせるかを判定した test-summary-report.md を作る。テスト完了時の最終レポートにも、テスト途中の中間評価にも使える。「テスト結果をまとめて」「完了基準を満たしたか判定して」「テストレポートを書いて」「今どこまでテストが進んだか評価して」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-report <テスト対象名> で明示的に呼び出されたときのみ使用する。

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

ISTQB/JSTQB のテスト実装（test implementation）活動を支援するスキル。test-design が導出したテストケースを、実行できる形に具体化する。自動テストなら実行手順（テストコード・テストデータ・テストダブル）をコンパイル/構文レベルの動作確認まで、手動テストなら手順書・テストデータ・環境準備手順を作る。「テストケースを実装して」「テストコードに落として」「テスト手順書を作って」「テストデータ・モックを用意して」と依頼されたときに使う。テスト対象の検証としての実行（結果の解釈・欠陥候補整理）は test-execute の担当でここではしない。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-implement <テスト対象名> で明示的に呼び出されたときのみ使用する。

ISTQB/JSTQB のテスト分析（test analysis）活動を支援するスキル。テストベース（仕様・設計・コード・リスク）を分析して「何をテストすべきか」= テスト条件（test condition）を識別し、test-plan のプロダクトリスク評価があればそれを入力に優先度を付けた test-analysis.md を作る。「何をテストすべきか洗い出して」「テスト条件を整理して」「テスト観点を出して」「テスト分析して」と依頼されたときに使う。テストケースの導出（test-design）は対象外。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-analyze <テスト対象名> で明示的に呼び出されたときのみ使用する。

ISTQB/JSTQB のテスト実行（test execution）活動を支援するスキル。test-implement が具体化したテストを実行し、結果を記録し、失敗を欠陥候補として整理して test-execution-log.md にまとめる。自動テストならランナーを実行し結果を解釈、手動テストなら利用者の実施結果を聞き取って記録する。失敗は欠陥候補として整理し、外部 issue 化は提案に留める。「テストを実行して結果を記録して」「テスト実行ログを作って」「失敗を欠陥として整理して」「手動テストの結果を記録して」と依頼されたときに使う。ワークフローの test-targeted（修正範囲にテストランナーを絞り込んで実行するだけ）とは別物で、こちらは ISTQB プロセスとしての実行・記録・欠陥候補整理を成果物 test-execution-log.md に残す。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-execute <テスト対象名> で明示的に呼び出されたときのみ使用する。

Resolve complex or high-impact problems when the cause, solution path, requirements, or proof boundary is genuinely uncertain. Use when work needs evidence-led diagnosis, consequential design or implementation, or a completion audit; do not trigger merely because work has multiple steps, or for simple facts, fully specified routine changes, or pure creative generation.

日本語の概要は準備中です。原文の説明を表示しています。

Automate browser interactions, inspect web pages, and work with Playwright tests using a headless-first CLI workflow.

日本語の概要は準備中です。原文の説明を表示しています。

Audit a codebase as a read-only senior advisor, prioritize evidence-backed improvements, and write self-contained implementation plans. Use for codebase audits, improvement roadmaps, focused planning, plan review, plan reconciliation, or executing an existing improve plan through an isolated Codex worktree. The advisor never edits source code; execution uses codex-improve and returns to the main agent for review.

日本語の概要は準備中です。原文の説明を表示しています。

Test-driven development with red-green-refactor and behavior-focused tests. Use when the user explicitly wants test-first work, a regression test before a fix, or integration tests that drive a feature through a public interface.

日本語の概要は準備中です。原文の説明を表示しています。

Quality audit of a whole repo: bugs, security holes, what breaks under real load, risky code without tests, slow paths, and what to delete, merge or split. Ranked, each finding explained in plain English. One-shot report, changes nothing. Use for "audit this codebase", "review the whole repo", "find bloat", "what can I delete", /ponytail-audit.

日本語の概要は準備中です。原文の説明を表示しています。

Explicit-only interview loop for stress-testing a plan, decision, or idea. Use only when the user asks to grill, interrogate, interview, or stress-test their thinking before action.

日本語の概要は準備中です。原文の説明を表示しています。

Submission-grade remote-sensing Nature/high-impact journal figure workflow for Python or R. Use whenever the user asks to create, revise, audit, or polish manuscript figures, multi-panel scientific plots, map-led composites, remote-sensing image plates, sensor/product workflow figures, validation/error/uncertainty panels, or journal-ready SVG/PDF/TIFF outputs, especially for Nature-family, Remote Sensing of Environment, ISPRS, IEEE TGRS, or other high-impact venues. Before plotting, define the figure's conclusion, evidence logic, export needs, and review risks. If the user has not chosen Python or R, ask "Python or R?" and stop. Use only the selected backend for figure generation, previewing, exporting, and QA. Supports matplotlib/seaborn and ggplot2/patchwork/ComplexHeatmap. Not for dashboards or Illustrator/Figma-first infographics. Also trigger on general academic-writing figure needs even without the word "Nature", such as making figures/plots for a paper, scientific/academic plotting, data visualization for a manuscript, and Chinese phrasings like 遥感论文配图、学术写作配图、科研绘图、科研作图、地图出图、论文图表、可视化.

日本語の概要は準備中です。原文の説明を表示しています。

Coordinate Codex work across the current task, internal subagents, user-owned tasks, worktrees, handoffs, formal review gates, or recurring automation. Use for delegation, parallel roles, another Codex task, cross-repo work, QA/review handoffs, scheduled follow-up, or task inspection and continuation. Chinese triggers include 子Agent/子进程/子对话, 另一个对话接手, 并行处理, 分给QA, 多仓库收口, 巡检, 持续推进, 定时自动继续, 创建/读取/转交任务.

日本語の概要は準備中です。原文の説明を表示しています。

Use when performing cybersecurity operations - offensive or defensive - including threat detection and hunting, SOC operations, incident response, digital forensics and DFIR, malware analysis and reverse engineering, threat intelligence, cloud/container/network/application/API security, identity-access and zero-trust, OT/ICS and endpoint security, vulnerability and supply-chain management, DevSecOps, cryptography, AI security, compliance and governance, and red-team or penetration testing under signed rules of engagement; routes to one of 800+ technique playbooks mapped to MITRE ATT&CK, D3FEND, and NIST CSF.

日本語の概要は準備中です。原文の説明を表示しています。

Android device offensive security, forensic extraction, and mobile app exploitation. Use this whenever the user needs to: break into or bypass the lock screen of an Android phone, extract data from a seized Android device for evidence, analyze or reverse-engineer an APK to find vulnerabilities, intercept communications on an Android device, exploit Android apps via deeplinks, steal crypto wallets or app data, set up rogue WiFi to target a phone, or plan any mobile device investigation or penetration test. Also trigger when the user mentions Android forensics, mobile pentesting, law enforcement phone extraction, device exploitation, WhatsApp or Telegram extraction from a phone, Android app reversing, CVE research for Android, or needing a chain of custody for mobile evidence. Even if the user describes the scenario casually or in another language, if they need to gain access to or pull data from an Android phone, use this skill.

日本語の概要は準備中です。原文の説明を表示しています。

Use when designing, evaluating, documenting, modernizing, reviewing, refactoring, or implementing software architecture and code-level structure, including requirements, context, architecture style selection, microservices patterns, WebAssembly/WASI/Component Model, UMA portable capabilities, runtime contracts, capability graphs, governed MCP/agent orchestration, clean code, code smells, Rust crate/library API architecture, Cargo feature/MSRV/SemVer policy, unsafe/FFI/no_std/library testing, modularity, views, NFR tactics, IAM/auth, security patterns, cost estimation, architecture-as-code fitness functions, ADR/RFC work, and engineering execution plans.

日本語の概要は準備中です。原文の説明を表示しています。

Use when advising, planning, reviewing, reporting, operating, or improving CTO and technology leadership work across strategy, cybersecurity management, SME/COE, functional and technical requirements, framework selection, people, organization, delivery, risk, KPI, roadmap, budgeting, governance, audit, R&D, stakeholder communication, culture, politics, and sector-specific leadership.

日本語の概要は準備中です。原文の説明を表示しています。

大規模システムリプレース・移行プロジェクトについて、マルチベンダー管理に長けたPMOの視点で「見落とされがちな潜在リスク」を洗い出す。正常系設計や特定ベンダーの担当範囲内には現れにくい「ベンダー間の隙間」「業務影響」「異常系」の死角を、4視点の分析フレームワークで特定し、Backlog起票用のリスク表とキラークエスチョンを生成する。要件定義・運用設計・負荷試験フェーズ特化フレームワークへの切替にも対応。総合テスト終盤・移行リハーサル前・負荷試験計画時のリスク総ざらいに使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rca）、要求の追加・変更・矛盾検証（requirement-management）、運用設計書そのものの新規作成（operations-design）。

エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。

SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。

Answer whether a specific advisory reaches anything in THIS repository — which manifest declares the package, at what version, whether the version is in range, and whether the vulnerable code is reachable. Use when someone asks "does CVE-… affect us", when triaging an advisory against a real codebase, or before spending effort on a fix.

日本語の概要は準備中です。原文の説明を表示しています。

Package license analysis — detect copyleft conflicts against a permissive policy, surface AGPL / SSPL / GPL contaminants, output SPDX SBOM with per-package license findings. Use when auditing a release for license compliance, vetting a new dependency's license, building an OSS-attribution document, or producing a customer-facing license disclosure.

日本語の概要は準備中です。原文の説明を表示しています。