Use when a task, feature, or fix is called done, complete, finished, or fixed, or before a commit, PR, or next task. Not for fact-checking: use verify-both-ways. Not for measuring: use verify-this.
日本語の概要は準備中です。原文の説明を表示しています。
2,446 件 ・ 関連度順
概要と使いどころ
Use when a task, feature, or fix is called done, complete, finished, or fixed, or before a commit, PR, or next task. Not for fact-checking: use verify-both-ways. Not for measuring: use verify-this.
日本語の概要は準備中です。原文の説明を表示しています。
Verify task completion by demonstrating real value: run the new code on real data, show visible results, find gaps between plan and reality. Not about tests/builds — about proving the feature WORKS end-to-end.
日本語の概要は準備中です。原文の説明を表示しています。
Verify which process actually owns a TCP port before assuming your fresh restart succeeded. Use when: (1) you killed an old server and started a new one but behaviour matches the OLD code/data, (2) `pkill -f pattern` returned 0 but old behaviour persists, (3) you embedded a new asset/binary but the served version is stale, (4) any "I just restarted X but I'm getting old results" situation. `pkill -f` matches against the process command line — if the live old process was started with `--port 0` (auto-assigned) and got the port you now want, the pattern won't match it. Always verify with `lsof -i :PORT` before debugging deeper.
日本語の概要は準備中です。原文の説明を表示しています。
This skill should be used when the user asks to "test what I just changed", "/devtest", "smoke test my change", "verify my latest commit", "测一下我刚改的", "看看刚改的功能能不能跑", "跑一下登录看看", or similar requests to verify a recent code change against a running Android or iOS device. The skill reads the git diff, infers the affected UI surface, generates a focused test plan, drives the app via ui-mcp + mobile-mcp, captures logs via log-mcp, and produces a Markdown report via report-mcp.
日本語の概要は準備中です。原文の説明を表示しています。
Fast headless browser for QA testing and site dogfooding. Navigate any URL, interact with elements, verify page state, diff before/after actions, take annotated screenshots, check responsive layouts, test forms and uploads, handle dialogs, and assert element states. ~100ms per command. Use when you need to test a feature, verify a deployment, dogfood a user flow, or file a bug with evidence. Use when asked to "open in browser", "test the site", "take a screenshot", or "dogfood this".
日本語の概要は準備中です。原文の説明を表示しています。
Audits brand/ files for completeness, consistency, and freshness. Use when the agent or user wants to review brand files, audit marketing docs, check brand consistency, verify brand health, or assess what's missing from brand memory. Produces a structured audit report with per-file scores, cross-file contradiction detection, staleness flags, and recommended next skills to run. This is the quality gate for the brand memory system. Also use when someone says 'check my brand', 'brand audit', 'what's missing', 'is my brand ready', 'brand health', 'review my marketing docs', or before running any campaign to verify brand foundations are solid.
日本語の概要は準備中です。原文の説明を表示しています。
Comprehensive fix verification methodology to ensure bugs are truly fixed. Use after implementing any bug fix to verify it works and hasn't caused regressions. Keywords: verify, confirm, test, validate, check, ensure, regression, fixed
日本語の概要は準備中です。原文の説明を表示しています。
Prepare and verify Microsoft Teams desktop chat drafts with Windows UI Automation, stopping before send. Use for Teamsチャット下書き, デスクトップTeams操作, 宛先確認, メッセージ入力, or when Teams Web/CDP is unavailable.
Build a customer-facing Azure Update PowerPoint from Azure Updates MCP results, including customer classification, Japan region stamps, UPDATE Points, speaker notes, and Verify-Pptx gate checks. Use when creating or updating an Azure Update / Azure アップデート customer deck, bootstrapping a new Azure Update PPTX workspace, reviewing Deploy Region support, or re-applying manifest JSON to an existing deck.
Generate a single self-contained HTML file — a horizontal slide deck, a vertical-scroll explainer document, or a fixed-canvas summary image — with zero external runtime dependencies, then verify it mechanically. Use when the user asks for HTMLスライド, 単一HTMLスライド, single-file HTML presentation, ブラウザーで開く説明資料, HTML 説明資料, HTMLサマリ画像, or self-contained HTML, or wants to hand someone a deck or explainer that opens anywhere without PowerPoint. Also use to embed images into such a file or to re-check an existing one. Does not output PPTX.
Plan version scope, verify release integrity (commit↔CHANGELOG, tag↔artifacts), generate changelogs, and run full releases. Use when cutting a release or bumping a version. Trigger on "cut a release", "bump the version", "generate changelog", "release plan", "verify the release".
日本語の概要は準備中です。原文の説明を表示しています。
Run security verification — SAST pattern scanning, DAST against a running app, OWASP Top 10 compliance, CVSS assessment, and adversarial code audit. Use before commit/push or when checking code for vulnerabilities. Trigger on "security scan", "is this vulnerable", "OWASP check", "security verify", "scan for vulnerabilities".
日本語の概要は準備中です。原文の説明を表示しています。
Performs a hallucination check on machine_readable sections by verifying every element traces back to the original legal text. Use this skill proactively when: machine_readable sections have been generated or modified, after /law-generate completes, when reviewing corpus YAML files for legal accuracy, or when user mentions "validate", "verify", or "hallucination check" for law YAML files. Activate automatically after editing machine_readable sections in corpus regulation YAML files.
日本語の概要は準備中です。原文の説明を表示しています。
Verify code or product claims after changes using fresh, risk-matched evidence. Use before saying a bug is fixed, tests pass, requirements are met, or a branch is ready.
日本語の概要は準備中です。原文の説明を表示しています。
Build/test/lint verification pass for this Flutter app — runs codegen, analyze, test, then iOS + Android native builds in parallel, then `dart format`. Does NOT commit anything; leaves the working tree dirty so the user can review and commit on demand. Used at the end of the prd → techspec → tasks → implement-tasks-sequence flow before `pr-review`, and can also be invoked manually when the user says "verify build", "run full verification", or "check everything".
日本語の概要は準備中です。原文の説明を表示しています。
Phase 3 of the feature-pipeline suite. Run this after /fp-implement has pushed all commits and printed the M2 stop hook. Spawns a sandboxed sub-agent (HEAVIER) in an isolated worktree to run RED/GREEN tests against the PR diff and post a structured review comment. Use when you need an independent agent to verify correctness of implementation changes before CI runs — especially for schema mutations, CLI surface changes, or doc-touching commits. Triggers on: "review the PR", "run sandbox review", "fp-review", "Phase 3", "check the implementation", "validate the changes", "run tests on the PR", or any instruction to verify what /fp-implement just pushed.
日本語の概要は準備中です。原文の説明を表示しています。
Top-level orchestrator for the Gaia Skill Tree evidence verification pipeline. Run this when you want to do a full evidence pass — collecting raw sources, verifying live GitHub star counts, running Phase 2B benchmark-source verification, adversarially auditing for quality/formatting issues, and checking that every URL is reachable — all in one coordinated sequence. Trigger phrases: "run the evidence pipeline", "full evidence pass", "verify evidence", "evidence verification pipeline", "run ev-pipeline", "check all evidence", "audit the data lake", "evidence quality sweep", "refresh evidence", "validate evidence sources". Also aliased as /evidence-verification-pipeline. Use the individual sub-skills (ev-collection, ev-star-verification, ev-adversarial-audit, ev-link-validation) only when you need to re-run one phase in isolation; for end-to-end work, always start here.
日本語の概要は準備中です。原文の説明を表示しています。
Canonical entry point for the full Gaia evidence verification pipeline. Invoke as /evidence-verification-pipeline or /ev-pipeline — both names trigger this skill. Use whenever you need to run the evidence phases end-to-end: collecting raw evidence from the data lake, verifying live GitHub star counts, running Phase 2B benchmark-source verification, running adversarial auditing for noise and URL errors, and checking link health via Firecrawl. Also use when someone says "run the evidence pipeline", "verify the evidence lake", "audit evidence", "run ev-pipeline", "full evidence check", "pipeline run", "prepare evidence for ingestion", or "refresh the data lake". This is the pre-ingestion step — run it before importing any evidence into the registry.
日本語の概要は準備中です。原文の説明を表示しています。
Generates EditMode and PlayMode tests using NUnit, mapped from GDD Gherkin scenarios. Use when writing tests, validating features, ensuring code quality, or verifying behavior after changes. Triggers on requests like "write tests for this", "test the health system", "add unit tests", "verify this works", "add PlayMode tests", "test this feature", "write integration tests", "make sure this doesn't break", "add test coverage", "TDD this feature", or any task involving test creation, test-driven development, or quality assurance. Maps Given/When/Then scenarios directly to test methods using NUnit assertions.
日本語の概要は準備中です。原文の説明を表示しています。
Run this after every code change in this Vue project, before committing, before opening a PR, or whenever the user says "verify", "check", "lint", "run tests", "build", "audit". Diff audit (router guards, store boundaries, UX, /ui consistency, error handling) → lint → tests + coverage gate → build. Coverage drops → add tests, never lower thresholds. Triggers on "is this ready to commit?", "any issues?", "tests passing?".
日本語の概要は準備中です。原文の説明を表示しています。
Use for questions about a specific flight’s departure or arrival time, including “when’s my flight?” and confirmation of remembered times, plus flight status, delays, and cancellations. Verify the exact dated flight before answering; memory identifies the itinerary but does not verify its current schedule. Use FlightAware to monitor operational changes for an upcoming booked flight when the user directly asks for ongoing monitoring.
日本語の概要は準備中です。原文の説明を表示しています。
ハンズオンで実装したプロダクトを「もし実際にデリバリーするなら」の観点で棚卸しし、足りない知識を学習計画(study-plan.md)に落とすスキル。ローカルで動作確認できる範囲で実装した前提。`/verify-project` 後・ピッチ前に実行してメタ認知してから登壇する。/study-plan で明示起動。
ハンズオンで作った動くアプリを「商品として売り出す」視点で見直し、ペライチのランディングページ(LP)を作る対話スキル。動くアプリを実際に触りながらコピーを練り、最後に frontend-design スキルを自動で呼び出して HTML 実物まで一気に着地させる。標準構成では /verify-project の後に本線として実施する(30〜50分)。/landing-page-design で明示起動。
scope.md をもとに Next.js アプリを projects/<name>/apps/ に実装する対話スキル。MVP を一括生成したあと「完了」で終わらず、想定ユーザー1人になりきって触る → 1サイクル1改善のチューニングを回し続けて体験を磨く。/scope-design の後、/verify-project の前に実行する。/build-app で明示起動。