Share AI project work across repositories and collaborators
Keep the relationship between local changes, commits and shared source identifiable.
When people and assistants share a project and useful work should not remain hidden in a local checkout.
Technical competence · Builders and systems · Public edition 0.3.2
Two people work in the same checkout. Identify the selected change and share that contribution while retaining the other person’s work.
The key relationship. Understands the selected repository state and carries relevant changes forward while preserving concurrent work and shared revision identity.
An illustrative situation to adapt to your work. Read the complete cases ↓
You supply the context: research, a service, a creative project or a team’s work. Examples make the method visible; adaptation preserves the relationships that make it work while understanding the purpose, sources, people and means of your own assignment.
Tell your AI what you want to achieve, what already exists and a practical situation to address. Ask how this competence changes the work and which knowledge from your domain should participate. MAIOS provenance identifies the shared knowledge; you can use it directly in your AI or compose it with an existing kernel.
Adaptation examples in other contexts ↗Saved work can remain invisible to the person who needs to continue it. This competence connects a local result to the project's shared source while keeping the selected change identifiable.
Continuity includes the reasons for the change, concurrent contributions and the revision a collaborator can actually read. Commit, sharing and product deployment remain distinct effects.
Reach the repository that owns the work and its current instructions. Understand what should become shared and why. A containing folder may hold several repositories. Continuity matters at meaningful results or handovers; it does not require Git closure after every edit or publication during a read-only request.
Distinguish working files, local commits, tracking references, verified remote revision and generated or ignored artifacts. Use the project's Git tools and access policy to inspect branch, differences and remote relation. A local tracking reference can be stale; a successful fetch does not mean selected content is already shared.
Understand changes before staging. Select only the files or portions belonging to authorized work. Older or uncommitted work is not disposable noise. Integrate independent local and remote contributions while preserving both lines. Resolve overlapping changes according to their meaning rather than deleting valid work for an apparently clean state.
When the current mandate covers committing and sharing, review the selected payload, perform proportionate checks, create a coherent commit and share it on the intended branch using the recipient's authentication policy. If authority or access is missing, preserve the work and identify the exact open step without claiming shared source.
After sharing, verify the remote revision and its relation to local work and tracking. If reconciliation produces different identities, explain which commits or contents correspond. Provide an exact reference with relevant reasons and checks. Reachable source does not prove reading, installation or execution; deployment and release need their own evidence.
Preserve the useful change, its reason, revision, checks and any remaining local-only work in the project guide. If a later case exposes loss or unnecessary procedure, improve the continuity method. Its purpose is shared, reconstructable work rather than a Git ritual or forced synchronization of every repository.
These cases illustrate situations, causal distinctions and choices you can adapt to your work.
Italiano. The following cases illustrate how the method is used.
Two people work in the same checkout. Identify the selected change and share that contribution while retaining the other person’s work. Making the entire checkout appear clean is not the objective.
A local commit and a remote commit change independent objects. Recover both lines, integrate through the project’s chosen method and verify shared content. Divergence is not a reason to erase either contribution.
An assistant hands over an exact revision and the useful reason for its change. The collaborator can read that source and continue. The handoff does not claim that the revision has already reached a website or is active in a runtime.
Use SKILL.md or START_CHAT_EN.txt with the relevant sources and your actual context. Keep observations, interpretations and what remains open distinguishable. Preserve the useful reason and continuation in the project’s guide.
Understands the selected repository state and carries relevant changes forward while preserving concurrent work and shared revision identity.
Identify the owning checkout, current branch, selected paths, local changes, upstream and actual remote identity. A workspace container may contain several independent repositories. Do not attribute every dirty file to the current task. Preserve concurrent lanes and existing staged work; stage only the selected contribution. A tracking reference is a cached observation until refreshed through the authorized credential mechanism.
If remote and local work changed independently, inspect relevant overlap and preserve both valid contributions. Use the smallest integration that continues the selected work; a reset or forced synchronization can erase unrelated knowledge. Before sharing, review the selected diff and checks pertinent to the change. Commit and push through the repository's existing authority and credential policy, without printing or persisting secrets.
Verify what the actual remote contains and distinguish source sharing from installation, deployment or public runtime behavior. A source push can trigger a separate deploy in some projects; understand that project relation before invoking it. Preserve the exact shared identity and remaining recovery condition where later work needs them. A clean checkout does not establish product correctness, and an ahead/behind count alone does not select which branch's meaning should prevail.
Understand the selected repository and share relevant changes while preserving concurrent work and the identity of the shared revision. Keep local changes, commits and shared source recognizably connected.
Use this competence when people or assistants share a project and useful work must become reachable beyond a local checkout. Continuity includes reasons, concurrent contributions and the revision a collaborator can actually read. Commit, source sharing and product publication remain distinct effects.
Reach the repository owning the work and its current instructions. Understand what should become shared and why continuation needs it. A container folder may hold several repositories; do not treat them as one. Continuity becomes pertinent for a meaningful result or handoff, rather than requiring Git closure after every edit or publication during read-only work.
Distinguish working files, local commits, tracking references, verified remote revision and generated or ignored artifacts. Use the project's actual Git tools and access to inspect branch, differences and relation to the remote. A local tracking ref can be stale; successful fetching does not prove the selected content is shared. Do not print or persist credentials while gathering these facts.
Understand changes before preparing a commit. Select files or portions belonging to the authorized work. Old or uncommitted work is not disposable noise. Integrate independent local and remote contributions while preserving both lines. For overlapping work on one object, resolve their relation before selecting content. Do not create apparent order by deleting valid work.
When the mandate includes committing and sharing, inspect relevant content, run proportionate checks, create a coherent commit and share to the intended branch through the recipient's authentication. Do not import another environment's credential or push policy. If authority or means are absent, preserve work and identify the particular remaining step without claiming shared source.
After sharing, verify the remote revision and its relation to local result and tracking ref. When reconciliation produces distinct identities, explain which commits or content correspond and which remain different. Give an exact reference with pertinent reasons and checks. Reachable source does not prove reading, installation or execution. Deployment, release and activation need their own observation.
Preserve the useful change, reason, revision, checks and remaining local work in the project guide. Improve the continuity method when a new case exposes loss or unnecessary procedure. Its purpose is shareable, reconstructable work, not Git ritual or forced synchronization of every repository.
This is a technical source-continuity competence. Repository or agent counts do not automatically confer a meta level.
The method becomes an object of learning when a handoff reveals that a shared change was not reachable by the collaborator. Correcting that entry changes continuity itself. This is distinct from, and does not authorize, a process that pushes on a timer.
A later case shows whether work reaches shared source without loss or reconstruction. A technical check remains tied to the revision actually verified.
Begin with available context, sources and means. Chat can exercise the method; persistence, tools and external effects depend on actual mandate. Observe behavior and value in real work.
Read OPERATING_GUIDE.md as part of this method when forming the work. It carries the practical knowledge, decision relations and available means for this capability. The complete chat starter includes this knowledge and worked examples, so it remains usable without private sources. Preserve the public source identity and adapt through the recipient's actual means.
This is a technical source-continuity competence. The number of repositories or agents does not automatically give it a meta level.
Its method can become an object of learning when a handover shows that shared work was not reachable by the collaborator. Repairing that entry changes continuity practice. This differs from an autonomous process that pushes on a schedule and does not authorize one.
Competence, meta and autology: the conceptual guide ↗A later case shows whether work reaches shared source without loss or repeated reconstruction. A technical check remains attached to the revision it actually verified.
Attach or paste START_CHAT_EN.txt, which contains the complete method, and add your context. The AI can work in the conversation's language. Retain the result and useful guidance if you want to resume in another chat.
Make the competence folder readable and have the agent read SKILL.md for the relevant work. Connect real sources and tools according to the environment's instructions. The kit does not install accounts, memory or recurring execution.
With an existing kernel, connect the method to the competence or guide already responsible for the work. Without one, apply the instructions directly and preserve useful knowledge in the project or a reusable note.
Read or copy the complete English starter and add your context. English is the kit’s primary language; Italian counterparts are included.
