tz-implement

Implements OpenSpec change proposals through phased stop-gates, logical commits, and spec-delta archival.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It enforces a disciplined, gated protocol for implementing approved OpenSpec change proposals (ТЗ) in the HubTalk AI Conversation Flow repository, preventing unreviewed code, spec-code drift, and undocumented changes. ## Core Features & Use Cases - Phased implementation with STOP-gates: verifies entry conditions (review verdict, grill provenance, RED tests, green validation) before any code is written, and requires user confirmation of the commit plan. - Code-over-spec rule: stops and reports discrepancies when the change contradicts actual code instead of silently forcing the code to match the document. - Logical commits with traceability: each commit references "ТЗ №NN §M", passes make test and frontend build, and carries the spec delta, DOCUMENTATION.md update, and version bump in the same commits. - Use Case: After a change in openspec/changes/ passes review, run this protocol to implement it via executor subagents, apply the spec delta to openspec/specs/, update documentation, and archive the change. ## Quick Start Ask the assistant to implement the approved change in openspec/changes/tz-NNN following the tz-implement protocol with its stop-gates.

Frequently Asked Questions about tz-implement

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

FAQPage Schema
How do I implement an OpenSpec change proposal with stop-gates?▼

Follow the phased protocol: verify entry conditions in phase 0, present a logical commit breakdown for user approval in phase 1, implement task-by-task with green tests per commit in phase 2, then apply the spec delta and archive the change.

What happens when a change proposal contradicts the actual code?▼

The protocol stops and reports the discrepancy to the user instead of forcing code to match the document. The change is never edited retroactively; corrections require user decision via a new or amended change.

Can the executor subagent commit code directly?▼

No. The executor subagent implements tasks strictly from tasks.md but never commits. Commits are made by the developer or the main session on explicit instruction after review.

What validations must pass before each commit?▼

Each commit requires make test (lint_brand, lint_migrations, lint_imports, ruff, pytest) to pass, plus the frontend build with tsc when frontend files are touched. Final validation includes openspec validate --strict and strict spec-lint.

When should this implementation protocol not be used?▼

Do not start when the change lacks a ready-for-implementation review verdict, grill provenance, or RED tests from test-author. Light-tier changes still require one RED test per scenario before implementation begins.