worktree-ops

Spec workflow by Zak Sakata: write-spec is the workflow entrypoint that turns a bare idea into a spec — eliciting and distilling requirements (full rigor) before drafting concise, scannable feature specs at a requested rigor (light/standard a code-free, implementation-agnostic WHAT to full deep spec that may pin implementation) that open with a flat, id'd Acceptance Criteria contract (optionally organized into ordered named groups); refine-spec hardens a draft into an accurate, not-over-engineered, implementation-ready spec via a grounded multi-pass review loop, commits the grounded AC group order, and hunts unstated non-functional constraints; launch-spec compiles a verified spec into one of three drivers (/goal, ultracode, /batch), each completed by a verify-spec gate on every acceptance criterion (emit-only), phasing a large or hard-sequenced build by AC group; verify-spec checks that the implementation actually matches the spec's claims and every acceptance criterion, grounded against the real code, git history, and live state — scaling each criterion's evidence standard and recording a per-AC verification method — and flags delivered code that maps to no criterion (backward coverage); on a spec re-run it drifts against the last clean verification, re-grounding only criteria whose evidence moved and flagging regressions. spec-ops commits the spec artifact at each stage (write the draft, refine the ready spec with Stop-hook enforcement, launch bakes a per-phase commit cadence into the /goal driver), each commit scoped to the spec file and never pushed. A verify→refine handoff carries verify-spec's backward-sweep proposed ACs to refine-spec via /tmp (hook-written), so a missed-requirement finding amends the spec on the next refine run without re-keying; verify stays read-only.

A collection of Claude Code utilities by Zak Sakata

Ralph Loop — autonomous agentic coding workflow with sandbox isolation, scoped memory, and self-managing task iteration

Run a small team's entire software lifecycle on GitHub Projects v2 — deterministic, free, and GitHub-native. scaffold-repo copies a golden-template Project (fields, 8 views, 9 Insights charts) across the org and installs the repo automation (issue forms, PR template, board-sync + signals-sync workflows, the self-contained board-status deploy action, release notes, CODEOWNERS, no-squash merge setting); intake-issues turns a raw dump into tiered, AC-bearing issues by delegating the spec body + Acceptance Criteria to spec-ops (write-spec at the tier's rigor, refine-spec for T3) and sizing/Epic-splitting from the AC-group count; sync-signals recomputes the auto Gantt-signal fields (Schedule health, Slippage, Blast radius, Blocked) from the native blocked-by DAG and posts the project Status update. The board tracks the full branch -> PR -> staging -> prod flow with no hand-maintenance: Status writes are idempotent + monotonic across three loosely-coupled layers (native built-ins, the event-driven board-sync, the opt-in board-status deploy step), every Projects v2 write uses a GitHub App installation token (never GITHUB_TOKEN), schema edits diff before mutate to keep option/iteration IDs stable, and a skill-scoped PreToolUse guard blocks --squash and prod actions without green checks. No metered AI in Phase 1.

Manage Claude Code skills across any project and marketplace: configure which plugins a project uses, push local skills up to a central marketplace, keep them in sync, and remove them. Adapts to any repo layout. Authoring new skills is delegated to the native skill-creator skill.