Prepare agreements and collaborations with AI
Make scope, contributions, rights, obligations and open choices explicit before drafting.
When a collaboration or service needs a clear agreement and standard clauses do not describe the actual work.
Domain competence · Method and learning · Public edition 0.3.2
Two groups share materials and intended results. Make contributions, access, timing and reuse questions visible for agreement.
The key relationship. Forms the agreement architecture from parties, intended outcome, exchanges and dependencies so the document can express those relations precisely.
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 ↗Before drafting an agreement, the relationship it should enable needs to be understood. Parties, contributions, deliveries, rights and conditions can seem clear in separate conversations yet conflict when brought together.
This competence forms a readable, reviewable agreement architecture. Document precision follows the actual relationship; legal sufficiency requires the sources and expertise pertinent to the case.
Start from the intended outcome and the relationship's sources: actual parties, roles, object and discussion state. Do not immediately fit the case into a standard contract. A map of what must be agreed may be the useful first form. Preserve the person's wording and decisions while keeping unresolved matters visible.
Clarify who provides what, to whom, when and under which conditions. Connect performance, resources, payment, access and acceptance evidence where pertinent. A delivery may depend on materials from another party; a payment may refer to an undefined event. Bring these relations together before drafting apparently precise commitments.
Project knowledge establishes feasibility and deliverables; business knowledge clarifies exchanges and negotiation position; writing makes definitions and consequences precise. None should invent the other's truth. When legal reliance matters, use current primary sources for the jurisdiction and appropriate qualified legal expertise. Otherwise return a review-ready structure and specific legal questions without declaring sufficiency.
Consider rights, obligations, conditions, duration, changes, exit and surviving relations where they matter. Ownership, reuse, data or confidentiality may be material in one case and absent in another. Do not fill unknowns with conventional wording. Check how definitions interact: responsibilities, dates and acceptance criteria can alter other terms.
The result may be a relation map, term structure, draft or comparison with supplied wording. Make agreed and unresolved matters visible. A counterparty response can change the next agreement but does not rewrite the source of earlier requests. Distinguish proposal, review, acceptance, signature and performance.
Composing and drafting do not send, accept, sign, pay, transfer rights or grant access. Keep each effect attached to its actual actor, means and authorization. After real work, preserve lessons that change future composition: hidden dependencies, ambiguous definitions, missing evidence or confused roles. Legal learning remains tied to qualified sources.
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 groups share materials and intended results. Make contributions, access, timing and reuse questions visible for agreement. Do not invent ownership or a licence when the parties have not determined them.
Delivery depends on data the client must provide. Connect data availability, the supplier’s work and acceptance criteria in the agreement architecture. Open choices become precise questions for the parties and relevant review.
A draft discusses completed delivery and payment but uses different definitions of the same result. Identify the mismatch and its operating consequence without automatically substituting clauses or declaring legal validity.
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.
Forms the agreement architecture from parties, intended outcome, exchanges and dependencies so the document can express those relations precisely.
Understand the actual parties, purpose, contributions, deliverables, acceptance, resources, rights and dependencies before selecting a contract form. Connect money, milestones and responsibilities to what each party can supply and decide. For an AI or research arrangement, distinguish source knowledge, existing intellectual property, generated work, licenses, data access, confidentiality, maintenance and authority over external actions when those relations matter. Do not turn every project into the same contractual template.
Expose a missing domain owner rather than asking business prose to invent the underlying relation. A technical source establishes what the product actually does; the business owner supplies selected commercial direction; qualified current legal sources and professionals supply legal interpretation where needed. The competence forms the operative arrangement without claiming enforceability from a coherent draft.
Write the selected document in clear terms that preserve those dependencies. A late change to rights or acceptance can affect payment, delivery and termination; follow the actual dependent clauses without rewriting unaffected terms. Keep negotiated determinations, unresolved points and assistant alternatives distinct. A term sheet, draft, agreed text, signature, filing and performance are different effects. Preserve version and exact selected parties/document before any authorized send or signature action.
Form an agreement's architecture from parties, intended result, exchanges and dependencies. Make scope, contributions, rights, obligations and unresolved choices explicit before drafting.
Use this competence when a collaboration or service needs a clear agreement and standard clauses do not describe the work. Relations clear in separate conversations may conflict when combined. Form an inspectable, revisable architecture. Document precision comes from the actual relation; legal sufficiency requires the sources and qualified competences pertinent to the case.
Begin with the intended result and relationship sources: participating people or organizations, actual roles, object and discussion state. Do not immediately fit the case into a standard contract. A map of issues to agree may be the useful first result. Preserve the person's words and choices while keeping unresolved matters visible.
Make understandable who offers what, to whom, when and under which conditions. Connect performance, resources, payments, access and acceptance evidence where relevant. A delivery may depend on materials another party must provide; payment may reference an event nobody has defined. Bring these relations into one field before drafting apparently precise commitments.
Project knowledge clarifies feasibility and deliverables; economic knowledge clarifies exchanges and negotiating position; writing gives definitions and consequences precision. None should invent the truth owned by another. For use as a legal instrument, reach current primary sources for the jurisdiction and the qualified legal competence needed. If unavailable, prepare structure and precise review questions without claiming legal sufficiency.
Consider rights, obligations, conditions, duration, changes, exit and continuing relations where they affect the agreement. Ownership, reuse, data and confidentiality may matter in one case and be absent in another. Do not fill unknowns with conventional wording. Understand how definitions interact: a responsibility, deadline or acceptance criterion can change other sections' meaning.
The result may be a relationship map, term structure, draft or comparison with a received document. Write so parties can see what is aligned and what needs a choice. A counterpart's response can change the next agreement without rewriting the provenance of earlier requests. Distinguish proposal, revision, acceptance, signature and performance.
Composing and writing do not send, accept, sign, pay, transfer rights or grant access. Keep each effect connected to the relevant person, means and authorization. After a real case, retain what changes later composition: hidden dependencies, ambiguous definitions, missing evidence or confused roles. Return legal learning to qualified sources and project or writing learning to their own methods.
The object is an agreement's architecture. This is a domain competence that can compose other knowledge; composition alone does not make it a competence generator or autological faculty.
It can learn about its own method when a case reveals an ignored dependency, such as delivery depending on client data that the structure failed to expose. Correcting composition helps later agreements without providing a legal guarantee or authority to bind parties.
A concrete case can change recognition of dependencies and responsibilities. Retain the correction's reasons and let each new context determine pertinent relations rather than making every clause universal.
Begin from available context and sources. The method can operate in chat; persistence, tools and external actions follow the recipient's means and 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.
The object is agreement architecture. This domain competence can compose other knowledge; composition does not automatically make it a competence generator or an autological faculty.
It can learn about its own method when a case reveals an overlooked dependency. A delivery may have depended on client data that the structure did not identify. Improving composition can help a later agreement; it supplies neither legal assurance nor autonomy to bind parties.
Competence, meta and autology: the conceptual guide ↗A concrete case can change how dependencies and responsibilities are recognized. Preserve the reasons for the correction and let the new context determine relevance, without turning every term into a universal template.
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.
