agentleFS
Sign inStart free
pytorchpytorch/torchtitan/.claude/skills/pr-description/SKILL.md

pr-description

Skill5.9k starsChanged 3 days agoBSD-3-ClauseView on GitHub

Write a torchtitan PR description that convinces a human reviewer -- concrete problem with a simple example, what changed, user-facing before/after, numerics, testing. Use when opening or updating a PR, or when asked to write or improve a PR summary.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 82 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never write the "Summary (human-written)" section.

    line 15
  2. Distinctive:

    Keep it scannable: short sections, tables over prose.

    line 33
  3. Distinctive:

    Don't include sections with nothing to say.

    line 36

“Common” is measured: kept by at least 6 in 10 of the 82 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writing a torchtitan PR Description

A maintainer reads the description first and must be convinced by it. They don't want a narration of the diff; they want to know what problem exists, why this is the right fix, and what evidence shows it works. Write for a reviewer who knows torchtitan but not your context.

Rules

  • Never write the "Summary (human-written)" section. Leave its placeholder for the author, and tell the user to fill it in before review. Don't draft text for them to paste. With ghstack the PR body is the commit message, so keep the placeholder there too.
  • Lead with the problem, in concrete terms. If you can't state a concrete input that misbehaves on main (or a concrete thing that is hard to do today), stop and reconsider whether the PR should exist.
  • Include a simple example: a few lines showing the scenario before and after (a config snippet, a tiny tensor/sequence example, an ASCII diagram of data or control flow). This is the part reviewers ask for most often.
  • Say why this is the right layer and the smallest fix, and name the alternatives you rejected in one line each. If the fix works around an upstream gap, link the upstream issue.
  • Separate mechanical changes (moves, renames) from logic changes, and say which files reviewers can skim. For large changes, split commits into moves-only and logic commits, or stack PRs ("Stacked on #N").
  • State evidence, not claims: numerics table, perf numbers end to end, the exact command. List failures that also happen on main separately.
  • Keep it scannable: short sections, tables over prose. Don't paste a long agent transcript; if an agent wrote the summary, a human must have checked it says what concretely changes.
  • Don't include sections with nothing to say.

Template

## Summary (human-written)
<!-- Write this yourself, not with an AI tool. 2-5 sentences: the problem, why
     this approach, and what you checked yourself. -->

## Why
<The concrete problem: what fails or is hard today, for whom. 2-5 sentences.>

**Example.**
<5-15 lines: minimal scenario, before vs. after.>

## What changed
- <grouped by concern; mark mechanical parts as such>

## Alternatives considered
- <one line each, why not>

## User-facing changes
| Before | After |
| --- | --- |
| `old.config.path` | `new.config.path` |

## Numerics
<For non-computation changes: bitwise-identical loss and grad_norm vs. base
commit <sha> (seed 42, deterministic, `scripts/loss_compare.py --assert-equal`),
per parallelism layout touched. For computation changes: convergence evidence
and an explanation of expected golden-loss changes.>

| Config | GPUs | Result |
| --- | --- | --- |

## Performance
<Only if relevant: TPS/MFU and memory before vs. after, end to end, same config.>

## Testing
<What you ran, on what hardware, and which existing tests cover the change. For
each new test, the regression it catches.>

## Known issues / follow-ups
<Failures that reproduce on main; TODOs left in code; next PR in the stack.>

Download now (ZIP)

Trending

More talk lately.about the whole repository

Dec 2025: 3 mentionsJan 2026: 2 mentionsFeb 2026: 1 mentionMar 2026: 2 mentionsApr 2026: 1 mentionMay 2026: 3 mentionsJun 2026: 0 mentionsJul 2026: 1 mentionAug 2026: 0 mentionsSep 2026: 2 mentionsOct 2026: 1 mentionNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the pytorch/torchtitan repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about pytorch/torchtitan

The biggest 5 of 53 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 53

Talked about on GitHub, Bluesky and Hacker News (53 times).

On GitHub · 50

45 more on GitHub

On Bluesky · 2

On Hacker News · 1

  • Other versions87 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 87

    1. jdx/mise★ 35ksame name
    2. zulip/zulip★ 26ksame name
    3. Nagi-ovo/gemini-voyager★ 20ksame name
    4. pipecat-ai/pipecat★ 17ksame name
    5. ComposioHQ/agent-orchestrator★ 14ksame name
    6. OrchestratorInc/agent-orchestrator★ 14ksame name
    7. Untrivial-ai/agent-orchestrator★ 14ksame name
    8. AgentWrapper/agent-orchestrator★ 13ksame name
    9. sanity-io/sanity★ 6.4ksame name
    10. basicmachines-co/basic-memory★ 4.3ksame name

    77 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use ao-desktop-dev, bug-triage and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • agentlab-inSkill

      ao-desktop-dev

      Launch, restart, or troubleshoot the real AO Electron desktop app from this repository; run a checkout against isolated or real local AO data; combine PR branches for local UI review; and diagnose stale Electron processes, port conflicts, or preload bridge mismatches. Use whenever asked to run, open, show, or visually verify AO frontend changes in the actual desktop app rather than ao preview, dev:web, or mock data.

      Also in 4 projects that use this

    • jMertaSkill

      bug-triage

      Use when the user reports a bug, regression, runtime error, failing build, or broken test and wants reproduction, diagnosis, root-cause analysis, or an authorized fix. Isolates the shared cause and verifies the smallest relevant change.

      Also in 4 projects that use this

    • GitHubSkill

      commit-message

      Generate conventional commit messages - use when creating commits, writing commit messages, or asking for git commit help

      Also in 8 projects that use this

    • francogalfreSkill

      dependency-audit

      Audits package.json dependencies for outdated packages, security vulnerabilities, unnecessary deps, and version issues. Use when the user says "audit my dependencies", "check my packages", "what deps should I update", "clean up package.json", "are there security issues in my deps", or pastes a package.json.

      Also in 3 projects that use this

    • PydanticSkill

      i-have-adhd

      Shape every response for an ADHD reader who reviews the work but does not do the coding — the agent does. Use whenever responding to ANY message — coding, debugging, planning, casual. Lead with the result or the decision. Surface anything needing the user's input as a structured question, never buried in prose they'll skim past. No preamble, no recap, no closers. State errors matter-of-factly. Make finished work visible. Trigger even on casual messages and even when brevity wasn't requested.

      Also in 3 projects that use this

    • HashiCorpSkill

      changelog

      Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.

      Also in 5 projects that use this

  • In this repository8 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free