Closing checklist memorandum for an intellectual property and technology asset purchase transaction, organizing pre-closing conditions, closing deliverables, and post-closing obligations derived from the governing transaction documents.
Scanned 9/11/2026
Install to Claude Code
npx -y skills add sunyifeisb-art/legalwork --skill draft-closing-checklist-memorandum --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Draft Closing Checklist Memorandum?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sunyifeisb-art-draft-closing-checklist-memorandum)More formats (shields.io, HTML) on the badges page.
---
name: draft-closing-checklist-ip-asset-purchase
task_id: intellectual-property/draft-closing-checklist-memorandum
description: Closing checklist memorandum for an intellectual property and technology asset purchase transaction, organizing pre-closing conditions, closing deliverables, and post-closing obligations derived from the governing transaction documents.
activates_for: [planner, solver, checker]
---
# Skill: Draft Closing Checklist Memorandum for IP & Technology Asset Purchase
## 1. Subject-matter triage
- Confirm the transaction is an asset purchase involving IP, technology, or related intangible rights, not a equity deal.
- Pull every operative source document into one pass: acquisition agreement, schedules/exhibits, disclosure schedules, consent tracker, assignment forms, escrow instructions, transition services, and any ancillary release or license documents.
- Separate items that must be satisfied before signing, before closing, at closing, and after closing; do not compress them into one undifferentiated checklist.
- Treat the checklist memorandum as the organizing instrument, not a legal opinion: its job is to surface what must happen, by whom, when, and in what sequence.
## 2. Failure modes the skill is correcting
- Producing a generic checklist that ignores the transaction-specific conditions, deliverables, and covenants in the deal documents.
- Missing third-party consents, assignment restrictions, or approval chains that are on the critical path to transfer.
- Failing to distinguish closing deliverables from post-closing covenants, recordations, or transition obligations.
- Collapsing multiple parties, assets, or deadlines into a single summary item instead of tracking each separately.
- Omitting the practical status signal the reader needs to run the closing process.
## 3. Legal frameworks / domain conventions that apply
- IP and technology asset purchases typically require assignment of enumerated assets, plus any ancillary instruments needed to transfer associated goodwill, source code, data rights, domain names, registrations, and contract rights.
- Transfer may be constrained by anti-assignment terms, consent requirements, security interests, government recordation rules, or export / data / privacy restrictions reflected in the documents.
- Closing conditions in the governing purchase agreement control whether the transaction may close; the memorandum should track each condition and the party responsible for satisfaction.
- Recordation of IP assignments follows the applicable office or registry practice for the relevant asset class and jurisdiction.
- If the transaction includes escrow, transition services, seller licenses, or retained-use covenants, those items are continuing obligations and must be tracked after closing.
- When the source documents cite a governing statute, regulation, rule, or contract provision, carry that authority through the memorandum rather than stating the obligation abstractly.
## 4. Analytical scaffolds
- Build the memorandum by extraction first, analysis second: identify every condition, deliverable, consent, filing, and covenant from the source set.
- For each item, record four fields: what must be done, who must do it, when it is due or triggered, and current status.
- Enumerate each distinct party, consent counterparty, filing jurisdiction, and post-closing obligation separately before assigning status or priority.
- Cross-check each item against related documents so the memorandum reflects dependencies, duplicates, and sequencing points.
- For items governed by a cited rule or contractual provision, include the specific authority in the item entry.
- If only one item exists in a category, say so affirmatively; do not imply multiplicity or fabricate a tracker.
## 5. Vertical / structural / temporal relationships
- Organize the memorandum vertically by transaction phase, then by responsible party within each phase.
- Use a sequence that mirrors execution: pre-closing conditions, closing deliverables, third-party consents, filings/recordations, then post-closing obligations.
- Flag dependency relationships where one deliverable triggers another, where a consent is needed before an assignment, or where a filing follows a closing act.
- Distinguish timing anchors precisely: before signing, before closing, at closing, promptly after closing, and continuing after closing.
- Where a continuing covenant spans multiple periods, note both the start trigger and the duration or endpoint stated in the documents.
## 6. Output structure conventions
- Draft a memorandum in a conventional checklist format, with clear headings for each transaction phase and subheadings by responsible party.
- For each item, include:
- description of the deliverable, condition, consent, filing, or obligation;
- responsible party;
- deadline or trigger;
- current status;
- governing source or cited authority, if identified in the documents.
- Use a concise checklist style that is operational rather than narrative.
- Include a brief closing note section for unresolved items, open dependencies, or items needing follow-up.
- End with an action-oriented wrap-up that identifies the immediate next steps for counsel or the deal team.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!