lets-workflow

🌱 LETS Workflow

A development workflow plugin for Claude Code

Stop babysitting your AI. Start shipping with it.

---

Claude Code is powerful, but without structure it drifts - forgets context between sessions, silently changes approach when something fails, reviews its own code with no outside perspective, and loses track of what was decided and why.

LETS fix this. You get a team of 15 specialized AI agents, a structured development workflow, and a PR review system that posts inline comments directly to GitHub - all from the terminal. Every session has a task. Every commit links to it. Context survives across sessions and conversation compaction.

Why LETS?

You don't just chat with AI. You run a process — /lets:* commands and 15 expert agents cover the whole development cycle, every change is reviewed by the right specialists, and every decision is made deliberately, with you in the loop.

• A complete workflow, not a chat box. One loop from start to ship — restore context and pick a task, plan the work, build it, review it, open a PR, close the task. The plugin keeps Claude on the rails the whole way; nothing falls through the cracks.
• Plan before you build. Pulse and clean up the backlog, design the architecture with real codebase exploration and expert review, then execute step by step behind approval gates. Choices are made on purpose, not improvised.
• Every change reviewed by the right experts. 15 specialized agents - the relevant ones select themselves based on what changed - security for auth code, database for migrations, architect for structure. Findings come tiered by severity, so you act on what matters. Plus an actor agent — point it at a senior iOS dev's profile, a UX designer's, anyone — and get their take.
• You decide, always. Commit, push, PR, merge - every state-changing step waits for your "go". The AI proposes and explains its reasoning; it never silently switches approach. Transparency by design.
• Context that survives. Tasks, decisions, and discovery notes live in beads and outlast conversation compaction and new sessions - pick up exactly where you left off.
• Built for teams. Shared task database via Dolt, Agent Teams that implement multiple tasks in parallel (each in its own worktree, plan approved by the lead), and worktrees for hands-on parallel sessions.
• GitHub-native PR review. Agents analyze the PR, you discuss findings, they post inline comments to the exact lines, follow up on fixes, approve or request changes - without leaving the terminal.
• Built on the latest Claude Code features. Ultrathink for deep analysis, interactive UI for decisions, native plan mode for execution.

LETS statusline and /lets:review command in action

🚀 Quick Start

LETS is two pieces: a small lets CLI on your $PATH, and the plugin inside Claude Code. Install both, then initialize your project.

1. Install the CLI

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/restarter/lets-workflow/main/scripts/install.sh | bash

You also need beads (bd) on $PATH — LETS uses it for task tracking. You don't have to learn beads: the plugin drives bd entirely for you, so just get it installed. Its install guide has all the options; the quick one-liner:

curl -fsSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh | bash

Manual download, Windows, source builds, troubleshooting → docs/installation.md.

2. Install the plugin

In Claude Code:

/plugin marketplace add restarter/lets-workflow
/plugin install lets

Install scope: Claude Code will ask where to install — all three options work:

• "Install for all collaborators on this repository" (project scope) — recommended for shared repos; the choice lands in .claude/settings.json, so teammates inherit lets without re-installing.
• "Install for you, in this repo only" (local scope) — fine for a solo or throwaway project; not committed.
• "Install for yourself everywhere" (user scope) — one install for all your projects. After installing, /lets:init in any project offers lets init --user: global workflow rules land in ~/.claude/rules/lets-rules.md and your personal defaults (language, launcher) in ~/.lets/.env — every project gets LETS without per-project setup. Project rules override global on conflict. Details, precedence, and the opt-out limitation: docs/installation.md.

Stay current (do this once): in /plugin → Marketplaces → lets-workflow, Enable auto-update — the plugin then tracks every release on its own. Staying current then collapses to a single self-driving loop: run /lets:update, do the one thing it says, re-run until it prints ✓ Everything on vX.Y.Z — each run advances one step (binary → plugin → reload → done), the binary step offers to run the installer in-session, and rules never sync to a plugin that's still behind.

(Or install from a local clone — git clone https://github.com/restarter/lets-workflow, then /plugin marketplace add ./lets-workflow and /plugin install lets — handy for hacking on the plugin: edit the clone, then /reload-plugins to pick up your changes.)

3. Initialize your project

cd your-project
claude

Then, inside the Claude Code session:

/lets:init

/lets:init creates .lets/ (config + statusline) and runs bd init if beads is installed. From there, start each work session with /lets:start — the full loop is in Using LETS below.

📖 Commands

→ Full docs: docs/commands.md

Session & Task

Command	Description
/lets:start	Start session - restore context, show tasks, create feature branch (--main = no-task project-assistant mode)
/lets:end	End session - save progress, sync tasks, write snapshot (--session, aliases --snapshot / --pre-compact / --compact, banks a snapshot without ending)
/lets:commit	Commit with review and conventional commit format
/lets:done	Finish task - create PR (GitHub or Bitbucket) or merge locally
/lets:status	Read-only orient snapshot — where you are, what's in flight, what's next (tracker-universal)
/lets:note	Add note to active task (--session, aliases --snapshot / --pre-compact / --compact, snapshots the session)

Planning & Execution

Command	Description
/lets:backlog	Backlog review (multi-agent, --workflow = off-context) + --fast quick no-agent pulse + interactive cleanup triage
/lets:plan	Structured planning - explore codebase, design architecture, write plan (--fast = orchestrator-only, no subagents; --idea = concept document, no code)
/lets:plan-workflow	PREVIEW - autonomous planning via a Dynamic Workflow: goal + rubric up front, off-context, you approve at the end (--fast = lean budget)
/lets:execute	Execute plan from /lets:plan via native plan mode - straight-through by default, or --step / --auto / --team
/lets:team	Parallel implementation with Agent Teams
/lets:worktree	Create/manage worktrees for parallel sessions
/lets:statusline	Manage & persist statusline appearance - light/dark, compact, hidden rows

Sessions & Agents

→ Full docs: docs/messaging.md

Command	Description
/lets:orc	Talk to the repo's orchestrator or a named peer session
/lets:peer	Alias: /lets:peer <name> <verb> [text] = /lets:orc with a target
/lets:hub	Orca addon: orchestrators across projects - read-only ask to a stopped one, wake one for gated work
/lets:handoff	Hand-off brief so another agent (fresh session, Codex, Antigravity, external reviewer) can pick up the exact state and review it - same target selectors as /lets:review, plus --commits / --range. --codex runs it through Codex headless, --send types it into an agent's Orca tab, and the report comes back verified against the code; --execute --send hands an approved plan to that tab to implement instead (old name /lets:review-handoff is a deprecated alias)

Review & Analysis

Command	Description
/lets:check	Inline 6-perspective sanity check, no subagents
/lets:review	Full code review with dynamic agent selection + verify pass
/lets:github-pr	GitHub PR review lifecycle - analyze, discuss, post inline, follow-up, approve
/lets:review-round	Work through a received review round - triage comments, record decisions, one final edit-pass
/lets:opinion	Technical decision analysis (dynamic expert agents in parallel)
/lets:ask	Quick expert consultation (single agent) - /lets:ask <expert> <question>
/lets:research	Web-sourced cited answer to an external/technical question - cross-check flags weak/contradicted claims (--workflow off-context, --project repo-grounded)

Init & Update

Command	Description
/lets:init	Initialize LETS in current project
/lets:update	Sync project with the current release - .lets/.env + rules self-heal, plus version status for the lets binary and the plugin

🤖 Expert Agents

→ Full docs: docs/agents.md

LETS ships 15 specialized agents. You don't have to pick them by hand — the commands that use agents (/lets:review, /lets:opinion, /lets:ask, /lets:plan, /lets:backlog, /lets:research, /lets:team) look at what you're doing and bring in only the ones that fit. When you want one specific colleague, /lets:ask <expert> <question> goes straight to them.

Agent	Expertise
architect	System design, patterns, SOLID, coupling
backend	APIs, business logic, error handling, performance
frontend	UI components, state management, accessibility
security	Vulnerabilities, auth, crypto, secrets, input validation
database	Schema design, migrations, query optimization, transactions
devops	Docker, CI/CD, deployment config, shell scripts
qa	Test strategy, coverage, assertion quality, mocking
compliance	Project standards and conventions (CLAUDE.md, style)
docs	Documentation sync, README accuracy, changelog
pragmatist	ROI analysis, overengineering detection, scope creep
git-historian	Blame analysis, past-decision context, change patterns
explorer	Codebase mapping, pattern discovery (used in /lets:plan)
implementer	Full-stack implementation (used by /lets:team)
skeptic	Verifier, never a reviewer: tries to refute each /lets:review finding and cross-checks each /lets:research claim
actor	Any expert personality loaded from a URL or local file

Dynamic selection. Each command analyzes the change (or the plan, or the question) and selects only the experts that matter — touch auth code and security, backend, and architect join; a pure docs update gets docs + compliance and nothing else; a full-stack feature can pull in up to 12, each focused on its domain. (compliance and docs always join a review. For plan reviews, the picks come from signals in the plan text — migrations, API endpoints, Docker configs, ….)