---
name: contract-change-review
description: Compare two versions of a contract (main text plus appendices), rate each change high/medium/low impact under Norwegian law via Lovkart, and deliver a neutral impact summary and redlines with no recommendations.
---

# Contract change review: redline with legal impact

Use this when the user wants to know what changed between two versions of a contract and what the changes mean legally. The user points to a folder; you find the right files, confirm them, work only on copies, and deliver:

1. a **summary of legal impacts** (high, then medium, then low impact), and
2. **redlines** showing old wording, new wording and the legal impact of each change.

The outputs **describe and weigh; they never advise.** Each item ends with neutral **points to consider**, never with a recommendation.

Reply to the user in their language. Write the outputs in the language the user picks in Step 2.

## Ground rules (always)

- **Never change the originals.** Read them, copy them, and do all work on the copies in `workspace/`. Never rename, edit, move or delete anything outside `workspace/`.
- **Ask, don't guess, when it matters.** Use AskUserQuestion with your preferred option first and marked "(Recommended)". Bundle questions so the user answers once per step, not once per file. These questions are about how to run the review (which files, which side, which language), never about what our side should do with the contract.
- **Show before you ask.** Anything the user must see in order to answer (the file table, the rename table) goes in a message the user sees verbatim, e.g. SendUserMessage, before the AskUserQuestion call. Text between tool calls may only reach them as a summary.
- **No advice in the outputs.**
  - Never write recommendations, counter-proposals, suggested clause wording, or what our side "should" do.
  - Don't use advisory words in the output language: "should", "recommend", "we suggest", "do not accept", "negotiate"; in Norwegian "bør", "anbefal", "foreslå", "ikke godta", "forhandle om".
  - Each item ends with **Points to consider**: 1–3 neutral lines stating facts, open questions or what depends on what.
    - Neutral: "Clause 5.3 and the hourly-rate slot in Appendix 6 already cover payment for handover; the format requirement is the only new element."
    - Neutral: "Whether this matters depends on whether customer data is used for product improvement today."
    - Advisory (don't): "Ask the customer to pay for the format conversion."
- **Weigh before you write.** An effect statement is only fair if it accounts for what the contract and the law already provide. Run the checks in Step 6c for every high- and medium-impact item. "Already covered by clause X" is a finding, not a gap.
- **Lovkart discipline:**
  - Call `describe_corpus` once at the start. Respect its `cannot_answer` list.
  - Search with 1–3 Norwegian key terms (`search_legal_sources`), never English sentences.
  - Call `get_law_provision` before stating what any provision says. Quote only text from `get_law_provision`, `get_forarbeid_document` or `get_decision`, never search snippets.
  - Every § and article you name is a link, using the url from the Lovkart payload. Never build a url yourself.
  - For a Høyesterett decision: state what it held only if you have read its text (the PDF linked from its domstol.no page). Otherwise say it rests on the case title or summary.
  - Respect status flags:
    - A law with `in_force_status: pending` is passed but **not in force**. Say so; never present it as current law.
    - An EU act listed in `eu_pending` is **not Norwegian law**. Say so and link its EEA-Lex status page.
- **Not legal advice.** Say once in the summary that this is information from the retrieved sources, not legal advice, and that decisions that matter call for a lawyer's review. This sentence is the only place the outputs point the reader to someone else.

## Step 1: Inventory the folder and propose what to compare

1. List the folder recursively. For each .docx/.pdf, collect:
   - the file name, size and modified date;
   - the document metadata (for .docx: `docProps/core.xml` title, created, modified, lastModifiedBy);
   - the title, version or year printed on the first page (cover text is often in text boxes, so read it from the XML);
   - whether the .docx already contains tracked changes (`w:ins`/`w:del`).
2. Group the files:
   - **Contract parts:** main text, appendices/bilag, schedules, annexes, data processing agreements.
   - **Versions:** version numbers, years, "draft"/"utkast", "signed"/"signert", "final".
   - **Language editions:** e.g. `-bok` (bokmål) or `-nyn` (nynorsk). Compare like with like.
   - **Noise:** duplicates, `(1)` copies, a PDF of a .docx you already have, temp files (`~$…`, `.DS_Store`).
   - **Supporting material:** the publisher's guidance (veileder) for a standard contract, the signed agreement's filled-in appendices, a data processing agreement. These are not compared. The guidance feeds the legal map (6a); the filled-in appendices and data processing agreement feed the "already covered" check (6c), since they show what the parties actually agreed (e.g. whether exit rates are filled in, whether a data processing agreement exists).
3. Rank versions using evidence in this order of reliability: version or date printed in the document; version or year in the file name; metadata dates; file modified date. Metadata and file dates are weak, because re-saving, downloading and copying reset them. A file with no year in its name often reveals its version on the cover.
4. Show one table: **File | Contract part | Version (guess) | Evidence | Include by default?**
5. Default proposal: compare the **latest version against the one immediately before it**, including the main text and all appendices of both. Exclude duplicates and noise, and use PDFs only as reference.
6. Ask the user to confirm:
   - (a) which version is the new one and which is the old one;
   - (b) which files belong to each version.
   If they answer differently, follow their answer.

## Step 2: Ask for context (in the same AskUserQuestion call as Step 1)

- **Whose side are we on?** For example customer / supplier / neutral. Every impact rating depends on this.
- **Purpose.** Reviewing the new version before signing / deciding whether to adopt a new template / checking an existing agreement against the new version. The purpose decides what the ratings measure (see the rating criteria).
- **For an existing agreement: what is actually signed?** Ask whether the signed agreement's filled-in appendices (especially any requirement specification, supplier description, price appendix, change appendix and data processing agreement) are available. The blank template shows what the parties *could* have agreed; the filled-in appendices show what they did. If they aren't available, say in the summary that the review rests on the template.
- **Output language.** Offer the contract's language as the default option when the user writes in another language.
- **Contract type and governing law.** Infer them and state them in the table; only ask if unclear.

## Step 3: Create the workspace

1. Create `workspace/` next to the originals' folder, inside the connected folder, with:
   - `workspace/00_source/` for copies of the confirmed files and the manifest only, never edited after copying;
   - `workspace/01_output/` for the deliverables;
   - `workspace/_work/` for intermediate files (text extracts, diffs, topic sweeps, checks). Never put working files in `00_source/`.
2. Copy with timestamps preserved (`cp -p`).
3. Write `workspace/00_source/MANIFEST.md`. It records, for each file: original path, copy name, size, original modified date and SHA-256 hash, plus the date of the review, the confirmed version pair, perspective, purpose, and the files left out.
4. Do not try to delete anything. Deletion in connected folders is blocked by default, and you don't need it.

## Step 4: Offer to rename the copies

1. Propose a pattern that sorts and reads well: `<year or date>_<contract>_<part>_<old|new>.<ext>`. For example:
   - `2024_Leieavtale_hoveddokument_old.docx`
   - `2025_Leieavtale_vedlegg-1_new.docx`
   - `2025-03-14_Rammeavtale-renhold_bilag-2_new.docx` (use the full date when there are several versions in one year)
2. Fix double extensions (`.docx.docx`) and typos.
3. Show an **old name → new name** table. Ask: accept / adjust the pattern / keep the original names.
4. Rename **only the copies** in `00_source/`. Update the manifest.

## Step 5: Compare the versions

1. **Extract all the text, not just the body.** Read paragraphs directly from the .docx XML: `word/document.xml`, including text boxes (`w:txbxContent`), plus headers, footers and footnotes. Skip `mc:Fallback` blocks, which duplicate text boxes.
   - Don't rely on `pandoc` alone: in testing it dropped about 90% of an appendix file that kept its text in text boxes.
   - Sanity-check: compare character counts between extraction methods. A big gap means content is missing.
   - If a file already has tracked changes, read them; they show the drafter's own view of what changed.
2. Diff paragraph by paragraph. Match clauses **by number and by heading/content**, because renumbering is common. Classify every difference as **changed / added / deleted / moved / renumbered**.
3. **Follow the cross-references.** For every changed clause, read the unchanged clauses it refers to or that govern it: "jf. punkt X", the order-of-precedence clause, the change-procedure clause, the liability cap. Conflicts and gaps between new and unchanged text are often the most important findings.
4. **Sweep the whole contract, not only the referenced clauses.** Cross-references miss rules that sit elsewhere. For each changed topic:
   - **Find every priority rule, wherever it sits.** Search the main text and all appendices for "går foran", "har forrang", "forrang", "uavhengig av", "med mindre annet fremgår av bilag", "prevails", "takes precedence". A data processing agreement, an SLA appendix or a special clause often has its own priority rule outside the general precedence clause.
   - **Find every clause on the same topic** by keyword (for data, for example: "data", "slett", "sikkerhetskopi", "tilbakelever", "overfør", "format", "metadata", "taushet"). Write the hits to `workspace/_work/topic_<topic>.md` with clause numbers.
   - **Read the appendix slots and guidance boxes.** Appendix templates often already provide for the issue (e.g. a price slot for exit assistance, a place to state formats). The guidance text shows how the publisher intends the clause to work.
5. **Read the new text as a whole for its internal logic.** A permission or exception granted elsewhere shows what the drafter assumed the main rule covers. For example: if the supplier is expressly allowed to use error logs, the drafter assumed error logs otherwise belong to the customer. Use such clues as evidence, for or against our side.
6. Check the changes that are easy to miss:
   - edited **definitions**, which change meaning across the whole contract;
   - broken or shifted **cross-references**;
   - changes in **appendices**, and in **which document takes priority**;
   - **headings that no longer match their text** (e.g. a heading says "changes to the agreement" while the clause speaks of "changes to the service");
   - **headers and footers**, e.g. a footer that still names the old version;
   - changes nobody announced.
7. Ignore pure formatting and page numbers. Group purely editorial changes into one low-impact item.
8. Record **what did not change** as well. When only a few clauses changed, "everything else is identical word for word" is a key finding.

## Step 6: Map the legal sources, assess each change, then weigh it

### 6a. Build a legal map (once, before looking up individual changes)

Do this after the comparison, so the map covers what the changes actually touch.

1. **Start from Lovkart's coverage.** Re-read the `describe_corpus` result from the start of the session: what it holds, its `cannot_answer` list and its snapshot date.
2. **List the candidate legal sources,** based on:
   - **the contract type**, e.g. IT services, lease, employment, sale of goods or consumer contract;
   - **the parties**, e.g. a public-sector customer brings in offentleglova, forvaltningsloven and the procurement rules; a consumer brings in mandatory consumer law;
   - **the topics the changes touch**, e.g. data → personopplysningsloven/GDPR and åndsverkloven; late payment → forsinkelsesrenteloven; damages → skadeserstatningsloven;
   - **EU/EEA rules** that may be relevant.
3. **Check each candidate in Lovkart** (`search_legal_sources` with the law's name, or `get_law_provision` for the whole act) and record its status:
   - in force;
   - in force, **but a replacement act is passed and pending** (search the law's short name with `doc_type="law"` and look for a newer act with `in_force_status: pending`); say the citation will change when the new act takes effect;
   - passed but not in force (`pending`);
   - EU act not part of EEA law (`eu_pending`);
   - not held by Lovkart.
4. **Mark where the background law is non-statutory** (general contract law principles). Lovkart can only show Høyesterett decisions there, not legal commentary, so say so instead of forcing a statutory citation.
5. **Look for the publisher's own guidance** when the contract is a standard form (e.g. SSA from DFØ/anskaffelser.no, NS standards, Agreed Documents). Use WebSearch to find the guidance (veileder) and any article explaining a new version; fetch what you can. Treat it as an aid to interpretation, not as law: say what it says and that it has no binding legal force. If the page can't be reached, say so in the limitations instead of silently skipping it.
6. **Write the map** to `workspace/_work/legal_map.md`: **Source | Why relevant | Status | Lovkart coverage | Used for item(s)**.
   - Show it to the user in a short message and carry on. They can add a source they know is relevant.
   - The map is the shortlist for 6b. A source that turns out not to matter stays in the map, marked "checked, not relevant".

### 6b. Assess each substantive change

Make **one item per separate duty or right**, even when several sit in the same paragraph (e.g. a duty to hand over data and a duty to delete it are two items). This keeps ratings consistent between runs.

1. **What changed:** old wording, then new wording, with clause references in both versions.
2. **Effect for our side:** who now carries which risk, cost, duty or deadline. Separate the realistic consequences from the theoretical ones, and say which is which.
3. **Legal basis, from the map:**
   - Fetch the relevant provisions with `get_law_provision` and link them. For EU rules that apply in Norway (e.g. GDPR via personopplysningsloven), fetch the article as `get_law_provision("personopplysningsloven", "artikkel N")`.
   - **Scope test before citing a statute as a source of risk.** Check that the provision actually reaches this situation: whose duty it is (ours or the other party's), which data or documents it covers, and which bodies or contract types it applies to. A retention rule for our own accounting records does not reach the customer's service data; a public body's duty of confidentiality only matters if the information is of the protected kind. If the fit is loose, say so and give it less weight, or leave the statute out.
   - If no rule applies, say "contract term, no statutory rule found" rather than forcing a citation.
   - Add Høyesterett decisions only where they matter, following the reading rule above.
   - If a change touches a topic the map missed, add the source to the map.
4. **Facts that depend on the purpose** (state them as facts, not advice):
   - **Existing agreement:**
     - State that the old terms keep applying, and what the change clause says: whether the other side can impose the new terms or can only ask for an amendment.
     - State what the precedence rules mean for any amendment: which appendix an amendment would have to sit in to override the main text, and that it would need to name the clause it replaces.
     - Where the new version *gives* our side a right the old one lacked, or the old one limits something, note as a point to consider whether current practice already goes beyond the old terms. This is often the only point that bears on the present.
     - For a public customer, state what the procurement rules say about changes to an existing contract.
   - **Reviewing before signing:** state which appendices let the parties set or vary the term (e.g. "Appendix 1 may set other rules"), as facts.
   - **Adopting a template:** state which slots in the appendices relate to the change and what they currently leave open.
5. **Why did the text change?** Only if useful. The map's status column (e.g. a new law passed but not in force, an EU act pending) and the publisher's guidance often answer this. Avoid `list_law_changes` across several years; it lists every change in the period.
6. **Impact rating** from our side, using the criteria below, plus a confidence level (high / medium / low).

### 6c. Weigh every high- and medium-impact item before you write it

For each such item, write the answers in `workspace/_work/item_checks.md`:

1. **Already covered?** Using the topic sweep from Step 5.4, list every clause, appendix slot, priority rule, data processing agreement term or mandatory statute that already deals with the issue. Typical places:
   - a precedence rule giving a data processing agreement priority, which brings in GDPR Art. 28(3) exceptions;
   - an existing exit or handover clause and its price slot;
   - a "jf. punkt X" link that pulls in an existing payment or procedure rule;
   - mandatory law that overrides the contract anyway.
2. **Strongest counterpoint.** Write the best argument that the impact is smaller than it looks, or that the other side's reading would fail. If it is strong, lower the rating or the confidence.
3. **Points to consider.** From 1 and 2, write 1–3 neutral lines: what is already covered, what remains open, and what the impact depends on. No advice (see ground rules).

### Impact rating criteria

The colour measures the **realistic impact on our side in the situation the purpose describes**, after the checks in 6c. It does not measure how big the textual change is, and it is not a call to action.

- 🔴 **High impact.** Moves material risk, liability or cost to our side; removes or weakens a protection we have under the contract or the background law; adds an unlimited or uncapped exposure; conflicts with mandatory law; or materially changes termination, liability, IP/data, price or deadlines against us. It also requires that nothing else in the contract or the law already deals with it.
- 🟡 **Medium impact.** Unclear or ambiguous wording; departs from the statutory default rule or common market practice without a clear effect; shifts balance moderately; turns on a business fact we can't see; or a favourable change that comes with conditions we could breach.
- 🟢 **Low or no impact.** Editorial or language-only, neutral, clarifies existing law, favours our side without conditions, or the issue is already covered elsewhere.

**Existing agreement:** where our side can decline the new terms, rate the impact **"if adopted"** and say so in the header. Keep a separate short list of facts that bear on the **present** under the old terms (often none, or only a question about current practice).

**When unsure between two colours,** pick the one that fits the realistic impact after the 6c checks, name the other colour, and state the fact that would move the item to it (e.g. "high if the data processing agreement lacks the Art. 28(3)(g) exception").

## Step 7: Build the outputs (in `workspace/01_output/`)

Use the docx skill.

1. **`00_Summary_legal_impact.docx`:**
   - **Header:** contract, versions compared (file names from the manifest), perspective, purpose, date of review, scope, and whether the review rests on the signed appendices or only on the template.
   - **Overview:**
     - number of high / medium / low impact items;
     - for an existing agreement: **"Bears on the present"** (under the old terms) and **"Would change if adopted"** as two separate short lists;
     - the three most important points in plain language, including what did not change.
   - **High, then medium, then low impact sections.** Each item gives:
     - clause reference (old → new) and the change;
     - effect for our side (realistic vs. theoretical);
     - linked sources;
     - confidence.
     High- and medium-impact items also give, from the 6c checks:
     - **already covered by** (clauses, appendix slots or statutes, or "nothing found");
     - **counterpoint**, in one sentence;
     - **points to consider** (1–3 neutral lines).
     Low-impact items get a one-line reason instead (e.g. "editorial", "already covered by clause X").
   - **Legal sources checked:** the legal map from Step 6a as a table (source, why relevant, status, Lovkart coverage, items it was used for). Include:
     - sources checked and found not relevant;
     - the publisher's guidance, and whether it could be read;
     - areas where the background law is non-statutory.
   - **Closing:**
     - method;
     - limitations (Lovkart covers Høyesterett only, no legal commentary, historical law versions are partial; publisher guidance not reachable, if so; signed appendices not reviewed, if so);
     - the not-legal-advice sentence;
     - who can check it (from `describe_corpus` → `verify_with`).
   - **Annex: change table** on landscape pages: Clause | Old wording | New wording | Effect | Impact | Already covered by | Source. Keep column headers short enough not to break mid-word in narrow columns.
2. **`01_Redline_<part>_<old>-<new>.docx`, one per contract part with changes:**
   - Built on the **new** version, with tracked changes from old to new (author: "Contract review"). Accept-all must give the new text; reject-all must give the old text. Check both.
   - **Readability:**
     - If a paragraph was mostly rewritten (under about 50% of its words in common), show it as one deletion followed by one insertion.
     - Use word-level marks only for light edits.
     - Mark wholly new paragraphs as inserted, including the paragraph mark.
   - A **margin comment** on every substantive change: impact emoji, effect in 1–3 sentences, "already covered by …" when relevant, and the source url. No advice; the comment carries the same content as the summary item, shortened, never anything extra.
   - Editorial changes inside text boxes (cover pages) can be left unmarked if they're listed in the summary.

## Step 8: Check the work, then report

Before telling the user it's done:

1. **Challenge pass.**
   - If you can spawn a subagent, give a fresh one the contract files (both versions, all appendices, any supporting material) and the draft summary, but not your working notes. Tell it the perspective and purpose, and that it may use Lovkart to verify a cited provision but must not add new recommendations. Without a subagent, do this pass yourself, re-reading the contract from the start rather than your notes.
   - For each high- and medium-impact item, the challenger argues that the effect is overstated or misdescribed:
     - already covered elsewhere;
     - a statute cited outside its scope;
     - a missed priority rule;
     - a theoretical risk presented as a realistic one;
     - a wrong statement of how an amendment would take effect.
   - Fix the summary where the challenge holds; where it doesn't, keep the item and record the counterpoint.
2. **Advice sweep.** Search both outputs for advisory language in the output language: "should", "recommend", "suggest", "propose", "do not accept", "negotiate"; in Norwegian "bør", "anbefal", "foreslå", "godta", "forhandle", "må". Each hit is a flag to read, not an automatic rewrite: a sentence that tells our side what to do is rewritten as a neutral fact or open question, or removed; a sentence that reports what the contract or the law says (e.g. "changes must be in writing", "the customer may accept the service with errors") stays. Quoted contract or statute text is exempt. Record in `workspace/_work/item_checks.md` how many hits there were and what was changed.
3. Validate each .docx. Render the pages that carry the changes and look at them.
4. Confirm:
   - every high- and medium-impact item has at least one linked source (or the explicit "contract term" note), an "already covered by" entry and points to consider;
   - every source cited in the items appears in the legal map;
   - the counts in the overview match the sections;
   - internal references in the summary are right (item numbers, "above"/"below", section names).
5. Re-hash the originals and compare them with the manifest **as a set** (order can differ), to confirm they are untouched.

Then reply briefly with:
- the counts per impact level;
- for an existing agreement, what bears on the present (or "nothing");
- the high-impact items in one line each;
- where the files are.

Do not recap the steps.

## Limitations to state when relevant

- Lovkart covers current Norwegian law, central regulations, preparatory works (1986–2026) and Høyesterett decisions. It does not cover lower courts, legal commentary or local regulations. EU/EEA coverage is partial.
- The publisher's guidance for a standard contract helps with interpretation but has no binding legal force; say if it could not be read.
- A review based on blank templates cannot see what the parties filled in; say so when the signed appendices were not available.
- Scanned PDFs need OCR first, and the result may contain errors. Say so.
- Impact ratings depend on the perspective the user chose. A different side means different colours.