make-it-work

Maps your codebase and builds a structured knowledge base that Claude loads before doing any work. Two rule files: architecture.md is the how (domains, components, code areas), product.md is the what (use cases, actors, business rules). Plus one skill per functional domain and use case - minimal, precise, loaded on demand. The cross-reference map connects everything: every domain skill points to the use cases it affects, every use case skill points to the domains it touches. Claude follows these links automatically - when planning a feature it traces which domains are involved; when planning tests it finds which use cases are affected. Part of what go-deep builds is a hard enforcement rule in CLAUDE.md: before every commit, Claude checks whether any skill or doc needs updating. Nothing ships without the knowledge base staying in sync with the code. Run it once when you onboard a project.

Acts as a Product Analyst before development begins. Loads the project skills relevant to the ticket, digs into the affected code, and surfaces every gap - unclear language, missing edge cases, conflicting requirements, unstated assumptions - then walks you through them one question at a time. The output is a Gherkin-ready refined spec. Unknown unknowns become explicit. Requirements are solid before a single line of code is written. Teams use it before refinement meetings so developers arrive with focused questions - or post the output directly to the Jira ticket for product to review asynchronously.

Turns an agreed spec or refined ticket into an execution-ready implementation plan before any code is written. Loads the project's guidance and relevant skills, investigates the real code paths across one or more repositories, closes technical and scoping gaps with you, and writes an atomic, verifiable plan to make-it-work/plan-<TICKET>.md.

Acts as a reviewer grounded in the project's own documentation instead of generic intuition. Runs three passes - business correctness against the uc-* skills, regression safety against the domain-* skills and architectural constraints, and coding standards against CLAUDE.md - then a docs-sync check to confirm skills were updated alongside behavior. Emits a verdict-first, evidence-dense report, both as a pasteable file and a scannable chat summary. Use it to review a pull request or diff in any repo that keeps the go-deep knowledge base (CLAUDE.md plus uc-*/domain-* skills and .claude/rules docs).

Acts as a senior product coach to help you write a complete, elaboration-ready epic for any work management tool. Runs five structured phases - context ingestion, discovery interview, internal analysis, criterion-by-criterion validation, and epic generation - covering value proposition, target users & permissions, KPIs, use cases with Gherkin acceptance criteria, rollout plan, and definition of done.

Breaks an oversized requirement into a small, ordered backlog of independently valuable, sprint-sized slices. Preserves the epic-level goal while making uncertainty, dependencies, and delivery order visible. Picks the split strategy that best preserves independent value - functional, workflow, data, role, or technical-risk - then writes each slice as a Gherkin-ready user story, ordered so the riskiest unresolved work surfaces first.

The onboarding step after go-deep: builds one repo's test-strategy skill, .claude/skills/test-strategy/SKILL.md. The skill records where that repo's tests live - including in other repos, such as a separate QA automation repo - how to run each suite and what it needs (env vars, services, CI-only suites), and where new tests of each layer belong. It also builds .claude/testing/test-map.json, shared project metadata connecting repo-qualified use cases and domains to tests in any registered repo. When no real tests exist, it discusses the testing strategy as part of onboarding - distinguishing current coverage, recommended target coverage, and a feasible first adoption phase. Run it once in each repo, right after go-deep.

Runs a project's regression suite - the full suite, one repo's suite (full:<repo>), or tests mapped to repo-qualified use-case and domain tokens. It reads each repo's test-strategy skill for its test locations, commands and prerequisites, queries the maintained map, reuses unchanged relationships and reassesses affected tests in memory. Results are reported live in chat, with nothing persisted to disk. Use it directly during day-to-day development to check a change against the regression suite, full or scoped. It's also the shared implementation execute calls as its completion gate at the end of a plan.

Finds which repositories own a ticket. It first checks whether the ticket's exact identifiers, endpoints, and UI labels already exist - leading with verify and finish when implementation is found - then shortlists repos using docs, domain and use-case skills, and bounded code searches. Workspace detection accepts catalog metadata, repo lists, and workspace configs as well as CLAUDE.md, and assesses all repos by default, even in a large sibling-repo workspace. Everything lands in one report, <TICKET>-repos.md, with evidence, ownership sources and conflicts, while the terminal shows a compact Definite repos / Owner(s) / Evidence table. Unlike the close-the-gaps, plan-the-work, execute, review-the-pr pipeline, it ships standalone - run it before that pipeline whenever a ticket's home repo isn't obvious.

Implements a plan that plan-the-work already wrote, step by step: it writes each step's code and re-runs that step's tests until they pass, with a 5-attempt retry limit before asking for help. It halts the whole plan rather than guessing whenever a failing test looks like a real product-behavior question instead of a test bug. Once every step is green it runs run-regression as a completion gate - the tests mapped to the plan's touched domains and use cases, plus the full suites its verification policy requires - and stops for your triage on a gate failure instead of auto-fixing. It never commits on your behalf, leaving finished work in the working tree for you to review.

Orchestrates the whole pipeline for one ticket: it checks the project has its go-deep context, runs close-the-gaps, assesses the ticket's risk, implements it in the matching mode, reviews it with review-the-pr, and finishes by syncing the project's skills and rules files with what was actually built. Low risk runs Lightweight - a fresh subagent implements the spec directly, with the independent review as verification. Medium and High risk run TDD: the full plan-the-work to execute pipeline with its regression gate and fix/replan loops. A Lightweight run escalates once to TDD when fixes start breaking earlier work or the implementation reveals more risk. Force a mode with --mode lightweight or --mode tdd.