agentleFS
Sign inStart free
assisjpassisjp/specflow/skills/engineering/file-pr/SKILL.md

file-pr

Skill17 starsChanged 3 months agoMITView on GitHub

Prepare and open or update an authorized pull request with a concise problem-first description and verifiable evidence. Use when the user asks to create, file, open, or update a PR. Do not use merely to review a diff or when publication is not authorized.

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 19 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow repository title conventions and inspect recent merged work if they are unclear.

    line 20
  2. Very specific:

    Use Closes #N only for an actual issue that this PR should close.

    line 39

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

File PR

Publish an authorized candidate so a reviewer can understand the problem, the solution, and the proof without reconstructing the implementation history.

1. Confirm the publishable candidate

Read repository instructions and the user's delivery scope. Resolve the base branch, current head SHA, owned paths, source/acceptance criteria, checks/evidence, and review status. Inspect the diff against the resolved base and compare it with the reviewed snapshot. Do not publish a candidate whose later changes have not received affected verification and review.

Check whether a PR already exists for the branch before creating another. Preserve an existing PR unless the user explicitly asks for a replacement. A dirty worktree, unrelated changes, missing remote, or unclear base is a concrete condition to report or resolve within authorization — never a reason to stage everything or guess.

2. Write the reviewer-facing story

Follow repository title conventions and inspect recent merged work if they are unclear. Make the title concise and outcome-oriented. The description should normally contain:

## Problem
<what a user, maintainer, or system could not reliably do>

## Solution
<the smallest behavior-level change>

## Evidence
<commands/observations tied to the final head, plus meaningful limitations>

Lead with the problem and behavior, not a file inventory. Include source links, screenshots, migration notes, rollout/rollback notes, or follow-ups only when relevant. Check title, body, pasted logs, links, and attachments for secrets and private material. Do not invent model, reviewer, benchmark, or user attribution.

3. Publish only what is authorized

Commit, push, create, or update a PR only when each action is within the task's authorization and the repository workflow. Stage only owned paths. Use the configured GitHub CLI/API or tracker integration; if an API action fails, report the measured failure rather than changing credentials or using a browser without authorization.

Use Closes #N only for an actual issue that this PR should close. Do not post follow-up comments merely to narrate work; comments require a purpose and authorization. Opening a PR does not authorize merge, auto-merge, base changes, force-push, deployment, or closing another PR.

4. Hand off accurately

Report the PR URL or local delivery state, final head/base, title and evidence summary, review status, and limitations. If the user asks to monitor it, use $pr-maintenance; otherwise stop after publication.

Download now (ZIP)

  • Other versions19 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 19

    1. t3dotgg/tstack★ 2.5ksame name
    2. GeiserX/agent-skills★ 4same name
    3. GeiserX/claude-skills★ 4same name
    4. itsyasirkhandev/skills★ 4same name
    5. bhagyamudgal/skills★ 2same name
    6. connorch/skills★ 2same name
    7. Dhruv2mars/skills★ 2same name
    8. falcondev-oss/skills★ 2same name
    9. ejarmand/skills★ 1same name
    10. johnnygreco/skills★ 1same name

    9 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 leaving-pr-comments, sol-loop 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.
    • Dhruv2marsSkill

      leaving-pr-comments

      Format and post agent-authored GitHub pull request

      Also in 6 projects that use this

    • salalaslamSkill

      sol-loop

      Use when the user says "sol loop", or when another skill (such as full-stop) asks for a sol loop. Not for a one-off review; that's interrogate.

      Also in 6 projects that use this

    • Nexus-Organization-InfosecSkill

      full-stop

      Shut down the Full Control phone-bridge completely — end Claude's watch loop, stop the bridge server (server.py started via ensure_server.ps1), and mark Claude offline in the app. Use whenever the user invokes /full-stop or says "stop full control", "stop the watch loop", "shut down the bridge/server", or "stop the ps1". Counterpart of [[full-control]], which starts everything.

      Also in 6 projects that use this

    • shhacSkill

      full-send

      Complete an explicitly assigned task autonomously through parallel agents, peer-reviewed decisions, and automatic retries of temporary blockers. Use only when the user explicitly invokes Full Send.

      Also in 6 projects that use this

    • garrytanSkill

      modernize

      Bring an aging pull request onto its current base and decide whether it should still exist: MODERNIZE, REWORK or CLOSE, with range-diff proof before any push. (gstack)

      Also in 5 projects that use this

    • Solly922Skill

      html-communication

      Create self-contained HTML artifacts for plans, architecture maps, comparisons, reports, timelines, diagrams, and technical explainers when visual structure improves understanding. Use for complex or spatial information; do not use for short, linear answers that are clearer in Markdown.

      Also in 3 projects that use this

  • In this repository14 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