菜单
Validate runtime behavior with real end-to-end evidence. Use when a change affects an app, browser surface, API, CLI, workflow, integration, dev server, runtime orchestration, or any user-visible behavior that tests and typechecks alone cannot prove.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Fix failing CI when the user asks for a CI repair or a required check goes red during PR work. Establish causal ownership before editing: repair current-PR failures in place, isolate target-branch regressions in a separate worker and PR, classify provider incidents and flakes without inventing code changes, then state merge order and confidence.
Build toward the model the code should have, not the one it currently has. Use when implementing, refactoring, addressing review feedback, deleting stale paths, evaluating tests as contracts, or deciding whether to reshape code instead of fitting into it.
Write high-signal automated tests and avoid test theatre. Use when adding, reviewing, deleting, or restructuring unit, integration, property, golden, fixture, or regression tests.
Ingest a meeting transcript into a markdown wiki -- creating cleaned transcripts, structured meeting notes, person profiles, term stubs, and feature evidence. Use when the user asks to "ingest meeting notes," "process a meeting," "add meeting to wiki," "create meeting notes from transcript," "process Granola notes," or provides a transcript to be turned into wiki content. Works with any domain wiki that follows the markdown content directory pattern.
Set up a markdown-based wiki knowledge base in a repository. Creates the directory structure, writing guide, AGENTS.md configuration, and initial content templates. Use when the user asks to "set up a wiki," "create a knowledge base," "start a wiki," "initialize wiki content," "set up a second brain," or wants to create a structured markdown content system for learning and research in their project.
Create deeply researched wiki term entries with web research, practical examples, and cross-references. Use when the user asks to "create a wiki term," "write a term entry," "add a glossary definition," "research a concept," "define this term," or when a meeting ingestion identifies terms to create. Produces comprehensive entries with external citations, worked examples, and detailed breakdowns. Works with any domain wiki using markdown content.
| name | testing-end-to-end |
| description | Validate runtime behavior with real end-to-end evidence. Use when a change affects an app, browser surface, API, CLI, workflow, integration, dev server, runtime orchestration, or any user-visible behavior that tests and typechecks alone cannot prove. |
The rule is evidence over confidence. Typecheck and lint verify code correctness, not feature correctness. They can pass while a page throws at runtime, a query is not deployed, a form never writes back, or a dev command starts on the wrong port.
When a change touches runtime behavior, exercise that behavior end to end before calling the work done.
Runtime surfaces include browser routes, pages, components, shared UI, forms, navigation, auth-gated flows, loading/empty/error states, APIs, CLI commands, workers, provider integrations, generated artifacts, dev servers, build-system changes, runtime upgrades, local proxies, port routing, process lifecycle, and orchestration scripts.
Unit tests, static screenshots, typecheck, lint, and API calls do not replace runtime proof for a browser-testable workflow. They can complement it.
Before reporting success, prove the changed path in the real surface:
If a user can reach the changed behavior in a browser, run the app and drive it in a real browser.
At minimum, cover:
The capture must visibly include the UI change or interaction state being verified, and it must come from the actual mounted product UI for the relevant route, account, data, and state. Fake, unmounted, unauthenticated, fixture-rendered, mocked, reference, Storybook, or component-only screenshots do not satisfy product evidence unless the task is explicitly about that isolated surface.
For existing UI, capture comparable before/after evidence when practical. For new UI, capture the new state. For motion, transitions, drag-and-drop, optimistic updates, or sequenced state, capture a short clip.
For backend/API/CLI work, call the real endpoint or command path that exercises the change. For writes, cross-check with a read after the write. For permission or runtime boundaries, exercise both allowed and denied paths when that is the changed behavior.
If a browser consumes the changed backend shape, run the backend/API check and a representative browser flow. New unit tests for the backend code do not prove the browser path still works under real interaction.
Dev-tooling, build-system, package-manager, runtime, local proxy, port-routing, and process-lifecycle changes also need an end-to-end smoke. Start the changed command, wait for readiness or capture the exact blocker, exercise the primary local endpoint if it boots, terminate intentionally, and verify no owned processes or listeners remain where applicable.
A browser navigation failure, auth bounce, server refusal, missing seed data, provider config gap, stale backend binding, or local port issue is a symptom to diagnose, not a completed blocker.
Before calling verification blocked, try the project's documented recovery path: restore the app/server, confirm the selected URL and port, recover auth if safe credentials or documented flows exist, refresh provider/backend state, seed the needed data, and try an allowed fallback browser/tool path. Only stop when the blocker is genuinely outside the agent's control.
Finish with the route/command/API exercised, the actions performed, where the evidence lives, the console/log/error result, and what could not be completed. Do not claim end-to-end verification passed if only tests, typecheck, lint, or a static render ran.
