{"id":47687051,"url":"https://github.com/sahil87/fab-kit","last_synced_at":"2026-06-13T08:01:27.356Z","repository":{"id":344381391,"uuid":"1150514910","full_name":"sahil87/fab-kit","owner":"sahil87","description":"Structured, spec-driven development workflow for AI coding agents.","archived":false,"fork":false,"pushed_at":"2026-06-07T17:50:11.000Z","size":12211,"stargazers_count":20,"open_issues_count":1,"forks_count":5,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-07T18:16:21.877Z","etag":null,"topics":["agents","ai-coding","claude-code","cli","codex","cursor","developer-tools","fab-kit","prompt-engineering","spec-driven-development","windsurf","worktrees"],"latest_commit_sha":null,"homepage":"https://shll.ai/fab-kit","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sahil87.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-02-05T11:19:47.000Z","updated_at":"2026-06-07T17:50:12.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/sahil87/fab-kit","commit_stats":null,"previous_names":["wvrdz/fab-kit","sahil87/fab-kit"],"tags_count":165,"template":false,"template_full_name":null,"purl":"pkg:github/sahil87/fab-kit","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sahil87%2Ffab-kit","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sahil87%2Ffab-kit/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sahil87%2Ffab-kit/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sahil87%2Ffab-kit/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sahil87","download_url":"https://codeload.github.com/sahil87/fab-kit/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sahil87%2Ffab-kit/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34276504,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-13T02:00:06.617Z","response_time":62,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agents","ai-coding","claude-code","cli","codex","cursor","developer-tools","fab-kit","prompt-engineering","spec-driven-development","windsurf","worktrees"],"created_at":"2026-04-02T14:54:22.646Z","updated_at":"2026-06-13T08:01:27.343Z","avatar_url":"https://github.com/sahil87.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Fab Kit\n\n\u003e Part of [@sahil87's open source toolkit](https://shll.ai) — see all projects there.\n\n[![Latest release](https://img.shields.io/github/v/release/sahil87/fab-kit)](https://github.com/sahil87/fab-kit/releases) [![Downloads](https://img.shields.io/github/downloads/sahil87/fab-kit/total)](https://github.com/sahil87/fab-kit/releases) [![Stars](https://img.shields.io/github/stars/sahil87/fab-kit?style=social)](https://github.com/sahil87/fab-kit/stargazers)\n\nA development toolkit for AI-assisted coding. It includes a 6-stage pipeline (intake → apply → review → hydrate → ship → review-PR), standalone CLI tools for [git worktree management](https://github.com/sahil87/fab-kit/blob/main/docs/specs/companions.md) (`wt`) and [idea backlogs](https://github.com/sahil87/fab-kit/blob/main/docs/specs/companions.md) (`idea`), and batch orchestration for running multiple AI agents in parallel. Plain markdown prompts, no SDK, no vendor lock-in. Works with Claude Code, Codex, Cursor, and Windsurf.\n\nAI agents write code fast. The bottleneck is now your clarity: did you define the problem well enough? Fab Kit sits at that bottleneck — it forces structured thinking before implementation, grounds every session in your project's actual context, and gets cheaper to run as agents improve.\n\n\u003e **[Try it now](#quick-start)** | **[Understand the concepts](#why-fab-kit)** | **[Install guide](docs/site/install.md)** | **[Workflows guide](docs/site/workflows.md)** | **[Glossary](https://github.com/sahil87/fab-kit/blob/main/docs/specs/glossary.md)** (new to Fab terminology?)\n\n**Contents:** [The 6 Stages](#the-6-stages) · [Prerequisites](#prerequisites) · [Quick Start](#quick-start) · [Why Fab Kit](#why-fab-kit) · [The 5 Cs](#the-5-cs-of-quality) · [Commands](#command-quick-reference)\n\n## The 6 Stages\n\nEvery change (a self-contained feature or fix with its own folder) moves through six stages:\n\n![Fab Kit 6-stage pipeline: 1 Intake → Execution (2 Apply → 3 Review) → Completion (4 Hydrate) → Shipping (5 Ship → 6 Review-PR)](https://raw.githubusercontent.com/sahil87/fab-kit/main/docs/img/pipeline-stages.svg)\n\n\u003cdetails\u003e\n\u003csummary\u003eMermaid source\u003c/summary\u003e\n\n```mermaid\nflowchart TD\n    B[\"1 INTAKE\"]\n    subgraph execution [\"Execution\"]\n        direction LR\n        A[\"2 APPLY\"] --\u003e V[\"3 REVIEW\"]\n    end\n    subgraph completion [\"Completion\"]\n        direction LR\n        AR[\"4 HYDRATE\"]\n    end\n    subgraph shipping [\"Shipping\"]\n        direction LR\n        SH[\"5 SHIP\"] --\u003e RPR[\"6 REVIEW-PR\"]\n    end\n\n    B --\u003e A\n    V --\u003e AR\n    AR --\u003e SH\n\n    style B fill:#64b5f6,stroke:#1565C0,color:#1a1a1a\n    style execution fill:#ffb74d,stroke:#E65100,color:#1a1a1a\n    style completion fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style shipping fill:#ce93d8,stroke:#7B1FA2,color:#1a1a1a\n```\n\n\u003c/details\u003e\n\n| # | Stage | Purpose | Artifact |\n|---|-------|---------|----------|\n| 1 | **Intake** | Capture intent, scope, approach | `intake.md` |\n| 2 | **Apply** | Co-generate `plan.md` (requirements + tasks + acceptance) from intake, then execute the tasks | `plan.md` + code changes |\n| 3 | **Review** | Sub-agent validates against the plan's requirements and [constitution](#code-quality-as-a-guardrail) (your project's architectural rules) | Prioritized findings report |\n| 4 | **Hydrate** | Save learnings into project memory (`docs/memory/`) | Memory updates |\n| 5 | **Ship** | Commit, push, and create a GitHub PR | Pull request |\n| 6 | **Review-PR** | Triage and fix PR review comments from humans or automated reviewers | Comments addressed |\n\nEach stage produces a persistent artifact or state update. Interrupt anything — re-run the same command to resume. All pipeline skills are idempotent.\n\nReview is performed by a **sub-agent** running in a separate context - a fresh perspective that validates against both the plan's requirements and your [project constitution](#code-quality-as-a-guardrail). Findings are prioritized (must-fix, should-fix, nice-to-have) and the agent triages them, looping back for automatic rework on the issues that matter most.\n\nA change folder looks like this:\n\n```\nfab/changes/260101-abcd-add-spinner/\n├── intake.md        # What you want and why\n├── plan.md          # Requirements + tasks + acceptance (generated at apply entry)\n└── .status.yaml     # Pipeline state (symlinked as .fab-status.yaml at repo root while this change is active)\n```\n\n## Prerequisites\n\n\u003e 📦 For the full, tool-specific install walkthrough — companion utilities, shell completion, and the new-project / existing-repo / upgrade flows — see the **[Install guide](docs/site/install.md)**.\n\n### Using Fab Kit\n\nInstall with [Homebrew](https://brew.sh/) (macOS and Linux):\n\n```bash\nbrew tap sahil87/tap\nbrew install fab-kit\n\n# Other utilities fab depends on\nbrew install yq jq gh direnv\n```\n\nThis installs the `fab` CLI (router), `fab-kit` (workspace lifecycle), and standalone tools `wt` (worktree manager) and `idea` (backlog manager).\n\n* After installing `gh`, authenticate with `gh auth login`.\n* After installing `direnv`, add the hook [to your shell](https://direnv.net/docs/hook.html).\n* Optional — activate shell completion in your shell's rc file:\n\n  ```bash\n  eval \"$(fab shell-init zsh)\"   # or bash / fish\n  ```\n\n  Works from any directory (no fab project required). Prefer saving the script to disk? Use `fab completion \u003cshell\u003e` instead.\n\n| Tool | Purpose |\n|------|---------|\n| [fab-kit](https://github.com/sahil87/fab-kit) | The `fab` CLI router, workspace lifecycle (`init`/`upgrade-repo`/`sync`), `wt`, and `idea` |\n| [yq](https://github.com/mikefarah/yq) | YAML processing for status files and schemas |\n| [jq](https://jqlang.github.io/jq/) | JSON processing for settings merge during sync |\n| [gh](https://cli.github.com/) | GitHub CLI - used for releases and PR workflows |\n| [direnv](https://direnv.net/) | Auto-loads `.envrc` to set workspace environment variables |\n\n### Developing Fab Kit\n\nIn addition to the above:\n\n```bash\nbrew install go just\n```\n\n| Tool | Purpose |\n|------|---------|\n| [Go](https://go.dev/) | Required for building binaries from source (`src/go/`) |\n| [just](https://just.systems/) | Task runner for build, test, and release recipes |\n\n## Quick Start\n\n### 1. Install\n\n#### New project\n\n```bash\nfab init\n```\n\nThis downloads the latest release to the system cache, sets `fab_version` in `fab/project/config.yaml`, and runs `fab sync` to deploy skills — all in one step. No curl scripts or manual downloads.\n\n**Then in your AI agent:**\n\n```\n/fab-setup    # Claude Code\n$fab-setup    # Codex\n```\n\nThis generates `fab/project/constitution.md` and other project configuration files. Run `fab doctor` to verify your setup.\n\nOnce setup completes, run `/fab-discuss` to load project context and orient before your first change.\n\n#### Onboarding an existing repo with prior docs\n\nIf your project already has documentation (Notion pages, Linear specs, READMEs, design docs), bootstrap memory from them before your first change:\n\n1. **Initialize the repo:**\n\n   ```bash\n   fab init        # new to Fab Kit\n   fab sync        # cloning a repo that already uses Fab Kit\n   ```\n\n2. **In your AI agent — set up project config:**\n\n   ```\n   /fab-setup\n   ```\n\n3. **Hydrate memory from your existing docs** (or from the codebase itself):\n\n   ```\n   /docs-hydrate-memory \u003cnotion-url\u003e \u003clinear-url\u003e ./README.md ./docs/\n   /docs-hydrate-memory                 # no args → generate from codebase analysis\n   ```\n\n   Accepts Notion/Linear URLs, local `.md` files, or folder paths. Safe to re-run — content is merged, not overwritten.\n\n4. **Propagate memory into structured specs:**\n\n   ```\n   /docs-hydrate-specs\n   ```\n\n   This flows memory → specs (the reverse of `hydrate`), surfacing gaps where memory covers a topic that specs don't. Top gaps are previewed for confirmation.\n\n5. **Orient before your first change:**\n\n   ```\n   /fab-discuss\n   ```\n\n#### Updating from a previous version\n\nTwo steps — one in the terminal, one in your AI agent:\n\n1. **In your terminal** — bump the kit version and re-sync:\n\n   ```bash\n   fab upgrade-repo              # upgrades to latest version\n   fab upgrade-repo 0.44.0       # upgrades to a specific version\n   ```\n\n2. **In your AI agent** — apply any data migrations:\n\n   ```\n   /fab-setup migrations    # Claude Code\n   $fab-setup migrations    # Codex\n   ```\n\n   Safe to re-run — no-op if no migrations are pending.\n\nTo re-deploy skills, scaffold structure, and sync hooks without changing the pinned version (useful after cloning):\n\n```bash\nfab sync\n```\n\n\u003e **Note:** `fab sync` runs automatically in every new worktree created by [`wt create`](https://github.com/sahil87/fab-kit/blob/main/docs/specs/companions.md#wt--worktree-isolation).\n\n### 2. Your first change\n\n\u003e 🛠️ For a task-oriented walkthrough of driving the pipeline — the per-stage command sequence, the apply⇄review auto-rework loop, `/fab-ff` vs `/fab-fff` vs `/fab-proceed`, and going parallel with worktrees — see the **[Workflows guide](docs/site/workflows.md)**.\n\nFab Kit skills are slash commands you type into an AI agent's chat, not the terminal. Open a session in your project directory:\n\n- **Claude Code:** `claude` in terminal\n- **Codex:** `codex` in terminal\n- **Cursor / Windsurf:** open the project, use the chat panel\n\nThen type the commands below in the agent's prompt. Each command runs one pipeline stage — the AI generates output in real time, so wait for it to finish before running the next.\n\n```bash\n# In your AI agent:\n\n# Creation - creates change folder, writes intake.md, activates the change, creates git branch\n/fab-new Add a loading spinner to the submit button\n\n# Apply - generates plan.md (requirements + tasks + acceptance) and implements the code, checking off tasks as it goes\n/fab-continue\n# Review - reviews implementation against the plan's requirements + constitution\n/fab-continue\n# Hydrate - saves learnings into docs/memory/\n/fab-continue\n\n# Ship - commit, push, and create a GitHub PR\n/git-pr\n# Review-PR - triage and fix PR review comments\n/git-pr-review\n\n# Archive - move the change folder out of active changes\n/fab-archive\n```\n\nAt any point, run `/fab-status` to see where you are.\n\nFor small changes, `/fab-ff` (fast-forward) runs the pipeline through hydrate in one shot - gated by a single intake [confidence score](#structured-autonomy-not-guesswork) that ensures ambiguity is low enough for safe execution. Both `/fab-ff` and `/fab-fff` (full fast-forward) auto-loop between apply and sub-agent review, fixing issues automatically before escalating to you.\n\n### 3. Going parallel\n\nWhile AI works on one change, start another in a separate [git worktree](https://git-scm.com/docs/git-worktree) (an isolated copy of your repo):\n\n```bash\n# In your terminal:\nwt create                # creates an isolated worktree with a random name\n\n# In a new AI agent session in that worktree:\n/fab-new Add error toast for failed submissions\n```\n\nEach change is a self-contained folder - multiple AI sessions run in parallel without conflicts. `/fab-new` auto-activates, so you can start working immediately. Use `/fab-draft` to queue a change without switching to it. [How the assembly line works →](https://github.com/sahil87/fab-kit/blob/main/docs/specs/assembly-line.md)\n\n### Troubleshooting\n\nRun `fab doctor` to check all prerequisites (git, yq, direnv hook, etc.) and diagnose common setup issues.\n\n- `direnv allow` doesn't work - reload your shell or run `eval \"$(direnv export zsh)\"`\n- `/fab-setup` not recognized - re-run `fab sync` to deploy skills\n- **After cloning a repo that uses Fab Kit** - run `fab sync` once. Agent skills and hooks live in `.claude/` which is gitignored by default, so each developer needs to deploy them locally.\n- **A stage fails mid-way** - run `/fab-continue` to resume from the last checkpoint. All stage artifacts are persisted, so no progress is lost.\n- **AI produces bad code** - the review sub-agent catches it. `/fab-ff` and `/fab-fff` auto-loop between apply and review (up to 3 cycles) before escalating to you.\n- **Abandon a change** - delete the change folder, or run `/fab-archive` to move it to the archive.\n\n## Why Fab Kit\n\nAI coding tools give you speed but leave you to manage quality and knowledge yourself. Fab Kit gives you all four:\n\n| [**Speed**](#parallel-by-default) | [**Knowledge**](#shared-memory-that-grows-with-your-project) | [**Quality**](#code-quality-as-a-guardrail) | [**Autonomy**](#structured-autonomy-not-guesswork) |\n|:---:|:---:|:---:|:---:|\n| Parallel changes - never idle | Compounds with every change | Constitution + self-correcting review | Confidence-scored - assumes or asks based on context |\n\n### Parallel by Default\n\n\u003c!-- Diagram: Traditional one-at-a-time workflow vs assembly line. In the traditional approach, you and AI alternate between working and idle. In the assembly line, you create batches of changes while AI executes previous batches - both stay busy. --\u003e\n```\n  ██ = working    ░░ = idle\n\n              One at a time\n              ─────────────\n\n  You    ██░░░░░░░░██░░░░░░░░██░░░░░░░░██░░░░░░░░\n  AI     ░░████████░░████████░░████████░░████████\n\n  Create, wait, review. Create, wait, review.\n  More waiting than working.\n\n\n              Assembly line\n              ─────────────\n\n  You    ██████░░█████████░██░█████████░██░░░░░░░\n  AI     ░░░░░░██████████░████████████░░████████░\n\n  Create a batch, hand off, create the next batch.\n  Both always working.\n```\n\nWithout Fab, you describe a task, wait while AI works, review, repeat. With Fab, you batch structured changes - each in its own folder and worktree - and create the next batch while AI executes the current one.\n\nThree properties make this work:\n\n- **Self-contained change folders** - Each change has its own intake, plan, and status. No shared state - parallel changes don't interfere during development.\n- **Git worktree isolation** - Each change runs in its own [worktree](https://git-scm.com/docs/git-worktree). Parallel AI sessions can't step on each other.\n- **Resumable pipeline** - Every stage produces a persistent artifact. Interrupt anything, resume later.\n\n### Shared Memory That Grows With Your Project\n\nMost AI tools give each session a private memory that disappears when the session ends. Fab saves learnings from every completed change into `docs/memory/` - a domain-organized knowledge base committed to git and shared with the entire team.\n\n```\n  ┌──────────┐    hydrate     ┌──────────────┐\n  │ plan.md  │ ─────────────▶ │ docs/memory/ │\n  └──────────┘                └──────┬───────┘\n       ▲                             │\n       │       context for next      │\n       └──────── change ─────────────┘\n```\n\nThis creates a self-reinforcing cycle:\n\n- **Every change makes the next one better** - Design decisions from `plan.md` merge into memory. Future changes load those files as context, so AI starts with real knowledge of your system instead of guessing.\n- **Team knowledge, not personal notes** - Memory lives in git. Every developer and every AI session reads the same source of truth. Onboarding means cloning the repo.\n- **Bootstrap from existing docs** - `/docs-hydrate-memory` ingests documentation from Notion, Linear, or local files. The pipeline keeps it current from there.\n- **Structured, not append-only** - Memory is organized by domain (`auth/`, `payments/`, `users/`). `/docs-reorg-memory` restructures as it grows. `/docs-hydrate-specs` updates spec files with relevant details from memory.\n\n### Code Quality as a Guardrail\n\nAI writes code fast. Without structure, it also skips requirements, ignores architectural conventions, and ships the first thing that works. Fab enforces quality through structure, a constitution, and self-correcting review.\n\n```\n        ┌───────────────────────────────┐\n        │  fab/project/constitution.md  │\n        │    MUST · SHOULD · MUST NOT   │\n        └───────────────┬───────────────┘\n                        │\n  intake → apply ⇄ review → hydrate\n             ↑       ↗\n             └───────┘\n          sub-agent review\n          with prioritized\n          findings\n```\n\n- **Stages that can't be skipped** - The pipeline requires intake before any code is written. The AI can't jump straight to implementation. Before code is written, the [SRAD framework](#structured-autonomy-not-guesswork) ensures planning decisions are grounded in context - not silently guessed.\n- **Project constitution** - `fab/project/constitution.md` defines your architectural rules using MUST/SHOULD/MUST NOT. Every plan and review checks against it - not just the change's requirements.\n- **Review that fixes, not just flags** - A **sub-agent** reviews in a fresh context, returning prioritized findings. The applying agent triages by severity and loops back to the right stage:\n\n| Review finds | Priority | Loops back to | What happens |\n|-------------|----------|---------------|--------------|\n| Requirement mismatch, failing tests | Must-fix | → apply | Unchecks failed tasks in `plan.md`, re-runs them |\n| Missing/wrong tasks | Must-fix | → apply | Regenerates `plan.md`, re-applies |\n| Requirements were wrong | Must-fix | → apply | Updates `plan.md`'s `## Requirements`, regenerates tasks |\n| Code quality issue | Should-fix | → apply | Addressed when clear and low-effort |\n| Style suggestion | Nice-to-have | - | May be skipped |\n\n`/fab-fff` and `/fab-ff` auto-loop between apply and review (up to 3 cycles) - each re-review uses a fresh sub-agent. `/fab-ff` falls back to interactive rework after exhausting auto-retries. A typical `/fab-fff` run uses 2-4 agent turns per stage; the sub-agent review spawns a separate context.\n\n#### The 5 Cs of Quality\n\nFive configuration files shape how AI works in your project. Each answers a different question:\n\n| C | File | Question |\n|---|------|----------|\n| **Constitution** | `fab/project/constitution.md` | What are our non-negotiable principles? |\n| **Context** | `fab/project/context.md` | What are we working with? |\n| **Code Quality** | `fab/project/code-quality.md` | How should code look when we write it? |\n| **Code Review** | `fab/project/code-review.md` | What should we look for when we validate? |\n| **Config** | `fab/project/config.yaml` | What are the project's factual settings? |\n\nNotice the author-vs-critic split: `code-quality.md` guides the **writing** agent during apply - coding standards, anti-patterns, test strategy. `code-review.md` guides the **reviewing** sub-agent during review - severity definitions, scope boundaries, rework budget. Different cognitive modes, different concerns, different files.\n\nAll five are optional except `constitution.md` and `config.yaml`. They live in `fab/project/`. Run `/fab-setup` to generate them from scaffolds with sensible defaults.\n\n### Structured Autonomy, Not Guesswork\n\nAI tools either ask too many questions or silently assume. Fab uses **SRAD** - a 4-dimension framework - to decide which to do for each decision point during planning.\n\n**S**ignal strength · **R**eversibility · **A**gent competence · **D**isambiguation type\n\nEach dimension scores how safe it is to assume. The scores aggregate into a confidence grade:\n\n| Grade | What happens |\n|-------|-------------|\n| **Certain** | Proceeds silently - deterministic from config/codebase |\n| **Confident** | Proceeds, noted in assumptions summary |\n| **Tentative** | Proceeds with marker - resolvable via `/fab-clarify` |\n| **Unresolved** | Blocks and asks - too ambiguous to guess |\n\nGrades aggregate into a **confidence score** that gates `/fab-ff`. If ambiguity is too high, the pipeline refuses to run and tells you what to clarify - no silent guesswork, no unnecessary interruption. [How SRAD works →](https://github.com/sahil87/fab-kit/blob/main/docs/specs/srad.md)\n\n## Command Quick Reference\n\n\u003e **Prefix:** Use `/fab-*` in Claude Code, `$fab-*` in Codex.\n\n\u003e 📖 The tables below are a quick reference. For the full, auto-generated command reference — every subcommand, flag, and usage string — see **[shll.ai/tools/fab-kit/commands](https://shll.ai/tools/fab-kit/commands/)**.\n\n### Pipeline\n\n| Command | Purpose |\n|---------|---------|\n| `/fab-new \u003cdescription\u003e` | Start a new change — creates the intake, activates it, and creates the git branch |\n| `/fab-draft \u003cdescription\u003e` | Create a change intake without activating it (queue for later) |\n| `/fab-continue` | Advance to the next stage (or reset to a specific stage) |\n| `/fab-ff` | Fast-forward through hydrate — confidence-gated, auto-rework loop |\n| `/fab-fff` | Fast-forward further through ship + PR review — same gates as ff |\n| `/fab-clarify` | Refine the current artifact — resolve gaps without advancing |\n| `/fab-archive` | Archive a completed change (or restore an archived one) |\n| `/fab-proceed` | Context-aware orchestrator — detects state, runs setup steps, then delegates to `/fab-fff` |\n\n### Setup \u0026 Status\n\n| Command | Purpose |\n|---------|---------|\n| `/fab-setup` | Bootstrap fab/ structure, manage config/constitution, apply migrations |\n| `/fab-status` | Show current change state — name, branch, stage, checklist, next command |\n| `/fab-switch` | Switch active change (or list available changes) |\n| `/fab-help` | Show workflow overview and command summary |\n| `/fab-discuss` | Load project context for an exploratory discussion session |\n\n### Git\n\n| Command | Purpose |\n|---------|---------|\n| `/git-branch` | Create or switch to the git branch matching the active change |\n| `/git-pr` | Commit, push, and create a GitHub PR |\n| `/git-pr-review` | Process PR review comments — triage and fix feedback |\n\n### Documentation\n\n| Command | Purpose |\n|---------|---------|\n| `/docs-hydrate-memory [sources...]` | Ingest external docs or generate memory from codebase analysis |\n| `/docs-hydrate-specs` | Detect gaps between memory and specs, propose additions |\n| `/docs-reorg-memory` | Analyze memory files for themes, suggest reorganization |\n| `/docs-reorg-specs` | Analyze spec files for themes, suggest reorganization |\n\n### Multi-Agent Coordination\n\nThe operator (`/fab-operator`) is a long-running coordination layer that sits in its own tmux pane, observing and directing agents across other panes. It is optional and useful when running multiple agent sessions simultaneously.\n\n| Command | Purpose |\n|---------|---------|\n| `/fab-operator` | Multi-agent coordination — monitoring, auto-answering, autopilot queues, dependency-aware spawning |\n\n[Operator version history →](https://github.com/sahil87/fab-kit/blob/main/docs/specs/operator.md)\n\n### CLI Subcommands\n\n| Command | Purpose |\n|---------|---------|\n| `fab sync` | Repair symlinks, scaffold structure, deploy skills |\n| `fab doctor` | Diagnose common setup issues |\n| `fab fab-help` | Print workflow overview to terminal |\n| `fab operator` | Launch operator in a dedicated tmux tab |\n| `fab batch new` | Create worktree tabs from backlog items |\n| `fab batch switch` | Open tmux tabs in worktrees for one or more changes |\n| `fab batch archive` | Archive multiple completed changes in one session |\n\n## Stage Coverage by Command\n\nWhich pipeline stages each command covers. Taller bars = more automation. Read left-to-right from most manual to most automated. **▶** marks typical entry points — start with `/fab-discuss` (exploratory) or `/fab-new` (ready to build). Arrows show the typical path from idea to PR. Dashed borders indicate optional/utility stages. Empty cells = not covered by that command.\n\n| Color | Category | Commands |\n|-------|----------|----------|\n| 🟦 Cyan | Explore (read-only) | `/fab-discuss` |\n| 🟧 Amber | Manual (single action) | `/fab-draft`, `/fab-switch`, `/fab-continue` |\n| ⬜ Blue-grey (dashed) | Git utilities | `/git-branch`, `/git-pr`, `/git-pr-review` |\n| 🟩 Green | Automated pipeline (multi-stage) | `/fab-new`, `/fab-ff`, `/fab-fff`, `/fab-proceed` |\n| ◻️ Grey | Fab pipeline stage (row label) | intake, change active, apply, review, hydrate |\n| ▶ | Typical entry point | `/fab-discuss`, `/fab-new` |\n\n![Stage coverage by command: a matrix of pipeline stages (rows) by command (columns), color-coded — cyan Explore, amber Manual, blue-grey dashed Git utilities, green Automated pipeline. fab-discuss covers context; fab-draft intake; fab-switch change active; git-branch branch name; fab-new intake/change active/branch name; fab-continue, fab-ff, fab-fff, fab-proceed each cover apply/review/hydrate; fab-fff and fab-proceed also ship and review-pr; git-pr ship; git-pr-review review-pr](https://raw.githubusercontent.com/sahil87/fab-kit/main/docs/img/stage-coverage.svg)\n\n\u003cdetails\u003e\n\u003csummary\u003eMermaid source\u003c/summary\u003e\n\n```mermaid\nblock-beta\n    columns 13\n\n    hdr_label[\"wt create →\"]:1 hdr_discuss[\"▶ /fab-discuss\"] hdr_draft[\"/fab-draft\"] hdr_switch[\"/fab-switch\"] hdr_branch[\"/git-branch\"] hdr_new[\"▶ /fab-new\"] hdr_continue[\"/fab-continue\"] hdr_ff[\"/fab-ff\"] hdr_gitpr[\"/git-pr\"] hdr_gitprreview[\"/git-pr-review\"] hdr_fff[\"/fab-fff\"] hdr_proceed[\"/fab-proceed\"] space:1\n\n    space:13\n\n    row_ctx[\"context\"]:1 discuss_ctx[\"project context\"]:1 space:11\n    row_intake[\"intake\"]:1 space:1 draft_intake[\"intake\"]:1 space:2 new_intake[\"intake\"]:1 space:5 proceed_intake[\"intake\"]:1 space:1\n    row_active[\"change active\"]:1 space:2 switch_active[\"change active\"]:1 space:1 new_active[\"change active\"]:1 space:5 proceed_active[\"change active\"]:1 space:1\n    row_branch[\"branch name\"]:1 space:3 branch_branch[\"branch name\"]:1 new_branch[\"branch name\"]:1 space:5 proceed_branch[\"branch name\"]:1 space:1\n    row_apply[\"apply\"]:1 space:5 cont_apply[\"one stage\"]:1 ff_apply[\"apply\"]:1 space:2 fff_apply[\"apply\"]:1 proceed_apply[\"apply\"]:1 space:1\n    row_review[\"review\"]:1 space:5 cont_review[\"one stage\"]:1 ff_review[\"review\"]:1 space:2 fff_review[\"review\"]:1 proceed_review[\"review\"]:1 space:1\n    row_hydrate[\"hydrate\"]:1 space:5 cont_hydrate[\"one stage\"]:1 ff_hydrate[\"hydrate\"]:1 space:2 fff_hydrate[\"hydrate\"]:1 proceed_hydrate[\"hydrate\"]:1 space:1\n    row_ship[\"ship\"]:1 space:5 space:1 space:1 gitpr_ship[\"PR raised\"]:1 space:1 fff_ship[\"PR raised\"]:1 proceed_ship[\"PR raised\"]:1 space:1\n    row_prreview[\"review-pr\"]:1 space:5 space:1 space:1 space:1 gitprreview_prreview[\"PR reviewed\"]:1 fff_prreview[\"PR reviewed\"]:1 proceed_prreview[\"PR reviewed\"]:1 space:1\n\n    %% Arrows — multiple paths from top-left to bottom-right\n    discuss_ctx --\u003e draft_intake\n    discuss_ctx --\u003e new_intake\n    discuss_ctx --\u003e proceed_intake\n    draft_intake --\u003e switch_active\n    switch_active --\u003e branch_branch\n    new_branch --\u003e cont_apply\n    new_branch --\u003e ff_apply\n    new_branch --\u003e fff_apply\n    ff_hydrate --\u003e gitpr_ship\n\n    %% Header styles\n    style hdr_label fill:none,stroke:none,color:#999\n    style hdr_discuss fill:#4dd0e1,stroke:#00838f,color:#1a1a1a\n    style hdr_draft fill:#ffb74d,stroke:#E65100,color:#1a1a1a\n    style hdr_switch fill:#ffb74d,stroke:#E65100,color:#1a1a1a\n    style hdr_new fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style hdr_branch fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n    style hdr_continue fill:#ffb74d,stroke:#E65100,color:#1a1a1a\n    style hdr_ff fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style hdr_gitpr fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n    style hdr_gitprreview fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n    style hdr_fff fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style hdr_proceed fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n\n    %% Row labels — grey for fab pipeline stages, blue-grey dashed for git stages\n    style row_ctx fill:#bdbdbd,stroke:#757575,color:#1a1a1a\n    style row_intake fill:#bdbdbd,stroke:#757575,color:#1a1a1a\n    style row_active fill:#bdbdbd,stroke:#757575,color:#1a1a1a\n    style row_branch fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n    style row_apply fill:#bdbdbd,stroke:#757575,color:#1a1a1a\n    style row_review fill:#bdbdbd,stroke:#757575,color:#1a1a1a\n    style row_hydrate fill:#bdbdbd,stroke:#757575,color:#1a1a1a\n    style row_ship fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n    style row_prreview fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n\n    %% fab-discuss (Explore — teal)\n    style discuss_ctx fill:#4dd0e1,stroke:#00838f,color:#1a1a1a\n\n    %% fab-draft (Manual — amber)\n    style draft_intake fill:#ffb74d,stroke:#E65100,color:#1a1a1a\n\n    %% fab-switch (Manual — amber)\n    style switch_active fill:#ffb74d,stroke:#E65100,color:#1a1a1a\n\n    %% fab-new (Automation — green, creates intake + activates + branches)\n    style new_intake fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style new_active fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style new_branch fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n\n    %% git-branch (Git utilities — blue-grey)\n    style branch_branch fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n\n    %% fab-continue (Stage advance — amber)\n    style cont_apply fill:#ffb74d,stroke:#E65100,color:#1a1a1a,stroke-dasharray: 5 5\n    style cont_review fill:#ffb74d,stroke:#E65100,color:#1a1a1a,stroke-dasharray: 5 5\n    style cont_hydrate fill:#ffb74d,stroke:#E65100,color:#1a1a1a,stroke-dasharray: 5 5\n\n    %% fab-ff (Automation — green)\n    style ff_apply fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style ff_review fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style ff_hydrate fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n\n    %% git-pr (Git utilities — blue-grey)\n    style gitpr_ship fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n\n    %% git-pr-review (Git utilities — blue-grey)\n    style gitprreview_prreview fill:#b0bec5,stroke:#546e7a,color:#1a1a1a,stroke-dasharray: 5 5\n\n    %% fab-fff (Automation — green)\n    style fff_apply fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style fff_review fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style fff_hydrate fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style fff_ship fill:#81c784,stroke:#2E7D32,color:#1a1a1a,stroke-dasharray: 5 5\n    style fff_prreview fill:#81c784,stroke:#2E7D32,color:#1a1a1a,stroke-dasharray: 5 5\n\n    %% fab-proceed (Automation — green)\n    style proceed_active fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style proceed_intake fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style proceed_branch fill:#81c784,stroke:#2E7D32,color:#1a1a1a,stroke-dasharray: 5 5\n    style proceed_apply fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style proceed_review fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style proceed_hydrate fill:#81c784,stroke:#2E7D32,color:#1a1a1a\n    style proceed_ship fill:#81c784,stroke:#2E7D32,color:#1a1a1a,stroke-dasharray: 5 5\n    style proceed_prreview fill:#81c784,stroke:#2E7D32,color:#1a1a1a,stroke-dasharray: 5 5\n```\n\n\u003c/details\u003e\n\n**Quick reference** — which stages does each command cover?\n\n| Stage | `/fab-discuss` | `/fab-draft` | `/fab-switch` | `/git-branch` | `/fab-new` | `/fab-continue` | `/fab-ff` | `/git-pr` | `/git-pr-review` | `/fab-fff` | `/fab-proceed` |\n|-------|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|\n| context | ✅ | | | | | | | | | | |\n| intake | | ✅ | | | ✅ | | | | | | ✅ |\n| change active | | | ✅ | | ✅ | | | | | | ✅ |\n| branch name | | | | ✅ | ✅ | | | | | | ✅ |\n| apply | | | | | | ✅ | ✅ | | | ✅ | ✅ |\n| review | | | | | | ✅ | ✅ | | | ✅ | ✅ |\n| hydrate | | | | | | ✅ | ✅ | | | ✅ | ✅ |\n| ship | | | | | | | | ✅ | | ✅ | ✅ |\n| review-pr | | | | | | | | | ✅ | ✅ | ✅ |\n\n## Companion tools\n\nfab-kit's Homebrew formula declares **wt** and **idea** as dependencies, so `brew install sahil87/tap/fab-kit` installs all four CLIs (`fab`, `fab-kit`, `wt`, `idea`) on PATH transitively. They're independent projects with their own release cadences:\n\n| Tool | Role in the fab workflow | Repo |\n|------|--------------------------|------|\n| **wt** | Worktree isolation — each change runs in its own worktree (the foundation of [parallel changes](#parallel-by-default)). Used by `fab batch new` and `fab batch switch`. | [sahil87/wt](https://github.com/sahil87/wt) |\n| **idea** | Per-repo backlog (`fab/backlog.md`) that feeds `/fab-new`. `fab batch new` reads open ideas and creates a worktree per item. | [sahil87/idea](https://github.com/sahil87/idea) |\n\nSee [companions.md](docs/specs/companions.md) for the integration architecture.\n\n## Learn More\n\n- **[The Assembly Line](docs/specs/assembly-line.md)** - batch scripts, Gantt charts, and the full numbers behind parallel development\n- **[Design \u0026 Workflow Details](docs/specs/overview.md)** - principles, detailed stage descriptions, example workflows\n- **[User Flow Diagrams](docs/specs/user-flow.md)** - visual maps of the full pipeline, shortcuts, rework paths, and state machine\n- **[Full Command Reference](docs/specs/skills.md)** - detailed behavior for every `/fab-*` skill\n- **[SRAD Autonomy Framework](docs/specs/srad.md)** - how the pipeline handles ambiguity, confidence scoring, and autonomous execution gates\n- **[Glossary](docs/specs/glossary.md)** - all Fab terminology defined\n- **[Contributing](CONTRIBUTING.md)** - developing, extending, and releasing Fab Kit\n\n## Development\n\nBuilding Fab Kit from source requires Go and `just` (see [Developing Fab Kit](#developing-fab-kit) above).\n\n```bash\njust test                      # run all Go tests (fab + fab-kit)\njust build                     # build binaries for your platform → dist/bin/\nrelease.sh [patch|minor|major] # cut a release (bumps VERSION, tags, pushes, creates GitHub Release)\n```\n\nFull contributor guide: [CONTRIBUTING.md](CONTRIBUTING.md).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsahil87%2Ffab-kit","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsahil87%2Ffab-kit","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsahil87%2Ffab-kit/lists"}