SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmodel-pr-diff-dossier

model-pr-diff-dossier

Agents & models

View repository

Updated 10-15 17:24

About this skill

Model PR Diff Dossier

Use this skill before publishing any model PR optimization history document that cites framework PRs.

Non-Negotiable Standard

Do not summarize a PR with only a title-level sentence. Do not use a script or bulk generator to fill motivation, implementation notes, or code excerpts.

For every PR cited as model optimization evidence, the document must include or link to a diff-reviewed PR card with:

  • PR link, title, state, merge time when available, additions/deletions, and changed-file count.
  • Motivation: why the PR existed, inferred from PR body, title, issue context, docs changes, tests, and code diff.
  • Key implementation idea: what runtime path changed and how the patch implements the change.
  • Key code excerpts: short, relevant snippets from the actual diff, not invented pseudocode.
  • Reviewed files: important files from the full diff, grouped by runtime/docs/tests where possible.
  • Validation implications: tests, benchmark paths, launch flags, or regression lanes implied by the diff.
  • Diff coverage note: state that the full diff was fetched/read and include diff line count.

Workflow

  1. Collect exact PR links from the target model history files. Use GitHub PR URLs, not bare #123 text.
  2. Open each PR diff directly with GitHub, gh pr diff, or the local framework repository commit. Read the changed source files, not just the PR title.
  3. For merged PRs, cross-check the final mainline code in the relevant framework checkout when the diff is ambiguous.
  4. Write the PR card manually in the matching model history document. Use references/card-schema.md when you need the exact card shape. The card must name concrete files/functions/classes and include a short real code excerpt.
  5. For docs-only or config-only PRs, quote the exact command/config line that changed and explain why it matters for serving or validation.
  6. After each model family, review the cards for repeated shallow words such as "follow-up", "bugfix", or "optimization"; replace them with concrete implementation detail.
  7. Run repository tests and formatting before publishing.

Review Gate

A model PR history is not ready if any PR card says only "follow-up", "bugfix", "docs", or "optimization" without:

  • named files/functions/classes touched by the diff,
  • a concrete motivation,
  • a concrete implementation summary,
  • and at least one code excerpt or an explicit reason why the PR is docs-only.