verify

Run format, typecheck, test, and lint across the monorepo. Use after implementing changes.

40 stars

Best use case

verify is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Run format, typecheck, test, and lint across the monorepo. Use after implementing changes.

Teams using verify should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/verify/SKILL.md --create-dirs "https://raw.githubusercontent.com/kdlbs/kandev/main/.agents/skills/verify/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/verify/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How verify Compares

Feature / AgentverifyStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Run format, typecheck, test, and lint across the monorepo. Use after implementing changes.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Verify

Run the full verification pipeline for the monorepo, then fix any issues found.

## Steps

**Create a task for each step below and mark them as completed as you go.** This pipeline must run in order — formatting before linting prevents formatter-induced lint failures.

### 1. Rebase on main

Ensures CI parity — CI merges main into the PR branch.

```bash
git fetch origin main --quiet
```

- If the current branch is `main`, skip this step.
- If the branch is stacked on another feature branch (not main), skip this step.
  Detect: `git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null` — if the upstream is NOT `origin/main` (e.g., another feature branch), skip rebase.
- Otherwise, rebase:
  ```bash
  git rebase origin/main
  ```
- If the rebase has conflicts, resolve them:
  1. For each conflicted file, read the file and understand both sides of the conflict
  2. Resolve by keeping the correct combination of both changes (don't just pick one side)
  3. `git add <resolved-file>` then `git rebase --continue`
  4. Repeat for each conflicting commit until the rebase completes
  5. If a conflict is too ambiguous to resolve confidently, abort (`git rebase --abort`) and ask the user for guidance

### 2. Format

Run formatters first — they may change line lengths which affects linter results.

- `make -C apps/backend fmt`
- `cd apps && pnpm format`

### 3. Verify in parallel

Run these in parallel where possible:

- `make -C apps/backend test lint`
- `cd apps && pnpm --filter @kandev/web typecheck && pnpm --filter @kandev/web lint`

### 4. Fix issues

Do NOT just report issues — fix them:

- Read each failing file at the reported line number
- Fix the root cause (don't suppress warnings or add ignores)
- Common fixes:
  - **Type errors**: fix the type, add a missing import, or correct the function signature
  - **Lint — function too long**: extract a helper function or sub-component
  - **Lint — file too long**: split the file into smaller, cohesive files grouped by responsibility (e.g., separate types, helpers, constants, or sub-domains into their own files)
  - **Lint — cyclomatic/cognitive complexity**: simplify conditionals, extract early returns, break into smaller functions
  - **Lint — unused imports**: remove them
  - **Lint — duplicate strings**: extract to a constant
  - **Test failures**: read the test, understand the assertion, fix the code (not the test) unless the test is outdated
- After fixing, re-run only the failed command to confirm the fix

### 5. Repeat

Repeat steps 3-4 until all commands pass. If a fix introduces new issues, address those too.

### 6. Done

All pass cleanly: rebase, fmt, typecheck, test, lint. Mark all tasks as completed.

Related Skills

tdd

40
from kdlbs/kandev

Implement changes using Test-Driven Development (Red-Green-Refactor). Use for bug fixes, new features, or any code change that should have test coverage.

spec

40
from kdlbs/kandev

Write a feature spec — the "what & why" of a kandev product feature, before coding. Use when the user says "let's spec X" or starts a new product feature.

simplify

40
from kdlbs/kandev

Simplify recently changed code — inline one-off abstractions, remove speculative code, reduce nesting, replace cleverness with clarity. Run after implementing a feature.

record

40
from kdlbs/kandev

Record an architectural decision (ADR) or save an implementation plan. Use after making significant design choices or completing features.

qa

40
from kdlbs/kandev

Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.

push

40
from kdlbs/kandev

Commit and push to the current branch. Use --fixup to also wait for CI/CodeRabbit and fix issues.

pr

40
from kdlbs/kandev

Commit, push, and create a PR. Default is ready-for-review with auto-fixup. Use --draft to skip review/fixup.

pr-fixup

40
from kdlbs/kandev

Wait for CI checks and automated reviews (CodeRabbit, Greptile, Claude) on a PR, fix failures and address comments, then push.

playwright-cli

40
from kdlbs/kandev

Automate browser interactions, test web pages and work with Playwright tests.

fix

40
from kdlbs/kandev

Fix bugs and issues — reproduce, find root cause, minimal fix with regression test. Use when something is broken.

feature

40
from kdlbs/kandev

Guided feature development — brainstorm, explore codebase, design architecture, implement with TDD, and review. Use for new features or significant changes.

e2e

40
from kdlbs/kandev

Write and run web E2E tests (Playwright) using TDD — locations, patterns, commands, and debugging.