agentleFS
forcedotcomforcedotcom/salesforcedx-vscode/.claude/skills/pr-draft/SKILL.md

pr-draft

Skill1k starsChanged 25 days agoBSD-3-ClauseView on GitHub

Draft PRs with trailing " - W-XXXXXXXX" in titles, conventional commit-style before it, GUS refs in body. Use when drafting PRs, PR titles, PR descriptions, opening PRs, or Git2Gus workflows.

  • Commits and pushes

5 other projects use a version of this.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about forcedotcom/salesforcedx-vscode

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

See all 52

Talked about on GitHub and Stack Overflow (52 times).

On GitHub · 50

45 more on GitHub

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 6 are distinctive, and 11 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 11

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Confirmation required: Never create or update work items without explicit user confirmation.

    line 13
  2. Very specific:

    Safety: never use --no-verify

    line 15
  3. Very specific:

    If branch name contains W-XXXXX, confirm it exists in GUS, resembles the work done on the branch, and use that

    line 17
  4. Very specific:

    If yes → try to find it using gus-cli/SKILL.md.

    line 19
  5. Very specific:

    Before creating PR: inspect gh pr view --json headRefName,baseRefName,url 2>/dev/null || true, git config --get "branch.$(git branch …

    line 21
  6. Very specific:

    After PR created: update work item Details__c with PR link.

    line 22
  7. Distinctive:

    After PR created: offer Ready for Review.

    line 23
  8. Distinctive:

    Never main; inferred main → develop

    line 29
  9. Very specific:

    Treat a branch whose PR base or stored github-pr-base-branch is neither develop nor main as stacked.

    line 33
  10. Very specific:

    Use gh stack push to publish changes to an existing stack.

    line 35
  11. Very specific:

    Use gh stack sync before resolving remote divergence and gh stack rebase for stack-wide rebases.

    line 36
  12. Distinctive:

    Use ordinary git push only for a non-stacked branch.

    line 37
  13. Distinctive:

    Before finalizing body, fetch and analyze:

    line 51
  14. Distinctive:

    LLM relevance pass: read PR diff/commits + all issue/discussion titles+bodies.

    line 55
  15. Very specific:

    Write content per concise/SKILL.md

    line 65
  16. Distinctive:

    Delete before/after section if empty

    line 67
  17. Very specific:

    User declined WI: If user explicitly declines WI but wants PR, include [skip-validate-pr] in body (e.g.

    line 68

“Common” is measured: kept by at least 6 in 10 of the 5 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

PR Draft

Draft PR titles and bodies per salesforcedx-vscode conventions. Requires a Gus work item number.

Work item

Confirmation required: Never create or update work items without explicit user confirmation. Present proposed fields (Subject, Epic, Details, etc.) and wait for user to approve before any sf data create record or sf data update record.

Safety never use --no-verify

  1. If branch name contains W-XXXXX, confirm it exists in GUS, resembles the work done on the branch, and use that
  2. Else ask: "Do you have a Gus work item (W-XXXXX) for this PR?"
  3. If yes → try to find it using gus-cli/SKILL.md. Confirm with the user that you got it right, or ask them to choose if several could be right.
  4. If no → offer to create via Gus. Follow gus-cli/SKILL.md. Before creating: show user Subject, Epic, Details, assignee. Ask: "Create this work item?" Do not run sf data create record until user says yes. If user declines creation and still wants to proceed with the PR, include [skip-validate-pr] in the PR body.
  5. Before creating PR: inspect gh pr view --json headRefName,baseRefName,url 2>/dev/null || true, git config --get "branch.$(git branch --show-current).github-pr-base-branch", and gh stack view. If the PR base or stored base is neither develop nor main, use gh stack push; otherwise use git push -u origin $(git branch --show-current). Never push to develop/main.
  6. After PR created: update work item Details__c with PR link. Query current Details__c, append "\nPR: <url>" (or prepend if empty). Before updating: show user the new Details__c. Ask: "Update work item with PR link?" Do not run sf data update record until user says yes.
  7. After PR created: offer Ready for Review. If the user opts in, run the reviewer-pick → WI update → GitHub reassignment → Slack ping handoff in review-handoff.md.

Target branch

  • Default develop
  • From other branch (≠ develop, ≠ main)? Use it. Detect: git reflog show <branch> | tail -1 → "moving from X" / "Created from X"
  • Never main; inferred main → develop

Stacked PRs

Treat a branch whose PR base or stored github-pr-base-branch is neither develop nor main as stacked.

  • Use gh stack push to publish changes to an existing stack.
  • Use gh stack sync before resolving remote divergence and gh stack rebase for stack-wide rebases.
  • Use ordinary git push only for a non-stacked branch.

Title format

type(scope): description - W-XXXXXXXX

  • Work item last: Append a space, hyphen, space, then the GUS Name ( - W-21735053). This is the Name field from GUS, not the Salesforce Record ID (e.g., a07...). If you just created the record, query the Name first.
  • Types: feat, fix, docs, style, refactor, perf, test, ci, chore, build
  • Scope: optional
  • Example: build(extensions): consolidate apex-tmlanguage - W-21735053
  • Avoid: leading brackets — [W-21735053] build(extensions): …; bare trailing WI without - — build(extensions): … W-21735053

GitHub issues & discussions

Before finalizing body, fetch and analyze:

  1. Issues: gh issue list --state open --limit 200 --json number,title,body,comments
  2. Discussions: gh api graphql — fetch all open discussions (title, number, url, body)
  3. LLM relevance pass: read PR diff/commits + all issue/discussion titles+bodies; identify candidates
  4. Auto-include any issue where a comment contains the PR's W-XXXXX (e.g. W-12345) — no prompt needed; Git2Gus already established the link
  5. Show remaining candidates (issues and discussions the LLM flagged as related); ask user which to include
  6. Stripped-href anchors in WI Details__c: SF empties external hrefs on save (the why + stored forms live in gus-cli), leaving <a href="">discussions/NNN</a> — text survives, href empty. Scan Details__c for such anchors with discussions/NNN|issues/NNN text, EXCLUDE anchors with a populated real href, and auto-include the reconstructed https://github.com/forcedotcom/salesforcedx-vscode/<path> URL — no prompt.
  7. Format: issues as #<number>, discussions as full URL — both in the "What issues does this PR fix or reference?" section

Body format

  • Base body on branch commits only
  • Ignore plans/conversation history (may be stale)
  • Write content per concise/SKILL.md
  • Include @W-XXXXX@ in "What issues does this PR fix or reference?" per .github/PULL_REQUEST_TEMPLATE.md:
  • Delete before/after section if empty
  • User declined WI: If user explicitly declines WI but wants PR, include [skip-validate-pr] in body (e.g. at end)
### What issues does this PR fix or reference?
#<GitHub Issue>, @W-XXXXX@

Download now (ZIP)

Does it work?

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

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.