agentleFS
pc-stylepc-style/x-md/.agents/skills/taking-over-work/SKILL.md

taking-over-work

Skill192 starsChanged 10 days agoMITView on GitHub

Finishes inherited work while preserving credit. Use when the user asks to take over a PR,

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the source PR, branch, or thread, including review findings and the user's later corrections.

    line 13
  2. Distinctive:

    If the work will be squashed, preserve human author/co-author credit in the merge commit too, using verified identities rather than guessed …

    line 30
  3. Very specific:

    Use modernizing-prs to update the continuation against its intended base and current architecture.

    line 34
  4. Very specific:

    When the requested finish includes a PR, use filing-prs to file or update it, then babysitting-prs rather than stopping at creation.

    line 44

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Takeover

Take responsibility for finishing the original goal while preserving the original contributors' credit. Do not defend an implementation just because another agent already built it.

Read the source PR, branch, or thread, including review findings and the user's later corrections. Resolve the handoff to the actual code and current head, and account for uncommitted work. Treat the handoff as context, not proof.

For an Amp source thread, use read_thread with full context. A thread message does not transfer code: identify the source checkout and use Amp's file-transfer tools for unpushed changes before continuing. Verify the received head and dirty files. For contributor credit, use manage_amp with topic git_identity and operation add-coauthor for the verified user ID; never guess their email.

For a replacement PR, import the original commits onto a new branch and add your fixes separately. Honor an explicitly requested in-place or stacked continuation instead. Do not overwrite unrelated work or change the original PR without authorization.

Preserve Git authorship and existing co-author trailers. Credit the original contributors in the PR description and link the original PR when there is one. If the work will be squashed, preserve human author/co-author credit in the merge commit too, using verified identities rather than guessed emails. Model attribution is not a substitute for contributor credit.

Use modernizing-prs to update the continuation against its intended base and current architecture. Rework what is necessary to finish the same goal, not unrelated features. Simplify the implementation without dropping intended behavior or surfaces. Recheck the source PR too: it may have improved while you were working.

Independently verify the original failure and realistic workflows, following repository guidance and permissions. Green mocked tests do not prove the user experience works. State what remains unverified.

When the requested finish includes a PR, use filing-prs to file or update it, then babysitting-prs rather than stopping at creation. Use leaving-pr-comments for replies. Merge or close the original PR only when authorized.

Report what you inherited, what you changed, how you verified it, how credit was preserved, and any remaining decision.

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.