agentleFS
Sign inStart free
LandonTomaineLandonTomaine/LT-Agents/skills/ship-change/SKILL.md

ship-change

Skill0 starsChanged 4 months agoMITView on GitHub

Lightweight end-to-end coding workflow for taking a user request through analysis, a concise plan, implementation, validation, and handoff. Use when the user wants Codex to do a repo change from start to finish, especially when the work should be committed and pushed only after the user approves the final diff, commit message, and push target.

  • Deletes or force-pushes

5 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions5 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 5

    1. mralexivy/AutoMode★ 8same name
    2. fnayou/dotfiles★ 2same name
    3. YangFan-Code-Star/context-dev★ 2same name
    4. tejastn10/workbench★ 1same name
    5. davidscotttufts/hyvemind★ 0same 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 repository5 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. 0 are common, 21 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 21

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Check git status --short --branch before editing.

    line 18
  2. Distinctive:

    Keep the plan proportional.

    line 23
  3. Distinctive:

    Ask only when a missing decision would make the implementation risky.

    line 24
  4. Distinctive:

    Follow existing repo patterns.

    line 27
  5. Distinctive:

    Keep edits scoped to the request.

    line 28
  6. Distinctive:

    Do not revert unrelated user changes.

    line 29
  7. Distinctive:

    Update docs or indexes when the change affects user or agent workflow.

    line 30
  8. Distinctive:

    Use or add a script only when it removes repeated deterministic work.

    line 31
  9. Distinctive:

    Run the repo's documented checks for the changed surface.

    line 34
  10. Distinctive:

    If no checks are documented, run the lightest relevant inspection and say that no stronger validation exists.

    line 35
  11. Distinctive:

    Ask for explicit approval before committing or pushing unless the user already gave explicit approval for commit and push in the current …

    line 42
  12. Distinctive:

    Commit and push after approval.

    line 44
  13. Distinctive:

    Commit with the approved or clearly proposed message.

    line 46
  14. Distinctive:

    Never use git reset --hard, git checkout --, rebase, force-push, or history rewrite unless the user explicitly requests that exact …

    line 52
  15. Distinctive:

    Do not use git add -A in a mixed worktree unless every changed file is in scope.

    line 53
  16. Distinctive:

    If publishing requires auth, remote creation, or a new branch, explain the target before acting.

    line 54
  17. Distinctive:

    If the push fails, stop and report the exact blocker.

    line 55
  18. Distinctive:

    Keep the final answer short:

    line 59
  19. Distinctive:

    commit SHA and push target, if shipped

    line 63
  20. Distinctive:

    Do not re-plan broad scope after implementation has started unless the request proves unsafe or ambiguous.

    line 68
  21. Distinctive:

    Do not commit or push from vague approval.

    line 69

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

Ship Change

Primary lens: Implementation.

Goal

Move a repo request from intent to delivered local changes with minimal ceremony, while keeping approval boundaries clear before commit and push.

Workflow

  1. Understand the request.
    • Inspect the repo before assuming architecture, commands, or conventions.
    • Check git status --short --branch before editing.
    • Identify whether the worktree has unrelated user changes.
  2. Plan briefly.
    • State the intended files or areas to touch.
    • Keep the plan proportional; use a short checklist for multi-step work.
    • Ask only when a missing decision would make the implementation risky.
  3. Implement.
    • Follow existing repo patterns.
    • Keep edits scoped to the request.
    • Do not revert unrelated user changes.
    • Update docs or indexes when the change affects user or agent workflow.
    • Use or add a script only when it removes repeated deterministic work.
  4. Validate.
    • Run the repo's documented checks for the changed surface.
    • If no checks are documented, run the lightest relevant inspection and say that no stronger validation exists.
    • Report any skipped checks and why.
  5. Review before shipping.
    • Show the changed files and validation result.
    • Inspect the diff yourself before asking for approval.
    • Propose a concise commit message.
    • Ask for explicit approval before committing or pushing unless the user already gave explicit approval for commit and push in the current request.
  6. Commit and push after approval.
    • Stage only the intended files.
    • Commit with the approved or clearly proposed message.
    • Push to the approved remote and branch.
    • Report the commit SHA, branch, remote URL, and validation performed.

Git Safety

  • Never use git reset --hard, git checkout --, rebase, force-push, or history rewrite unless the user explicitly requests that exact operation.
  • Do not use git add -A in a mixed worktree unless every changed file is in scope.
  • If publishing requires auth, remote creation, or a new branch, explain the target before acting.
  • If the push fails, stop and report the exact blocker; do not try destructive fixes.

Output

Keep the final answer short:

  • what changed
  • validation run
  • commit SHA and push target, if shipped
  • anything not done or still needing approval

Do Not

  • Do not re-plan broad scope after implementation has started unless the request proves unsafe or ambiguous.
  • Do not commit or push from vague approval.

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.

Check your setup, free