agent-testing
Agentic end-to-end testing for any project: backend verification via the project CLI, frontend verification via agent-browser (web), and desktop verification via CDP (Electron). Drives the real surface, captures visually confirmed evidence, and publishes a structured report to the LobeHub verify platform. Triggers on 'cli test', 'test with cli', 'verify with cli', 'backend test with cli', 'local test', 'test in electron', 'test desktop', 'manual test', 'test report', or any local end-to-end verification task.
Profile →npx skills add lobehub/lobehub --skill agent-testing --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Agent Testing (Agentic End-to-End Verification) enables end-to-end testing across backend, frontend, and desktop surfaces. It drives real surface verification, captures visually confirmed evidence, and publishes a structured report to the LobeHub verify platform. It triggers on a range of test-related phrases such as 'cli test', 'test with cli', 'verify with cli', 'backend test with cli', 'local test', 'test in electron', 'test desktop', 'manual test', 'test report', or any local end-to-end verification task. The concrete project-specific start/stop commands, ports, auth, surfaces, and probes come from an adapter described in .agents/acceptance/PROJECT.md.
How it works
- The skill organizes test runs into three phases: PLAN (Steps 0–2) → EXECUTE (Steps 3–6) → FINISH (Step 7).
- It requires the environment state and execution plan to be confirmed before Execute.
- Phase 1 focuses on grounding the test target, reading living logs, and validating readiness. It reads generic and project-specific living logs to guide decisions.
- Step 0 grounds the target from user input or infers a candidate, then asks a structured confirmation question if inferred.
- Step 2 ensures environment readiness: dependencies installed, dev services up, per-surface auth status, and screen-capture preflight for OS-based surfaces.
- The actual per-step commands come from the project adapter file noted as
.agents/acceptance/PROJECT.md; this skill provides the process, evidence discipline, and surface methodology. - If the project adapter file is missing, an adapter bootstrap is performed as described in the referenced references. Execution proceeds only after environment is confirmed.
- Phase 2 (Execute) proceeds with surface selection, verification, reporting, and publication without re-evaluating environment decisions unless the observed state invalidates the plan.
When to use it
- Use when performing end-to-end verification across backend CLI, frontend web (agent-browser), and desktop (Electron/CDP) for any project.
- Triggered by phrases like 'cli test', 'test with cli', 'verify with cli', 'backend test with cli', 'local test', 'test in electron', 'test desktop', 'manual test', or 'test report'.
- Use when there is a need to drive the real surface, capture evidence, and publish a structured report to LobeHub verify platform.
What it can touch
- The concrete start/stop commands, ports, auth, surfaces, and probes are defined in the project adapter at
.agents/acceptance/PROJECT.mdand are executed as part of Phase 2. - This skill reads the living logs and references to guide execution but relies on the project adapter for actual commands.
Caveats
- The project layer (.agents/acceptance/PROJECT.md) provides project-specific commands; if missing, an adapter bootstrap is invoked per references/project-adapter.md.
- Environment and auth handling is surface-scoped; interactive logins should not be driven automatically when not injectable.
- The description notes that the start/stop commands and probes are project-specific and provided by the adapter, not by this skill alone.
# Agent Testing (Agentic End-to-End Verification) One skill for agentic end-to-end testing of any project — backend through the project CLI, web through a browser, desktop through Electron/CDP. Every session follows three phases: ```text PLAN (Steps 0–2) → EXECUTE (Steps 3–6) → FINISH (Step 7) ``` Do not enter Execute until Plan has confirmed both the environment state and the execution plan. Treat Steps 3–6 as one continuous execution phase: select the surface, run the cases, produce the report, and publish it. Always end with Finish unless the user explicitly asks to keep the environment running. **Everything project-specific comes from an adapter, not from this skill.** The concrete start/stop commands, ports, auth, surfaces, and probes for the project under test live in `.agents/acceptance/PROJECT.md`. This skill supplies the process, the evidence discipline, and the surface methodology; `PROJECT.md` supplies the commands. When a step below says "from `PROJECT.md`", read that file for the actual command instead of guessing. See [references/project-adapter.md](./references/project-adapter.md). ## Phase 1 — Plan Confirm what will run and whether the environment is ready before ch
- Phase 1 — Plan
- Step 0 — Ground the target, then read the two living-log layers (mandatory)
- Step 0.5 — Adapter check (mandatory when PROJECT.md is missing)
- Step 1 — Prepare the execution plan
- Step 2 — Confirm environment state and auth (mandatory)
- Phase 2 — Execute
- Step 3 — Pick the surface by change scope
- Step 4 — Run
- Step 5 — Structured report (mandatory deliverable)
- Step 6 — Publish to the LobeHub verify platform (mandatory)
- Phase 3 — Finish
- Step 7 — Teardown and handoff (default: stop what you started)
- Directory map
- Gotchas
caffeinate -dimsu & # prevent display/idle sleep for the run; kill when done Pass the acceptance subject up front so every round is grouped correctly. fill $DIR/result.json (scenario, context, plan[], cases[], summary.conclusion) — the report; palette-open palette-long-list) Strip local-dev CLI overrides so `lh` uses production defaults + the user's real login. env -u LOBEHUB_SERVER -u LOBE_API_KEY -u LOBEHUB_CLI_API_KEY -u LOBEHUB_CLI_HOME \ lh acceptance run ingest "$DIR" --source agent-testing --open --json SUBJECT is task:$TASK_ID, topic:$TOPIC_ID, or document:$DOC_ID lh acceptance run ingest "$DIR" --source agent-testing --subject "$SUBJECT" \ lh task create -n "<project>: <what this run verifies>" -i "<one-line goal>"
What does the agent-testing skill do?
Agentic end-to-end testing for any project: backend verification via the project CLI, frontend verification via agent-browser (web), and desktop verification via CDP (Electron). Drives the real surface, captures visually confirmed evidence, and publishes a structured report to the LobeHub verify platform. Triggers on 'cli test', 'test with cli', 'verify with cli', 'backend test with cli', 'local test', 'test in electron', 'test desktop', 'manual test', 'test report', or any local end-to-end verification task.
How do I install it?
Run `npx skills add lobehub/lobehub --skill agent-testing --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From lobehub/lobehub, a repository with 81,252 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.