Draft Markup Technology License Agreement

Skill: Draft Markup of Technology License Agreement

1. Subject-matter triage (only if applicable)

• Confirm the primary deliverable is the markup/redline itself; do not let any summary, memo, or email draft displace the agreement file.
• Read the agreement, playbook, partner instructions, and product documentation as a single instruction set, then separate:
  • mandatory positions,
  • negotiable positions,
  • document-driven deal terms,
  • drafting gaps.
• Identify whether the draft is a single agreement or a family of related documents; if more than one instrument is in scope, analyze each instrument separately before harmonizing them.
• If the product documentation constrains the license grant, functionality, fields of use, deployment model, support obligations, or warranty scope, treat those constraints as controlling drafting inputs.

2. Failure modes the skill is correcting

• Marking only deviations that are already present while failing to add missing provisions the playbook requires.
• Treating the license grant as boilerplate instead of matching it to the product documentation, especially on scope, use restrictions, territory, exclusivity, and sublicensing.
• Missing commercially sensitive clauses on improvements, grantback, ownership of derivatives, and feedback.
• Overlooking audit, royalty, reporting, and payment mechanics even when the draft appears otherwise complete.
• Leaving warranty, indemnity, limitation of liability, and infringement allocation underdeveloped or internally inconsistent.
• Providing markup without plain-text change markers or without a short rationale for each change.
• Drafting comments that describe the issue but do not explain why the change is being made or how it aligns with the playbook.
• Failing to reconcile the agreement against internal instructions and product documentation before commenting.
• Using generic language where the deal requires precise terminology tied to the technology and the contemplated use case.

3. Legal frameworks / domain conventions that apply

• A technology license agreement must be checked for completeness, consistency, and conformity with the governing playbook rather than read as a standalone contract.
• License grant drafting should specify the licensed technology, permitted uses, field of use, territory, exclusivity, sublicensing, transferability, and any reservation of rights.
• Product documentation may function as the technical source of truth for what the technology does and does not do; the grant and warranty language should track that description.
• Grantback and improvement provisions should be narrow enough to avoid unintended transfer of unrelated developments and to preserve incentives to innovate.
• Audit and reporting provisions should permit verification of royalties or usage without becoming oppressive or commercially impractical.
• Warranty and indemnity language should align with the license scope and the risk allocation contemplated by the instructions.
• Confidentiality, ownership, feedback, open-source, export, compliance, and termination terms often interact with core license economics and should be checked for cross-consistency.
• Where legal propositions are stated in the commentary, cite the controlling authority or governing contract principle by name if the source documents identify it, or by the recognized doctrine, statute, rule, or regulation if not.

4. Analytical scaffolds

• Use a gap-and-deviation pass:
  • first identify provisions required by the playbook that are missing,
  • then identify existing provisions that depart from the prescribed position,
  • then determine whether the product documentation requires further narrowing or expansion.
• For each issue, decide whether the response is:
  • insert a missing clause,
  • replace a nonconforming clause,
  • narrow overly broad language,
  • harmonize inconsistent provisions,
  • or add a defined term / cross-reference.
• Assign an ordinal severity to every substantive markup comment using one consistent scale stated once at the top of the markup commentary.
• For every issue, include a short rationale that states:
  • the legal or commercial concern,
  • the relevant playbook or instruction basis,
  • and the downstream consequence of leaving the draft unchanged.
• When multiple parties, products, versions, or use cases are in play, enumerate them explicitly before drafting the markup so each receives a separate treatment.
• If the draft implicates a legal proposition, anchor the comment in the applicable rule, doctrine, statute, regulation, or contract principle rather than in conclusory language.
• Prefer drafting that is directly insertable into the agreement, with bracketed commentary immediately adjacent to the changed text.

5. Vertical / structural / temporal relationships (only if applicable)

• Reconcile definitions, grant language, restrictions, warranties, remedies, and termination provisions across the document so one clause does not silently defeat another.
• Check whether the grant is temporally limited by term, survival, transition rights, wind-down periods, or post-termination sell-off rights.
• Check whether obligations that should continue after termination are expressly identified, especially payment, confidentiality, audit, ownership, infringement indemnity, and accrued rights.
• If the transaction has phased implementation, launch, beta, pilot, renewal, or expansion stages, align the license scope and compliance obligations to the relevant phase.
• Track whether downstream rights depend on upstream approvals, delivery milestones, acceptance criteria, or technical specifications in the product documentation.
• Ensure that any improvement ownership, feedback rights, or derivative works provisions do not conflict with the ownership, license scope, or confidentiality structure elsewhere in the agreement.
• Confirm that royalty triggers, reporting periods, audit windows, and payment due dates are internally coherent and do not create undefined gaps.

6. Output structure conventions

• Produce the agreement as a true redline/markup, not a narrative summary standing in for the contract.
• Make every substantive change visible in plain text using robust markers such as [DELETED: …], [INSERTED: …], and [REPLACED: old → new], even if document styling also shows tracked changes.
• Place a short [Rationale: …] comment next to each substantive change; the rationale should be concise but specific.
• Use industry-conventional contract headings and internal organization rather than mirroring any hidden checklist or rubric structure.
• Include any newly required provisions as inserted clauses or schedules, clearly labeled as additions.
• Preserve existing language where it conforms; do not rewrite for style alone.
• Where the draft is silent on a required topic, add the missing clause rather than noting the omission only in commentary.
• Use bracketed commentary to flag unresolved negotiation points, but keep the markup operative and reviewable.
• End with a brief priority-ordered summary of key issues and a short recommended-actions section that assigns next steps to the appropriate role and timing anchor.