/e2e
Selects and runs the appropriate AgentsMesh end-to-end suite for Web, Desktop, MCP, or iOS, including worktree-specific environment setup and browser-level verification. Use when a change needs E2E coverage, a user asks to execute or diagnose an E2E test, or a cross-service
$ npx -y skills add AgentsMesh/AgentsMesh --skill e2e --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/e2e
Context preview
The summary Claude sees to decide when to auto-load this skill.
Selects and runs the appropriate AgentsMesh end-to-end suite for Web, Desktop, MCP, or iOS, including worktree-specific environment setup and browser-level verification. Use when a change needs E2E coverage, a user asks to execute or diagnose an E2E test, or a cross-service
SKILL.md
e2e.SKILL.mdname: e2e
description: >-
Selects and runs the appropriate AgentsMesh end-to-end suite for Web,
Desktop, MCP, or iOS, including worktree-specific environment setup and
browser-level verification. Use when a change needs E2E coverage, a user
asks to execute or diagnose an E2E test, or a cross-service workflow must be
verified against the real development stack.
AgentsMesh E2E
Run the smallest real end-to-end test that proves the requested behavior, then expand coverage in proportion to the change.
Invariants
- Use the current worktree's generated `deploy/dev/.env`; never assume fixed
ports or container names.
- A UI requirement must be verified by a browser or app UI test. Do not replace
it with a raw API request.
- Start the development stack only when the selected suite needs it. Record
whether this workflow started the stack before deciding whether to clean it.
- Authentication uses Connect-RPC. Never restore the removed REST login route;
read `references/connect-rpc.md` when testing auth or proxy routing.
- Do not claim a suite passed unless its command completed successfully.
- Preserve test artifacts and relevant service logs when a failure occurs.
Workflow
1. Inspect the requested behavior and changed files. 2. Select the suite from `references/test-matrix.md`. Read the selected target's BUILD file, config, and nearby tests before running it. 3. Reuse a healthy existing stack. Otherwise start `//deploy/dev:up` for Web flows or `//deploy/dev:backend_only` when frontends are not required. 4. Load `deploy/dev/.env` with automatic export enabled so Bazel can forward the worktree-specific values:
set -a
source deploy/dev/.env
set +a
5. Run the narrowest relevant spec or test filter first. If it passes, run the owning target when the blast radius warrants it. 6. For UI behavior, inspect the rendered state and interaction result through the suite's browser/app assertions. Capture a screenshot or trace when the visual result is central to the bug. 7. On failure, report the failing assertion and inspect the applicable service logs and test artifacts listed in the test matrix. 8. Clean the stack with `bazel run //deploy/dev:clean` only when this workflow started it and no concurrent work depends on it.
Result
Report the exact target and filter, actual worktree ports used, pass/fail status, failing evidence when applicable, and any coverage that could not be run with the reason.
Read more
name: e2e description: >- Selects and runs the appropriate AgentsMesh end-to-end suite for Web, Desktop, MCP, or iOS, including worktree-specific environment setup and browser-level verification. Use when a change needs E2E coverage, a user asks to execute or diagnose an E2E test, or a cross-service workflow must be verified against the real development stack.
AgentsMesh E2E
Run the smallest real end-to-end test that proves the requested behavior, then expand coverage in proportion to the change.
Invariants
- Use the current worktree's generated `deploy/dev/.env`; never assume fixed
ports or container names.
- A UI requirement must be verified by a browser or app UI test. Do not replace
it with a raw API request.
- Start the development stack only when the selected suite needs it. Record
whether this workflow started the stack before deciding whether to clean it.
- Authentication uses Connect-RPC. Never restore the removed REST login route;
read `references/connect-rpc.md` when testing auth or proxy routing.
- Do not claim a suite passed unless its command completed successfully.
- Preserve test artifacts and relevant service logs when a failure occurs.
Workflow
1. Inspect the requested behavior and changed files. 2. Select the suite from `references/test-matrix.md`. Read the selected target's BUILD file, config, and nearby tests before running it. 3. Reuse a healthy existing stack. Otherwise start `//deploy/dev:up` for Web flows or `//deploy/dev:backend_only` when frontends are not required. 4. Load `deploy/dev/.env` with automatic export enabled so Bazel can forward the worktree-specific values:
set -a source deploy/dev/.env set +a
5. Run the narrowest relevant spec or test filter first. If it passes, run the owning target when the blast radius warrants it. 6. For UI behavior, inspect the rendered state and interaction result through the suite's browser/app assertions. Capture a screenshot or trace when the visual result is central to the bug. 7. On failure, report the failing assertion and inspect the applicable service logs and test artifacts listed in the test matrix. 8. Clean the stack with `bazel run //deploy/dev:clean` only when this workflow started it and no concurrent work depends on it.
Result
Report the exact target and filter, actual worktree ports used, pass/fail status, failing evidence when applicable, and any coverage that could not be run with the reason.
The AI Agent Workforce Platform. Run a hundred AI coding agents across your own machines — schedule, isolate, and steer them all from one console.
Repo: AgentsMesh/AgentsMesh
Other skills on agentsmesh.
- /arch-check
架构与实现审查 —— 基于「概念建模 → 职责划分 → 机制/策略分离 → 因果与不变量 → 属性建模 → 模块化 → SOLID → GRASP → YAGNI」的全维度审查,带置信度门控与假阳性抑制(对抗"过度工程建议"这类 AI slop)。触发于:要求 review/审查架构、检查目录结构/依赖关系/职责划分、重构前评估、技术债盘点、判断是否过度设计,或问「这个设计合理吗 / 该怎么拆 / 有没有循环依赖 / 这个改动架构上 OK 吗」。一律按最高强度审查。用法:`arch-check [范围]
Open skill - /gh-merge
Completes the AgentsMesh GitHub pull-request workflow: commits scoped changes, rebases on the authoritative GitHub branch, opens or reuses a PR, monitors required checks, fixes failures, and merges only after verification. Use when the user asks to merge, submit, or land
Open skill - /github-gitlab-mirror
Audits or synchronizes the authoritative GitHub main branch to the internal GitLab mirror without importing GitLab-only history back into GitHub. Use when checking GitHub/GitLab consistency, updating the internal mirror, or resolving a divergence between the two remotes.
Open skill - /worktree
Creates or reuses an isolated AgentsMesh Git worktree from a verified base branch, preserves existing changes, and optionally starts the worktree-scoped development environment. Use when the user asks for a new worktree or isolated work for a feature, fix, investigation, or
Open skill

