Skip to content
Back to skills

Verify

ASecurity

Use when the user says 'verify', 'check this work', 'does it pass', or before committing completed work.

  • 423 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added June 5, 2026
ai-agentspythongobashnodeexpresstestinggitapi

Works with

  • api

Security analysis

A100/100

Scanned June 5, 2026

npx -y skills add cwinvestments/memstack --skill verify --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Verify?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Verify
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cwinvestments-verify/badge)](https://www.skillsdirectory.com/skills/cwinvestments-verify)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: verify
description: "Use when the user says 'verify', 'check this work', 'does it pass', or before committing completed work."
version: 1.0.0
---


# ✅ Verify — Checking Work...
*Review completed work against requirements before committing.*

## Activation

When this skill activates, output:

`✅ Verify — Checking work against requirements...`

Then execute the protocol below.

## Context Guard

| Context | Status | Priority |
|---------|--------|----------|
| **User says "verify", "check this work", "does it pass"** | ACTIVE — run verification | P1 |
| **User says "is this done", "ready to commit"** | ACTIVE — run verification | P1 |
| **User is mid-task, still actively coding** | DORMANT — let them finish first | — |
| **User asks to commit or push** | DORMANT — Seal hook handles pre-push checks | — |
| **User asks to review someone else's code** | DORMANT — not a code review tool | — |

## Anti-Rationalization

If you're thinking any of these, STOP — you're about to skip the protocol:

| You're thinking... | Reality |
|---|---|
| "I already tested this manually" | Ad-hoc testing leaves no record. Run the automated checks. |
| "This change is too small to verify" | Small changes cause regressions. Run the full protocol. |
| "The build passed, so it's fine" | Build passing ≠ requirements met. Always do the manual requirement check (Step 3). |
| "I'll just commit and fix issues later" | Issues found after commit are 10x harder to fix. Verify first. |
| "There are no tests for this project" | Skip automated tests, but ALWAYS do the manual requirement check and common issues scan. |
| "The user seems in a hurry" | Shipping broken code wastes more time than verification takes. |

## Protocol

### Step 1: Identify the Task

Determine what was being built by checking:
- Recent conversation context (what the user asked for)
- Git diff for uncommitted changes
- Recent commits if already committed

Summarize: "**Task:** [what was being built/changed]"

### Step 2: Run Automated Checks

Run whatever applies to the current project:

**Build check:**
```bash
# Detect and run the project's build command
npm run build    # Node.js
make build       # Makefile
python -m py_compile <file>  # Python
```

**Test check:**
```bash
# Detect and run the project's test command
npm test         # Node.js
pytest           # Python
make test        # Makefile
```

**Lint check (if available):**
```bash
npm run lint     # Node.js
```

If no build/test tooling exists, skip and note "No automated checks configured."

### Step 3: Manual Requirement Check

Compare the completed work against the original requirements:
- List each requirement from the original task
- Check whether it was implemented
- Flag any gaps, missing edge cases, or regressions

### Step 4: Check for Common Issues

- **Uncommitted debug code**: `console.log`, `print()`, `debugger`, `TODO` markers left behind
- **Hardcoded values**: Magic numbers, hardcoded URLs, temp credentials
- **Missing error handling**: Unhandled promises, missing try/catch at boundaries
- **Incomplete cleanup**: Unused imports, dead code from earlier attempts

### Step 5: Generate Report

```markdown
## Verification Report
*{YYYY-MM-DD}*

### Task: {what was being built}

### Automated Checks
- [x] Build: passes / [ ] fails — {error}
- [x] Tests: passes / [ ] fails — {error}
- [x] Lint: passes / [ ] N/A

### Requirements
- [x] {Requirement 1} — implemented in {file}
- [x] {Requirement 2} — implemented in {file}
- [ ] {Requirement 3} — MISSING: {what's needed}

### Issues Found
1. {Issue} → {Suggested fix}

### Verdict: PASS / NEEDS FIX
```

### Step 6: Recommend Action

- **PASS**: "Looks good. Ready to commit."
- **NEEDS FIX**: List specific fixes needed, prioritized by severity.

## Inputs
- Current working context (project, recent changes)
- Original task requirements (from conversation or plan)
- Git diff / status for change analysis

## Outputs
- Verification report with pass/fail checklist
- Specific fix recommendations if issues found

## Example Usage

**User:** "verify this work"

```
✅ Verify — Checking work against requirements...

## Verification Report
Task: Add user registration API endpoint

### Automated Checks
- [x] Build: passes
- [x] Tests: 14/14 passing
- [x] Lint: clean

### Requirements
- [x] POST /api/register endpoint — server/routes/auth.ts
- [x] Email validation — uses zod schema
- [x] Password hashing — bcrypt with salt rounds=12
- [ ] Rate limiting — MISSING: no rate limiter on registration endpoint

### Issues Found
1. No rate limiting on /api/register → Add express-rate-limit middleware

### Verdict: NEEDS FIX (1 issue)
```

## Level History

- **Lv.1** — Base: Pre-commit verification with automated + manual checks, structured report output, framework-agnostic detection. (Origin: MemStack v3.1, Feb 2026)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.