Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →OSS-facing channel to share a Sutando use case with the community. Opens a labeled GitHub issue on sonichi/sutando and (CLA-gated) a PR adding docs/community-use-cases/<slug>.md. Validates outcome-framed titles with the same checker as add-use-case. Default: both; flags --issue-only / --pr-only opt out.
.claude/skills/sonichi-submit-use-case/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-07 | ✗→✓ | ▲ Improved | 60% | 0% |
| case-12 | ✗→✓ | ▲ Improved | -8% | 0% |
| case-08 | ✗→✓ | ▲ Improved | -6% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 90% | 0% |
| case-13 | ✗→✓ | ▲ Improved | -2% | 0% |
OSS counterpart to add-use-case. add-use-case targets the private AG2Platform/agent-universe repo (rendered on sutando.ai) and is for the internal fleet. submit-use-case targets the public sonichi/sutando repo so external contributors can share a use case without needing access to the private rendering repo.
bashpython3 "$SKILL_DIR/scripts/submit_use_case.py" \ --title "Your AI plays piano while you sleep" \ --summary "Outcome-first summary that appears on tile + detail page." \ --bullets "bullet1" --bullets "bullet2" \ [--video /abs/path/to/clip.mp4] \ [--media-url https://example.com/clip.jpg] \ [--youtube-id ABCDEFG1234] \ [--x-url https://x.com/...] \ [--linkedin-url https://www.linkedin.com/...] \ [--contact "you@example.com or @yourhandle"] \ [--issue-only | --pr-only] \ [--dry-run]
--dry-run runs the framing check and prints both the rendered issue body and the rendered docs/community-use-cases/<slug>.md file to stdout. No clone, no gh calls.
REJECT_PATTERNS + validate_title +suggest_reframes from add-use-case verbatim. Capability-listy titles ("Ask your AI to ...", "Sutando can ...", "Send a ...") are rejected with deterministic reframe suggestions. Same rules, same voice.
slugify(title) — lowercased, non-alphanum→-, trimmed to 60 chars.--dry-run):community-use-case/<slug> already exist on sonichi/sutando?If yes, abort with a pointer to the existing PR.
sonichi/sutando with the same title? If yes,abort with the existing issue URL.
--pr-only). gh issue create --repo sonichi/sutandowith label use-case-submission. Body has structured sections: Title, Summary, Bullets, Links (video / youtube / x / linkedin), Contact, and a forward-ref to the PR if one is opened in the same invocation.
--issue-only).gh repo clone sonichi/sutando /tmp/sutando-submit-use-case-{ts}/community-use-case/<slug> from maindocs/community-use-cases/<slug>.md — YAML frontmatter mirroring theagent-universe UseCase shape so the sync script can later promote it.
attributed to the runner's existing user.name / user.email, so the CLA signs under whoever they already are (that's the whole point of CLA-Assistant signing). It prints the identity before committing and aborts if it's unset, so attribution can't silently go out wrong.
gh pr create. PR body cross-links the issue if one was opened.docs/community-use-cases/<slug>.md)yaml--- slug: <derived> title: <user title> summary: <user summary> videoUrl: <if --video> # absolute or hosted; raw path uploaded to issue, not PR youtubeId: <if --youtube-id> xUrl: <if --x-url> linkedinUrl: <if --linkedin-url> thumbnail: /use-cases/<slug>.jpg contact: <if --contact> submitted_at: <ISO UTC timestamp> --- <longDescription stitched from --bullets, or summary if no bullets>
The frontmatter intentionally mirrors AG2Platform/agent-universe's lib/use-cases.ts UseCase TypeScript type so a later sync script can read this YAML and emit the literal entry the rendering repo expects. The submitter is not asked to upload the thumbnail in the PR — it stays as a pending path that the maintainer fills in when promoting.
use-case-submission (the maintainer monitors this label to triage incoming community submissions).
community-use-case/<slug> is checked on origin before pushing.title (case-insensitive, open state) aborts.--dry-run skips all remote checks and only prints rendered output.CLA-Assistant signs the contributor under the email of the commit author. That MUST be the runner's own email — overwriting it would wrongly attribute the PR and sign the CLA under the wrong identity. So the script never sets user.email / user.name: it commits under whatever the runner already has configured (the maintainer's machine already carries the project identity in its global git config; contributors carry their own). It surfaces the identity before committing and aborts if unset, rather than guessing or silently using the wrong author.
git, gh (authenticated to GitHub as the submitter)| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 8,192 | 7,049 | -14% | 1 | 1 | 0% | 1,685 | 1,791 | +6% | 0 | 0 | — |
case-02 | fail→fail | 11,550 | 9,542 | -17% | 1 | 1 | 0% | 2,257 | 1,751 | -22% | 0 | 0 | — |
case-03 | fail→fail | 7,779 | 5,472 | -30% | 1 | 1 | 0% | 1,532 | 1,684 | +10% | 0 | 0 | — |
case-04 | pass→pass | 13,184 | 5,188 | -61% | 1 | 1 | 0% | 1,976 | 2,216 | +12% | 0 | 0 | — |
case-05 | pass→pass | 9,908 | 11,033 | +11% | 1 | 1 | 0% | 1,945 | 3,386 | +74% | 0 | 0 | — |
case-06 | pass→pass | 10,317 | 7,000 | -32% | 1 | 1 | 0% | 1,852 | 2,638 | +42% | 0 | 0 | — |
case-07 | fail→pass | 7,766 | 4,526 | -42% | 1 | 1 | 0% | 1,258 | 2,008 | +60% | 0 | 0 | — |
case-12 | fail→pass | 10,451 | 2,023 | -81% | 1 | 1 | 0% | 1,827 | 1,684 | -8% | 0 | 0 | — |
case-08 | fail→pass | 13,363 | 3,206 | -76% | 1 | 1 | 0% | 1,986 | 1,862 | -6% | 0 | 0 | — |
case-09 | fail→pass | 6,629 | 4,785 | -28% | 1 | 1 | 0% | 1,113 | 2,117 | +90% | 0 | 0 | — |
case-10 | pass→pass | 10,594 | 2,274 | -79% | 1 | 1 | 0% | 1,591 | 1,646 | +3% | 0 | 0 | — |
case-11 | pass→pass | 12,625 | 2,866 | -77% | 1 | 1 | 0% | 1,916 | 1,764 | -8% | 0 | 0 | — |
case-13 | fail→pass | 11,393 | 2,806 | -75% | 1 | 1 | 0% | 1,829 | 1,795 | -2% | 0 | 0 | — |
case-14 | fail→pass | 10,153 | 1,452 | -86% | 1 | 1 | 0% | 1,626 | 1,586 | -2% | 0 | 0 | — |
case-15 | fail→pass | 6,598 | 9,223 | +40% | 1 | 1 | 0% | 1,132 | 3,084 | +172% | 0 | 0 | — |
case-16 | fail→pass | 11,989 | 2,477 | -79% | 1 | 1 | 0% | 2,140 | 1,656 | -23% | 0 | 0 | — |
case-17 | pass→pass | 6,122 | 2,139 | -65% | 1 | 1 | 0% | 1,048 | 1,697 | +62% | 0 | 0 | — |
case-18 | fail→pass | 12,607 | 4,754 | -62% | 1 | 1 | 0% | 2,034 | 2,186 | +7% | 0 | 0 | — |
case-19 | pass→pass | 8,147 | 2,832 | -65% | 1 | 1 | 0% | 1,228 | 1,739 | +42% | 0 | 0 | — |
case-20 | fail→pass | 9,440 | 1,705 | -82% | 1 | 1 | 0% | 1,491 | 1,598 | +7% | 0 | 0 | — |
case-21 | fail→pass | 9,985 | 1,255 | -87% | 1 | 1 | 0% | 1,703 | 1,566 | -8% | 0 | 0 | — |
case-22 | fail→pass | 12,741 | 3,005 | -76% | 1 | 1 | 0% | 2,145 | 1,913 | -11% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 19 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +55 percentage points is the difference between those two pass rates over the 19 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.