openspec-verify

Validates OpenSpec changes by running Gradle builds, lint checks, and unit tests on Android projects.

1|Updated Jun 27, 2026
One-click install
npx skills add https://github.com/TE-QuanBZhang/skills-pool --skill openspec-verify-te-quanbzhang
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openspec-verify
Source: https://github.com/TE-QuanBZhang/skills-pool/tree/main/ai-coding/skills/openspec-verify
Command: npx skills add https://github.com/TE-QuanBZhang/skills-pool --skill openspec-verify-te-quanbzhang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After implementing an OpenSpec change in an Android project, you need to confirm the code compiles, passes tests, and meets quality standards before archiving. This Skill automates that verification workflow using the project's Gradle wrapper. ## Core Features & Use Cases - Module-Scoped Verification: Uses CodeGraph exploration to identify affected Gradle modules and runs targeted tasks like :module:assembleDebug and :module:testDebugUnitTest instead of slow project-wide builds. - Quality Gate Checks: Detects and runs only the static analysis tools configured in the project (ktlint, detekt, spotless, Android Lint), marking missing ones as N/A. - Structured Reporting: Produces a pass/fail verification report covering static analysis, lint, compilation, and unit tests with suggested fix commands. - Use Case: After implementing a login feature change, run verification to confirm :feature:login compiles, passes its 42 unit tests, and has no lint errors before archiving the change. ## Quick Start Verify the OpenSpec change named add-user-auth by running the Gradle build, lint, and unit tests for the affected modules.

Frequently Asked Questions about openspec-verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify an OpenSpec change in an Android project?

Run the verification workflow with the change name, which checks status via openspec CLI, identifies affected Gradle modules with CodeGraph, then runs assembleDebug, lint, and testDebugUnitTest scoped to those modules. Results are reported as a structured pass/fail summary.

How to run unit tests for only affected Gradle modules?

Use module-scoped Gradle tasks like ./gradlew :feature:login:testDebugUnitTest instead of project-wide test tasks. CodeGraph exploration identifies which modules the change touched so verification stays fast and targeted.

Does this verification run ktlint, detekt, and spotless automatically?

It detects which quality plugins exist in the project's build scripts and runs only those tasks, marking missing ones as N/A. ktlint issues can often be auto-fixed with ./gradlew :module:ktlintFormat and spotless with :module:spotlessApply.

Can I run instrumented Android tests during verification?

No, instrumented tests (connectedDebugAndroidTest) are out of scope because they require a device or emulator. They are only suggested as a manual follow-up when the change affects UI or integration behavior.

What happens if CodeGraph returns no results during verification?

Verification proceeds without it since CodeGraph is an enhancement, not a blocker. The workflow falls back to ripgrep and direct file inspection for XML, manifest, and Gradle script analysis.