app-runtime-verify

Solid

Verify a built mobile or app runtime at runtime: run the app (device, emulator, or headless), read the captured runtime output (native logcat, iOS device log, or the Metro/JS console), classify any runtime errors against a per-stack taxonomy, and decide a PASS/FAIL runtime gate for the slice's acceptance behavior. The run's real output IS the Layer-1 runtime evidence (ADR-0048); a claimed-but-not-shown run is unverified. Capability-routed and MCP-agnostic about how the app is run; React Native/Expo (logcat plus Metro) is the first documented adapter. It verifies and routes fixes, it does not apply them. Use after an app slice is implemented to gate runtime behavior the static checks (typecheck, lint) cannot catch. Do not use to plan a screen (use implementation-plan), to write or fix code (use implement-approved-slice), to triage a failure into a fix size (use incident-triage), to verify a Godot scene (use godot-runtime-verify), or with no implemented app to run.

AI & Automation 6 stars 0 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
28
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

Act as a senior mobile/app engineer running a built app and verifying its runtime behavior before the slice is closed. Goal: Run the implemented app (on a device, an emulator/simulator, or a headless run), capture and read the runtime output, classify any runtime errors against a per-stack taxonomy, and decide a PASS or FAIL runtime gate for the slice's acceptance behavior. This is the "feedback edge" the static checks cannot cover: the crash class the rn-reference-app dogfood chased (`addViewAt ... ReactEditText already has a parent`, a Fabric navigation-teardown crash) never shows up in typecheck or lint, only at runtime on the device. The command's verdict is a Layer-1 runtime gate per the three-layer model (`wos/gate-conditions.md`, ADR-0048): the run's actual output is the evidence, and it feeds Layer 2 (`review-hard`) and Layer 3 (human approval), never replacing them. The command verifies and routes; it does not write or fix code. Mandatory context bootstrap (before any output): <!-- shared:mandatory-context-bootstrap --> - Read these sections in `WORKFLOW_OPERATING_SYSTEM.md` first: - `## LLM execution contract` - `## Editor mode policy` (mode definitions only; the tool mapping table is lazy-loaded in `wos/editor-mode-mappings.md` and needed only for non-Claude-Code tools) - `## Global output contract` (including **Adaptive handoff** and **Mode selection rule**) - `## Cross-cutting workflow guardrails` - **Bootstrap tiers (ADR-0025):** the light-weight comma...

Details

Author
Mozurok
Repository
Mozurok/fhorja.dev
Created
1 months ago
Last Updated
5 days ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

godot-runtime-verify

Verify a built Godot 2D or 3D scene at runtime: run the scene (press-play or headless), read the captured debugger output, classify any runtime errors against a Godot-specific taxonomy, and decide a PASS/FAIL runtime gate for the slice's acceptance behavior. The run's real output IS the Layer-1 runtime evidence (ADR-0048); a claimed-but-not-shown run is unverified. MCP-agnostic about how the scene is run; it verifies and routes fixes, it does not apply them. Use after a Godot slice is implemented to gate runtime behavior the static checks (lint, typecheck) cannot catch. Do not use to plan a scene (use godot-scene-plan), to write or fix the code (use implement-approved-slice or implement-slice-complement), to triage a failure into a fix size (use incident-triage), or with no implemented scene to run.

6 Updated 5 days ago
Mozurok
API & Backend Solid

api-runtime-verify

Verify an implemented backend HTTP surface at runtime: per route, record the request actually made, the HTTP status, the response content-type, and the observed body shape, assert each response against the slice's acceptance behavior, classify the findings, and decide a PASS/FAIL/BLOCKED runtime gate. The probe's real output IS the Layer-1 evidence (ADR-0048): a route whose output is not shown is unverified, never PASS, and an absent tool reports an honest n/a. Capability-routed: it pins no HTTP client and no MCP server, and it routes fixes rather than applying them. Use after a backend slice is implemented to gate route behavior the static checks cannot catch. Do not use to review a contract before implementation (use api-contract-review or graphql-contract-review), to write or fix code (use implement-approved-slice), to triage a failure into a fix size (use incident-triage), for a browser, app, or Godot surface (the sibling verify commands), or with no running backend to probe.

6 Updated 5 days ago
Mozurok
Code & Development Listed

app-verify

Drive a running or deployed web app end-to-end as a real user to catch bugs that automated tests and typechecks miss: pages that return HTTP 200 but render wrong, forms that POST 200 yet never save, stat cards that are hardcoded fakes, reports fed by dead database columns, and silent data-layer failures (access rules hiding rows, swallowed query errors, wrong DB identity or connection) — for any framework and any datastore. Also verifies deployments against the live server: build gate, push, deploy, health check, commit match. Use whenever the user wants to verify prod, smoke test the app, QA the app, test every page or tab, check the app as a user, confirm a deploy shipped, ask if production is healthy, or sweep the whole app for what's broken — even if they never say the word "test", and right after any deploy. Do NOT use for: running an existing unit/integration test suite, fixing a typecheck or build error, scoring code quality (that's a "health" check), reviewing a PR diff, setting up CI, debugging one k

0 Updated 1 months ago
nikhilkyn-png