Agent skill · software engineering · lobehub
acceptance
End-to-end verification and self-evidence for a delivery in any repository, with or without a preconfigured verify plan. Discover an existing plan when one was handed to this run; otherwise author checks and publish a standalone acceptance. Pick the proving surface (CLI / web / desktop / iOS Simulator), drive the real product, capture visually confirmed evidence, and publish a round with the lh CLI. Triggers on 'verify the task', 'collect evidence', 'prove it works', 'upload evidence', 'verify plan', 'requiredEvidence', 'local test', 'manual test', 'test report', 'test with cli', 'test in electron', 'test desktop', or any local end-to-end verification task. Needs no ambient ids, and never depends on running inside a LobeHub conversation.
Why this skill is useful
Adds specific commands and workflows for verifying delivery in LobeHub that the AI wouldn't reliably generate on its own.
What it needs
Requires lh installed locally. About 11k tokens when loaded. Last updated 2026-08-07. 81,352 stars on the source repository.
What this skill does
Acceptance (Builder Self-Evidence) You are the builder for a delivery. A separate review step judges it against a plan — checks you author, or a verify plan handed to this run. A check that declares requiredEvidence cannot pass on your text alone: a missing artifact marks it uncertain and holds the delivery. Independent acceptance review (first round only) The primary checks the environment, writes the plan, executes cases, inspects evidence, repairs failures, and publishes. Use one acceptance-checker agent at two points in the first acceptance round: give at most two feedback responses on the plan and cases before execution, then perform exactly one quick report/evidence check against the agreed criteria before publishing. A second plan check is optional, only to check the primary's revisions; there is no third plan-feedback response. Count the two stages separately. After either stage's limit, the primary owns remaining corrections and verification. The acceptance-checker is the plan gate — never ask the user to approve a plan; ask the user only for a user-owned prerequisite or a product decision that changes the plan. In both stages, the primary supplies an explicit file list and the relevant diff text or prepared diff artifact paths. The acceptance-checker limits code reading to these materials; it must not run git diff or discover its own scope. This does not restrict inspection of the plan, report, or evidence. During evidence review, use it only to identify the updates and the agreed cases whose evidence needs checking; the core task is checking the report against the plan and artifacts. Do not reopen requirements, expand into code review, or investigate implementation details. Return contradictions to the primary for explanation or repair. Follow-up rounds have no acceptance-checker: the primary re-runs, inspects, and publishes itself. Do not delegate execution or require per-case approval. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills lobehub/acceptance