Work on an agent with someone else

Before any tooling, settle one thing: which copy is the real one. Everything else follows from that answer, including who is allowed to change what.

• The instructions and skills live in one repository, and that repository is the copy.
• One person owns publishing here, so two versions never compete for the same page.
• The README names who to ask, by handle, so a reader knows where a question goes.

That first bullet is the one that saves the most time. Keep your agent in Git is how the copy gets a history and a way back.

Upload it as a private pack and put their handle on the audience list. They can read it and download it while it waits for review, and nothing about it is public.

An audience is a list of handles, up to twenty, and the pack's owner can rewrite it later. Name your collaborators covers who can do what, and Who can see your agent template covers the moment a pack stops being private.

Download it, change it, and upload your version. Then say in the summary what you changed and whose work it started from.

That one line is the difference between an adaptation and a copy. A pack presented as yours when it is not is one of the three things that sends a pack back, listed in What review checks.

The licence sets the floor rather than the ceiling. MIT asks you to keep the notice, Apache-2.0 asks you to keep the notices and say what you changed, and CC-BY-4.0 asks for credit and a note of the changes. All three allow commercial use (MIT, Apache-2.0, CC-BY-4.0).

• Specialise: keep the skills that fit, and rewrite the instructions for the new job.
• Generalise: lift the part that works, and drop the assumptions about the old one.
• Credit: name the original author in the README and in the summary you upload with.
• Ask: the author's handle is on the pack's page, and they are the fastest answer about their own work.

An audience of twenty handles is a private beta with a review at the end of it. Publish an early version, let people run it, and change one thing at a time so you can tell what caused what.

Every published version keeps its change note, so a reader can see what moved between the build they ran and the one in front of them. That history is also the fairest record of who did what.