| name | council-verify |
| description | Verify code, documents, or implementation against requirements using LLM Council multi-model deliberation.
Use when you need multi-model consensus on correctness, completeness, or quality.
Keywords: verify, check, validate, review, approve, pass/fail, consensus, multi-model
|
| license | Apache-2.0 |
| compatibility | llm-council-core >= 0.33, mcp >= 1.0 |
| metadata | {"category":"verification","domain":"ai-governance","council-version":"0.33","author":"amiable-dev","repository":"https://github.com/amiable-dev/llm-council"} |
| allowed-tools | Read Grep Glob mcp:llm-council/verify mcp:llm-council/audit |
Council Verification Skill
Use LLM Council's multi-model deliberation to verify work with structured, machine-actionable verdicts.
When to Use
- Verify code changes before committing
- Validate implementation against requirements
- Check documents for accuracy and completeness
- Get multi-model consensus on quality
Workflow
- Snapshot: pin the git commit SHA (reproducibility)
- Verify: call
mcp:llm-council/verify (isolated context)
- Act on the verdict (structured JSON below)
- Audit: transcript via
mcp:llm-council/audit
Parameters
| Parameter | Type | Default | Description |
|---|
snapshot_id | string | required | Git commit SHA for reproducibility |
rubric_focus | string | null | Focus area: "Security", "Performance", "Accessibility" |
confidence_threshold | float | 0.7 | Minimum confidence for PASS verdict |
tier | string | "balanced" | Confidence tier: "quick", "balanced", "high", "reasoning" |
Tier Selection Guide
| Tier | Use When | Timeout | Max Input |
|---|
quick | Fast sanity checks, small diffs | ~30s | 15K chars |
balanced | Default. Routine verification | ~90s | 30K chars |
high | Security-critical reviews only | ~180s | 50K chars |
reasoning | Complex architectural decisions | ~600s | 50K chars |
Important: high/reasoning use slow frontier models. For large diffs (>20K chars), prefer balanced to avoid timeouts.
Evidence (ADR-042)
Pass pre-computed analysis from upstream tools (linters, slop detectors) via evidence: List[EvidenceItem]. Council emits evidence_summary and evidence_warnings in the response. See references/evidence.md for fields, limits, example.
Output Schema
{
"verdict": "pass|fail|unclear",
"confidence": 0.85,
"confidence_calibrated": 0.62,
"unclear_reason": null,
"rubric_scores": { "accuracy": 8.5, "completeness": 7.0, "...": "..." },
"blocking_issues": [...],
"rationale": "Chairman synthesis...",
"transcript_location": ".council/logs/...",
"partial": false,
"timeout_fired": false,
"completed_stages": ["stage1", "stage2", "stage3"],
"timing": { "total_elapsed_ms": 142000, "budget_utilization": 0.53, "...": "..." },
"input_metrics": { "content_chars": 32000, "tier": "high", "...": "..." },
"evidence_summary": [...],
"evidence_warnings": [...]
}
If timeout_fired: true, the tier deadline was exceeded. Check completed_stages for progress. timing.budget_utilization shows time used vs deadline (1.0 on timeout). See ADR-040 for full timeout semantics.
On UNCLEAR, route on unclear_reason: infra_failure → check gateway + RETRY; low_confidence → accept-and-audit if no blocking issues; timeout → re-tier. Details: references/unclear-routing.md.
Rules
- One call at a time. Never fire multiple verify calls concurrently or in rapid succession. Wait for each to complete before deciding next steps.
- One call per commit. Never retry the same snapshot_id. If it fails, fix the code first.
- Act on verdicts, don't retry them:
- PASS (exit_code 0): Proceed.
- FAIL (exit_code 1): Read
blocking_issues. Fix the code, commit, then re-verify the new snapshot.
- UNCLEAR (exit_code 2): Accept and move on. Do not retry.
- Do not reduce scope and retry. Sending the same code with fewer files is still a retry.
Related Skills
council-review (code review), council-gate (CI/CD gate)
