ds-ship
Skill80 starsChanged 15 days agoMITView on GitHub
Takes a change all the way from code to a merged pull request without supervision: build it, prove it, review it, file the PR, watch it and merge it. Use when the user says ship it, send it all the way, merge when green, or /ds-ship.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- sungurerdim/dev-skillstheir own version, first seen Jul 10, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- sungurerdim/dev-skills★ 1same name
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.
In this repository28 other files it gives its agents.
- ds-adoptSkill
- ds-best-of-nSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-catchupSkill
- ds-context-resetSkill
- ds-design-auditSkill
- ds-designSkill
- ds-explainSkill
- ds-helpSkill
- ds-jurySkill
- ds-ledgerSkill
- ds-lessonsSkill
- ds-modeSkill
- ds-plan-loopSkill
- ds-pr-commentsSkill
- ds-principlesSkill
- ds-prSkill
- ds-readySkill
- ds-review-loopSkill
- ds-reviveSkill
- ds-sharpenSkill
- ds-swarmSkill
- ds-tddSkill
- ds-unslopSkill
- ds-unstickSkill
- ds-verify-loopSkill
- ds-watch-prSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
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
- Distinctive: line 12
If you are on the default branch, create a new branch.
- Very specific: line 18
Check the merge gate on the latest commit.
- Distinctive: line 32
Do not end your turn while checks are pending.
- Distinctive: line 33
Ask with the harness question tool, not a plain message.
- Distinctive: line 34
If no question tool exists or nobody answers, leave the PR open and unmerged, and start your final message with the question.
- Distinctive: line 36
Keep scope fixed. Decline extra work from reviews and list it as follow-ups.
≈ “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.
Files
Own the work from its current state to a merged PR while nobody is watching.
Only act this way when the user clearly asked for it. The request grants three things: run the tests and app checks the proof needs without asking first, force-push this task's own branch with --force-with-lease, and merge once the gate below passes. It grants nothing else.
Steps
- If you are on the default branch, create a new branch.
- Make the smallest change that meets the goal. Fix the case that was reported, not every case that might exist.
- Prove every part of the diff. Reproduce the failure, apply the fix, and run the same reproduction again. Run the checks CI runs. For UI or runtime behavior, run the app and look. Paste the command and its output into your notes.
- Review the change with
ds-review-loop. Re-prove anything the review changed. - Rebase on the latest default branch, then file the PR with
ds-pr. Add one line that says how you proved it. - Watch the PR with
ds-watch-pr. Fix real findings and CI failures, prove each fix, push, and watch again. - Check the merge gate on the latest commit. Merge with the repo's usual method. Never use
--adminor any other bypass. - Report the PR link, merge commit, proof, and every decision you made for the user.
Merge gate, all true on the latest head: proof covers the full diff, required checks are green, review bots are finished, each finding is fixed or answered with a reason, no human review asks for changes, and the branch is current and mergeable.
Stop when
- The PR is merged and the report is written.
- You cannot prove the change, or the gate cannot pass and you cannot fix it. Ask the user.
- The next step deletes data, touches production, closes a PR, or pushes another branch. Ask the user.
- Six fix-and-watch cycles pass without a green gate. Stop and report what blocks it.
Rules
- Do not end your turn while checks are pending. Wait with the watcher.
- Ask with the harness question tool, not a plain message. Put the PR link, the blocker and your recommended option in the question.
- If no question tool exists or nobody answers, leave the PR open and unmerged, and start your final message with the question.
- Evidence is output you saw in this session. A claim without output is not proof.
- Keep scope fixed. Decline extra work from reviews and list it as follow-ups.
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
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.