Sling for Claude Code CLI users

Mental model

Claude Code CLI	Sling
Synchronous, interactive	Asynchronous, autonomous
You watch every turn, redirect mid-flow	You file an issue, walk away, get a PR
Best for thinking out loud, exploring, judgement calls	Best for executing well-defined work in parallel
Free with your Max plan	Free with your Max plan (uses the same login)

Both run the same Claude model with the same tool access. The difference is who's driving — you, or a labelled GitHub issue.

When to use which

Stay in Claude Code locally when

You're still figuring out architecture
You want to explore a refactor before committing to it
The work is < 10 min — you'd type the brief in less time than the issue
You need to think out loud
Production hotfix — needs to ship in 5 min

Hand off to Sling when

The brief is concrete: clear problem, clear acceptance criteria, files identifiable
You're doing 3+ similar tickets and want them in parallel — Sling runs many workers concurrently; your laptop runs one Claude session at a time
You want a real PR with tests, not a draft
It's late and you want work done overnight (Night Shift cron picks up labelled issues every 5 min)
The work touches a repo Sling already manages — no setup tax

One-time setup

You don't install Sling locally. It runs on sven.svenlabs.ai already. To use it for a new repo:

Add the repo to config/repositories.json (PR to svenlabsllc/sling). Minimum config:

{
  "id": "my-repo",
  "github_repo": "owner/my-repo",
  "github_app": "svenlabs-ci-app",
  "branch": "develop",
  "sourceBranch": "main",
  "execution_mode": "claude-code",
  "test_command": "pnpm test",
  "labels": ["auto-implement"]
}

Install the App on the repo via GitHub App admin. Use svenlabs-ci-app for SvenLabs-owned repos, gdt-ci-app for GDT.
Merge the PR → Sling auto-deploys → done. Sling now watches that repo.

Day-to-day workflow

The most natural pattern for a Claude Code user:

1

Draft the issue in Claude Code

Talk through the change. Ask Claude to write the body in 4-section format (Problem / What to build / How we'll verify / Out of scope). Paste into a new GitHub issue.

2

Label it

auto-implement + claude-code. Hit submit.

3

Walk away

Webhook fires within seconds. ~5 min for small tickets, ~15 min for medium.

4

Read the PR comment

Sling posts a rolling summary: files changed, tests added, review score, phase timings, cost. That's your "what got done" report.

5

Merge or revise

If right → merge. If missed → see "Revising" below.

Revising a ticket

Sling missed the point. Two options:

Light revision — the spec was right, the output was off

Comment on the GitHub issue (not the PR):

/retry The SearchBar should be inline, not a modal. See PR #1234.

Sling reads the issue body + all comments after the original retry. Pasting a comment link is fine — Sling fetches the linked thread.

Heavy revision — the spec was wrong

Edit the issue body to clarify the new requirement
Drop a comment summarising what changed
Comment /retry
Wait ~5 min

What about commenting on the PR directly?

Yes, comment on PR lines and Sling reads those too. But you still need /retry on the issue to re-enter the pipeline — PR comments alone don't trigger.

Default move: when in doubt, edit the issue body and run /retry. ~80% of "Sling got it wrong" is fixed by this. If it's still wrong after 2 retries, take it back into Claude Code locally — the brief is probably ambiguous.

Mixing the two

The most powerful pattern is hybrid:

Architecture in Claude Code, execution in Sling

Spend 15 min in Claude Code deciding schema + API shape. Commit nothing. Write up the decision as a Sling-ready issue, let Sling execute it. Saves you the typing.

Sling does boilerplate, Claude Code does polish

Sling opens a PR with 80% of the work. Check out the branch locally, run claude in the workspace, finish the parts that need judgement (naming, edge cases, tests for unusual inputs).

Multiple tickets in parallel

When you have 5+ similar tickets (e.g. "add the same column to 5 tables"), file them all, wait, review them together. Sling runs them concurrently up to its worker pool size.

Commands cheatsheet

Type these as GitHub comments, not in a terminal:

Command	Where	Effect
`/retry <feedback>`	Issue or PR comment	Re-enter the pipeline. Reads issue body + all comments since the last retry.
`/revise`	Same — alias	Identical to `/retry`.
`/update <text>`	Issue or PR comment	Inject a free-text producer change request and re-enter (targeted alternative to `/retry`).
`/qa`	Issue or PR comment	Run the E2E harness on the linked PR; results posted back as a comment.
`/cancel`	Issue comment	Stop in-flight workers + clear the task mapping.
`/skip <phase>`	Issue comment	Skip a phase. `tests` honoured today; `quality`/`review` planned.
`/approve`	Issue comment	Clear governance gate for tier-2 risk tasks.
`/reject`	Issue comment	Don't run this task.

Make Claude Code know about Sling natively

Two snippets so any claude session in any repo already understands what Sling is and how to delegate to it.

1. Global — once per laptop

Append the cross-repo block to your ~/.claude/CLAUDE.md. Re-running updates in place (idempotent markers).

curl -fsSL https://sling.svenlabs.ai/claude-md/global >> ~/.claude/CLAUDE.md

2. Per-repo — automatic

Every Sling-managed repo's CLAUDE.md includes a  …  block with that repo's specific config (App, labels, branches, test command, blocked paths). A weekly cron refreshes it via PR if it drifts.

To preview what would land in your repo:

curl -fsSL https://sling.svenlabs.ai/claude-md/repo/<repo-id>

Or, from a checkout of the Sling repo, write it directly:

node scripts/sync-claude-md.mjs --repo-id <id> --workspace /path/to/your/repo

The script supports --check (drift-only, exit 1 on drift) and --print (stdout, no FS write) so you can wire it into your own CI.

What you DON'T do

Don't git pull Sling's branch and finish it manually if you can /retry instead — keeps the trace clean
Don't open the same issue twice if Sling missed — /retry is the right tool
Don't use Sling for hotfixes you need shipped in 5 min — open Claude Code locally, push directly
Don't expect Sling to make architecture calls — risk-tier 3 tickets get rejected; that's intentional

Where to look

/dashboard

Live state of every Sling task

/onboarding

Universal 10-min walkthrough

/onboarding/engineer

Engineer-flavoured deep dive

/docs

Operator/API reference — env vars, schema, runbooks

/ticket/{owner}/{repo}/{issue}

Per-ticket timeline (lifecycle + cost + phase logs)

/claude-md/global

Plain-text snippet for ~/.claude/CLAUDE.md — curl-pipeable.

Bottom line

Sling is your autonomous worker pool. Claude Code is your interactive pair. Both have the same brain; the workflow you pick depends on whether the work is "I know what I want, type it for me" (Sling) or "I'm not sure yet, think with me" (Claude Code).

Get good at recognising which one a given task is and you'll move ~3× faster.