verify

Engineering Community

Repo stars 357
License GPL-2.0
Author repo woocommerce-ios

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Build the app, launch on simulator, and verify feature behavior via mobile-mcp interaction. Use after making changes to visually…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Step 1: Assess the Environment”, “Step 2: Detect Feature Scope”, “Step 3: Start Mock Server (only if needed)”, “Step 4: Build the App”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name verify directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Step 1: Assess the Environment / Step 2: Detect Feature Scope / Step 3: Start Mock Server (only if needed)” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

E2E Simulator Verification

Build the app, launch it on the iOS simulator, and verify the affected feature areas work correctly by navigating the UI and checking for expected elements.

Read .claude/references/screen-identifiers.md to understand how to identify screens and navigate between them.

Step 1: Assess the Environment

Before setting up anything, determine what's already available:

Simulator: is an iPhone simulator already booted? (xcrun simctl list devices booted | grep iPhone)
App state: is the app already installed? (xcrun simctl listapps <UDID> 2>/dev/null | grep com.automattic.woocommerce)
Session state: launch the app and check the current screen — is the user already logged in (tab bar visible) or on the login screen?

Most verification happens during development where the simulator has a current build and an active session. In this case, you only need to build your changes and re-launch — no mock server or login flow needed.

Use the mocked environment (WireMock + logout-at-launch) only when:

There is no existing session / data on the simulator
You need deterministic mock data (e.g., verifying specific order states)
The user explicitly requests mocked verification

If a mocked environment is not needed, skip Steps 3 and the mock-specific launch args in Step 5.

Step 2: Detect Feature Scope

Determine which features were changed:

git diff --name-only trunk...HEAD

If no diff against trunk, fall back to git diff --name-only HEAD~1.

Read .claude/references/feature-map.json and match changed file paths against pathPatterns for each feature. Collect all matched features. If no features match, skip verification entirely — report which files changed, note that none matched any feature path pattern, and stop (do not proceed to Steps 3-8).

Step 3: Start Mock Server (only if needed)

Use the /mocks skill approach: start WireMock on port 8282 in the background. Verify it's running before proceeding.

Step 4: Build the App

Use the /simulator skill approach to discover a booted simulator UDID.

xcodebuild -workspace WooCommerce.xcworkspace -scheme WooCommerce \
  -destination "platform=iOS Simulator,id=<UDID>" -sdk iphonesimulator \
  build 2>&1 | tail -30

If the build fails, analyze errors and report. The build must succeed — verification requires the current code.

Step 5: Launch App

If using mocked environment, collect launch arguments:

logout-at-launch, disable-animations, mocked-wpcom-api, -ui_testing, -mocks-port, 8282
Append any feature-specific launchArgs from feature-map.json
Mock credentials (for login flow): site http://yourwoosite.com, email t@wp.com, password pw

Launch using xcrun simctl launch (supports launch arguments, unlike mobile-mcp's launch_app):

xcrun simctl launch <UDID> com.automattic.woocommerce <all-args-space-separated>

If using existing environment, launch without mock args:

xcrun simctl launch <UDID> com.automattic.woocommerce

Wait 5 seconds for the app to settle.

Step 6: Navigate and Verify

Use mobile-mcp tools (list_elements_on_screen, click_on_screen_at_coordinates, take_screenshot) to interact with the app.

Consult .claude/references/screen-identifiers.md for screen identification, element lookup, and navigation flows (including login flow when using mocked environment).

For each matched feature from the feature map:

Navigate to the feature's screen following the navigation flows in screen-identifiers.md
List elements to confirm you arrived at the right screen (match primary identifier)
Screenshot and visually assess the screen
Verify the feature's verifyElements from feature-map.json are present
Interact if the feature defines interactions — execute each action

Verification Criteria

The screen loaded (not blank/empty/error)
Expected accessibility elements are present
No crash or unexpected error state visible

Step 7: Report Results

Summarize:

Features verified: list each feature and pass/fail
Screenshots taken: file paths
Missing elements: any expected elements not found
Visual assessment: brief description of what the UI looks like
Issues found: crashes, error states, unexpected behavior

Step 8: Cleanup

xcrun simctl terminate <UDID> com.automattic.woocommerce

If mock server was started, stop it using the /mocks skill approach (kill by port).

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 94 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @woocommerce · GPL-2.0
Fluxly token estimate: Lean
Fluxly setup estimate: Guided setup
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Shell exec
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview verify.preview

# Step 7: Report Results

- **Features verified**: list each feature and pass/fail
- **Screenshots taken**: file paths
- **Missing elements**: any expected elements not found
- **Visual assessment**: brief description of what the UI looks like
- **Issues found**: crashes, error states, unexpected behavior

SKILL.md SKILL.md

# E2E Simulator Verification

Build the app, launch it on the iOS simulator, and verify the affected feature areas work correctly by navigating the UI and checking for expected elements.

Read `.claude/references/screen-identifiers.md` to understand how to identify screens and navigate between them.

## Step 1: Assess the Environment

Before setting up anything, determine what's already available:

1. **Simulator**: is an iPhone simulator already booted? (`xcrun simctl list devices booted | grep iPhone`)
2. **App state**: is the app already installed? (`xcrun simctl listapps <UDID> 2>/dev/null | grep com.automattic.woocommerce`)
3. **Session state**: launch the app and check the current screen — is the user already logged in (tab bar visible) or on the login screen?

**Most verification happens during development** where the simulator has a current build and an active session. In this case, you only need to build your changes and re-launch — no mock server or login flow needed.

**Use the mocked environment** (WireMock + `logout-at-launch`) only when:
- There is no existing session / data on the simulator
- You need deterministic mock data (e.g., verifying specific order states)
- The user explicitly requests mocked verification

If a mocked environment is not needed, skip Steps 3 and the mock-specific launch args in Step 5.

## Step 2: Detect Feature Scope

Determine which features were changed:

```bash
git diff --name-only trunk...HEAD
```

If no diff against trunk, fall back to `git diff --name-only HEAD~1`.

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Step 1: Assess the Environment → Step 2: Detect Feature Scope → Step 3: Start Mock Server (only if needed) → Step 4: Build the App → Step 5: Launch App → Step 6: Navigate and Verify
terms    -> Simulator · App state · Session state · Most verification happens during development · Use the mocked environment · skip verification entirely · If using mocked environment · Mock credentials
files/cmd -> .claude/references/screen-identifiers.md · xcrun simctl list devices booted | grep iPhone · xcrun simctl listapps <UDID> 2>/dev/null | grep com.automattic.woocommerce · logout-at-launch · git diff --name-only HEAD~1 · .claude/references/feature-map.json · pathPatterns · /mocks
body sha256 -> 4cb9e02d28a3