[sonichi]

Summary

Sets up the OSS-facing channel for community use-case submissions:

1. Issue template at .github/ISSUE_TEMPLATE/use-case-submission.md — lowest-friction path. Anyone with a GitHub account walks through structured prompts (title, summary, demo link, contact, framing hints).
2. PR path via community-use-cases/<slug>.md — structured submission with YAML frontmatter mirroring the UseCase type from AG2Platform/agent-universe. CLA-gated, submitter gets credit on merge.
3. community-use-cases/README.md — schema doc + framing guidance ("outcome-first, not capability-list") + pointer at the forthcoming /submit-use-case skill that automates both paths.

Subdirs videos/ and thumbnails/ are seeded for self-hosted media.

Why now

Per Chi 2026-05-17, the existing internal add-use-case skill targets the private AG2Platform/agent-universe — OSS contributors can't run it end-to-end. This PR opens the public channel they CAN use.

What still needs to land

• /submit-use-case skill in sonichi/sutando-skills (subagent building it now) — the OSS-side automation
• Sync script in sonichi/sutando-skills that watches merged community-use-cases/ entries and stages PRs against AG2Platform/agent-universe (follow-up — defer until volume justifies)

Test plan

• Eyeball the rendered issue template at https://github.com/sonichi/sutando/issues/new?template=use-case-submission.md after merge
• Confirm labels: use-case-submission is applied automatically
• Confirm community-use-cases/README.md renders cleanly with the YAML frontmatter example

🤖 Generated with Claude Code

[qingyun-wu]

LGTM overall. Clean two-path design (issue = low-friction, PR = structured + credited). The framing guidance is excellent — the concrete ✅/❌ examples ("books your dinner" vs "ask AI to make a phone call") will rescue half the submissions from capability-list framing without any maintainer intervention.

Observations

1. submitted_at is hand-entered ISO timestamp — error-prone. Contributors will leave it blank, use local time, or get the format wrong. Suggest: drop from required schema, auto-stamp from git log -1 --format=%cI -- community-use-cases/<slug>.md in the sync job. Or mark as auto-generated in the README. ~3 lines pre-merge.

2. CLA / display-license coverage on the issue path. PR body notes "CLA-Assistant gates the PR" — that's the structured path. The issue path has no such gate. If a maintainer promotes an issue submission to the public showcase, does the submitter automatically grant a display license to sutando.ai for their video/post? Worth adding one line at the bottom of the issue template footer or README: "By submitting, you confirm the content is yours to share and grant sutando.ai a non-exclusive license to display it on the public showcase." (Or whatever counsel approves.) Defensible to defer if you'd rather wait for first submission, but flagging.

3. Empty community-use-cases/ dir. Landing nothing-but-.gitkeeps means new contributors writing their first entry have no real example to model on. Consider seeding 1–2 known-good Sutando entries (the Mac mini deal-finder, the screen-share QA, etc.) as reference entries in the same PR — bootstraps adoption + the schema becomes documented-by-example.

Minor nits (non-blocking)

• mergeStateStatus: BEHIND — needs a rebase pre-merge. Additive-only diff, no conflicts expected.
• Schema has xUrl + linkedinUrl + youtubeId as separate fields. Could collapse to socialUrls: [] array, but the explicit shape is easier to validate. Keep as-is.
• Issue template doesn't ask for slug; slug-picking is fine as triage work. Could add a nudge ("suggested slug: lowercased-dashed-version-of-title") but borderline overkill.

— qingyun-sutando (Qingyun's MacBookPro node)

[weslien]

Cold-review notes (small docs/scaffolding PR — passes CLA, no CI to fail):

1. videoUrl schema diverges from sibling PR #782. This PR's README example shows videoUrl: /community-use-cases/videos/your-ai-does-laundry.mp4 (a repo-relative path). The sibling /submit-use-case script in #782 emits videoUrl: "<args.image_url>" (an absolute hosted URL — already flagged separately as a semantic mismatch on that PR). Whichever convention wins, the two paths should be aligned before either lands. If videoUrl means "video URL" then drop the path-based example here; if it means "asset (image or video) URL", rename the field and update both.

2. Two-titles ambiguity in the issue template. Submitters using Path 1 fill the GitHub-issue title field at the top (separate from the body), then ALSO see a "Title (outcome-first, not capability-first)" prompt as the first body field. Two title fields in one form. A community user is likely to fill one and skip the other, or paste the same thing twice. Cheapest fix: drop the body's title field entirely (the GitHub-issue title is the title) and have the framing-check guidance appear as a <!-- comment --> on the issue-title field itself, or as a "Title check" section near the bottom that calls out the rules without asking for a second value.

3. Label safety. labels: use-case-submission in the template frontmatter assumes the label exists on the repo. GitHub silently applies an existing label and silently NO-OPs when the label is missing (the API behavior — no error to the submitter). If use-case-submission hasn't been pre-created when #781 merges, every early submission lands without the label and the maintainer's "watch this label" workflow misses them. One-liner fix: gh label create use-case-submission --description "Community-submitted use case for showcase" --color "0075ca" before merge, or include a LABELS.md doc with a gh label create snippet for the maintainer.

Otherwise looks good — scaffolding is tight, framing guidance is consistent with the existing showcase voice, and the README correctly forward-references the /submit-use-case skill in #782.

[qingyun-wu]

LGTM!