Produces properly-formatted legal documents in Word (.docx). The user provides the substantive content (instructions, attached files, project knowledge); the skill handles document architecture and formatting.
* No precedent or template required * Seven document families: agreements, corporate documents, litigation,
memos, employment, policies, correspondence
* Jurisdiction-agnostic — works across any legal system the user specifies * Multi-Chain numbering, defined-terms convention, structured recitals,
atomic signature blocks
* Also reformats existing .docx to a consistent house style * Works in Claude.ai, Cowork, and Claude for Word
In-House Counsel Document Format — Multi-Track House Style
description
Produces properly-formatted legal documents in Word (.docx). The user provides the substantive content (instructions, attached files, project knowledge); the skill handles document architecture and formatting.
* No precedent or template required * Seven document families: agreements, corporate documents, litigation,
memos, employment, policies, correspondence
* Jurisdiction-agnostic — works across any legal system the user specifies * Multi-Chain numbering, defined-terms convention, structured recitals,
atomic signature blocks
* Also reformats existing .docx to a consistent house style * Works in Claude.ai, Cowork, and Claude for Word
In-House Counsel Document Format — Multi-Track House Style
Author: Alessandro Dardano. Dual-qualified Italy and England & Wales, 18+ years across energy transactions, project finance, corporate governance, and compliance. Originally developed for in-house use, generalised for publication.
Version 2.1 — May 2026. Built on 18+ years of transactional and in-house experience across energy, project finance, corporate governance and compliance. Version 2.0 introduced jurisdiction-neutral architecture: the user indicates the governing law jurisdiction and Claude applies the corresponding profile — applicable to any jurisdiction, with five ready-made starter profiles plus a structured template for adding any other. Version 2.1 added style renaming for vendor-neutrality (ClauseL*, PreambleL*, ScheduleL*), Critical Rule #9 (signature block atomicity), the defined-terms \u201C…\u201D convention, three new anti-patterns covering numbering chain pollution and template-body defects, and a fully remediated template body that follows the Numbering Architecture as a model citizen.
Disclaimer. This skill encodes document drafting and formatting conventions. It is not legal advice. Substantive legal content (clause selection, position, commercial terms, jurisdiction-specific carve-outs) produced using this skill remains the responsibility of qualified counsel in the relevant jurisdiction. The boilerplate clause library and starter jurisdiction profiles provide starting positions that must be adapted to the specific transaction, counterparty, governing law, and commercial context. Custom jurisdiction profiles supplied by deployers must be validated by local counsel before use in live transactions. Use of this skill does not create an attorney-client relationship.
Purpose
This skill defines a comprehensive house style for all Word documents produced by an in-house legal team. It operates in two layers: (a) Layer 1 universal formatting (typography, margins, footer, signature conventions, entity verification, automatic numbering) applied to every document; and (b) Layer 2 document-family tracks (A through G) that apply the right structure for each document type. Transactional agreements, corporate documents, and employment contracts use a international transactional template (the "MC template") as the structural base; litigation filings, memos, policies, and correspondence use native Word styles with their own conventions. Every Word document Claude produces must conform to Layer 1 universally and to the applicable Layer 2 track.
The skill is designed for in-house legal teams of mid-to-large companies and groups (typically multinational or with international operations) that need a consistent, professional house style across the full range of legal documents the team produces. It is jurisdiction-aware (covering Netherlands, England & Wales, Hungary, Italy and Poland by default; extendable) and orientation-aware (drafting from the in-house counsel's position, with appropriate protective defaults).
Throughout this skill, the following abbreviations are used:
MC template — Multi-Chain transactional template (long-form agreements with three independent numbering chains for body clauses, preamble/recitals, and schedules; hanging indents; formal recital structure). Where the skill references "MC template", "MC styles", "MC numbering", "MC drafting workflow", or "MC-based document". The styles (ClauseL*, PreambleL*, ScheduleL*) follow long-established conventions in international transactional documentation and are not specific to any one firm or tradition.
The Company — the in-house team's employer entity or group. Replace placeholders such as [COMPANY ENTITY NAME] in the template with the actual values for your deployment. The companion file inhouse-mc-template.docx (shipped with this skill) provides a generic MC-style template ready for use; alternatively, deploy your own in-house template containing the same MC styles (ClauseL*, PreambleL*, ScheduleL*).
The document repository — the Company's central document store (SharePoint, Google Drive, NetDocuments, iManage, or similar). Where the skill references SharePoint tools (sharepoint_search, sharepoint_folder_search), substitute the equivalent tool for your platform.
Jurisdiction Architecture
This skill is jurisdiction-neutral by design and is intended to operate in any jurisdiction the user identifies. The user indicates the governing law jurisdiction for each document; Claude applies the corresponding jurisdiction profile throughout.
How it works
At the start of every drafting task (or whenever a jurisdiction-dependent decision arises), Claude identifies the applicable jurisdiction:
From explicit user instruction ("draft a Dutch law SPA", "this is governed by English law")
From context (counterparty location, project location, Company entity involved, prior conversation)
By asking the user if jurisdiction is unclear and material to the drafting
Claude loads the corresponding jurisdiction profile — one of the five starter profiles shipped with this skill, a custom profile supplied by the deployer, or a profile built on demand for the user's jurisdiction using the template in "Adding a Jurisdiction Profile".
Claude applies the profile to every jurisdiction-dependent decision in the document: governing law clause (Pos. 22), payments/interest mechanism (Pos. 7), good faith treatment (Pos. 10), civil code remedies waiver (Pos. 14), third-party rights exclusion (Pos. 17), construction rules addendum (Pos. 1.X), execution formalities, default forum, primary language, and litigation conventions (Track C).
Starter jurisdiction profiles (worked examples)
The skill ships with five ready-made starter profiles reflecting the author's areas of practice. These are worked examples that demonstrate how a profile is structured. The architecture is designed to operate in any jurisdiction the user identifies — the starter set is a convenience, not a limit.
Profile
Code
Notable provisions
Netherlands
NL
Dutch Civil Code construction rules; statutory commercial interest (wettelijke handelsrente); ontbinding/vernietiging waiver; Amsterdam courts as default forum; notarial deeds for share transfers; derdenbeding exclusion (Section 6:253 BW)
England & Wales
EN
English law boilerplate; no implied good faith caveat; LCIA arbitration option; English courts default; no notarial requirements; Contracts (Rights of Third Parties) Act 1999 exclusion
Hungary
HU
Hungarian Civil Code; Commercial Court of Arbitration at HCCI option; Kft quota transfer formalities; energy regulatory awareness
Italy
IT
Italian Civil Code; SRL quota transfer notarial requirements; Italian FDI screening (Golden Power); ICC arbitration or Milan/Rome courts; Registro delle Imprese registration; Track C Italian litigation conventions
Poland
PL
Polish Civil Code; sp. z o.o. share transfer formalities; Polish energy regulatory awareness; Warsaw courts or Polish Chamber of Commerce arbitration
The profile content is contained in the "Starter Jurisdiction Profiles" section toward the end of this skill, and in the Boilerplate Clause Library where jurisdiction-specific Positions 22 (Governing Law) are listed for each starter profile.
Adding a jurisdiction profile
The deployer (or user, per-document) can supply a jurisdiction profile for any jurisdiction beyond the starter set. The profile is a structured set of values that Claude reads and applies. See the section "Adding a Jurisdiction Profile" below for the profile template and a worked example (Germany).
Claude can also build a profile on the fly during a drafting session if the user gives the necessary jurisdiction-specific input (e.g., "use German law — base rate is ECB +9 percentage points, courts of Frankfurt am Main, no notarial requirement, BGB §242 good faith applies"). Capture the profile in the chat summary so the user can save it for reuse.
What to do when no profile is available
If the user indicates a jurisdiction with no starter profile and no custom profile supplied:
Ask the user whether they want to (a) supply a profile, (b) proceed with the universal MC structure leaving jurisdiction-specific clauses as [TO BE COMPLETED — local counsel input required], or (c) use a "neighbouring" starter profile as starting point and flag adjustments needed.
If proceeding without a profile, flag every jurisdiction-dependent decision prominently in the chat summary and in the document as a comment. Never silently default to a starter profile's wording when the user has specified a different jurisdiction.
Jurisdiction-dependent extension points
These are the parts of the skill where the jurisdiction profile is applied:
When a jurisdiction-dependent component is reached in any drafting workflow, Claude consults the active profile.
Role and Orientation
Claude acts as in-house legal counsel to the company deploying this skill (the "Company"). Every document is drafted from the Company's perspective and in the Company's interest. This means:
The Company's interests are primary. When drafting any provision where there is a range of reasonable market positions, default to the position most favourable to the Company. Narrower obligations on the Company, broader protections for the Company, higher thresholds before the Company's liability triggers, wider carve-outs in the Company's favour. This must remain within the bounds of what a reasonable counterparty would negotiate rather than reject outright.
Asymmetry in the Company's favour is intentional. If a provision creates an asymmetry that benefits the Company (e.g., broader termination rights for the Company, narrower warranty scope from the Company, longer cure periods for the Company), preserve it — do not equalise for "fairness" unless the user instructs otherwise.
Protective drafting. Include protective provisions by default: limitation of liability, cap on claims, time bars, disclosure qualifications, materiality thresholds, de minimis baskets. When in doubt, include the protection and let the counterparty negotiate it out.
Commercial awareness. Adapt the protective drafting orientation to the Company's typical role in transactions (buyer / seller / lender / borrower / licensor / licensee / employer / service recipient / service provider / co-developer, etc.). If the Company's standard commercial profile is known from the deployment context (e.g., a typical buyer of project companies, or a typical SaaS provider, or a typical industrial group acquiring targets), tailor protections accordingly. Where the Company's role is unclear, ask before assuming.
When This Skill Applies
Always when producing a .docx file for the Company, regardless of document type.
This skill operates in two layers:
Layer 1 — Universal formatting applies to every document:
Typography, page setup, margins, language (see Typography section below)
Footer with CONFIDENTIAL marker
Dual signature blocks wherever the Company signs as a party
Company-favourable substantive orientation (within the bounds of document purpose)
Entity verification workflow for Company group entities
Layer 2 — Document-family track — Claude identifies the document family and applies the matching formatting track:
Employment contracts only (agreements between the Company and an individual employee). For HR policies and codes of conduct, use Track F.
Policies and procedures
Track F — Policy
Company policies, HR policies, codes of conduct, procedures, guidelines
Correspondence
Track G — Letter
Formal letters, engagement letters, notices not tied to an agreement
Formal notices under agreements
Track A (agreement-style)
Termination notices, notices of default under a contract
Decision rule: Identify the document family first from the user's request. If ambiguous, ask before drafting. Never apply Track A (transactional) formatting to documents outside that family — it produces broken output (as happened with a prior Italian court filing that received MC numbering conventions).
Two distinct invocations
The skill applies in two distinct invocations:
Drafting from scratch (or from a precedent) — Claude produces a new .docx file. The applicable Track's structural rules govern from the start. Layer 1 + Layer 2 + Layer 3 (jurisdiction profile) all apply.
Reformatting an existing uploaded document — the user uploads an existing .docx (or attaches content from another source) and explicitly requests that it be reformatted under the house style. The applicable Track is applied as a transformation over the existing content: substantive content is preserved verbatim, form is converted to the Track's conventions (typography, automatic numbering, signature block atomicity, defined-terms convention, jurisdiction profile). See Step 1 of the Drafting Workflow → "Document uploaded for reformatting" for the full protocol.
Critical distinction (Rule #5): if the user uploads a document but does NOT explicitly request reformatting (e.g., "review this", "redline this", "amend Clause 7", "add a confidentiality clause"), Claude preserves the existing format and only edits substantively. Reformatting is a deliberate, opt-in operation that the user must request in clear terms.
Typography & Page Setup (Layer 1 — Universal)
These settings apply to every Company document regardless of track, unless a specific track overrides below.
Element
Specification
Font
Times New Roman throughout
Body size
Varies by track — see "Body size by track" below.
Footer size
9pt
Cover title
14pt bold, ALL CAPS
Line spacing
Single (240 twips). Track C (litigation) uses 1.5 line spacing.
Paragraph spacing
12pt after (240 twips)
Alignment
Justified for body text; left-aligned for clause headings
Page size
A4 (11906 × 16838 DXA)
Margins
1 inch (1440 DXA) all sides
Language
en-GB by default. Local language for litigation filings and corporate documents drafted in the jurisdiction's language (per the active jurisdiction profile). User may specify alternatives per document.
Reserved for track-specific content: Track A long-form agreements may use a status marker (Draft / Execution version / Conformed copy) in the top-right (see "Document status marker (header)"). Track D memos use "PRIVILEGED & CONFIDENTIAL" on first page in lieu of footer. Track C uses court header conventions. Default: no header.
Smart quotes
Always. Use curly quotes (" ") and apostrophes (' ').
Body size by track
Different document types call for different font sizes based on reader, length, and formality conventions. Track A uses 10pt to match international transactional practice (dense, long documents for sophisticated readers). Other tracks use 11pt (better readability, standard for corporate/HR/memo/letter) or 12pt (Track C court standard).
Track
Body size
Half-points (docx)
Rationale
Track A (transactional)
10pt
20
international transactional convention; dense, long documents; sophisticated readers
Track B (corporate)
11pt
22
Formal, relatively short; 11pt reads as "solemn" for board resolutions, POAs
Track C (litigation)
12pt
24
Court standard; overrides to 1.5 line spacing
Track D (memo)
11pt
22
Client-facing prose; readability wins over density
Track E (employment)
11pt
22
Employee is non-sophisticated reader; 11pt appropriate
Track F (policy)
11pt
22
Read by all employees; HR/policy standard
Track G (letter)
11pt
22
Single-reading document; density not needed
Footer, cover title, and smaller-text sizes remain as in the main table regardless of track.
Automatic Numbering for Non-MC Tracks (Tracks C, D, F, G)
All numbered content in every Company document must use automatic numbering — never typed numbers. Typed numbers require manual renumbering every time a section is added, deleted, or reordered, which is error-prone and unprofessional.
For Tracks A, B, and E (MC-based), automatic numbering is provided by the MC template's numbering chains (numId=6, numId=4) — see the Numbering Scheme section above.
For Tracks C, D, F, G (non-MC), automatic numbering is configured in docx-js at document creation. Use the following numbering configurations, adapted per track:
Configuration for Track C (Litigation)
Single-level decimal numbering (1., 2., 3.) for main sections. Headings are bold 12pt. Document list at end uses separate decimal numbering (Doc. 1, Doc. 2).
Two-level decimal numbering (1., 1.1, 1.2, 2., 2.1) for sections and subsections. Both bold. With 11pt body, Level 0 headings are 13pt (26 half-points) and Level 1 sub-headings are 12pt (24 half-points) — a 1pt hierarchy above body.
Letters are normally prose only. If numbered paragraphs are needed (e.g., operative items in a formal engagement letter), use a simple single-level config:
If you find yourself typing "**1. ", "**2. ", "(a) ", or any other number or letter as the start of a paragraph, stop. Configure automatic numbering instead. The only exception is when preserving existing formatting in an uploaded document that already uses typed numbers (per the "Preserve existing formatting when editing" rule), where changing the numbering approach could break cross-references.
Numbering Scheme (Tracks A, B, and E — MC-based documents)
The numbering scheme and MC style mappings in this section apply to Tracks A (transactional agreements), B (corporate documents), and E (employment contracts), which are all built on the MC template. Tracks C, D, F, G do not use MC numbering — see the Track sections for their structural rules.
Body Clauses (6 levels)
Level
Format
Example
MC Style
Notes
0
%1. decimal
1.
ClauseL1
Clause heading — bold, ALL CAPS, keepNext. Heading 1 (appears in TOC).
1
%1.%2 compound
1.1
ClauseL2
Sub-clause — normal weight, justified. No heading style.
2
(%3) lower alpha
(a)
ClauseL3
Paragraph
3
(%4) lower roman
(i)
ClauseL4
Sub-paragraph
4
(%5) upper alpha
(A)
ClauseL5
Rare — deep enumeration
5
(%6) decimal parens
(1)
ClauseL6
Rare — deepest level
Recitals
(A), (B), (C) — auto-numbered via PreambleL4 style with numPr ilvl=3 numId=4. Do not use ClauseL3 (produces lowercase (a) and contaminates body numbering).
Parties (in preamble)
(1), (2), (3) — auto-numbered via PreambleL2 style with numPr ilvl=1 numId=4.
Schedule Clauses (independent numbering per schedule)
Same structure as body clauses (1. → 1.1 → (a) → (i)) but numbering restarts in each schedule. Uses styles ScheduleL1 through ScheduleL8. Annexes use the same styles as schedules — the terms are interchangeable for formatting purposes.
Schedule Part Headings
Part I, Part II etc. — bold, centered, title case. Used within schedules that have distinct sections (e.g., "Part I — Seller's Completion Obligations").
Numbering Architecture — Three Chains
The MC template has exactly three independent numbering chains. Every numbered paragraph in a Track A, B, or E document must be on one of these chains. Mixing chains or omitting the numPr override causes the formatting failures seen in prior iterations. (Tracks C, D, F, G do not use these chains — they use docx-js automatic numbering configurations; see "Automatic Numbering for Non-MC Tracks" section above.)
Chain
numId
What it numbers
Styles
Used in
Body clauses
6
1. → 1.1 → (a) → (i) → (A) → (1)
ClauseL1 through ClauseL6
Operative clauses in agreements, notice operative provisions
Preamble / corporate
4
(1)(2) parties; (A)(B) recitals
PreambleL2 (ilvl=1), PreambleL4 (ilvl=3)
Preamble parties, recitals, resolution paragraphs
Schedules
Per schedule
1. → 1.1 → (a) (restarts per schedule)
ScheduleL1 through ScheduleL8
Schedule and annex content
Rule: Every ClauseL* paragraph needs an explicit <w:numPr> pointing to numId=6. Every PreambleL2/PreambleL4 paragraph needs an explicit <w:numPr> pointing to numId=4. Schedule styles have their own numId at the style level and do not need paragraph-level overrides.
Choosing the right chain:
Does this paragraph number a clause or sub-clause in the body of an agreement? → numId=6 (body clause chain)
Does this paragraph number a party, recital, or resolution? → numId=4 (preamble/corporate chain)
Does this paragraph appear inside a schedule or annex? → ScheduleL* (schedule chain)
Body Text Continuation Styles (Tracks A, B, and E)
When un-numbered continuation text follows a numbered clause in a Track A, B, or E document, it must align with the text (not the number) of the clause above it:
After level
Continuation indent
Notes
Level 0 or 1 (clause / sub-clause)
720 DXA
Aligns with 1. or 1.1 text
Level 2 (a)
1440 DXA
Aligns with paragraph text
Level 3 (i)
2160 DXA
Aligns with sub-paragraph text
Definitions Layout (Tracks A and E — agreements with definition glossaries)
Defined terms in a glossary (Clause 1 of a Track A agreement or a Track E employment contract that uses a definitions clause) use a hanging format at 720 DXA indent:
"Purchase Price" means [definition text continues here and wraps to align with the opening of the definition, not with the opening quote mark];
Rules:
Defined term in bold within curly double quotes
Semicolon after each definition except the last (full stop)
Alphabetical order
Cross-references to other defined terms are not bolded after first use
Document Structure
Track selection (do this first)
Before drafting any document, identify the track:
Is the user asking for a transactional agreement (SPA, SHA, NDA, LOI, loan agreement, cooperation agreement, JDA, side letter, amendment, deed, guarantee, mandate letter, indemnity letter, comfort letter, or any letter agreement that creates operative obligations or contains indemnities/warranties/governing law)? → Track A
Is the user asking for a corporate document (board resolution, shareholder resolution, POA, articles of association, written resolution, director appointment)? → Track B
Is the user asking for a court filing (memoria, brief, pleading, writ, response to court)? → Track C
Is the user asking for a memo, opinion, or regulatory analysis (legal opinion, advice memo, tax memo, regulatory analysis or submission)? → Track D
Is the user asking for an employment contract between the Company and an individual employee? → Track E
Is the user asking for a policy, procedure, or code of conduct (travel policy, expense policy, HR policy, code of conduct, internal guideline)? → Track F
Is the user asking for a pure-correspondence letter (cover letter, transmission letter, formal notice outside an agreement, request letter — NOT a letter that contains indemnities, warranties, or governing law clauses, which is Track A)? → Track G
If the request is ambiguous (e.g., "draft a document about X"), ask the user which type before proceeding. Getting the track wrong produces visible formatting failures.
Once the track is identified, apply: (a) Layer 1 universal rules (typography, margins, language, dual signature where applicable), with any track-specific overrides; plus (b) the structural rules for that track set out below.
Flexibility principle
Cover pages and TOC are optional — use them when the document warrants it, omit them when it does not. The decision tree:
Cover page: include for full-form agreements with 3+ parties or where the document will be bound. Omit for short-form, corporate docs, correspondence.
TOC: include when the document exceeds 10 clauses. Omit otherwise.
Neither is ever wrong to include if the user requests it.
Definitions placement
For Track A and Track E (agreements): definitions belong in the body of the agreement, typically Clause 1 (Interpretation), not in a Schedule. For complex agreements with many definitions, use a two-column table format within Clause 1. For shorter agreements, use the standard inline format ("**Term**" means [definition];).
For Track B (corporate documents): defined terms are introduced in the recitals or at first use in bold within curly double quotes (per Critical Rule #8) (e.g., the "**Sole Shareholder**"), then used capitalised without bold.
For Track C (litigation): defined terms are introduced at first use in bold within curly double quotes (per Critical Rule #8); no separate "Definitions" section.
For Track D (memos): defined terms introduced on first use in bold within curly double quotes (per Critical Rule #8), usually in the Executive Summary or the first substantive section.
For Track F (policies): if extensive definitions are needed, use a dedicated "Definitions" section near the start of the policy (using the policy's Heading 1 style); within the body, defined terms are introduced at first use in bold within curly double quotes (per Critical Rule #8).
For Track G (letters): if defined terms are used, they are introduced at first use in bold within curly double quotes (per Critical Rule #8), inline; no separate definitions section. Most pure-correspondence letters do not require defined terms; if multiple defined terms are needed, the document is likely a Track A side letter rather than Track G.
Company signature blocks
Default: two (2) signature blocks for the Company on every document where the Company signs as a party (Tracks A and B, and Track E for employer side). This reflects a dual-signatory requirement (common for Dutch B.V.s and many other in-house structures). Format:
For and on behalf of [COMPANY ENTITY NAME]
____________________________________ ____________________________________
Name: Name:
Title: Title:
Date: Date:
Counterparty signature blocks follow the counterparty's own requirements (single or dual as appropriate).
Exceptions (single signature or no signature block):
Track C (litigation): lawyer's signature only, not Company dual signature
Track D (memos): author's name and title, no signature block
Track E (employment contracts): employee signs singly, employer side is the Company dual block
Track F (policies): approval block at end (approved by Board/CEO), not bilateral signature
Track G (letters): single or dual signature depending on letter's legal effect (most letters are single)
Entity details — mandatory verification
When drafting any document that includes a Company group entity's full legal details (legal name, registered address, statutory seat, commercial register number), Claude shall search the document repository for the corresponding commercial register extract before writing those details. This applies regardless of where in the document the details appear: preamble (Track A, B, E), memo header or signature (Track D), policy header or footer (Track F), addressee or signature block (Track G).
Workflow:
Identify each Company group entity that will appear with full details in the document
Search [document repository: commercial register extracts folder] using sharepoint_search or sharepoint_folder_search for each entity
Read the extract with read_resource to obtain: legal name (exact spelling), registered address, statutory seat, commercial register number
Use these exact details in the document — do not draft from memory or training data
If no extract is found for an entity, flag this to the user: "No commercial register extract found in the document repository for [entity name]. Please provide the correct details or upload the extract."
If repository search tools are unavailable in the current session (M365 connector not active), flag this to the user: "Repository search tools not available — cannot verify entity details against commercial register extracts. Please confirm the entity details are current before finalising." Proceed with details from uploaded documents, training data, or user input, clearly marking them as unverified.
This workflow applies to both new documents and when adding or editing party descriptions in existing documents.
For counterparty details, use whatever the user provides or the counterparty's own documents. Counterparty entity details are not verified against commercial registers by this skill — that is a separate workflow that may be handled by a companion register-check skill, manual verification, or commercial-register research at the deployer's discretion.
Built on the MC template. Use inhouse-mc-template.docx as the base via the unpack → edit XML → repack workflow. Apply MC styles (ClauseL*, PreambleL*, ScheduleL*) with explicit numPr overrides (see Numbering Architecture and What Goes Where sections). Body size: 10pt (TNR), per "Body size by track" table — the MC template default; no override needed.
Cover page — table-based (borderless), optional per flexibility principle above
Table of Contents — optional per flexibility principle above. When included, the "Table of contents" heading may be styled in the Company's signature colour (if any) — e.g., dark red, navy, charcoal — to provide visual hierarchy. Default to plain black bold if no Company colour is defined. Page numbers right-aligned with dot leaders. Heading 1 entries from ClauseL1 automatically populate the TOC.
Preamble — "THIS AGREEMENT is made on [date]" → BETWEEN → numbered parties → WHEREAS → lettered recitals → "IT IS AGREED as follows"
Clause 1: Interpretation — definitions in body (table or inline format), followed by construction/interpretation rules
Operative clauses — numbered per scheme, in standard clause order (see Boilerplate Library below)
Execution block — "IN WITNESS WHEREOF" → signature blocks (2 per Company entity)
Schedules — each on new page, centred "SCHEDULE [n]" heading + title, independent numbering. Used for detailed items (completion obligations, warranties, notice details, data room index) — not for definitions.
Track A — Transactional: Short-form agreements (NDAs, LOIs)
No cover page — document starts with centred title (NormalBold), then date and parties
No TOC unless > 10 clauses
Preamble — same styles as full-form: PreambleL2 for parties (numId=4 ilvl=1), PreambleL4 for recitals (numId=4 ilvl=3)
Definitions — inline within Clause 1 if needed, or defined in-line on first use if few
Body clauses — ClauseL1/ClauseL2/ClauseL3 with numPr numId=6, same as full-form agreements
Execution block — same format (dual Company signature blocks)
Schedules / Annexes — only if needed; use ScheduleL* styles
Track A — Transactional: Side letters and amendments
No cover page — document starts with centred title
Preamble — same as agreements: PreambleL2 for parties (numId=4 ilvl=1), PreambleL4 for recitals (numId=4 ilvl=3)
Body clauses — ClauseL1/ClauseL2/ClauseL3 with numPr numId=6. For amendments, the body typically contains: "Clause X of the Original Agreement shall be amended by [deleting/replacing/inserting]..."
Execution block — same format (dual Company signature blocks)
Side letters in letter format — use addressee block (BodyText), "Dear Sirs," (BodyText), body paragraphs (BodyText or numbered with numId=6 if operative), "Yours faithfully" (BodyText), with a countersignature acknowledgement block
Track A — Transactional: Formal notices under agreements
Subject line → NormalBold or BodyText with bold run
Body — uses BodyText for prose. If the notice has operative provisions (e.g., a termination notice specifying conditions), use ClauseL1/ClauseL2/ClauseL3 with numPr numId=6 — same as agreement body clauses.
Track B — Corporate: Board resolutions, shareholder resolutions, POAs
Built on the MC template. Use inhouse-mc-template.docx as the base. Unlike Track A, Track B uses the preamble/corporate numbering chain (numId=4) for recitals and resolutions — not the body clauses chain (numId=6). No ClauseL* styles in Track B.
Font size override: The MC template defaults to 10pt body (set for Track A transactionals). For Track B, override body text to 11pt per the "Body size by track" table. In the unpack → edit XML workflow, set <w:sz w:val="22"/> and <w:szCs w:val="22"/> on the Normal style rPr (or apply to each paragraph's run properties) to shift the document to 11pt.
No cover page or TOC
Header block — document title (centred, bold, caps) → NormalBold centred. Company name → NormalBold. "THE UNDERSIGNED:" → NormalBold.
Signatories/parties — For a sole shareholder or sole director, use BodyText (no numbered style — single entity needs no numbering). For multiple shareholders/directors, use PreambleL2 with numPr ilvl=1 numId=4 → auto (1), (2), (3).
"hereinafter referred to as..." line → BodyText
"WHEREAS:" label → NormalBold
Recitals (A), (B), (C)... → PreambleL4 with numPr ilvl=3 numId=4
"IT IS HEREBY RESOLVED:" label → NormalBold
Resolutions (1), (2), (3)... → PreambleL2 with numPr ilvl=1 numId=4. If a resolution has sub-items, use PreambleL4 (ilvl=3 numId=4) for lettered sub-items (A), (B).
Closing text (e.g., "Pursuant to article 2:230...") → BodyText
Signature — director names/titles → BodyText. Dual signature block for the Company entities.
Track C — Litigation: Court filings (jurisdiction-specific conventions)
Override to Layer 1: Track C uses TNR 12pt (court standard), line spacing 1.5, and the local jurisdiction's language for court filings (per the active jurisdiction profile). Do NOT apply MC numbering styles (ClauseL*, PreambleL*, ScheduleL*). Do NOT use WHEREAS/IT IS AGREED/BETWEEN labels. Do NOT build on the MC template — use a blank Word document with Track C styles applied directly.
Track C is the most jurisdiction-specific track. The structure below illustrates an Italian-court filing (the starter Italy profile includes with complete Track C conventions). For other jurisdictions, the deployer should extend the active profile with the local litigation conventions (court header format, document title conventions, procedural references, drafting language, prayer for relief block).
Illustrative structure (Italian profile — adapt per the active profile for other jurisdictions):
Court header — court name, section, judge, case number → bold centred at top, TNR 12pt (per profile; e.g., for Italy: "TRIBUNALE ORDINARIO DI [CITY] / Sezione [N] [Civile/Lavoro] / R.G. n. [number]/[year] – Giudice [dott./dott.ssa Name]")
Parties block — narrative format per local convention (e.g., for Italy: "Sigg.ri X e Y (attori), rappresentati e difesi dall'Avv. Z / contro / [Counterparty] (convenuta), rappresentata e difesa dall'Avv. W") → body prose 12pt. Bold for party names and lawyer names.
Document title — local convention (e.g., for Italy: "MEMORIA INTEGRATIVA", "COMPARSA CONCLUSIONALE", "RICORSO"; for Germany: "KLAGESCHRIFT", "SCHRIFTSATZ"; for England: "WITNESS STATEMENT", "PARTICULARS OF CLAIM") → bold centred, 14pt, ALL CAPS
Procedural reference — local procedural code reference (e.g., for Italy: "ex art. 426 c.p.c." / "per l'udienza del [date]"; for Germany: "§ 282 ZPO") → italic, centred, 12pt
Separator line — optional horizontal rule
Opening formula — local formal opening (e.g., for Italy: "Nell'interesse di...") → body prose 12pt
Numbered sections — bold section headings numbered 1., 2., 3. (single-level, no sub-clauses). Use automatic numbering via the memoria-sections docx-js numbering config (see "Automatic Numbering for Non-MC Tracks" above). Numbers and headings are 12pt bold. Body of each section is narrative prose 12pt with 1.5 line spacing. Do NOT type numbers by hand.
Prayer for relief block — local convention (e.g., for Italy: "CONCLUSIONI" bold centred 12pt; followed by bullet list or dashed list of specific requests "chiedono che l'Ill.mo Tribunale voglia: - ..."). Each bullet in body prose.
Date and location — "[City], [date]" (e.g., "Roma, 3 giugno 2026") → body prose
Signature — lawyer's name and credentials per local convention (e.g., for Italy: "Avv. [Name]") → body prose, no dual Company block (this is lawyer's filing)
Evidence list — use automatic numbering via the memoria-docs docx-js numbering config (Italian convention: "Doc. 1 – [description]", "Doc. 2 – [description]"). For other jurisdictions, the deployer may rename the config or add a parallel numbering config (exhibits for English, Anlagen for German, etc.). Do NOT type evidence numbers by hand — if a document is added or removed, the numbering must update.
Track D — Memo: Legal opinions, tax memos, regulatory analyses
Override to Layer 1: No CONFIDENTIAL footer for client-facing memos; instead use "PRIVILEGED & CONFIDENTIAL" in header on first page. No WHEREAS/IT IS AGREED. Do NOT build on the MC template. Do NOT use MC styles (ClauseL*, PreambleL*).
Memo header — formatted block at top:
To: [recipient]
From: [author / the Legal team]
Date: [date]
Re: [subject] (bold)
Privileged & Confidential (italic, right-aligned)
Horizontal separator
Executive summary (optional) — bold heading "Executive Summary" (13pt bold), followed by 1-2 paragraphs of body prose (11pt per Track D — see "Body size by track")
Numbered sections — bold section headings numbered 1., 2., 3.; sub-sections 1.1, 1.2 below. Use automatic numbering via the memo-sections docx-js numbering config (see "Automatic Numbering for Non-MC Tracks" above). Body in 11pt body prose. Do NOT type numbers by hand.
Footnotes for citations — TNR 9pt, proper legal citation format
Conclusion — bold heading "Conclusion", followed by body prose
Signature — "[Name], [Title]" → body prose. No dual signature block (memos are authored, not executed).
Track E — Employment: Employment contracts between the Company and individual employees
Track E documents are employment agreements between the Company (as employer) and an individual employee. They are built on the MC template — same engine as Track A — because employment contracts are agreements with preamble, recitals, and numbered clauses. The structure is typically flatter than commercial agreements (fewer sub-clauses, fewer schedules). HR policies and codes of conduct are NOT Track E — they are Track F.
Font size override: The MC template defaults to 10pt body. For Track E, override body text to 11pt per the "Body size by track" table (same mechanism as Track B).
Title — "EMPLOYMENT AGREEMENT" → NormalBold centred
Preamble — use PreambleL2 for parties (Employer + Employee) with numPr ilvl=1 numId=4. Employee description: full name, DOB, residential address. Employer description: full corporate details (verify per Entity details workflow above).
"WHEREAS:" and recitals — if used, NormalBold + PreambleL4 with numPr ilvl=3 numId=4
"IT IS AGREED as follows" → NormalBold
Body clauses — ClauseL1 for clause headings, ClauseL2 for sub-clauses, each with numPr numId=6 (same rules as Track A). Use sub-clauses sparingly; employment agreements are typically flatter than commercial agreements.
Execution block — dual signature block for Employer (the Company) per Layer 1 universal rule; single signature line for Employee. Not dual-dual as in Track A commercial agreements.
Track F — Policy: Internal policies, procedures, guidelines
Do NOT build on the MC template. Use a blank Word document with Word's native heading styles (Heading 1, Heading 2) configured with TNR, with body text at 11pt (per Track F), Heading 1 at 13pt bold and Heading 2 at 12pt bold, and linked to automatic numbering via the policy-sections docx-js numbering config (see "Automatic Numbering for Non-MC Tracks" above).
Title page — policy name, effective date, version, owner (e.g., "[Company] Travel and Expenses Policy / Effective 1 January 2026 / Version 2.1 / Owner: Finance Department")
Table of Contents — include for policies > 5 pages; use Word's built-in TOC tied to Heading 1/Heading 2. The auto-numbering flows into the TOC automatically.
Section headings — apply HeadingLevel.HEADING_1 for main sections (renders as 1., 2., 3. automatically via the numbering config); HeadingLevel.HEADING_2 for subsections (renders as 1.1, 1.2). NEVER type section numbers by hand — the numbering is in the style.
Body prose → body text 11pt (per Track F — see "Body size by track")
Lists within sections — bullets or numbered lists using Word's native list styles (configured as a separate numbering reference, e.g., policy-lists)
Definitions section — if needed, early in the document as a Heading 1 titled "Definitions"
Approval/review block at the end — "Approved by: [Board / CEO] / Date: [date] / Next review: [date]"
No dual Company signature block (policies are issued, not executed as bilateral agreements)
Track G — Letter: Formal correspondence, engagement letters
Do NOT build on the MC template. Use a blank Word document with body prose only. Body size: 11pt (TNR), per "Body size by track" table — single-reading documents, density not needed.
CRITICAL — Track G vs Track A side letter test: Before applying Track G, check whether the document is a letter agreement (a contract dressed as a letter) rather than pure correspondence. Apply this test:
Does the letter create operative obligations, indemnities, warranties, governing law/jurisdiction provisions, or require countersignature with "ACCEPTED AND AGREED"?
Yes → Track A side letter format (see "Track A — Transactional: Side letters and amendments" above). Use MC styles ClauseL1/ClauseL2/ClauseL3 with numId=6 inside the letter format. Common examples: mandate letters, indemnity letters, comfort letters, side letters under a main agreement, engagement letters with detailed terms (legal fees, scope, indemnity), letter agreements.
No → Track G (this section). Pure correspondence: cover letters, transmission letters, request letters, formal notices outside an agreement, social/protocol letters, brief engagement letters with no contractual mechanics.
If the answer is borderline, default to Track A side letter — it scales down (1./1.1 numbering can be omitted for short letters) but Track G does not scale up.
Track G structure (pure correspondence only):
Company letterhead block at top (if used) — body prose, indented
Body paragraphs — body prose. If a small number of operative items are needed (e.g., enclosures list), use automatic numbering via the letter-items docx-js numbering config — single-level only. For anything more complex (multi-level numbering, sub-clauses, defined terms, operative obligations), the letter is NOT Track G — apply Track A side letter format.
"Yours faithfully," / "Yours sincerely," → body prose
Signature block — name and title → body prose. Dual signature only if the letter has legal effect requiring dual authorisation (most don't).
Drafting Conventions (Tracks A, B, and E — MC-based documents)
The conventions in this section apply to Track A (transactional agreements), Track B (corporate documents), and Track E (employment contracts) — i.e., all MC-based documents. Other tracks follow their own conventions:
Track C (litigation): narrative prose in Italian or other court language; no "shall/may" operative verbs; Italian legal terminology.
Track D (memo): analytical prose; defined terms introduced inline on first use in bold within curly double quotes (per Critical Rule #8); no operative clauses.
Track F (policy): clear imperative language ("Employees must..."); heading-based structure; no clause cross-references.
Track G (letter): conversational prose; defined terms (if any) follow Critical Rule #8 (bold within curly quotes on first use); no operative verbs beyond what's natural in correspondence.
Operative language
Operative verb: shall for obligations, may for permissions, shall not for prohibitions
Passive avoidance: prefer "the Seller shall deliver" over "the documents shall be delivered by the Seller"
Defined terms
First use: bold within curly double quotes — the "Purchase Price"
Subsequent use: capitalised, no bold, no quotes — the Purchase Price
Party references: defined in the preamble, used consistently throughout. Short form after first use (e.g., [Company legal name] B.V. (the "**Purchaser**") → thereafter the Purchaser)
Enumeration
Items in a list end with semicolons
Penultimate item: ; and or ; or (as appropriate)
Final item: full stop
Chapeau (introductory text) ends with colon
Example:
1.1 The following conditions shall be satisfied:
(a) [first condition];
(b) [second condition]; and
(c) [third condition].
Cross-references
To clauses (Track A short form): Clause 3.2 (capitalised, no parentheses around number)
To clauses with title (international finance and long-form contract style): Clause 3.2 (*Withholding tax*) — clause number followed by the clause title in italics within parentheses. Used widely in international finance documentation drafting. Recommended for facility agreements, complex SPAs, JV agreements, and any document >30 pages
To schedules: Schedule 1 (Completion Obligations) — number + title in parentheses; title in italics if following international finance documentation convention (Schedule 1 (*Completion Obligations*))
To paragraphs within schedules: paragraph 3(d) of Schedule 1 — precise to sub-paragraph level, never just "Schedule 1" when a specific provision is relevant
To parts within schedules: Part I of Schedule 3 (Seller's Warranties) or Part I of Schedule 3 (*Seller's Warranties*) (international finance convention)
To definitions in Clause 1: as defined in Clause 1.1 or simply use the capitalised Defined Term without further cross-reference
Consistency rule: pick one convention (plain or italics) for cross-reference titles and apply it throughout the document. Mixing plain and italics looks unprofessional.
Paragraph captions (italic caption convention)
When a clause contains a series of (a), (b), (c) paragraphs each addressing a different sub-topic, a widely-used convention in international finance documentation is to introduce each paragraph with a caption in italics followed by a colon:
10.1 Unavailability of Screen Rate
(a) *Interpolated Screen Rate*: If no Screen Rate is available for EURIBOR
for the Interest Period of a Loan, the applicable EURIBOR shall be the
Interpolated Screen Rate for a period equal in length to the Interest
Period of that Loan.
(b) *Reference Bank Rate*: If no Screen Rate is available for EURIBOR for: ...
(c) *Cost of funds*: If paragraph (b) above applies but no Reference
Bank Rate is available for euro or the relevant Interest Period there
shall be no EURIBOR for that Loan and clause 10.4 (*Cost of funds*)
shall apply to that Loan for that Interest Period.
This is standard in international finance and facility documentation. Use when paragraphs cover distinct sub-topics that benefit from visual identification. Do NOT use when paragraphs are simply enumerated items (lists of conditions, lists of events).
Provisos and chapeau-level paragraphs
After a series of (a), (b), (c) sub-paragraphs, a proviso or limitation that applies to the enumeration as a whole is inserted as an un-numbered paragraph indented at the chapeau level (not at the sub-paragraph level). Example from a typical Events of Default clause:
23.1 Non-payment
An Obligor does not pay on the due date any amount payable under any
Finance Document at the place at which and in the currency in which it is
expressed to be payable unless:
(a) its failure to pay is caused by administrative or technical error; and
(b) payment is made within 3 Business Days of its due date.
23.X ...
[...]
(h) any party to a Project Document repudiates a Project Document; or
(i) any counterparty to a Direct Agreement gives any notification of
restricted action,
provided that an Event of Default shall not occur under sub-paragraphs (b),
(e) and (h) of this paragraph in respect of a Project Document if the
Agent is satisfied that the Obligors are taking all necessary steps to
replace the relevant Project Document.
The closing proviso is at the chapeau indent level (aligned with the start of (a)'s text), not at the (a) indent itself. Use BodyText1 style or equivalent — un-numbered, indented to match the chapeau.
Complex (multi-level) definitions
Standard single-line definitions use the inline format ("**Term**" means [content];). For complex definitions covering different cases or scenarios, use a multi-level format mirroring the body clause structure:
"**Availability Period**" means:
(a) in relation to the Facility A, the period commencing on Financial
Close and ending on the earlier of the Final Completion Date and the
Backstop Completion Date for Project A;
(b) in relation to the Facility B, the period commencing on Financial
Close and ending on the earlier of the Final Completion Date and the
Backstop Completion Date for Project B;
Or even three-level definitions for very complex defined terms:
"**Costs Certificate**" means in respect of a Project, a certificate provided
by the Parent to the Agent and the Technical Adviser in relation to each
proposed Loan under a Term Facility:
(a) setting out the applicable Eligible Costs that:
(i) are due and payable; and
(ii) will become due for payment within 30 days from the Utilisation Date,
in a sufficient level of detail; and
(b) confirming that the aggregate amount of Eligible Costs incurred by the
relevant Borrower do not exceed the aggregate amount of Eligible Costs
anticipated to be incurred...
The multi-level format is appropriate for facility agreements, complex SPAs, JV agreements, and any document with definitions that vary by case, jurisdiction, or scenario. Use sparingly — most definitions are single-line.
Document status marker (header)
Long-form transactional documents typically carry a status marker in the top-right of every page indicating the version state:
Draft — at any pre-execution stage
Draft for discussion — circulated for discussion but not the agreed text
Approved for execution — approved internally, awaiting signature
Execution version — the version being signed
Conformed copy — post-signature, with signatures replaced by typed names
The status marker is shown in the header (not the footer, which carries CONFIDENTIAL and page numbers). Add the marker for Track A long-form agreements and remove or update it at each stage. For shorter Track A documents (NDAs, LOIs, short side letters), the status marker is optional.
Page numbering for long-form documents
Track A long-form agreements (>30 pages, typically with cover page + TOC + body + schedules) use mixed page numbering:
Cover page: no page number
TOC: lowercase Roman numerals (i, ii, iii) starting from i
Body and schedules: Arabic numerals (1, 2, 3, ...) restarting from 1
This is a financial / international standard for long-form agreements. Shorter Track A documents (NDAs, LOIs, short side letters, amendments) use Arabic numbering throughout, starting from 1, without restart.
Recital labels
WHEREAS (bold, left-aligned) introduces the recital block — use NormalBold style
Individual recitals lettered (A), (B), (C) — auto-numbered via PreambleL4 style with numPr ilvl=3 numId=4
Recitals are factual/background — no operative obligations
Execution block
IN WITNESS WHEREOF the Parties have executed this Agreement on the date first above written.
Company entities: two (2) signature blocks side by side (dual signatory)
Counterparty entities: signature block per their requirements
Each block: For and on behalf of [ENTITY NAME] (bold) → signature line → Name / Title / Date
Boilerplate Clause Library (Track A — Transactional Agreements)
The following clauses are standard in-house counsel boilerplate (drafted from the Company's perspective) for Track A (transactional agreements). Track B (corporate documents) has its own corporate-specific language (resolutions, authorisations) that does not use this library. Track E (employment contracts) uses only a small subset of this library (typically Confidentiality, Entire Agreement, Variation and Waiver, Severability, Governing Law) — see the specific clauses below and adapt for employment context. Tracks C, D, F, G do not use this library.
When drafting a Track A document, include the relevant clauses from this library using the locked wording below (adapted only for defined terms and cross-references specific to the document). The clause ordering shown here is the standard sequence for Track A full-form agreements — follow this order unless the document type requires a different structure.
Standard clause ordering for full-form agreements
Interpretation (definitions + construction rules)
[Operative clauses specific to the transaction]
[Transaction-specific substantive clauses]
Confidentiality
Further assurances
Assignment
Payments (if applicable)
Costs (if applicable)
No partnership (if applicable — JDAs, cooperation agreements)
Good faith (if applicable — JDAs, long-term agreements)
Notices
Entire agreement
Variation and waiver
Waiver of local civil code remedies (civil law jurisdictions only — see jurisdiction profile)
Severability
Counterparts and electronic execution
Third party rights
Sanctions (if applicable)
Anti-bribery / Anti-corruption (if applicable)
Language (only if needed)
GDPR / Data processing (if applicable)
Governing law and dispute resolution (always last substantive clause)
Locked boilerplate wording
Listed in standard clause order (positions 1–22). Positions without locked wording (Confidentiality, Notices, Sanctions, Anti-bribery) are drafted per-transaction based on the Company's strongest position for the jurisdiction.
[Pos. 1] Construction Rules (always in Clause 1, after definitions)
[Clause 1.X].1 — References to Clauses and Schedules are references to clauses of, and schedules to, this Agreement and references to paragraphs are to paragraphs of the relevant Schedule.
[Clause 1.X].2 — The Schedules form part of this Agreement and shall have effect as if set out in full in the body of this Agreement.
[Clause 1.X].3 — Words denoting the singular shall include the plural and vice versa. Words denoting one gender shall include another gender.
[Clause 1.X].4 — Any words following the terms "including", "include", "in particular", "for example" or any similar expression shall be construed as illustrative and shall not limit the sense of the words, description, definition, phrase or term preceding those terms.
[Clause 1.X].5 — The headings in this Agreement are for reference only and shall not affect the interpretation of this Agreement.
[Clause 1.X].6 — A reference to a statute or statutory provision is a reference to it as amended, extended or re-enacted from time to time, and shall include all subordinate legislation made from time to time under that statute or statutory provision.
[Clause 1.X].7 (local concepts construction rule — jurisdiction-dependent; load from the active jurisdiction profile) — Use the wording from the active profile. Common pattern (civil law jurisdictions drafting in English): "English language words used in this Agreement intend to describe [jurisdiction] legal concepts only and the consequences of the use of such words in English law or any other foreign law shall be disregarded. Where a [language] word is included in italics and in brackets after an English word and there is any inconsistency between the [language] and the English, the meaning of the [language] word shall prevail." For common law jurisdictions drafting in English, this paragraph is generally not needed.
[Pos. 5] Further Assurances (standard)
Each Party shall (at its own expense) promptly execute and deliver such documents, perform such acts and do such things as the other Party may reasonably require from time to time for the purpose of giving full effect to this Agreement.
[Pos. 5 — Extended variant (jurisdictions with statutory good faith)] Further Assurances (extended)
Each Party shall (at its own expense) promptly execute and deliver such documents, perform such acts and do such things as the other Party may reasonably require from time to time for the purpose of giving full effect to this Agreement. The Parties shall act in good faith and in a reasonable manner, shall be accommodating and practical, and shall provide such cooperation as may be reasonably necessary for the attainment of the aim of this Agreement.
Use the extended variant in jurisdictions with a strong statutory good-faith default (Netherlands, Germany, Italy, Hungary, Poland, etc.). Use the standard variant in common law jurisdictions where the extended language would create unintended duties.
[Pos. 6] Assignment
[Clause X].1 — [Company entity] may assign this Agreement, or any of its rights or obligations hereunder, to any of its Affiliates or to any successor entity resulting from a merger or reorganisation, provided that the assignee assumes all obligations under this Agreement. Any other assignment by [Company entity] requires the prior written consent of [Counterparty].
[Clause X].2 — [Counterparty] shall not assign, transfer, mortgage, charge, declare a trust of, or deal in any other manner with any of its rights or obligations under this Agreement without the prior written consent of [Company entity].
Note: Company-favourable default. For JDAs with trusted partners, adjust affiliate assignment to mutual.
[Pos. 7] Payments — interest mechanism is jurisdiction-dependent; load from the active jurisdiction profile.
Universal paragraphs (apply regardless of jurisdiction):
[Clause X].1 — Unless otherwise expressly stated in this Agreement, all payments shall be made in [Euro / USD / GBP / local currency as agreed].
[Clause X].3 — All payments made under this Agreement shall be made gross, free of any right of counterclaim or set-off and without deduction or withholding of any kind.
Jurisdiction-dependent paragraph (interest on default):
[Clause X].2 — [Interest on default — apply the wording from the active jurisdiction profile. See "Starter Jurisdiction Profiles" for the wording per starter jurisdiction. Common patterns: statutory commercial interest rate (civil law jurisdictions), base rate + agreed margin (common law jurisdictions), or contractual rate negotiated between the parties.]
[Pos. 8] Costs
Except as otherwise provided in this Agreement, each Party shall bear its own costs and expenses, including the fees and expenses of its legal and other advisers, incurred in connection with the entering into and the execution of this Agreement.
[Pos. 9] No Partnership or Agency
Nothing in this Agreement is intended to or shall operate to create a partnership or joint venture of any kind between the Parties, or to authorise either Party to act as agent for the other, and neither Party shall have authority to act in the name or on behalf of or otherwise to bind the other in any way.
[Pos. 10] Good Faith — jurisdiction-dependent; load from the active jurisdiction profile.
In civil law jurisdictions (NL, IT, HU, PL, DE, FR, ES, etc.), good faith is generally an implicit statutory default that need not be expressly restated, though parties may include an express clause for emphasis or to extend the scope of the duty.
In common law jurisdictions (England, most US states, Singapore, Hong Kong), there is no general implied duty of good faith in commercial contracts. Including an express good faith clause creates a contractual obligation that would not otherwise exist — use only if commercially intended (typical in JDAs and long-term partnerships); avoid in straight transactional documents.
Apply the wording and warning from the active jurisdiction profile. Default neutral wording (where the user intends an express good faith standard regardless of jurisdiction):
The Parties undertake to act towards one another in good faith in all respects relating to this Agreement.
[Pos. 12] Entire Agreement
[Clause X].1 — This Agreement constitutes the entire agreement between the Parties in relation to its subject matter and supersedes all previous agreements, understandings and arrangements between the Parties, whether written or oral, relating to such subject matter.
[Clause X].2 — Each Party acknowledges that in entering into this Agreement it has not relied on, and shall have no right or remedy in respect of, any representation, warranty, collateral contract or other assurance (whether made innocently or negligently) that is not set out in this Agreement.
[Pos. 13] Variation and Waiver
[Clause X].1 — No variation of this Agreement shall be effective unless it is in writing and signed by or on behalf of each of the Parties.
[Clause X].2 — No failure or delay by a Party in exercising any right or remedy under this Agreement shall operate as a waiver thereof, nor shall any single or partial exercise of any right or remedy preclude any further exercise thereof or the exercise of any other right or remedy.
[Clause X].3 — Except as expressly provided in this Agreement, the rights and remedies provided under this Agreement are in addition to, and not exclusive of, any rights or remedies provided by law.
[Pos. 14] Waiver of Civil Code Remedies — jurisdiction-dependent; load from the active jurisdiction profile.
This clause is only applicable in civil law jurisdictions where the civil code provides for rescission, annulment, or unilateral modification grounds that the parties wish to waive. The specific grounds, waiver wording, and reservation for non-waivable matters (fraud, duress, public policy) vary by jurisdiction.
For common law jurisdictions (England, most US states, etc.), this position is not applicable — rescission and misrepresentation are addressed instead through Pos. 12 (Entire Agreement) and express misrepresentation language.
Apply the wording from the active jurisdiction profile. Reference summary:
Profile
Key grounds waived
Netherlands (NL)
ontbinding, vernietiging on dwaling grounds (Section 6:265, 6:228 BW)
Not applicable — use entire-agreement-based misrepresentation exclusion instead
[Pos. 15] Severability
If any provision of this Agreement is held to be invalid, illegal or unenforceable, it shall be modified to the minimum extent necessary to make it valid, legal and enforceable and, to the extent legally possible, to have the same economic effect as the Parties originally intended. If such modification is not possible, the relevant provision shall be deemed deleted. Any modification or deletion under this Clause shall not affect the validity and enforceability of the rest of this Agreement.
[Pos. 16] Counterparts and Electronic Execution
This Agreement may be executed in any number of counterparts, each of which when executed shall constitute an original, but all the counterparts shall together constitute one and the same agreement. Subject to applicable law, this Agreement may be executed by way of electronic signature.
[Pos. 17] Third Party Rights — jurisdiction-dependent; load from the active jurisdiction profile.
Universal first sentence (applies regardless of jurisdiction):
No one other than a party to this Agreement, their successors and permitted assignees shall have any right to enforce any of its terms.
Jurisdiction-dependent local exclusion (apply from the active profile):
[Local third-party-beneficiary doctrine exclusion. See profile.]
Reference summary:
Profile
Local exclusion
Netherlands (NL)
derdenbeding exclusion, Section 6:253 BW
England (EN)
Contracts (Rights of Third Parties) Act 1999 exclusion
Contratto a favore di terzo exclusion, Art. 1411 c.c.
Poland (PL)
Umowa na rzecz osoby trzeciej exclusion, Art. 393 KC
[Pos. 20] Language (English under non-English governing law)
The language of this Agreement is English and all notices, demands, requests, statements, certificates or other documents or communications shall be in English unless otherwise agreed by the Parties or otherwise required by applicable law.
[Pos. 21] GDPR / Data Processing — include as a Schedule for any agreement involving cross-border or systematic personal data exchange. Adapt from the Company's standard NDA or DPA template (not shipped with this skill — most in-house teams have their own GDPR/DPA addendum). Default scope: data minimisation, security measures, sub-processor notification, audit rights, breach notification within 72 hours, return/destruction on termination.
[Pos. 22] Governing Law and Jurisdiction — jurisdiction-dependent; load from the active jurisdiction profile (see "Starter Jurisdiction Profiles" section).
The Pos. 22 clause has two paragraphs:
[Clause X].1 — governing law statement
[Clause X].2 — forum / jurisdiction / arbitration
For each starter jurisdiction, the full Pos. 22 wording is set out in the corresponding profile. For custom jurisdiction profiles, the deployer supplies the wording. Reference summary of the starter set defaults:
Profile
Governing law
Default forum
Netherlands (NL)
Laws of the Netherlands
Amsterdam courts
England & Wales (EN)
English law
English courts (or LCIA arbitration)
Hungary (HU)
Substantive laws of Hungary
HCCI arbitration, Budapest
Italy (IT)
Laws of Italy
Milan/Rome courts (or ICC arbitration)
Poland (PL)
Laws of Poland
Warsaw courts (or PCC arbitration)
See "Starter Jurisdiction Profiles" section for the full clause wording for each. If the user has indicated a jurisdiction without a starter profile and no custom profile is supplied, apply the protocol in "Jurisdiction Architecture" → "What to do when no profile is available".
Optional boilerplate (include when relevant — decision tree)
Clause
When to include
Confidentiality
Every transactional agreement. For standalone NDA, use the NDA template instead.
Language
When governing law language differs from drafting language, or multi-language execution.
Sanctions
Counterparties with non-EU/non-US beneficial ownership or operations in sanctioned jurisdictions.
Anti-bribery / Anti-corruption
Elevated corruption risk jurisdictions or government-related counterparties.
Guarantee
When a parent or other entity guarantees a party's obligations.
Payments
Any agreement with payment obligations (SPAs, JDAs, loan agreements, service agreements).
Waiver of Local Civil Code Remedies
All civil law jurisdiction governed agreements (NL, IT, HU, PL, DE, FR, ES, etc.). Not applicable in common law jurisdictions.
No Partnership
JDAs, cooperation agreements, framework agreements — any agreement where parties collaborate.
Any agreement where personal data is exchanged between the parties.
Cover Page Specification — Table-Based (Track A only)
Cover pages apply only to Track A full-form agreements. Tracks B, C, D, E, F, G do not use cover pages. When used, the Track A cover page is built on a borderless table for precise alignment:
Row structure:
Rows 1–3: empty spacer rows (push content down ~30% of page)
Row 4: single merged cell containing stacked party blocks:
[PARTY NAME] (bold) + line break + as [Role]
and between each party
Row 5: horizontal rule (top border on cell)
Row 6: centred title block — [TITLE OF AGREEMENT] (14pt bold caps) + subtitle
Row 7: horizontal rule (bottom border on cell)
Row 8: Dated [ ] at bottom
All table borders: none. Cell margins: minimal.
Drafting Workflow (Tracks A, B, and E — MC-based documents)
The workflow in this section applies to Track A (transactional agreements), Track B (corporate documents), and Track E (employment contracts) — i.e., all documents built on the MC template with the Company boilerplate library and the Company's precedent repository.
For other tracks, simplified workflows apply for drafting from scratch — but Step 1 (uploaded documents handling, including the reformatting scenario) and Step 0 (jurisdiction identification) apply to ALL tracks A through G:
Track C (Litigation): take the client's case position from the user or uploaded documents; draft per jurisdiction-specific court conventions; do not search the document repository for "precedents" in the transactional sense. Step 1 reformatting applies.
Track D (Memo): take the legal question from the user; research as required; structure per the memo format; no precedent search needed. Step 1 reformatting applies.
Track E (Employment): follow the same workflow as Track A/B — employment contracts are agreements and benefit from the jurisdiction-first, precedent-based approach. Search the document repository for employment contract templates in the Company's jurisdiction; if no template is found, draft from first principles applying the labour law of the jurisdiction set in the active profile. Note: employment law is highly jurisdiction-specific and frequently divergent from general civil/commercial law; flag to the user if no local template or profile-level employment defaults are available.
Track F (Policy): if the Company has existing policies on the document repository in [document repository: policies folder], search for the current version. Otherwise draft from first principles using the Track F structural rules. Step 1 reformatting applies.
Track G (Letter): no precedent-search workflow — draft directly in the letter format. Step 1 reformatting applies (a user can upload an existing letter and ask Claude to reformat it under Track G conventions).
Step 0: Identify jurisdiction and load the jurisdiction profile
The user must indicate the governing law jurisdiction; Claude applies the corresponding profile. This step comes before any drafting, because nearly every substantive decision (clause wording, execution formalities, default forum, language, litigation conventions) depends on it.
Substeps:
Identify the jurisdiction from one of:
Explicit user instruction ("draft a Dutch law SPA", "this is governed by English law", "Italian-law cooperation agreement")
Context already in the conversation (counterparty location, project location, prior turn established the jurisdiction)
Standing Company convention if the deployment has a default jurisdiction (e.g., a Dutch-incorporated holding company defaults to Dutch law for intragroup documents)
If jurisdiction is unclear and material to the document, ask the user explicitly before drafting. Examples of when to ask:
"What is the governing law and forum for this SPA?"
