Write the brief. Ship the PR. Push back when it misses.
If your issue has these four, Sling lands it on the first try most of the time.
| Label | What it does | When to add |
|---|---|---|
auto-implement | Sends the issue through Sling's pipeline | Every brief you want shipped |
claude-code | Picks the execution mode (recommended over default STIV today) | Every brief, paired with auto-implement |
p0 / p1 / p2 / p3 | Priority — affects ordering in the queue | Anything that's not the default p2 |
hotfix / critical | Routes the PR to main instead of develop | True production breakage only |
It happens. Three options, in increasing order of involvement.
/retryEdit 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.
Comment on a line of the PR with what you want different. Then /retry from the PR. Sling reads the PR comments too.
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.
#sling — short summary + cost + duration + direct PR link./ticket/{owner}/{repo}/{issue} — full audit trail across every retry.You don't have to ask. The PR comment is the source of truth.