← back to /onboarding Producer

Sling for producers

Write the brief. Ship the PR. Push back when it misses.

What you get out of Sling

~5 min
brief → PR
No queue
no waiting on engineering
PR + tests
not a draft, a real review-ready change
/retry
push back without rewriting from scratch

The brief — four sections, every time

If your issue has these four, Sling lands it on the first try most of the time.

  1. Problem. What's broken or missing? One paragraph.
  2. What to build. Bullet list. Specific files if you know them.
  3. How we'll verify. What test or manual check proves it works?
  4. Out of scope. Anything you do not want changed — be explicit.
Pro tip. If you can't write "How we'll verify," the brief isn't ready. That's the half people most often skip — and the half Sling needs the most.

Labels that matter

LabelWhat it doesWhen to add
auto-implementSends the issue through Sling's pipelineEvery brief you want shipped
claude-codePicks the execution mode (recommended over default STIV today)Every brief, paired with auto-implement
p0 / p1 / p2 / p3Priority — affects ordering in the queueAnything that's not the default p2
hotfix / criticalRoutes the PR to main instead of developTrue production breakage only

When the PR misses

It happens. Three options, in increasing order of involvement.

1. Edit + /retry

Edit the issue body to clarify, drop a comment with what's wrong, then comment /retry. Sling re-runs with the latest issue + thread. This is the right answer ~80% of the time.

2. Specific change request on the PR

Comment on a line of the PR with what you want different. Then /retry from the PR. Sling reads the PR comments too.

3. Take it back manually

If after 2–3 retries it's still wrong, the brief was probably ambiguous. Implement it yourself or hand it to an engineer. Don't burn budget retrying past 3.

What Sling tells you back

You don't have to ask. The PR comment is the source of truth.

Different role?