Verify Skill

Run a comprehensive quality gate check against a target project or directory. Detects the project language, runs linting, tests, and security scans in parallel, and produces a unified report.

Arguments

• •$ARGUMENTS -- Path to a project directory (default: current working directory).

Phase 0: Consult Knowledge Base

After detecting the project language (Phase 1), check for known issues:

~/.claude/scripts/learning_capture.sh query --language <detected-language> --format llm

If the knowledge base contains relevant antipatterns or insights:

• •Note them in the final report under a "Known Issues" section
• •Flag any linter/test failures that match known antipatterns with their KB ID

This phase is non-blocking — if the knowledge base is empty or the query fails, proceed with the standard verification.

Phase 1: Language Detection

Scan the target directory for indicator files to determine the language(s) in use. Run checks for every detected language.

If no language is detected, report an error and stop.

Phase 2: Tool Selection

Based on the detected language, select the tools for each gate category.

Before running a tool, verify it is installed with command -v <tool>. If a tool is missing, record its category as skip with a message explaining which tool to install, and continue with the remaining tools.

Phase 3: Parallel Execution

Run all three categories (lint, test, security) in parallel using background processes. Capture both stdout and stderr for each. Apply a 120-second timeout per tool.

# Example parallel execution pattern
<lint_command> > /tmp/verify_lint.out 2>&1 &
<test_command> > /tmp/verify_test.out 2>&1 &
<security_command> > /tmp/verify_security.out 2>&1 &
wait

Phase 3.5: Browser Tests (Optional)

After the standard lint/test/security scans complete, check for browser-use E2E tests:

1. •

   Detect test directory: Check if tests/browser/ exists and contains *.yaml or *.yml files.

2. •

   Check tool availability: Run command -v browser-use or python3 -c "import browser_use".

3. •

   If both exist: Execute browser tests via the wrapper:

   bash

   ~/.claude/scripts/browser_test.sh run-all tests/browser/ --timeout 120
   

4. •

   If tests/browser/ exists but browser-use is not installed: Record as skip with message:

   text

   Browser tests: skip — browser-use not installed (pip install browser-use)
   

5. •

   If tests/browser/ does not exist: Skip silently (do not report).

Add browser test results to the Phase 4 classification and Phase 5 report table as a Browser category row alongside Lint, Test, and Security.

Phase 4: Result Classification

Classify each category result:

For security scans, further classify by severity:

• •High/Critical findings -> fail
• •Medium findings -> warn
• •Low/Info findings -> pass (noted)

Phase 5: Output Report

## Verify Report

**Project**: {absolute-path}
**Language(s)**: {detected-languages}
**Timestamp**: {ISO-8601}

### Results

| Category | Tool | Status | Summary |
|----------|------|--------|---------|
| Lint | ruff | pass | 0 issues |
| Test | pytest | fail | 3 failed, 42 passed |
| Security | bandit | warn | 2 medium-severity findings |

### Details

#### Lint
{trimmed lint output -- first 50 lines}

#### Test
{trimmed test output -- first 50 lines}

#### Security
{trimmed security output -- first 50 lines}

### Verdict

- **PASS**: All categories pass
- **WARN**: No failures but warnings present
- **FAIL**: One or more categories failed

Safety Checks

• •Never modify source files -- this skill is read-only analysis
• •Never install packages or dependencies -- report missing tools and stop
• •Respect .gitignore patterns -- do not scan ignored directories
• •Cap output at 50 lines per category to avoid flooding context

Learning Capture (Optional)

After producing the quality report, if any checks failed:

1. •

   For each failed check category (lint, test, security):

   • •

     Record the tool, failure count, and most common failure pattern

   • •

     Run:

     bash

     ~/.claude/scripts/learning_capture.sh add \
       --category antipattern --language <detected> \
       --title "Verify: <tool> failures" \
       --description "<summary of failures>" \
       --source verify --confidence medium
     

2. •

   This step is non-blocking -- failures in learning capture should not affect the verify report.