Verify logo

Verify

Organization
codewithmukesh
verify

Run a comprehensive 7-phase verification pipeline for .NET projects: build, analyzers, antipattern detection, tests, security, formatting, and diff review. Each phase produces PASS/FAIL with actionable output and the pipeline short-circuits on critical failures. Also the authority on verification strategy: which phases to run for a given change, quality gates, and fix-and-retry loops. Use when: "verify", "check everything", "is this ready", "pre-PR check", "run all checks", "quality gate", "verification strategy", "which checks should run", or after completing a feature or refactor.

Overview

Publishercodewithmukesh
Repositorydotnet-claude-kit
Skill nameverify
Stars
721
Forks
170
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by codewithmukesh on GitHub. Read the source before you install it.

Installation

Install the Verify AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/codewithmukesh/dotnet-claude-kit.git /tmp/dotnet-claude-kit
mkdir -p .claude/skills
cp -r /tmp/dotnet-claude-kit/skills/verify .claude/skills/verify
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Verify in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Verify on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Verify is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

/verify -- 7-Phase Verification Pipeline

What

Runs a sequential, 7-phase verification pipeline that catches issues at every level -- from compiler errors to subtle antipatterns to formatting drift. Each phase produces an explicit PASS, WARN, or FAIL with details. "It looks fine" is not a verification result; a table of statuses is. Critical failures (Phase 1 build, Phase 4 tests) short-circuit the pipeline because later phases cannot produce meaningful results on broken code.

The pipeline answers one question: "Is this code ready for review?"

PhaseToolWhat It CatchesCritical
1. Builddotnet buildCompilation errors, missing referencesYes
2. Diagnosticsget_diagnostics (MCP)New analyzer warnings, nullability issuesFAIL on new errors
3. Antipatternsdetect_antipatterns (MCP)async void, sync-over-async, DateTime.Now, moreNo
4. Testsdotnet testFailing tests, regressionsYes
5. Securitydotnet list package --vulnerable + scanSecrets, SQL injection, missing auth, vulnerable packagesFAIL on critical/high
6. Formatdotnet format --verify-no-changesStyle drift, formatting inconsistenciesNo
7. Diff Reviewgit diff analysisAccidental changes, debug leftovers, TODOsNo

When

  • After completing a feature, bug fix, or major refactor
  • Before creating a pull request -- non-negotiable, full pipeline
  • After merging upstream changes or updating dependencies
  • When the user says "verify", "check everything", "is this ready", "run all checks"
  • As the final step before marking a task complete

Which Phases to Run

Full pipeline is the default. For scoped changes, run a subset:

ScenarioPhasesNotes
Feature complete / Pre-PR / new endpointAll 7No shortcuts
Bug fix1, 2, 4Add a test first if none covers it
After refactor1, 2, 3, 4Correctness focus; add 5-7 if security-sensitive
Dependency update1, 4, 5Build, tests, vulnerability scan
Config or test-only change1, 4Build and test
Formatting only6Format check is sufficient

When in doubt, run all 7. Extra phases cost minutes; a missed security issue costs days of incident response. Never cherry-pick phases because a change "looks safe".

How

Phase 1: Build (CRITICAL -- short-circuits)

bash
dotnet build --no-restore --verbosity quiet
  • If the build fails, STOP. Report errors and fix before continuing -- nothing downstream is meaningful on code that does not compile.
  • Capture the warning count even on PASS; new warnings are tracked in Phase 2.
  • Output: PASS (0 errors) or FAIL (with error list)

Phase 2: Diagnostics

Use the Roslyn MCP get_diagnostics tool, scoped to changed files/projects (full solution for cross-cutting changes). Compare against baseline -- flag only NEW warnings introduced by the current changes. Common findings: CS8600/CS8602 (nullability), CS0219 (unused variable).

Output: PASS (0 new) / WARN (new warnings) / FAIL (new errors). Treat new warnings as work -- today's CS8600 is next month's production NullReferenceException.

Phase 3: Antipattern Detection

Use the Roslyn MCP detect_antipatterns tool on changed files (full project for broad changes). Catches: async void, sync-over-async (.Result, .GetAwaiter().GetResult()), new HttpClient(), DateTime.Now/UtcNow instead of TimeProvider, broad catch (Exception), string interpolation in logging, missing CancellationToken, EF read queries without AsNoTracking.

Output: PASS (0 findings) / WARN (findings) / FAIL (critical antipatterns)

Phase 4: Tests (CRITICAL -- short-circuits)

bash
dotnet test --no-build --verbosity quiet
  • Full suite, or scoped to affected test projects for large solutions.
  • Any failing test is a FAIL -- no exceptions. Stop and fix before later phases.
  • If no test project exists: SKIP with a recommendation to add tests.

Output: PASS (all green) or FAIL (failing test names + error messages)

Phase 5: Security Scan

bash
dotnet list package --vulnerable --include-transitive

Then review changed files for: hardcoded secrets/connection strings/API keys, SQL injection (raw SQL without parameterization), missing [Authorize] on endpoints that need it, permissive CORS, missing input validation, disabled HTTPS or certificate validation.

Output: PASS / WARN (medium/low findings) / FAIL (critical/high vulnerabilities)

Phase 6: Format Check

bash
dotnet format --verify-no-changes --verbosity quiet

Reports drift without auto-fixing. To resolve, run dotnet format and include the changes in the commit. If no .editorconfig exists, note it as a recommendation.

Output: PASS / WARN (with file list)

Phase 7: Diff Review

Analyze git diff --stat and git diff (staged + unstaged) for:

  • Accidental or unrelated file changes (.vs/, bin/, obj/, .env, secrets)
  • Debug leftovers (Console.WriteLine, #if DEBUG in production paths)
  • Unresolved TODO/HACK/FIXME markers
  • Scope mismatch -- changes must match the task/PR description

Output: PASS (clean, matches intent) / WARN (with findings)

Fix-and-Retry Loop

A single pass rarely produces all-green. The loop is the point:

  1. IDENTIFY -- which phase failed, and the specific error
  2. FIX -- make the minimal change that resolves it
  3. RE-RUN -- from Phase 1 if the fix changed code; otherwise from the failed phase
  4. REPEAT -- until all phases pass, or an issue needs user input

Final Summary

## Verification Results

| Phase | Result | Details |
|-------|--------|---------|
| 1. Build | PASS | 0 errors, 0 warnings |
| 2. Diagnostics | PASS | 0 new diagnostics |
| 3. Antipatterns | WARN | 1 missing CancellationToken |
| 4. Tests | PASS | 47 passed, 0 failed |
| 5. Security | PASS | No findings |
| 6. Format | PASS | Clean |
| 7. Diff Review | WARN | 1 TODO marker found |

**Verdict: READY FOR REVIEW** (with 2 non-blocking warnings)

Verdicts: READY FOR REVIEW (all PASS, or only non-blocking WARNs) or NEEDS FIXES (any FAIL, with specific remediation steps). For pre-PR runs, include the verification report in the PR description.

Example

User: /verify

Claude: Running 7-phase verification pipeline...

Phase 1: Build ............ PASS (0 errors)
Phase 2: Diagnostics ...... PASS (0 new warnings)
Phase 3: Antipatterns ..... WARN
  - src/Features/Orders/CreateOrder.cs:42 -- DateTime.Now usage, use TimeProvider
Phase 4: Tests ............ PASS (23 passed, 0 failed, 0 skipped)
Phase 5: Security ......... PASS
Phase 6: Format ........... PASS
Phase 7: Diff Review ...... PASS

Verdict: READY FOR REVIEW (1 non-blocking warning)

Recommendation: Replace DateTime.Now with TimeProvider on line 42 before
merging. Not blocking, but it will fail the antipattern check in CI.

Related

  • /build-fix -- Auto-fix build errors when Phase 1 fails
  • /code-review -- Multi-dimensional review once verification passes
  • /health-check -- Whole-project graded assessment (beyond this change set)

Frequently asked questions

What does the Verify AI skill do?

Run a comprehensive 7-phase verification pipeline for .NET projects: build, analyzers, antipattern detection, tests, security, formatting, and diff review. Each phase produces PASS/FAIL with actionable output and the pipeline short-circuits on critical failures. Also the authority on verification strategy: which phases to run for a given change, quality gates, and fix-and-retry loops. Use when: "verify", "check everything", "is this ready", "pre-PR check", "run all checks", "quality gate", "verification strategy", "which checks should run", or after completing a feature or refactor.

Why use Verify on TypingMind?

Because you install it once and use it with any model. Verify is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Verify in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/codewithmukesh/dotnet-claude-kit/tree/main/skills/verify. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Verify?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Verify?

As many as you like. As long as a model supports skills, you can use Verify with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Verify AI skill free?

Yes. It is published on GitHub by codewithmukesh under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇