npx claudepluginhub kesteva/soloflow --plugin soloflow-dev<screen or feature to verify># /soloflow:verify You are running standalone visual verification. The user wants to visually check a screen or feature without running the full workflow. The target to verify is: **$ARGUMENTS** ## Step 0: Check initialization If `.soloflow/` does not exist, report: "SoloFlow not initialized. Run `/soloflow:init` first." and stop. ## Step 1: Check Availability Pick a mobile path **once** per the **Path Selection** recipe in `skills/visual-verify/SKILL.md`, then probe web. **For mobile verification (MCP preferred, CLI fallback):** 1. **Probe MCP.** Call `mcp__maestro__list_devices`. I...
/verifyRuns verification checks on codebase including types (mypy), lint (ruff), tests (pytest cov), security (pip-audit), secrets, prints, and git status. Outputs summary report with pass/fail and readiness status.
/verifyVerifies all git-changed files for common mistakes, logic errors, and security issues, outputting per-file summaries with issue counts and severity ratings (CRITICAL, WARNING, INFO).
/verifyRuns 7-phase verification pipeline for .NET projects: build, diagnostics, antipatterns, tests, security, format, diff review. Outputs PASS/FAIL per phase with actionable fixes; short-circuits critical failures.
/verifyVerifies current codebase state with sequential build, type, lint, test, console.log audit, and git status checks. Produces concise PASS/FAIL report with PR readiness.
/verifyVerifies implementations or changes using parallel specialized agents with 0-10 grading, full reports across tests/security/quality, and improvement suggestions.
/verifyRun full R verification loop before committing. Checks build, lint, style, test coverage, and code quality.
Share bugs, ideas, or general feedback.
You are running standalone visual verification. The user wants to visually check a screen or feature without running the full workflow.
The target to verify is: $ARGUMENTS
If .soloflow/ does not exist, report: "SoloFlow not initialized. Run /soloflow:init first." and stop.
Pick a mobile path once per the Path Selection recipe in skills/visual-verify/SKILL.md, then probe web.
For mobile verification (MCP preferred, CLI fallback):
mcp__maestro__list_devices. If it returns a result, set USE_MAESTRO_MCP=true. If the tool is unbound or the call errors, continue.which maestro via Bash. If not found AND MCP probe failed, report: "Maestro is not available via MCP or CLI. Install the CLI with: curl -Ls 'https://get.maestro.mobile.dev' | bash, or register the MCP server with: claude mcp add --scope user maestro maestro mcp."IOS=$(xcrun simctl list devices booted 2>/dev/null | grep -c Booted || true)
AND=$(adb devices 2>/dev/null | awk '$2=="device"' | wc -l | tr -d ' ' || true)
If both are zero, report: "No simulator/emulator booted. Start one with: open -a Simulator (iOS) or emulator -avd <name> (Android)." (MCP's start_device can also boot one for you if you prefer — but the user likely wants an explicit choice.)For web verification:
which npx via Bash.If neither mobile nor web tooling is available, report this to the user and stop.
maestro/, .maestro/, test/maestro/ that match the targetStay on the path chosen in Step 1. See skills/visual-verify/SKILL.md for exact tool signatures and command patterns.
MCP path:
mcp__maestro__run_flow_files(device_id, flow_files=[<path>]) and report the per-step results.launchApp + tapOn / inputText) and call mcp__maestro__run_flow(device_id, flow_yaml=<body>).mcp__maestro__inspect_view_hierarchy(device_id) to check element presence and layout (CSV, ~50 tokens).mcp__maestro__take_screenshot(device_id) only if visual appearance needs checking (limit to 3).CLI path:
maestro test <flow.yaml> via Bash and report the exit code + any failing-step output.appId from verification.visual_mobile_app_id or existing flows.launchApp + tapOn / inputText) to /tmp/sf-maestro-*.yaml, run maestro test, remove the file.maestro hierarchy to check element presence and layout (~200–600 tokens plain text).sips -Z 1400, limit to 3):
xcrun simctl io booted screenshot <path>adb exec-out screencap -p > <path>If relevant to the target:
Output a visual verification report:
## Visual Verification Report
- **Target:** {what was verified}
- **Method:** Maestro | Playwright | Both
### Results
- {check 1}: PASS | FAIL — {evidence}
- {check 2}: PASS | FAIL — {evidence}
### Screenshots
- {description of each screenshot taken, if any}
### Issues Found
- {any problems discovered, or "None"}