Onboarding · ~10 minutes

Sling in 60 seconds

Sling turns a labelled GitHub issue into a tested, reviewed pull request. You stay in your normal GitHub workflow — Sling is the worker.

1
You open an issue
In any Sling-configured repo. Add the trigger label.
→
2
Sling builds it
Spec, tests, code, review — autonomously.
→
3
You get a PR
Tested, reviewed, ready to merge — or push back via comments.
You don't write code with Sling. You write the brief, you review the PR, you say /retry if it's wrong. Sling does the typing.

Should I use Sling for this?

Three tools, three jobs. Pick the one that fits.

Sling

You know what to build, you don't want to type it

  • Bug fix with a clear repro
  • Feature with concrete acceptance criteria
  • Refactor scoped to 1–8 files
  • You want a PR with tests, not a draft
Label: auto-implement + claude-code
Claude Code (interactive)

You need to think out loud while the work happens

  • Architecture decisions on the fly
  • Exploratory spike — "what would it look like if…"
  • Cross-cutting refactor needing judgement at every step
  • You want a conversation, not a PR
Use the Claude Code CLI directly
By hand

The cost of explaining is higher than the cost of doing

  • One-line config tweak
  • Anything touching prod auth, payments, PHI tables
  • Production hotfix where you need it shipped in 5 min
  • You already have the diff in your head
Open your editor.
Rule of thumb: If you can describe the change in 5 bullet points and say how you'd verify it works — Sling can take it. If either half is fuzzy, do it interactively.

Your first ticket

A worked example. Steal the shape.

svenlabsllc/sling #NEW
Add a /skip-tests label that bypasses the test-generation phase
auto-implement claude-code enhancement
Problem. When fixing a one-line typo, generating tests adds 4 minutes. We want a label that tells Sling to skip Phase 1 (test generation). What to build.
  • If the issue carries label skip-tests, the runner skips TestGenerator and notes "tests skipped (label)" in the PR body.
  • Quality gate still runs — existing tests must pass.
  • If skip-tests is present and any file under src/security/ changes, refuse and post a comment.
How we'll verify.
  • Unit test: runner skips TestGenerator when label present.
  • Unit test: runner refuses skip on security-path changes.
  • Integration: an existing issue re-run with the label produces a PR without new test files.
Out of scope. A general-purpose phase-skipping system. skip-tests only.

The label matters

auto-implement sends it through Sling's pipeline. claude-code picks the execution mode — recommended over default STIV right now.

Four sections, every time

Problem · What to build · How we'll verify · Out of scope. If your issue body has these four, Sling will land it on the first try ~most of the time.

Acceptance criteria are not optional

If you can't say how you'd verify the fix, Sling can't either. Write the verification before you write the request.

Commands you can run

From any comment on the issue or the PR. Sling reads them like Slack slash-commands.

CommandAvailableWhat it doesWhen to use
/approve shipped Clear governance gate for tasks awaiting human approval. Tier-2 risk tasks that paused for review.
/reject shipped Reject a pending task. It will not run. You changed your mind, or the assessment was wrong.
/retry alias /revise shipped Re-enter the pipeline using the latest issue body + comment thread as context. The PR missed the point. Edit the issue, drop a clarifying comment, then /retry.
/update soon — A2 (#434) Alias for /retry. Same behaviour, more obvious name. Use this once it's wired. Until then, use /retry.
/qa soon — A1 (#433) Run the QA harness against the PR's branch and post results back. You want a second-opinion smoke test before approving.
/cancel partial — see #426 Acknowledges a cancel request. Stopping in-flight tasks is the next step. Wrong ticket. Don't run. (For now: /reject instead if pre-approval.)
/skip planned Skip a single phase (tests, quality, review). Edge cases. Default is: don't.
Tip. Comment commands work on the issue for pre-PR control (/approve, /reject, /retry) and on the PR for post-PR control (/retry, soon /qa).

What Sling tells you back

Three surfaces. All on by default.

GitHub PR comment
Sling: PR ready for review

Implemented 3 files, 1 test file. Spec generated, 4 acceptance criteria covered. Risk tier 1 (auto-approved, PR-only).

  • Spec · 4 ACs · 12s
  • Tests · 6 cases generated · 38s
  • Implement · 2 attempts · 4m12s
  • Review · score 8/10 · 1 nit
  • PR · #1234 · branch feat/auto-440/onboarding
Slack notification
#sling

svenlabsllc/sling#440 · Onboarding presentation

✅ PR #1234 opened · 8/10 review · ~$1.42 · 5m12s

Thread for retries. Reactions sync to GitHub labels.

Timeline page
/ticket/svenlabsllc/sling/440

Per-ticket page joining lifecycle state, releases, and cost.

  • Lifecycle: building → ready_for_uat
  • Cost: $1.42 (budget $25)
  • Phases: spec ✓ tests ✓ implement ✓ review ✓ pr ✓
  • Logs and prompts available on click-through.

"Does Sling tell me what it built?"

Yes. The PR comment is the answer. The Slack ping is the nudge. The timeline page is the audit trail. You don't have to ask.

When it goes wrong

Most failures fall into one of these. Each has a fix that doesn't need engineering.

PR misses the point

The change works, but it's not what you wanted.

Fix: Edit the issue body to clarify, comment with what's wrong, then /retry. Sling reads the latest issue + comments.
Tests don't pass

Sling self-iterates up to 3 times per file. After that, it ships the PR with failures listed.

Fix: Look at the failures in the PR comment. If it's a flaky test, /retry. If the spec was wrong, edit + /retry.
Sling never picked it up

Issue sat for >5 minutes with no Sling response.

Fix: Check the labels — needs auto-implement. Check the repo is in config/repositories.json. Check /status-page. If all good, ping #sling.
Risk-tier rejection

Sling refused: "Tier 3 — requires manual implementation."

Fix: The issue touches auth, payments, or HIPAA paths. This is intentional. Implement by hand.
Spend cap hit

"Per-ticket budget exceeded" — Sling stopped to avoid burning budget.

Fix: The brief is probably too big. Split it into 2–3 issues. Or raise the budget for this one ticket via env override.
PR review noise

Sling commenting too often on the PR.

Fix: The rolling comment + SHA dedup (#424) lands one comment per real change. If you see runaway comments, that's a bug — file under #413.
Default move: when in doubt, edit the issue body and run /retry. That re-enters the pipeline with the corrected context. 80% of "Sling got it wrong" is fixed by this.

Full walkthrough

A recorded pair-programming session — Sling on a real architecture-heavy ticket.

Tracked under A7 (#439). Embed config: ONBOARDING_VIDEO_FULL env var.

Where to look

Pin this page in #sling. Bookmark the rest.

/dashboard

Live state of every ticket Sling is working on. Approvals, cost, status.

/guide

Role-based reference — producer, owner, engineer. Deep dive on every label and field.

/onboarding/cli-user

Already use the Claude Code CLI locally? When to delegate to Sling, how to hand off, the mixed pattern.

/workflow

How the original 20-step proposal maps to what's shipped. For stakeholders.

/docs

Runbooks: db-restore, sling-down, env vars, ADRs.

/status-page

Is Sling up? Worker pool depth. Recent failures.

EPIC #432

The adoption push tracker — A1 through A8 — what's coming next for usability.

You're ready.

Pick a small ticket. Add auto-implement + claude-code. Wait 5 minutes. Check the PR.

If it works — file the next one. If it doesn't — /retry with feedback.

— Sling