SuperAPI AI Directory

goodcase

Agents & models

View repository

Updated 10-16 06:23

About this skill

goodcase Skill

Let the Agent query the hand-picked AI viral cases on goodcase.ai using natural language—each one has a real source, creator attribution, complete Prompt, recommended models, and an explainable score. Available across Claude Code / Codex CLI / Cursor / Gemini CLI / any compatible platform.

Online:https://goodcase.ai(公开匿名可访,无需 token)

Base URL: https://goodcase.ai/api/public

When to use

First routing principle: What the user is asking about is "real, existing AI creation cases"; do not make up cases or Prompts from training data, always go through the API. Even if you "think" you know how a certain viral piece was made, you still have to look it up—if you can't find it, say so plainly.

The user is saying The endpoint to use
Broad question: "What good AI cases are there", "What AI images are popular recently", "Show me a few viral cases" GET /cases(default 20 items, can add take)
Restricted type: "AI video cases", "find a few image cases", "AI coding UI cases", "AI copywriting cases", "AI hardware cases" GET /cases?category=video(image / video / web / copy / hardware)
With keywords: "find a glass-texture prompt", "are there poster-type cases", "that arrow video by Umesh" GET /cases?q=<关键词>(matches title/summary/creator, case-insensitive)
Want the complete Prompt / reproduction method: "give me the complete prompt", "how do I reproduce this", "break this one down in detail" GET /cases/{slug}(includes promptFull, editor commentary, experiment notes)
Find by model: "Veo cases", "what can Seedance do", "GPT Image use cases" First GET /cases(can include category), then filter within the results by the returned recommendedModels field
Evaluate a new model: "use goodcase to test model XX", "sample a few cases to evaluate the model", "a new model is out, run the goodcase questions" Sample by category GET /cases?sample=N&seed=..., one by one GET /cases/{slug} + GET /cases/{slug}/retests, see the "Model Evaluation" workflow below

Typical two-step flow: for a broad question, first GET /cases to get the list → the user is interested in one item → GET /cases/{slug} to get the complete Prompt and breakdown.

Workflow

# 宽问题:拉案例列表(默认 20 条)
curl -s "https://goodcase.ai/api/public/cases"

# 限定分类 + 条数
curl -s "https://goodcase.ai/api/public/cases?category=video&take=5"

# 关键词搜索(标题/摘要/创作者子串匹配,大小写不敏感)
curl -s "https://goodcase.ai/api/public/cases?q=海报"

# 单条全量(含 promptFull、editorNote、labNote)
curl -s "https://goodcase.ai/api/public/cases/real-case-01-umesh-ai"

Parameter conventions:

  • category:image(AI image) / video(AI video) / web(AI coding/UI) / copy(AI copywriting) / hardware(AI hardware). Passing any other value returns 400
  • q: keyword, matches title / summary / creator, Chinese or English both work
  • take: 1-50, default 20, out-of-range values are automatically clamped
  • Authentication: none (anonymous)
  • Server-side cache for 5 minutes; if the user asks the same question, no need to call again

Model Evaluation

When the user wants to run the goodcase questions with a new model, or have a certain model undergo evaluation, follow these four steps:

Step one: draw questions. Sample N items each by primary category (video / web / image / hardware) and secondary form (video tier: text-to-video / ref-to-video; web tier: web-ui / motion-3d / agent-tool): for those with secondary forms, sample by secondary form, defaulting to 3 items per secondary form; for primary categories without secondary forms (image, hardware), sample by primary category, defaulting to 3 items each. If the user specifies categories, sample only those specified. Default exclude=motion-3d—motion-3d tests materials and runtime effects, not model capability, so by default it is not counted against the model in evaluation; add it back only if the user explicitly requests it. seed defaults to 日期YYYYMMDD + 模型名(e.g. 20260902-veo3), and you must record the actual seed used and tell the user, to facilitate reproduction and subsequent alignment with in-site re-testing.

# 按二级形态抽样(web-ui,3 条,固定 seed)
curl -s "https://goodcase.ai/api/public/cases?form=web-ui&sample=3&seed=20260902-veo3&exclude=motion-3d"

# 按一级分类抽样(image,无二级形态)
curl -s "https://goodcase.ai/api/public/cases?category=image&sample=3&seed=20260902-veo3"

# 排除多个形态
curl -s "https://goodcase.ai/api/public/cases?category=web&sample=3&seed=20260902-veo3&exclude=motion-3d,agent-tool"

sample when present, take;sample is ignored; range 1-50;seed any string, same seed with same parameters gives the same result, if not passed it is random and not reproducible; for sampled hits, the top level of the response echoes back seed and sample, check them to confirm nothing went off track.form single value, only accepts text-to-video / ref-to-video / web-ui / motion-3d / agent-tool, passing any other value returns 400.

If a certain secondary form samples out to count of 0 (current situation: the text-to-video / ref-to-video tags in the video tier are not yet fully tagged across the whole library, so sampling will most likely come out empty), fall back to removing formand sampling the same number of items by primary category, keepingexclude=motion-3d and this seed unchanged, and note in the report for this tier "this category is sampled by primary category".

Step 2: Pull baselines. For each slug sampled, obtain two sets of data:

# 案例全量(拿 promptFull / recommendedModels / costBand / stabilityScore)
curl -s "https://goodcase.ai/api/public/cases/{slug}"

# 站内逐模型复测记录(拿基线,见下方返回数据形态)
curl -s "https://goodcase.ai/api/public/cases/{slug}/retests"

Step 3: Run the prompts and record. Hand each item's promptFull to the user or use your own tools to run the target model, and record item by item reproduced(reproduced) / degraded(discounted) / failed(could not run), with artifact links or a brief description. If you do not have tools to run the model yourself, list the Prompts clearly for the user to run; do not fabricate results for the user.

Step 4: Produce the report. Output a plain-language comparison table (see "Output format for the user") plus a returnable JSON list. The JSON is the hook left for subsequent alignment with in-site re-testing—the same batch of slugs sampled from the same batch of seeds can be matched directly by slug when in-site re-testing reaches this batch of cases, without needing to re-match.

Returned data forms

GET /cases returns

{
  "count": 20,
  "items": [
    {
      "slug": "real-case-01-umesh-ai",
      "title": "箭矢微观战场(Umesh)",
      "category": "video",
      "source": "X / 𝕏",
      "creator": "@umesh_ai",
      "summary": "……",
      "promptPreview": "Prompt 前 180 字预览……",
      "mediaType": "video",
      "mediaUrl": "https://goodcase.ai/media/goodcase/....mp4",
      "posterUrl": "https://goodcase.ai/media/goodcase/....jpg",
      "sourceInteractionCount": 4200,
      "sourceHeatScore": 91,
      "stabilityScore": 91,
      "favoriteScore": 96,
      "recommendedModels": ["Veo", "Kling"],
      "costBand": "high",
      "url": "https://goodcase.ai/cases/real-case-01-umesh-ai"
    }
  ]
}

The list does not include promptFull—to get the full Prompt you must use the single-item endpoint.

GET /cases/{slug} returns

The full set of list fields, plus:

  • promptFull: the full original Prompt text (the original prompt published by the creator)
  • editorNote: editorial commentary (from what angle this case is suitable to learn)
  • labNote: array of experiment notes (re-test suggestions: which model to use first, which variables to watch, how to control cost)
  • spreadScore / spreadScoreNote: spread potential score and its definition explanation
  • promptPublicNote / promptLoginNotes / promptContributionNotes: in-site Prompt tiering explanation text

If the slug is not found, returns 404 {"error": "case not found"}。

GET /cases/{slug}/retests returns

In-site per-model re-test records, used to get baselines when doing model evaluation:

{
  "slug": "real-case-01-umesh-ai",
  "stabilityScore": 91,
  "evidenceLevel": "verified",
  "stabilityState": "stable",
  "count": 6,
  "byModel": [
    {
      "model": "Veo 3",
      "kind": "video",
      "latest": { "verdict": "reproduced", "finalScore": 88, "testedAt": "2026-08-20T00:00:00Z" },
      "history": [{ "verdict": "reproduced", "finalScore": 88 }, { "verdict": "degraded", "finalScore": 61 }]
    }
  ],
  "records": [
    {
      "id": "rt_001",
      "runId": "run_20260820",
      "testedAt": "2026-08-20T00:00:00Z",
      "kind": "video",
      "status": "complete",
      "model": "Veo 3",
      "modelDisclosure": "verified",
      "artifacts": { "primary": "https://...", "desktop": null, "mobile": null, "html": null, "video": "https://..." },
      "finalScore": 88,
      "judges": [{ "model": "gpt-5", "score": 90 }, { "model": "claude", "score": 86 }],
      "disagreement": 4,
      "automaticOnly": false,
      "promptSha256": "…",
      "failureReason": null,
      "verdict": "reproduced"
    }
  ]
}

Field descriptions, places that are easy to trip up on:

  • modelDisclosure is requested-model-unverified , it means "the requester claims to have used this model, but there is no independent verification in-site"; do not treat it as "verified to have been run with this model"—when displaying, state truthfully that it is unverified
  • finalScore(review score, 0-100, combined from multiple judge scores) and stabilityScore(human review stability tier) are not the same unit,cannot be directly subtracted or converted, they can only be referenced separately
  • kind is the media type of this retest record itself (image / ui / video), not the case's primary category
  • verdict has reproduced(reproduced) / degraded(discounted) / failed(failed) / inconclusive(uncertain) / null(not yet judged), five states
  • byModel is the view aggregated by model (latest + history),records is the complete per-run record; the two are different ways of slicing the same batch of data, not two independent datasets

Field invariants

  • Required:slug / title / category / creator / url / mediaUrl
  • Nullable:posterUrl(only video-type ones usually have a cover image; image-type ones are null)
  • Score meanings:
    • stabilityScore Stability score (0-100): the degree to which the same Prompt reproduces a consistent output direction across retests; the higher, the more "copy it and you'll get it"
    • stabilityScore = 0: pending retest, not "stability of zero"
    • sourceHeatScore Source popularity (0-100): valid only when a verifiable snapshot of the original post's engagement exists
    • sourceInteractionCount: the raw total of the original post's likes, comments, reposts, and saves
    • favoriteScore / likedCount / remakeCount: legacy compatibility field, not used for the source engagement ranking
    • costBand Cost tier:low low / medium medium / high high—high is usually video-type; retest in small steps before scaling up
  • recommendedModels: the list of models officially recommended to try first; the first one is the top choice
  • category Value set:image / video / web / copy / hardware

Output format for users

⚠️ Core principles: the output must be Chinese markdown, well formatted, and a case recommendation that ordinary people can understand directly,not an API debugging log. Do not expose raw JSON, endpoint paths, or raw parameters.

Each case must include:

  1. Titlebold + creator attribution (creator field, e.g. @umesh_ai)
  2. One sentence on what's good about it / what it's suitable to learn (based on summary + scores)
  3. Key signals in plain language: e.g. "stability score 91 (reproducing the direction from the Prompt is very stable), high cost tier (recommend trying in small steps first)"
  4. Must include the goodcase.ai detail page link(url field)—users click through to see the media, full Prompt, and unlocked content; this is a hard requirement for driving traffic

List-style output template:

**goodcase 精选 — AI 视频案例**(共 N 条)

1. **箭矢微观战场** — @umesh_ai
   一镜到底从战场宏观拉到箭杆微观文明,适合学镜头编排与无缝转场。
   推荐模型:Veo / Kling | 稳定分 91 | 成本档高
   👉 https://goodcase.ai/cases/real-case-01-umesh-ai

2. ...

Single-item detail output: first give the full Prompt (code block), then give the key points of the editorial commentary and retest suggestions, and finally put the detail page link.promptFull must state that it comes from that creator, e.g. "Below is the original Prompt posted by @umesh_ai".

Model evaluation comparison table template:

**goodcase 模型评测 — Veo 3**(seed: 20260902-veo3,共 9 条)

| case | 分类 | 站内基线 | 新模型结果 | 备注 |
|---|---|---|---|---|
| 箭矢微观战场 | video / text-to-video | Veo 3・reproduced・稳定分 91 | reproduced | 镜头连贯,色调略偏冷 |
| ... | | | | |

seed:`20260902-veo3`(同 seed 同批题可复现,后续站内复测对齐这批 slug 时直接按 seed 找回)

The corresponding JSON list:

{
  "schema": "goodcase-model-eval-v1",
  "model": "Veo 3",
  "seed": "20260902-veo3",
  "sampledAt": "2026-09-02T00:00:00Z",
  "filters": { "category": null, "form": ["text-to-video", "web-ui"], "exclude": ["motion-3d"] },
  "items": [
    {
      "slug": "real-case-01-umesh-ai",
      "category": "video",
      "form": "text-to-video",
      "baseline": { "stabilityScore": 91, "evidenceLevel": "verified", "models": [{ "model": "Veo 3", "verdict": "reproduced", "finalScore": 88 }] },
      "result": { "verdict": "reproduced", "notes": "镜头连贯,色调略偏冷", "artifactUrl": "https://..." }
    }
  ]
}

The ending must include the seed and this JSON list—this is the hook for subsequent alignment with on-site retests; don't omit it.

Don't do

  • Don't make up cases from memory — the "viral cases" in your training data are very likely outdated or simply don't exist on goodcase.ai. Always go by what the API returns; if it's not in the API, say clearly that it's not there
  • When the API is unreachable / returns empty, say so clearly —"goodcase.ai temporarily found no related cases", rather than making one up to pad the count
  • Don't claim promptFull as your own writing — it is the original Prompt posted by the creator, and when displaying it you must include the creator attribution (creator field)
  • Every case must include a link to its goodcase.ai detail page — If the url is missing, users cannot trace back to the original case, and this recommendation is as good as untrustworthy
  • Do not expose raw JSON, endpoint paths,category=video raw parameters like these in the output — what users want to see is the case brief, not API documentation
  • Do not poll at high frequency — the server caches for 5 minutes, so reuse the previous result for the same question
  • The list endpoint not returning promptFull is by design; do not try to infer and fill it in from promptPreview — if you need the full text, call GET /cases/{slug}
  • Do not present your own evaluation results as goodcase's official retest conclusions — /retests returns retest records that have already occurred on the site; the model evaluation you run now is a new batch, and the two must be labeled separately and must not be conflated into one statement
  • Do not count motion-3d case failures against the model — These cases test assets and runtime effects, not model generation capability, and are excluded by default from evaluation; if the user insists on testing them, the conclusion must also state that this does not represent model capability
  • If you did not run it, do not make up results — After extracting the questions and providing the Prompt, if the model has not actually been run yet, do not fill in reproduced/degraded/failed in the comparison table; write "pending" or leave it blank as appropriate