About ds-adopt
ds-adopt is a skill for taking over another contributor’s unfinished work while preserving their credit. It guides agents through inspecting the handoff, updating and verifying the work, and reporting what remains.
Key features
- 01Inspecting the source PR and current state
- 02Preserving original authorship and credit
- 03Updating work with ds-revive
- 04Reproducing and verifying the original issue
- 05Filing and monitoring a PR when requested
Use cases
- 01Taking over an unfinished pull request
- 02Continuing work from a branch or discussion thread
- 03Checking inherited changes against the original goal
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ aicodeking/ deepseek-stack --skill ds-adoptAfter installing, type/ds-adoptin Claude Code to confirm it loaded.
Details
From the project READMEFinish someone else's work as if it were yours, but credit them for what they did.
Steps
- Read the source PR, branch or thread in full: description, commits, review comments and any later corrections from the user.
- Find the real current state: the head SHA, uncommitted changes and open review findings. Treat the handoff notes as hints, not facts.
- Write down the original goal in one sentence.
- Choose where to work. By default, make a new branch with the original commits on it and add your fixes as separate commits. Continue in place or stack only if the user asked for it.
- Run
ds-reviveto bring the work up to date with the base branch. - Fix what is needed to reach the original goal. Simplify where you can, but keep every intended behavior.
- Verify on your own. Reproduce the original problem, then show it fixed. Run the real workflow, not only mocked tests. Record the commands and output.
- Check the source PR again. It may have changed while you worked.
- If a PR is wanted, file it with
ds-pr, then watch it withds-watch-pr. Useds-pr-commentsfor any reply. - Report what you inherited, what you changed, how you verified it, how credit was kept and what is still open.
Stop when
- The goal is reached, verified and reported.
- The goal is unclear, or finishing it needs a product decision. Ask the user.
- Verification fails three times in a row on the same issue. Report the blocker.
Rules
- Keep the original Git authors and co-author trailers. Name the contributors and link the original PR in the description.
- If the PR will be squashed, keep human co-author lines in the squash message. Use verified identities only, never guessed emails.
- Do not defend the old code because it exists. Do not add unrelated features.
- Do not edit, merge or close the original PR without permission.
- State plainly what you could not verify.
Comments
Markdown supported