AGENT SKILL

norvidize

Extract and audit claims for norvid tracking system

License 许可
Apache-2.0
最近更新
2026-07-12
Stars
★ 82
Forks
18

01 前言 Front Matter

name
norvidize
description
Extract and audit claims for norvid tracking system

03 SKILL.md 正文

Norvidize Skill

<<<<<<< HEAD Extract claims from documentation, code, and tests into a claim tracking system based on multicomputational irreducibility -- claims that cannot be reduced to simpler forms without losing verification guarantees.

Extract claims from documentation, code, and tests into the norvid claim tracking system.

origin/main

When to Use

  • After completing a significant feature
  • When auditing documentation accuracy
  • Before releases to ensure claims match reality
  • When docs/tests/specs diverge from implementation

<<<<<<< HEAD

Claim Registry Location

crates/basin-norvid/src/claims.rs

origin/main

Assurance Levels (lowest to highest)

Level Meaning Evidence Required
Mentioned Just referenced somewhere Any doc
<<<<<<< HEAD
Designed Has design doc Design markdown
Specified Has formal spec Spec file
Implemented Code exists Source file + symbol
Tested Has passing tests Test file + test name
Proven Has formal proof Proof file + theorem
=======
Designed Has design doc docs/design/*.md
Specified Has sigil spec *.sigil file
Implemented Code exists Rust file + symbol
Tested Has passing tests Test file + test name
Proven Has Lean proof Lean file + theorem

origin/main

Claim Categories

  • Feature: User-visible functionality
  • Property: System guarantee (linearizability, durability)
  • Guarantee: Promise to users
  • Optimization: Performance improvement
  • Invariant: Internal system invariant
  • Decision: Architectural choice with rationale
  • Omission: Deliberate non-feature

<<<<<<< HEAD

Covariant Claim Structure

Claims form a presheaf over the assurance poset: higher assurance levels pull back evidence from lower levels. A Tested claim covariantly transports its Designed evidence forward.

Mentioned -> Designed -> Specified -> Implemented -> Tested -> Proven

Each arrow preserves evidence (covariant functor from assurance levels to evidence sets).

Evidence Types

// Documentation
Evidence::doc("docs/CLAIMS.md")

// Rust implementation
Evidence::rust("crates/foo/src/bar.rs", "SymbolName")

// Test file
Evidence::test("crates/foo/src/bar.rs", "test_prefix")

// Sigil specification
Evidence::sigil("sigil/specs/foo.sigil")

// External (benchmark, paper)
Evidence::external("benchmarks/harnesses/redis/src/main.rs")

Adding Claims

registry.register(
    Claim::new("CLM_UNIQUE_ID", "Short description")
        .with_category(Category::Feature)
        .with_component(Component::Slate)
        .with_assurance(Assurance::Implemented)
        .with_evidence(Assurance::Designed, Evidence::doc("docs/design/foo.md"))
        .with_evidence(Assurance::Implemented, Evidence::rust("crates/slate/src/lib.rs", "FooStruct"))
);

origin/main

Extraction Process

1. Find Candidate Claims

<<<<<<< HEAD Scan sources for claim candidates:

grep -r "CLAIM\|GUARANTEE\|INVARIANT" docs/
grep -r "#\[test\]" -A 2 src/ | grep "fn test_"
grep -r "ops/s\|latency\|throughput" docs/

2. Categorize by Irreducibility

  • Irreducible claims: Cannot be verified by simpler means (need full test execution)
  • Reducible claims: Can be statically verified (type checking, linting)
  • Compositional claims: Verified by composing sub-claim verifications

3. Verify Evidence Paths

Before adding at Tested/Implemented level, verify paths exist.

4. Downgrade Strategy

If evidence path is uncertain, downgrade assurance level. Upgrade later when evidence is confirmed.

Anti-Patterns

  • Don't add Tested claims without verifying paths
  • Don't skip Designed level -- even Tested claims should have design evidence
  • Don't guess component names ======= Scan these sources for claim candidates:
# Explicit claims in docs
grep -r "CLM-\|CLAIM\|GUARANTEE\|INVARIANT" docs/

# Test names suggest guarantees
grep -r "#\[test\]" -A 2 crates/ | grep "fn test_"

# Performance claims
grep -r "ops/s\|latency\|throughput" docs/

# Sigil specs
find sigil/ -name "*.sigil" -exec grep -l "claim\|invariant\|property" {} \;

2. Categorize and Deduplicate

Group into tiers:

  • Tier 1 (SPEC_*): Claims with sigil specs - highest value
  • Tier 2 (TEST_*): Claims with test evidence
  • Tier 3: Design-level claims (docs only)

3. Verify Evidence Paths

Before adding at Tested/Implemented level, verify paths exist:

# Check file exists
test -f "crates/basin-redis/src/crdt.rs" && echo "OK"

# Check symbol exists
grep -l "EntityStore" crates/basin-meta/src/indexes/*.rs

4. Add to Registry

Add claims to claims.rs in appropriate section:

  • SPEC_* claims near line 1720
  • TEST_* claims after specs
  • PERF_* claims in performance section
  • Product claims (CLM_STASH, etc.) with products

CI Verification

The CI test filters claims at Tested/Proven level and verifies:

  1. Evidence file exists
  2. Symbol/test found in file
# Run verification
graft test -p basin-norvid test_all_claims_verified

Common Path Mappings

Old/Wrong Path Correct Path
crates/stash/ crates/basin-redis/
crates/shelf/ crates/basin-mesh/ or crates/spool-core/
crates/basin-jepsen/ tests/basin-jepsen/
products/nfs/tests/ crates/nfs/tests/

Downgrade Strategy

If evidence path is uncertain, downgrade to Designed level:

// Was Tested but can't verify path
.with_assurance(Assurance::Designed)
.with_evidence(Assurance::Designed, Evidence::doc("docs/CLAIMS.md"))

Upgrade later when evidence is confirmed.

Parallel Audit Pattern

For bulk verification, spawn sonnet agents:

Task: Audit PERF_* claims
- Check benchmark files exist
- Verify they actually measure what claim says
- Report which claims have valid evidence

Task: Audit product claims (CLM_STASH, etc.)
- Find actual test locations
- Verify symbol names
- Report path corrections needed

Anti-Patterns

  • Don't add Tested claims without verifying paths - CI will fail
  • Don't embed large values in claim IDs - Keep IDs short like CLM_STASH
  • Don't skip Designed level - Even Tested claims should have design evidence
  • Don't guess component names - Check Component enum in identity.rs

Quick Reference

# Find existing claims
grep -n "Claim::new" crates/basin-norvid/src/claims.rs | head -20

# Check CI status
graft test -p basin-norvid test_all_claims_verified 2>&1 | grep -E "FAILED|passed"

# Find test files for a crate
find crates/basin-meta -name "*.rs" -exec grep -l "#\[test\]" {} \;

# Count claims by category
grep -E "Category::" crates/basin-norvid/src/claims.rs | sort | uniq -c

origin/main

04 同仓库更多 Skills

FDU-INS
FDU-INS/Insurance-Skills

로인장 (Roinjiang)

Activates when the user needs legal advice, contract review, insurance law consultation, startup legal support, or any legal/regulatory matter. She is a top-tier in-house lawyer with absolute loyalty to the CEO, specializing in insurance law, financial consumer protection, privacy, contracts, labor law, family law, civil and criminal matters.

律师与法务
★ 82
FDU-INS
FDU-INS/Insurance-Skills

zocdoc-doctor-finder

Use when a user needs to find a doctor, dentist, specialist, therapist, or healthcare provider — especially when they mention insurance, in-network, availability, location, appointments, or booking. Also use for browsing provider reviews, comparing doctors by specialty, or checking if a provider takes their insurance.

★ 82
FDU-INS
FDU-INS/Insurance-Skills

zenmux-context

Answers any question about ZenMux by reading the latest official documentation. Use this skill whenever the user asks about ZenMux product features, API usage, configuration, integration, pricing, models, providers, routing, fallback, streaming, multimodal, structured output, tool calling, reasoning, prompt caching, image generation, video generation, web search, long context, observability, logs, cost tracking, usage analytics, insurance, subscription, pay-as-you-go, invoices, best practices for tools like Claude Code, Cursor, Cline, CodeX, Gemini CLI, opencode, Cherry Studio, Obsidian, Sider, Open-WebUI, Dify, Neovate, GitHub Copilot, OpenClaw, CC-Switch, Immersive Translate, Studio Chat, architecture, benchmarks, FAQ, contact, privacy, terms of service, compliance, or any other ZenMux-related topic. Also trigger when the user writes in Chinese about ZenMux: 文档, 使用指南, 快速开始, API 参考, 最佳实践, 模型路由, 供应商路由, 订阅, 按量计费, 可观测性, 帮助, 常见问题, 接入指南, 配置. Trigger on phrases like "how to use ZenMux", "ZenMux docs", "ZenMux API", "ZenMux integration", "ZenMux 怎么用", "ZenMux 接入", "ZenMux 配置". Even if the user doesn't say "ZenMux" explicitly but asks about LLM API aggregation, model routing, provider fallback in a context where ZenMux is the project being worked on, this skill should activate.

图像与多媒体
★ 82
FDU-INS
FDU-INS/Insurance-Skills

workers-comp-guide

Guide workers compensation compliance and claims management. TRIGGERS - Use when user needs help with workers-comp-guide related tasks.

★ 82
FDU-INS
FDU-INS/Insurance-Skills

weekly-kpi-report

Generate McKinsey-style board presentation PPTs from weekly auto insurance data. Automatically calculates 16+ KPIs, creates executive-level slides with actionable insights, and supports week-over-week comparisons. Use when user uploads insurance cost data (Excel/CSV) and requests board report, weekly presentation, executive briefing, or mentions keywords like 董事会汇报, 周报PPT, 经营分析演示, McKinsey-style reports.

行政与办公人员演示文稿电子表格
★ 82
FDU-INS
FDU-INS/Insurance-Skills

wealth-advisory

Wealth management and financial planning for HNW and UHNW clients. Activate when the user mentions wealth management, financial planning, retirement, estate planning, tax planning, GRAT, IDGT, trust, asset allocation, withdrawal rate, Monte Carlo simulation, goals-based investing, tax-loss harvesting, Roth conversion, insurance, annuity, mortgage strategy, concentrated stock, family office, direct indexing, 529 plan, charitable giving, donor-advised fund, private foundation, or asks about personal finance strategy, inheritance, long-term financial planning, or UHNW advisory.

财务
★ 82