「テスト」の検索結果

日本語を主対象とする資料から選択式の問題を 1 ページのフォームで出し、採点結果を学習履歴に残し、解説を絵解きノート（HTML）とテキストブック（PDF）に蓄積し、書き手向けの還流レポートを作るスキル。「理解度を確認して」「この資料でクイズして」「読めているかテストして」「内容を復習したい」などで発動する。

承認済みの実装計画（Plan）を Agent Team で並列に実装するスキル。 Plan をタスクに分割 → 依存関係を設定 → Wave ごとに並列エージェントを起動 → 完了を待って次の Wave → 最後にビルド＆テスト検証。 team-plan スキル（調査→計画）の後に使う「実装実行フェーズ」。 Use when: 計画を並列に実装したい、チームで実装を進めたい、 Wave 実行で効率よくコードを書きたい。 Triggers: "team implement", "チームで実装", "並列実装", "plan を実装して", "wave 実行", "team-implement", "エージェントで実装", "実装フェーズ", "implement the plan"

.github/workflows/*.yml を自動解析し、CI で定義されたチェックをローカル実行する汎用スキル。 lint・fmt・test・build・audit 等に限定せず、ワークフローの run ステップを抽出して実行する。 エラーがあれば修正し、再実行して確認する。 Use when: CI を通したい、lint/test を実行したい、CI チェックしたい、 ワークフローをローカルで試したい。 Triggers: "CI", "ci-check", "lint", "test", "format", "fmt", "audit", "チェック", "検証", "CI 通して", "テスト実行", "ビルド確認"

改修後の動作確認を、AIが自分で環境を立てて最後まで進めるための検証スキル。CLI（curl / php evo / DB）を優先し、画面操作でしか判定できないときだけ Playwright（既定はヘッドレス）に切り替える。Docker の検証環境の起動、インストール、テスト用ユーザー作成、mailpit でのメール確認、main との比較、後片付けまでを扱う。「動作確認」「自走で確認」「実環境で確かめる」「ブラウザで確認」「再現を確認」「Playwright」と依頼されたとき、または修正のあとに実機での裏付けが必要なときに使う。

Agent Skillのusability testを行うスキル。 下位tierのmodelのsubagentに、検証したいskillだけを頼りにゴールを与え、手を貸さずに観察し、終了後にインタビューとtranscriptの監査で判断の根拠を確かめる。 ユーザーが「skillのusability testをして」「skillをE2Eテストして」「手順書だけで完遂できるか試して」と言った時に使用する。 手順の追加や組み替え、新しいコマンドの組み込み、ガイドラインの判断基準の変更のように、skillのワークフロー構成や判断基準に影響する変更をした後に、実行をユーザーに提案する。

ソフトウェアテストを書く時の心得。何をtestし、何をtestしないかの判断基準と、アクセス権限のtestの書き方、落ちたtestの直し方、fixtureの仮名を定める。 testを書く時、足すか決める時、落ちたtestを直す時、レビューする時に読み込む。

Chrome/ブラウザ拡張機能開発の包括的ガイド。WXTフレームワーク、Manifest V3、Chrome API、テスト手法をカバー。Use when: ブラウザ拡張機能を作成・修正する時。Triggers on 'ブラウザ拡張機能', 'Chrome拡張', 'browser extension', 'WXT', 'content script', 'service worker'.

仕様書/実装計画書をもとに、計画を見出し単位のステップへ分解し、各ステップで「テスト作成→レビュー→収束ならコミット」「実装→レビュー→収束ならコミット」(必要なら「ドキュメント修正→レビュー→収束ならコミット」)を自律反復する。ユーザーから自律進行(止まらず最後まで進める・ステップを自動で回す等)の明示的な指示があったときだけ使う。単に計画に沿って実装してほしいだけの依頼(自律進行の指示を伴わない)では使わない。レビューは codex-review-loop、コミットは commit に委譲し、仕様整合(参照の記法・用語規約)はエージェントが直接確認する。

Cloudflare Durable Objects の実装とレビューに使用する。チャットルーム、マルチプレイ、予約システムなどの状態を持つ協調処理、RPC methods、SQLite storage、alarms、WebSockets、Workers統合、wrangler設定、Vitestでのテストを扱う。事前学習の知識より最新のCloudflare docsの取得を優先する。

Cloudflare WorkersのCI(自動検査)とCD(自動デプロイ)を、Workers Buildsまたは外部CI/CDから案件に合う1経路だけ選び、無料枠に収まる最小構成で構築・運用するためのスキル。 「CIを入れて」「CDを組んで」「自動デプロイしたい」「GitHub Actions」「ワークフロー」「テストを自動で回したい」 「マージしたら勝手に公開されるようにして」「デプロイを自動化して」「CIが落ちた」「Actionsが失敗する」 「デプロイの手作業をなくしたい」「Cloudflareの設定が分からない」「非エンジニア向け手順を作って」などの文脈で必ず使用する。 デプロイ先が Cloudflare Workers の場合は Skill cloudflare-secure-deploy を併用する(D1マイグレーションの扱いが最重要)。ブランチ・PR・タグの規約は Skill solo-git-flow に従う。手動デプロイを繰り返している状況を見つけたら、依頼されていなくても このスキルの §0 を読んで導入可否を判断すること。

このリポジトリでワークツリーを作成・利用・片付けるときの手順。git wt でブランチ用のワークツリーを作るとき、ワークツリーでサービス起動・DB操作・テストを行うとき、作業が終わってワークツリーを削除するときに使う。

Angular コードを生成し、アーキテクチャ ガイダンスを提供します。プロジェクトの作成、コンポーネント、またはサービスを作成するとき、または反応性（シグナル、linkedSignal、リソース）、フォーム、依存性注入、ルーティング、SSR、アクセシビリティ（ARIA）、アニメーション、スタイリング（コンポーネント スタイル、Tailwind CSS）、テスト、または CLI ツール作成のベスト プラクティスについてトリガーされます。

本番と同じ失敗を本番前に検出するためのテスト階層設計スキル。 DB方言差、実依存関係、永続化確認、timezone差、packaging整合性、 adversarial regressionをunit/integration/e2e/smoke/packagingに 適切に割り振り、PR CIで最低限の本番同等性を保証する。 Use when designing production-parity tests, closing test blind spots, building smoke suites for real dependencies, verifying persistence beyond UI success, or creating adversarial regression backlogs.

事業継続計画（BCP）と災害復旧計画（DRP）の策定支援スキル。ビジネスインパクト分析、リスク評価、復旧戦略策定、 BCP/DRP文書作成、テスト・訓練計画を提供。ISO 22301準拠。 Use when developing business continuity plans, disaster recovery strategies, or conducting business impact analysis. Triggers: "BCP", "business continuity", "disaster recovery", "DRP", "business impact analysis", "BIA", "contingency planning".

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

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

E2E テストを実行する手順に沿って E2E を動かす際に発火させる。実行環境のセットアップ、実行コマンド、CI 統合、実行が失敗したときの対処など、E2E を「動かす」場面で使う。触る範囲に対応するプロジェクトの実行手順を探して従わせる入口。E2E spec を書く・レビューするのとは別の責務 (spec の書き方は扱わない)。

設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。

8フェーズの開発サイクル：機能リクエスト、現状確認、機能計画、フロントエンド、バックエンド計画、バックエンドコード、テスト、ユースケース。体系的なソフトウェア開発のための反復フレームワーク。

既存のパイプライン、個別プロジェクトフォルダ、ドキュメント構造、またはソフトウェアスタックを改善、改修、再構築するための構造化された6ステップのプロシージャ。「pipeline optimizer」（ソフトウェア、研究、ゲーム開発パイプラインなど、トピック全体のパイプライン対象）または「project-folder optimizer」（単一のソフトウェアツールや論文プロジェクトなど、パイプライン内の個別プロジェクトフォルダ対象）として呼び出し可能。「パイプラインXを改善する」、「スタックを最適化する」、「Yを再構築する」、「改修」、「パイプラインのリファクタリング」、「プロジェクトフォルダのクリーンアップ」、「フォルダ構造の改善」、「規約の統一」、「ドキュメントの統合」、「既存システムへの統合」、または確立された構造に対する実質的な介入タスクで起動。既存資産の調査、目的の明確化、理想像のスケッチ、ギャップ計画、経験的課題の特定、および新しいサブエージェントによる再テストを提供。並行標準の発生、重複、パイプラインの破綻を防止。

体系的な 6 段階デバッグプロトコル。クイックチェック、孤立テスト、20分ルール、バグレポートテンプレートを備えた構造化アプローチ。

タスクが明確で小さい変更を Implement → Review で進める。バグ修正、小機能、設定、文書など、計画や振り返りを別 artifact にする必要がない作業に使う。レビューとテストは実差分のリスクに応じて選ぶ。

実装済みコードを、親から渡された受入条件と検証範囲に沿って確認する。既存テストと必要なアドホック確認の結果を、共通のCOVERAGE/VERDICT契約で返す。ユーザーが /tester と入力したら必ず使う。

ScalarDB Cluster および ScalarDB Analytics のアーキテクチャ、サイジング、構成を見積もるスキル。 性能要件、可用性要件、クラウド環境からScalarDB Cluster Pod数、Kubernetes構成、 バックエンドDB、API Gateway、監視システム等の全体構成を見積もる。 ScalarDB Analyticsを使用する場合はEMR/Databricksのサイジングも含む。 使用タイミング: - 「ScalarDBのサイジングを見積もりたい」「ScalarDB環境を構築したい」 - 「ScalarDB Clusterの構成を決めたい」「ScalarDBの費用を算出したい」 - 「開発/テスト/ステージング/本番環境のScalarDB構成」 - CI/CD、Blue/Green、Canary Deploymentを含む本番環境設計 - 「ScalarDB Analyticsを使いたい」「分析クエリ環境を構築したい」 - 「EMR/Databricksのサイジングを見積もりたい」 出力: Markdown形式の見積もり結果 + HTML形式のレポート 費用: USD/JPY両建て（為替レート明記）