verify
Run format, typecheck, test, and lint across the monorepo. Use after implementing changes.
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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/verify/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How verify Compares
| Feature / Agent | verify | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/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
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
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
Simplify recently changed code — inline one-off abstractions, remove speculative code, reduce nesting, replace cleverness with clarity. Run after implementing a feature.
record
Record an architectural decision (ADR) or save an implementation plan. Use after making significant design choices or completing features.
qa
Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.
push
Commit and push to the current branch. Use --fixup to also wait for CI/CodeRabbit and fix issues.
pr
Commit, push, and create a PR. Default is ready-for-review with auto-fixup. Use --draft to skip review/fixup.
pr-fixup
Wait for CI checks and automated reviews (CodeRabbit, Greptile, Claude) on a PR, fix failures and address comments, then push.
playwright-cli
Automate browser interactions, test web pages and work with Playwright tests.
fix
Fix bugs and issues — reproduce, find root cause, minimal fix with regression test. Use when something is broken.
feature
Guided feature development — brainstorm, explore codebase, design architecture, implement with TDD, and review. Use for new features or significant changes.
e2e
Write and run web E2E tests (Playwright) using TDD — locations, patterns, commands, and debugging.