tz-review

Reviews OpenSpec change proposals against codebase facts before implementation.

Updated Jul 28, 2026
One-click install
npx skills add https://github.com/CybernetKZ/sdd-kit --skill tz-review-cybernetkz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tz-review
Source: https://github.com/CybernetKZ/sdd-kit/tree/main/profiles/conversation_flow/.claude/skills/tz-review
Command: npx skills add https://github.com/CybernetKZ/sdd-kit --skill tz-review-cybernetkz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical specifications (OpenSpec changes) often contain invented file names, wrong line references, or contradictions with existing specs, and these defects slip into implementation. This Skill performs a mechanical pre-implementation audit of a change document, verifying every claim against the actual repository before any code is written. ## Core Features & Use Cases - Fact verification: Every mentioned file, class, field, function, and extension point is checked with Grep/Read against the repository, with findings reported as file:line references. - Anchor and spec-delta validation: Validates enforced: anchors, requirement IDs, and MODIFIED/ADDED deltas using spec-lint.py, openspec validate --strict, lint_brand.py, and sdd-check gates. - Consistency and numbering checks: Detects conflicts with archived specs, other active changes, AGENTS.md conventions, and verifies the sequential change number across all four sources. - Use Case: A change tz-105-add-retry-logic is dropped into openspec/changes/. Run the review to get a numbered list of findings grouped by format, code facts, anchors, consistency, and formalities, plus a one-line verdict: ready for implementation or requires fixes. ## Quick Start Review the OpenSpec change in openspec/changes/tz-105-add-retry-logic and report findings with a verdict before implementation.

Frequently Asked Questions about tz-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review an OpenSpec change before implementation?▼

Point the reviewer at the change directory under openspec/changes/ or paste the change text into chat. It audits the proposal, spec deltas, and tasks against the repository and returns numbered findings with file:line references plus a verdict.

What does a spec review check in the codebase?▼

It verifies that every mentioned file, class, function, and extension point actually exists via grep, that claims about current behavior match the code, and that enforced anchors resolve to real symbols rather than just existing files.

Does the review modify the change document it audits?▼

No. The review never edits the document. Findings are reported in chat as a numbered list with fix suggestions, and the author applies corrections themselves or explicitly asks for them.

Which validation gates run during an OpenSpec change review?▼

The reviewer runs scripts/sdd/check.sh, which includes openspec validate --strict and spec-lint.py, plus lint_brand.py for branding stop-words. Each gate's result is reported line by line in the output.

Why does an enforced anchor fail validation even when the file exists?▼

The anchor suffix must resolve to an actual symbol, line, or range inside the file, not just the file itself. If the file exists but the named symbol is missing, that is a blocking finding and the anchor must be moved to an existing container symbol.

When is a change review not the right step in the workflow?▼

The review is a mechanical audit, not an interactive design interrogation. Deep requirement questioning belongs to the plan-griller step, which runs after the review passes and writes its results into the proposal's Grill section.