Meticulous Test

作者 alwaysmeticulousdeb5e45e6e56無授權條款10 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫今天更新

Run a Meticulous test run after implementing a frontend change, then hand off to the `meticulous-review` skill to classify each visual change as intended or unintended. Uploads the build once — the same build can be re-triggered against different bases without rebuilding — and it works with uncommitted changes. Use when implementing a feature autonomously end-to-end before creating a PR.

AI 產生的概覽

對前端變更執行 Meticulous 視覺測試,並交由審查環節判定視覺差異。

功能
此技能引導代理以 Meticulous 測試前端變更:依 CI 設定建置前端、將建置產物上傳為可重複使用的部署,並針對某個基準提交觸發測試執行。接著把取得的 testRunId 交給 meticulous-review 技能,由它將每項視覺變更分類為預期內或非預期。內容也說明了未提交變更、臨時提交,以及同一個建置針對不同基準重複觸發的情況。
適用情境
適用於自主端到端實作前端功能,並希望在建立拉取請求前驗證視覺變更的情境。也適合需要在無須重新建置的情況下,讓同一個建置針對一個或多個基準提交進行測試的工作流程。
執行需求
需要 Meticulous CLI 或 MCP 指令、前端建置產物(資源檔案或 Docker 映像),以及存取儲存庫中 CI 設定與 git 歷史的權限。觸發執行時必須提供基準提交。此技能不含指令碼,僅為說明性指示。

To test a frontend change using Meticulous, follow the workflow below step by step, using the CLI or MCP commands as described.

Before starting, run the meticulous-cli-update skill to ensure the Meticulous CLI and skills are up to date — unless it has already run earlier in this conversation, in which case skip it.

If you are already given a test run id, skip to Step 4.

Step 1 -- Build the frontend

  1. Find out what build artefact Meticulous expects by checking your CI config for the corresponding step:
    • GitHub: .github/workflows/*.yml for uses: alwaysmeticulous/report-diffs-action/upload-assets@v1 (build assets) or upload-container@v1 (docker image)
    • GitLab: .gitlab-ci.yml (or an included .gitlab/ci/*.yml) for npx @alwaysmeticulous/cli ci upload-assets (build assets) or ci upload-container (docker image)
    • Bitbucket: bitbucket-pipelines.yml for the same npx @alwaysmeticulous/cli ci upload-assets / ci upload-container step
  2. Build the frontend following the same instructions as used in that CI config.

Step 2 -- Upload the build

Register the build as a reusable deployment with agent upload-build. This uploads the artefact and prints a deploymentId to stdout — it does not trigger a run yet.

bash
# CLImeticulous agent upload-build --appDirectory <path-to-build>     # assetsmeticulous agent upload-build --localImageTag <image-tag>        # container
# MCP (not 1:1 — request an upload URL, upload the artifact yourself, then register it)request_asset_upload(size=<zipByteSize>)      # or request_container_upload() — no required args# ... upload the zip/image to the returned URL/registry yourself ...register_asset_build(uploadId="<id>", commitSha="<sha>")      # or register_container_build(uploadId="<id>", commitSha="<sha>")
  • --appDirectory points to the build output directory (e.g. a dist/ subfolder); --localImageTag is the local Docker image tag. The build mode is auto-detected.
  • The build's commit defaults to the local git HEAD. If the working tree is dirty, it is captured as an ephemeral commit (printed as commitSha (local, ephemeral due to dirty working tree): …) — see the uncommitted-changes note below.
  • Untracked files are rejected (they can't be captured) — git add them first.
  • Capture the deploymentId from stdout (pass --verbose to also see progress on stderr).

Step 3 -- Trigger a test run

Trigger a run for the deployment, comparing against a base. Run it from the repo directory to infer both the base (merge-base with the origin default branch) and the git diff automatically:

bash
# CLImeticulous agent trigger-test-run --deploymentId <deploymentId>
# MCP (never infers `baseSha`/`gitDiffOutput` — pass them explicitly — and always returns immediately without waiting for the run to finish)trigger_test_run(deploymentId="<deploymentId>", baseSha="<sha>")
  • A base is required. It's auto-inferred from the current directory, or pass --baseSha <sha> (and optionally --gitDiffOutput) to set it explicitly.
  • Omit --deploymentId to use the most recent deployment already uploaded for the local HEAD commit instead — this requires a clean working tree (no uncommitted changes).
  • The command blocks until the run finishes by default and prints the testRunId to stdout; the final status is Failure when visual differences were detected (a normal completed verdict, not an error). Pass --dontWaitForTestRunToComplete to return as soon as the run is triggered.
  • One build, many bases: the same deploymentId can be re-triggered against different bases — just run agent trigger-test-run again with a different --baseSha. No rebuild or re-upload needed.

Note the testRunId from the output.

Step 4 -- Review the visual changes

Follow the meticulous-review skill, passing the testRunId from Step 3. It fetches the diff summary, inspects representative screenshots / DOM diffs / timelines, and produces a final report classifying each visual change as intended or unintended.

Uncommitted changes: if you built/tested with a dirty working tree, the run is recorded against an ephemeral commit that is not your HEAD (and isn't pushed). Commands that resolve a run from the local checkout — meticulous-review / agent test-run-diffs run with no --testRunId — won't find it by commit, so always pass the explicit --testRunId to the review step in that case.

來源與署名

來源:alwaysmeticulous/skills位於skills/meticulous-test提交deb5e45

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架