agentleFS
Sign inStart free
finosfinos/git-proxy/.agents/skills/implement/SKILL.md

implement

Skill262 starsChanged 2 months agoApache-2.0View on GitHub

Implement a GitHub issue end-to-end: fetch, plan, code with approval, commit incrementally, and generate a PR summary

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 170 edited versions we read keep these.

  • 25

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read AGENTS.md first. It is the canonical project guide for this repository.

    line 8
  2. Very specific:

    If it is a full URL like https://github.com/{owner}/{repo}/issues/{number}, extract {owner}/{repo} and {number}.

    line 15
  3. Very specific:

    If it is just a number, use the current repo (run gh repo view --json nameWithOwner -q .nameWithOwner to get it).

    line 16
  4. Distinctive:

    Ask the programmer to confirm this is the right issue before proceeding.

    line 26
  5. Distinctive:

    If there is more than one remote, ask the programmer which remote to use as upstream using AskUserQuestion (list the remote names as …

    line 31
  6. Distinctive:

    If there is only one remote, use it automatically.

    line 32
  7. Distinctive:

    Create a new branch from main.

    line 39
  8. Distinctive:

    Create an implementation plan with numbered steps.

    line 51
  9. Distinctive:

    Ask the programmer using AskUserQuestion with options: "Approve plan", "Modify plan", "Cancel".

    line 73
  10. Distinctive:

    If the programmer wants modifications, iterate on the plan until approved.

    line 74
  11. Very specific:

    If the step involves logic changes, run tests (npm run test) and show the result

    line 82
  12. Distinctive:

    Ask the programmer using AskUserQuestion with options: "Commit this step", "Revise changes", "Skip this step", "Stop here".

    line 84
  13. Distinctive:

    If the programmer picks "Commit this step", run the /commit skill to commit the changes

    line 85
  14. Distinctive:

    If the programmer picks "Revise changes", iterate until they are satisfied

    line 86
  15. Distinctive:

    If the programmer picks "Skip this step", move to the next step without committing

    line 87
  16. Distinctive:

    If the programmer picks "Stop here", skip all remaining steps and jump to Phase 5

    line 88
  17. Distinctive:

    After each commit, briefly confirm the commit was made and move to the next step.

    line 90
  18. Distinctive:

    After all steps are complete (or the programmer stops early):

    line 94
  19. Distinctive:

    Run the /summary skill to generate a PR description based on all commits made during this session

    line 95
  20. Distinctive:

    Do NOT create a PR or push.

    line 97
  21. Distinctive:

    If no commits were made (e.g.

    line 98
  22. Distinctive:

    Never make code changes without programmer approval

    line 102
  23. Distinctive:

    Always show what changed after each step before committing

    line 103
  24. Distinctive:

    If the issue is from a different repo (not the current one), fetch it via the full URL but make changes in the current repo

    line 107
  25. Distinctive:

    No emojis in any output

    line 108
  26. Distinctive:

    Do not create a PR or push to remote — only local commits and a summary

    line 109
  27. Distinctive:

    If a step requires running tests, run them and show results before committing

    line 110
  28. Distinctive:

    Use subagents for codebase exploration and code changes.

    line 111

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

Implement a GitHub issue end-to-end: fetch the issue, plan, code with approval, commit incrementally, and generate a PR summary.

Read AGENTS.md first. It is the canonical project guide for this repository.

The argument is an issue number (e.g. /implement 42) or a full GitHub URL (e.g. /implement https://github.com/finos/git-proxy/issues/42). If no argument is given, ask the user.

Phase 1: Fetch issue

  1. Parse the argument:
    • If it is a full URL like https://github.com/{owner}/{repo}/issues/{number}, extract {owner}/{repo} and {number}.
    • If it is just a number, use the current repo (run gh repo view --json nameWithOwner -q .nameWithOwner to get it).
  2. Fetch issue details:
    gh issue view <number> --repo <owner/repo> --json title,body,labels,assignees,comments
  3. Display a summary to the programmer:
    • Issue number and title
    • Labels (if any)
    • Body (truncated to ~40 lines if longer)
    • Number of comments and any noteworthy discussion points
  4. Ask the programmer to confirm this is the right issue before proceeding. Use AskUserQuestion with options: "Proceed", "Show full issue body", "Cancel".

Phase 2: Branch setup

  1. List all configured remotes: git remote -v
  2. If there is more than one remote, ask the programmer which remote to use as upstream using AskUserQuestion (list the remote names as options). If there is only one remote, use it automatically.
  3. Fetch and update main from the chosen remote:
    git fetch <remote>
git checkout main
git pull <remote> main
  4. Create a new branch from main. The branch name must follow this convention:
    • Format: <type>/<short-slug> where <type> is a Conventional Commits type (feat, fix, refactor, docs, chore, etc.) and <short-slug> is a kebab-case summary derived from the issue title (3-5 words max).
    • Examples: feat/dynamic-allocation-support, fix/event-watcher-reconnect, refactor/pod-spec-converter
    • Pick the type based on the issue labels and description (e.g. a bug report maps to fix/, a feature request to feat/).
    git checkout -b <type>/<short-slug>
  5. Confirm to the programmer: "Created branch <branch-name> from <remote>/main."

Phase 3: Plan

  1. Based on the issue description, explore the codebase to understand the relevant code paths. Use subagents to search for files, classes, and patterns referenced in or implied by the issue.
  2. Create an implementation plan with numbered steps. Each step should be a logical, committable unit of work. The plan must include:
    • A 1-2 sentence summary of the issue
    • Numbered steps, where each step has a title, a description of what to change, and the affected file paths

  3. Save the plan to plans/implement-<issue-number>.md using this format:

    ## Issue #<number>: <title>

<1-2 sentence summary of what the issue asks for>

## Steps

1. <step title>
   - <what to change and where>
   - Files: <path/to/file.ts>

2. <step title>
   - <what to change and where>
   - Files: <path/to/file.ts, path/to/other.ts>
  4. Show the full plan to the programmer for approval.
  5. Ask the programmer using AskUserQuestion with options: "Approve plan", "Modify plan", "Cancel".
  6. If the programmer wants modifications, iterate on the plan until approved.

Phase 4: Execute step by step

For each step in the approved plan:

  1. Announce the step: "Step <n>/<total>: <step title>"
  2. Make the code changes for that step
  3. If the step involves logic changes, run tests (npm run test) and show the result
  4. Show the programmer a brief summary of what changed (key files and the nature of the change)
  5. Ask the programmer using AskUserQuestion with options: "Commit this step", "Revise changes", "Skip this step", "Stop here".
  6. If the programmer picks "Commit this step", run the /commit skill to commit the changes
  7. If the programmer picks "Revise changes", iterate until they are satisfied
  8. If the programmer picks "Skip this step", move to the next step without committing
  9. If the programmer picks "Stop here", skip all remaining steps and jump to Phase 5

After each commit, briefly confirm the commit was made and move to the next step.

Phase 5: Summary

  1. After all steps are complete (or the programmer stops early):
    • Run the /summary skill to generate a PR description based on all commits made during this session
    • Show the summary to the programmer
  2. Do NOT create a PR or push. Just present the summary for the programmer to use when they are ready.
  3. If no commits were made (e.g. the programmer cancelled early), skip the summary and say so.

Rules

  • Never make code changes without programmer approval
  • Always show what changed after each step before committing
  • The programmer can modify, skip, reorder, or stop steps at any point
  • Save the plan file before starting execution so the programmer has a reference
  • Each commit should be a logical unit (one step = one commit, unless the step is trivial)
  • If the issue is from a different repo (not the current one), fetch it via the full URL but make changes in the current repo
  • No emojis in any output
  • Do not create a PR or push to remote — only local commits and a summary
  • If a step requires running tests, run them and show results before committing
  • Use subagents for codebase exploration and code changes; keep the main flow focused on coordination and programmer interaction

$ARGUMENTS

Download now (ZIP)

  • Other versions191 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 191

    1. mattpocock/skills★ 309ksame name
    2. QuivrHQ/quivr★ 40ksame name
    3. foambubble/foam★ 17ksame name
    4. formbricks/formbricks★ 13ksame name
    5. ArcReel/ArcReel★ 6ksame name
    6. vinvcn/mattpocock-skills-zh-CN★ 5.5ksame name
    7. fallow-rs/fallow★ 5.3ksame name
    8. withcoral/coral★ 4.9ksame name
    9. bestofjs/bestofjs★ 3.1ksame name
    10. meta-pytorch/OpenEnv★ 2.8ksame name

    181 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 setup-ts-deep-modules, ask-matt 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.
    • liufeng1976Skill

      setup-ts-deep-modules

      Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

      Also in 38 projects that use this

    • GoogleSkill

      ask-matt

      Ask which skill or flow fits your situation. A router over the skills in this repo.

      Also in 84 projects that use this

    • AWSSkill

      to-questionnaire

      Turn a decision you can't fully answer into a questionnaire for someone else to fill in.

      Also in 82 projects that use this

    • ryotaroh180105Skill

      claude-handoff

      Hand the current conversation off to a fresh background agent that picks up the work immediately.

      Also in 38 projects that use this

    • RoentekSkill

      loop-me

      Grill me about specs for the workflows I want to build, within this workspace.

      Also in 45 projects that use this

    • GoogleSkill

      to-spec

      Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

      Also in 154 projects that use this

    • +3 more from google
  • In this repository10 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