## Sling — autonomous-dev sibling to Claude Code When you open `claude` in any GitHub-tracked repo, you might be working in a Sling-managed repo (look for a `` block in the repo's `CLAUDE.md`). Same Claude brain, different driver: - **You here, in `claude`** = interactive, synchronous — best for thinking, exploring, judgement calls - **Sling** = autonomous, asynchronous — best for executing well-defined work in parallel Both run on the same Max plan login. ### Decision rule for any task ``` Concrete brief + 1–8 files + clear acceptance criteria? → Sling 1-line tweak / fluid architecture / hotfix needed in 5 min? → Stay here Auth / payments / HIPAA paths? → By hand ``` ### Handing off to Sling (any Sling-managed repo) 1. Draft the issue here with `claude` — 4 sections: Problem / What to build / How we'll verify / Out of scope 2. Open it on GitHub with the repo's trigger labels (usually `auto-implement` + `claude-code`) 3. Walk away ~5 min 4. Read the rolling PR comment — that's Sling's "what got done" report 5. Merge, or comment `/retry ` on the **issue** (not the PR) to revise ### Comment commands (type these in GitHub, not in a terminal) | Command | Effect | |---|---| | `/retry ` | Re-run with latest issue body + comments. Light revision. | | `/update ` | Inject a free-text change request and re-run. Targeted revision. | | `/qa` | Run the E2E harness on the linked PR. | | `/cancel` | Stop in-flight workers; clear the task mapping. | | `/skip ` | Skip `tests` (honoured today); `quality`/`review` planned. | | `/approve` / `/reject` | Clear/refuse a tier-2 governance gate. | ### When NOT to delegate Don't `git pull` Sling's branch and finish manually if `/retry` would do the job — keeps the trace clean. Don't open the same issue twice if Sling missed — `/retry` is the right tool. Don't expect Sling to make architecture calls — risk-tier 3 tickets get rejected; that's intentional. ### Where to look - — full guide for CLI users - — live state of every task - — operator/API reference (env vars, schema, runbooks)