hzt

Verify acceptance criteria for a task. Reads the task's detail file, fans every unchecked AC out to an independent verifier subagent, adversarially refutes each PASS before marking it, and inserts a "All criteria verified" timestamp when all pass. Use when you want to run or re-run ACs independently of task execution — e.g. after implementation, in a follow-up session, or to get an honest mid-task progress check.

Add a new task to any of the team's registered projects. Auto-detects the current project from the working directory and conforms to that project's conventions — prefix, numbering, todo-file layout, task-file template. Reads conventions from `~/.claude/commands/hzt/add-task-projects.yaml`. Use when the user wants to add a task, capture a TODO, or track a new idea in a local project.

Deterministic browser verification for visual / behavioural acceptance criteria. Validates SVG assets with xmllint, refuses to test a stale build, serves the built output over local HTTP (never file://), runs parameterised Playwright specs that assert DOM state and computed style, and captures screenshots as artifacts — never as the pass/fail gate. Emits the per-AC {ac_id, verdict, evidence} table that hzt:ac and hzt:do-task Step 5e consume. Use when an AC needs browser evidence ("renders", "is visible", "navigates to", "highlights", "font size", "contrast", "scrolls to") instead of marking it UNCLEAR.

Run a multi-agent code review TEAM over a codebase diff or path. Dispatches 7 specialist reviewers in parallel (correctness, design, performance, maintainability, testing, api-contract, security), consolidates findings into a severity-ranked REVIEW-REPORT.md with inter-agent agreement scoring, adversarial validation, and a merge recommendation. correctness and performance run as a loop-until-dry consensus fan-out (2-8 passes); every surviving finding is verified by a dedicated validator agent before it can appear in the report. Use when the user says "code review team", "multi-agent code review", "team review", "review this diff with a team", or similar. Review-only — no fixes.

Execute or plan a task in any of the team's registered projects. Auto-detects the current project from the working directory, reads conventions from `~/.claude/commands/hzt/add-task-projects.yaml`, and either drafts a missing task plan (plan mode) or implements the existing one (execute mode). Always creates a task-detail file before executing — even for lightweight projects. Use when the user says "do HZT-087", "work on PROJ-031", "execute task 12", or similar.

Estimate story points for epics, stories, and tasks using Fibonacci scale

Turn `hzt:next`'s readiness ranking into a scope-aware dispatch plan by detecting file-scope overlap between candidate tasks — candidates whose `**Location:**` scopes intersect are serialized into a chain, everyone else goes to `hzt:do-task` Step 0.5's concurrent batch. Calls `hzt:next` Steps 0–3 unchanged; never re-implements readiness ranking. Use when dispatching more than one ready task at once and file-scope safety matters — "fleet select", "dispatch these safely", "check for scope overlap before running these together", "what can run concurrently right now".

Initialize a new project with a standard directory structure, template files, and a git repository. Use this skill whenever the user starts a new project, types /init, asks to "set up a new project", "initialize a repo", "scaffold a project", or wants to create the standard folder layout. Run once per project at the start of the work. Even if the user only mentions creating a repo or setting up folders, trigger this skill — it handles all of it in one shot.

Pick the next open task from the current project's todo file and invoke `/hzt:do-task` with that task ID. Ranks candidates by readiness (has a task-detail file, no stated unmet dependency) and reports why one was chosen. Accepts an optional count (`/hzt:next 3`) to hand off multiple ranked candidates to `do-task`'s concurrent multi-task dispatch. Auto-detects the current project from the working directory using the same YAML config as other hzt skills. Use when the user says "do the next task", "what's next", "next task", "next 3 tasks", or similar.

Guide the user through planning a significant project, a large epic/initiative spanning multiple epics, or a codebase refactor. Produces five planning artifacts (project.md, architecture.md, roadmap.md, verification.md, instructions.md) modeled on a completed large-refactor initiative, gated phase by phase like hzt:prd. Use when the user says "plan this project", "plan this refactor", "help me plan this epic", or similar.

Run a detailed, adversarial multi-agent review of an implementation plan — a GitHub PR, a branch, or a planning document — against the baseline spec, ADR, or prior plan it is meant to honour. Reviews the plan, not the code. Builds a shared inventory, runs up to 7 independent lenses in parallel (completeness, consistency, logic, feasibility, assumptions, testability, baseline-diff), verifies every finding against the repository so that anything without a path:line or a runnable command is dropped, adjudicates by severity, then loops a completeness critic until dry. Writes a findings document to a caller-specified target. Use when the user says "review this plan", "review this PR's plan", "does this plan match the spec", "red team this implementation plan", "what's missing from this plan", "check this plan against the ADR", "plan review", or similar. Review-only — never edits the plan, the PR, or any source file.

Guide the user through writing a Product Requirements Document or feature spec. Uses a four-phase gated flow (Discovery → Specify → Plan → Tasks) to produce spec.md, plan.md, and tasks.md in the project's planning/prd/ directory. Use when the user says "write a PRD", "write a spec", "spec out this feature", "help me define requirements", or similar.

Rewrites a draft prompt intended for Claude into a stronger, more reliable one, applying Anthropic's own prompt engineering techniques (specificity, role/system framing, XML-tag structure, examples/multishot, chain-of-thought cues, explicit output formatting, prompt chaining for complex tasks). Use this skill whenever the user pastes a prompt, system prompt, skill instruction, or agent/subagent prompt and asks to improve, strengthen, tighten, fix, optimize, or rewrite it, or asks things like "how do I phrase this better," "why isn't this prompt working," "make this more reliable," or "can you clean this up" — even if they never say "prompt engineering." Also use it proactively when the user is iterating on a system prompt, skill, or agent persona and it is under-specified or clearly causing inconsistent behavior.

Run a multi-agent security review TEAM over a codebase or recent diff. Picks a specialist roster based on detected stack signals (webapp / desktop / iac / llm-agent / container / backend / mobile / etc.) from a library of 13 specialists. Each specialist writes structured JSONL + prose findings in parallel; input-validation-auditor and auth-authz-auditor run a loop-until-dry consensus fan-out (2-8 passes); every deduped finding is adversarially verified by a dedicated validator agent before it can appear in the report. Orchestrator consolidates into a single severity-ranked REPORT.md with deduped root issues, archived per-run under a known-findings.jsonl ledger that drives auto re-review. Distinct from the built-in `/security-review` (which is a single-pass branch review). Use when the user says "multi-agent security review", "security review team", "sec-review team", "audit this branch with a team", "pre-release hardening team pass", or similar. Review-only — no fixes.

Gather codebase and initiative context before planning starts — runs a graphify build or query when graphify is available locally, falls back to a manual repo sweep otherwise, then asks targeted questions and writes a single context.md. Invocable standalone or as hzt:plan's mandatory Phase 0. Use when the user says "set context", "gather context", or as the first step of hzt:plan.

Wrap up a finished round of work — verify README and CHANGELOG are current, cut a version if warranted, move completed task files into the completed/ folder, then create a feature branch if needed, commit, push, and open a PR. Run after `/hzt:do-task` has marked one or more tasks done. Takes no arguments.

Run a detailed, adversarial multi-agent review of a written proposal or specification (spec.md, PRD, RFC, design doc, architecture proposal, business case) — reviews the document, not code. Runs a steelman/inventory pass, then up to 10 specialist lenses (logic, assumptions, evidence, completeness, feasibility, alternatives, consistency, stakeholders, testability, risk), then adversarial validation that defaults to refuting each finding unless it survives, then a loop-until-dry completeness pass. Writes a single severity-ranked SPEC-REVIEW.md next to the document. Use when the user says "review this spec", "adversarial review", "poke holes in this proposal", "red team this PRD", "critique this design doc", "what's wrong with this RFC", "stress test this plan", or similar. Review-only — never edits the document.

Pre-flight sync check for registered projects. Fetches from remote, reports uncommitted changes, and handles four states — up-to-date, ahead, behind (warns + pulls), or diverged (warns, no pull). Supports single-project (cwd detection), named-project (hzt:sync key1 key2), and full-sync (hzt:sync ALL) modes.