kn-verify

kn-verify is a skill for Claude Code, Codex from knowns-dev/knowns. It costs 13 tokens per session (1,504 once invoked), scanned A, original, MIT.

A verification workflow for checking whether a software specification is covered by its tasks and recorded decisions. It reports warnings about missing coverage, broken links, and conflicting records.

In plain words
What is it for?
Checking specification coverage, task status, acceptance evidence, decision markers, links, and current guidance across a project.
Why use it?
It helps reveal when completed work does not actually prove all requirements, or when project references and decision records are inconsistent.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/knowns-dev/knowns/kn-verify
Any agent
npx skills add knowns-dev/knowns --skill kn-verify
Clone the repo
git clone --depth 1 https://github.com/knowns-dev/knowns

Made for: Claude Code, Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for kn-verify

README.md
[![agentmods](https://agentmods.dev/badge/skills/knowns-dev/knowns/kn-verify.svg)](https://agentmods.dev/skills/knowns-dev/knowns/kn-verify)
Your own site
<a href="https://agentmods.dev/skills/knowns-dev/knowns/kn-verify"><img src="https://agentmods.dev/badge/skills/knowns-dev/knowns/kn-verify.svg" alt="Measured on agentmods" height="20"></a>
Per session 13 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,504 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00013 $0.01504
Opus 5 $0.00006 $0.00752
Sonnet 5 $0.00003 $0.00301
Haiku 4.5 $0.00001 $0.00150

Measured 4d ago against content hash 7f481b3bdde3, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

kn-verify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

internal/instructions/skills/kn-verify/SKILL.md · 175 lines

How it starts

The opening of the file, as written. The whole thing — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.

SDD Verification

Run validation with SDD-awareness to check spec coverage and task status.

Announce: "Using kn-verify to check SDD status."

Core principle: VERIFY SPEC COVERAGE → REPORT WARNINGS → SUGGEST FIXES.

Inputs

  • Entire project SDD state, or a narrower entity if the user asked for focused validation

Verification Rules

  • Report concrete warnings before general commentary
  • Prefer actionable fixes over generic advice
  • Separate coverage problems from broken refs or missing links
  • Require complete Spec Decision Compliance markers for in-review/done linked tasks; any conflict is a validation failure
  • Require every in-review/done linked task to record exactly one valid impact branch:
    • System Decision Impact: none — <reason> creates no candidate
    • System Decision Impact: candidate @decision/<id> (added|changed|removed) — <summary> resolves to a persisted non-current candidate linked to originating work
  • Keep unverified draft/replacement Decisions out of current guidance
  • Keep Spec Decisions canonical in the spec's Locked Decisions section; ledger duplication is a validation failure
  • Treat new Memory category decision as legacy workflow drift and require first-class Decision capture instead
  • When gathering context, retrieve only relevant accepted/current System Decisions with bounded filters; do not serialize all Decisions

Step 1: Run SDD Validation

Via CLI

knowns validate --sdd --plain

Via MCP (if available)

mcp_knowns_validate({ "scope": "sdd" })

Step 2: Present SDD Status

Return the verification result using the shared output contract:

  • Goal/result: whether SDD validation passed, failed, or surfaced warnings
  • Key details: coverage summary, explicit warnings, passing checks, and the highest-priority fixes
  • Next action: only when the warnings point to a clear follow-up command

The key-details portion may include a compact status block such as:

Specs:    X total | Y approved | Z draft
Tasks:    X total | Y done | Z in-progress | W todo
Coverage: X/Y tasks linked to specs (Z%)
Warnings:
- task-XX has no spec reference
- specs/feature: X/Y ACs incomplete
Passed:
- All spec references resolve
- specs/auth: fully implemented
- Spec Decisions: all linked D-IDs assessed with no conflicts
- System Decision Impact: declared and lifecycle-valid
- System Decision Impact refs: persisted with task/spec/source provenance

Read the full file on GitHub · 175 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 4d ago First seen · 175 lines · 13 tokens per session scan A 7f481b3bdde3

Subscribe to this mod's changes

kn-verify is a skill published in the GitHub repository knowns-dev/knowns (242 stars, last pushed today), licensed MIT. It adds 13 tokens to every session and 1,504 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

agent-session-monitor

Real-time agent conversation monitoring - monitors Higress access logs, aggregates conversations by session, tracks token usage. Supports web interface for viewing complete conversation history and costs. Use when users ask about current session token consumption, conversation history, or cost statistics.

higress-group/higress · 53 tokens

trellis-brainstorm

Guides collaborative requirements discovery before implementation. Creates task directory, seeds PRD, asks high-value questions one at a time, researches technical choices, and converges on MVP scope. Use when requirements are unclear, there are multiple valid approaches, or the user describes a new feature or complex…

mindfold-ai/Trellis · 65 tokens

fullenrich-content-engagers

Use when the user says "enrich people who engaged with this post", "qualify post engagers with FullEnrich", "scrape and enrich LinkedIn post {URL}", "engagers from this post into a CSV", "enrich this CSV of leads", "FullEnrich content engagers", or any variant indicating they want to convert a list of leads — either…

Othmane-Khadri/YALC-the-GTM-operating-system · 123 tokens

architecture-reviewer

Use when making architectural decisions, planning features, designing new components, reviewing PRs, or validating that proposed changes align with Clean Architecture principles. Triggers include "review architecture", "check design", "does this fit", "where should this go", "planning a feature", or before…

shep-ai/shep · 80 tokens

enrich-with-signals

Pull PredictLeads buying-intent signals (jobs, news, funding, tech, leadership changes) for a result set of companies and write them back into the local cache. Use when the user says 'enrich these companies with signals', 'add buying signals to this list', 'pull intent data for [domain]', 'check signals for these…

Othmane-Khadri/YALC-the-GTM-operating-system · 105 tokens

alive:system-upgrade

Upgrade ALIVE to the current version. Handles v1/v2/v3.x source states, multi-surface aware (alive-mcp / Hermes / Codex), retroactive version detection, partial-failure resume, dry-run previews, and rollback inspection.

alivecontext/alive · 57 tokens