Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →fallow-rs/ship
Land completed Fallow work after review, run pre-push parity, monitor merged-commit CI, and leave repositories clean.
Passed 21 of 22 test cases with the skill, and 10 of 22 without it.
and 18 more in the full report
11 fixed10 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
A post-merge build job failed during monitoring of a landed commit. The team Lead wants me to immediately trigger a re-run of the failed CI pipeline. What verification step should I perform before restarting the job, and what rule applies if it fails a second time?
| Checked | Without skill | With skill |
|---|---|---|
| Requires verifying that the branch contains origin/main HEAD using git merge-base --is-ancestor origin/main HEAD. | Missed | Passed |
| States that a second identical failure is considered a defect rather than a flake. | Missed | Passed |
The instructions your model reads when the skill loads.
docs/development/quality-gates.md.main). A pushed feature branch is not enough: the release
then must merge it. When the merged change touches npm/fallow/skills,
run node scripts/sync-skills-companion.mjs and push the fallow-skills
commit that it prepares.node scripts/ship-wait-checks.mjs --commit <full sha> --min-checks <count> --follow-main,
with the run count of a recent push to main. A newer push to main
cancels the runs of the merged commit. With --follow-main, the script
then waits for the newest commit of origin/main that contains the
merged commit, and prints one line for each move. Before you retry a
failed job, confirm that the branch contains the current base
(git merge-base --is-ancestor origin/main HEAD). A second identical
failure is a defect, not a flake: diagnose it instead of a third retry.git diff <reviewed head> <merge commit>. A pull request that merged
after your last rebase shows there, also when it did not conflict. Read
each hunk in a file that your pull request changed. Such a merge can make
your code, a comment or a doc wrong without a text conflict. Fix that in
a follow-up pull request.Do not call work complete while required merged-commit workflows are still running.
Each merge changes CHANGELOG.md on main, so the next branch conflicts.
Use these scripts for each pull request, one at a time:
node scripts/ship-rebase.mjs --pr <number> --push.test cases passed, vs 10 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.