fenix-claude-plugin 0.1.2 → 0.2.0

package/skills/fenix-office-action/references/oa-analysis.md

@@ -1,6 +1,6 @@
 # Office Action Rejection Analysis
 
-**Version: 4**
+**Version: 25**
 
 This file is how you turn the imported `oa_data` into a response strategy. The method is **classify → select → fill**:
 
@@ -15,7 +15,7 @@ Then present the per-rejection strategy to the attorney and **stop for approval
 Each entry in `oa_data.oa_rejections` has:
 - `status_type` / `status_type_extended` — the rejection basis (e.g. contains "101", "102", "103", "112").
 - `status_claims` — the claim numbers under this rejection.
-- `reject_refs` / `status_refs` — the references applied (resolve to citations; their disclosure text is on the citation's `plainText` after `import_oa_references`).
+- `reject_refs` / `status_refs` — the references applied (resolve to citations; their disclosure text is on the citation's `plainText` after `write {resource:"oa", action:"import-references"}`).
 - `match`, `page` — the verbatim rejection text and page in the OA.
 
 `oa_data.claim_dispositions` tells you the big picture: `allowed_claims`, `rejected_claims`, `objected_claims`, `withdrawn_claims`, `restriction_or_election`.
@@ -34,10 +34,20 @@ Before working rejection-by-rejection, orient the attorney with two things:
    |---|---|---|
    | _e.g. "a processor configured to…"_ | _e.g. Smith ¶[0042], Fig. 3_ | _e.g. Questionable — Smith discloses X but not the claimed Y_ |
 
-   Fill the middle column from the rejection's `match`/`page` and the cited reference's disclosure text — call `get_reference_text({ citationId })` for the references the examiner applied (the `citationId` comes from the `import_oa_references` list). Fill the right column with your element-by-element read: is the examiner's mapping correct, a stretch, or wrong, and why. This table is the backbone of the §102/§103 analysis — the strongest distinctions surface here.
+   Fill the middle column from the rejection's `match`/`page` and the cited reference's disclosure text — call `read {resource:"reference-text", options:{citationId, query}}` for the references the examiner applied, passing the claim limitation (or the concept the examiner cited) as `query` to pull just the most relevant passages with paragraph numbers (`maxPassages` caps how many). The `citationId` comes from the `write {resource:"oa", action:"import-references"}` list. Fill the right column with your element-by-element read: is the examiner's mapping correct, a stretch, or wrong, and why. This table is the backbone of the §102/§103 analysis — the strongest distinctions surface here.
 
 Present the overview + table to the attorney, then proceed to the per-rejection analysis below.
 
+## Analyzing the cited references — fan out when there are several
+
+The element-by-element mapping below depends on each cited reference's disclosure text (via `read {resource:"reference-text"}`). **If more than two references are cited** across the office action, analyze them **in parallel** rather than one at a time:
+
+- Launch the reference-analysis agents in a single message (one Agent call per reference) so they run concurrently.
+- Each agent's prompt must include the `projectId`, the `citationId`, and the claim language to map (the limitations of the rejected claim(s) the reference is applied against).
+- Agents must **not** call `write {resource:"project", action:"save"}` — collect their findings and save once from the main conversation.
+
+Each agent returns its reference's element-by-element mapping and the disclosure gaps it found; you assemble those into the per-rejection analysis. With two or fewer references, just analyze them inline — the fan-out overhead isn't worth it.
+
 ## §101 — Subject-matter eligibility (MPEP 2106)
 
 **Classify** the rejection into the Alice/Mayo step it turns on, and the abstract-idea grouping it asserts:
@@ -61,7 +71,7 @@ Present the overview + table to the attorney, then proceed to the per-rejection
 2. For each, find where (if anywhere) the reference discloses it; quote the passage.
 3. Identify at least one element that is **absent** from the reference (or not arranged as claimed). That gap is the anticipation argument.
 
-To get a reference's text, call `get_reference_text({ citationId })` (the `citationId` comes from the `import_oa_references` list). It returns clean EPO text, or the PDF as base64 to read, or a Google Patents link, or captured OCR text, and only asks the attorney as a last resort. Never guess a reference's contents.
+To get a reference's text, call `read {resource:"reference-text", options:{citationId, query, maxPassages}}` (the `citationId` comes from the `write {resource:"oa", action:"import-references"}` list). Pass the claim limitation or the examiner's cited concept as `query` to retrieve just the most relevant passages (with ¶ numbers) instead of the whole disclosure — better for element mapping and far smaller. It returns clean EPO text or targeted passages, a presigned PDF download URL (`pdf_url`) to read, a Google Patents link, or captured OCR text, and only asks the attorney as a last resort. Never guess a reference's contents.
 
 ## §103 — Obviousness (MPEP 2141–2145)
 

package/skills/fenix-office-action/references/oa-drafting.md

@@ -1,68 +1,154 @@
 # Office Action Response Drafting & Save Contracts
 
-**Version: 4**
+**Version: 25**
 
 This file defines how drafted amendments and arguments are written back to Fenix. Everything here happens **after** the attorney approves the strategy (Phase 4) and the draft (Phases 5–6).
 
+## The model in one paragraph
+
+You save **clean data**; Fenix renders the document. Save the **amended claim text** (clean — no markup) with status `Currently Amended`, the **per-rejection argument** prose, and the **amendment bookkeeping**. The OAR document generator then derives amendment markup (underline additions / strikethrough deletions) by diffing your amended claims against the as-pending snapshot, and inserts each argument after its boilerplate — automatically. You do **not** produce markup or hand-fill the document.
+
 ## Where each artifact is saved
 
 | Artifact | Saved to | How |
 |---|---|---|
-| Amended claim text | `Project.claims` | `save_project({ type: "claims" })` |
-| Which claims were amended / cancelled / added | `oa_data.amendmentsStatus` | `save_project({ fields: { oa_data } })` (read-merge-write) |
-| Per-rejection drafted argument | `oa_data.oa_rejections[i].argument` / `.response_strategy` | `save_project({ fields: { oa_data } })` (read-merge-write) |
-| Final remarks prose | `Project.sections` | `save_project({ type: "sections" })` |
+| One amended/new claim | `Project.claims` (by claimNumber) | `write {resource:"project", action:"save", options:{type: "claim", claim}}` — **preferred** |
+| Several claims at once | `Project.claims` | `write {resource:"project", action:"save", options:{type: "claims", claims: [...]}}` |
+| Which claims were amended / cancelled / added | `oa_data.amendmentsStatus` | `write {resource:"project", action:"save", options:{fields: { oa_data }}}` (read-merge-write) |
+| Per-rejection drafted argument | `oa_data.oa_rejections[i].argument` / `.response_strategy` | `write {resource:"project", action:"save", options:{fields: { oa_data }}}` (read-merge-write) |
+| Final remarks prose | `Project.sections` | `write {resource:"project", action:"save", options:{type: "sections"}}` |
 
-## Save efficiently — batch in ONE call
+## Amendment markup is automatic — save clean text
 
-At the end of drafting you typically save several things: the updated `oa_data` (amendmentsStatus + per-rejection arguments), the amended `claims`, and the remarks `sections`. **Do them in a single `save_project` call using the `operations` array** — do not make a separate call for each:
+When you amend a claim, save the **final amended claim text only** (the clean "after" version) with `claimStatus: "Currently Amended"`. Fenix keeps an immutable snapshot of the as-pending claims (`oa_data.original_claims`) and, when it generates the OAR document, diffs your amended claim against that snapshot to produce the underline/strikethrough markup and the `(Currently Amended)` heading. **Do not** embed underline/strikethrough, brackets, or any markup in `claimText` — just the clean amended language.
 
-```
-save_project({
-  projectId,
-  operations: [
-    { fields: { oa_data: <full merged oa_data> } },   // amendmentsStatus + oa_rejections[].argument (read-merge-write)
-    { type: "claims", claims: [ ... ] },               // amended claims
-    { type: "sections", sections: { ... } }            // remarks
-  ]
-})
-```
+### Use the LEAST markup possible — minimal, surgical edits
+
+The markup is a **word-level diff** against the as-pending claim, so every word you change becomes strikethrough (deletion) or underline (addition). Make the amendment as small as the change requires:
+
+- **Start from the exact as-pending claim text** and edit only the words the amendment actually needs. Keep all surrounding language **verbatim** — same words, same order.
+- **Do not reword, rephrase, "clean up," reorder, or re-punctuate** any part you are not deliberately amending. Rewording untouched text produces large, noisy markup that overstates the scope of the amendment (and can create unintended prosecution-history estoppel).
+- If your edit to a limitation changes more than the words you intend, you have reworded too much — revert to the original wording and make a tighter change.
+
+### Preserve the claim's existing formatting
+
+Keep the as-pending claim's structure so the diff lines up cleanly limitation-by-limitation:
+
+- Keep the **same line breaks between limitations** — one `claimText` array entry per limitation/line, exactly as in the as-pending claim. Edit *within* the existing lines; do not merge limitations onto one line or re-split them.
+- Keep the same punctuation, indentation, and ordering of limitations.
+
+If the `claimText` array structure changes, the diff can no longer align limitations and instead strikes an entire limitation and re-inserts it — turning a one-word change into a whole-paragraph rewrite in the markup. Matching the original structure keeps the markup minimal and readable.
 
-The operations run in order; the response returns a `steps` array — check each `ok`, and the claims step's `parseVerification.ok`. The single-operation params still work for one-off saves.
+## Prefer single-claim saves
+
+Amendments usually touch a few claims out of many. Save each amended (or new) claim on its own with `write {resource:"project", action:"save", options:{type: "claim", claim: { ... }}}` — it upserts that one claim by `claimNumber` and re-derives the claim tree, instead of re-sending the whole set. Use the bulk `type: "claims"` only when you are replacing most/all of the claims.
 
 ## CRITICAL: read-merge-write for `oa_data`
 
-`save_project({ fields: { oa_data } })` **replaces the entire `oa_data` object** (it is a `$set`). To avoid wiping the imported rejections, dispositions, and references, you must:
+`write {resource:"project", action:"save", options:{fields: { oa_data }}}` **replaces the entire `oa_data` object** (it is a `$set`). To avoid wiping the imported rejections, dispositions, references, and the `original_claims` snapshot, you must:
 
-1. Load the current full object: `get_project({ projectId, include: ["oa_data"] })`.
-2. Modify the in-memory object (add `amendmentsStatus`, set `oa_rejections[i].argument`, etc.) **without dropping any existing keys**.
-3. Save the complete merged object back: `save_project({ projectId, fields: { oa_data: <full merged object> } })`.
+1. Load the current full object: `read {resource:"project", options:{projectId, include: ["oa_data"]}}`.
+2. Modify the in-memory object (set `amendmentsStatus`, `oa_rejections[i].argument`, etc.) **without dropping any existing keys**.
+3. Save the complete merged object back: `write {resource:"project", action:"save", options:{projectId, fields: { oa_data: <full merged object> }}}`.
 
-Never send a partial `oa_data`.
+Never send a partial `oa_data`. (Single-claim and `type:"claims"` saves write `Project.claims`, not `oa_data`, so they never touch `original_claims`.)
 
 ## Amendment status conventions (37 CFR 1.121)
 
-Every claim presented in an amendment carries a status identifier. Use these exact `claimStatus` values:
-- **(Original)** — unchanged since filing.
-- **(Currently Amended)** — being changed in this response (show changes with underline/strikethrough in the remarks/document, not in the stored `claimText`).
-- **(Previously Presented)** — added/amended in an earlier response, unchanged now.
-- **(Canceled)** — removed; no claim text.
-- **(New)** — newly added in this response.
-- **(Withdrawn)** — non-elected; not under examination.
-
-## Saving amended claims
+Use these exact `claimStatus` values:
+- **Original** — unchanged since filing.
+- **Currently Amended** — changed in this response. Save the clean amended text; markup + heading are derived.
+- **Previously Presented** — amended in an earlier response, unchanged now.
+- **Canceled** — removed; no claim text.
+- **New** — newly added in this response.
+- **Withdrawn** — non-elected; not under examination.
 
-`save_project({ type: "claims", claims: [ ... ] })` where each claim is:
+## Saving a claim
 
 ```
-{ claimNumber: "1", claimStatus: "Currently Amended", claimType: "independent",
-  claimText: ["...limitation...", "...limitation..."], parent: "", independentParent: "" }
+write {resource:"project", action:"save", options:{type: "claim", claim: {
+  claimNumber: "7", claimStatus: "Currently Amended", claimType: "dependent",
+  claimText: ["...clean amended limitation...", "..."], parent: "1", independentParent: "1"
+}}}
 ```
 
-- Dependent claims set `claimType: "dependent"`, `parent` to the claim they depend from, and `independentParent` to the root independent claim.
-- You may instead pass `rawClaims` (text); the server parses it and returns `parseVerification`.
+- Independent claims set `claimType: "independent"` and empty `parent`/`independentParent`.
+- For a bulk `type:"claims"` save with `rawClaims` text, the response includes `parseVerification`. **You MUST evaluate `parseVerification.ok`** — if `false`, parse the claims yourself into the structured array and re-save; do not just resend raw text.
+- Optional optimistic concurrency: pass `baseRev` (the `claimsRev` you loaded) to have a stale save rejected (409) instead of overwriting.
+
+## Save efficiently — batch in ONE call
 
-**You MUST evaluate `parseVerification.ok` in the response.** If it is `false` (gaps in numbering, suspected merged claims, or count mismatch vs. `sourceClaimMarkers`), the auto-parse failed: parse the claims yourself into the structured array above and re-call `save_project({ type: "claims", claims: [...] })` with your corrected JSON. Do not just resend raw text.
+Save several things in a single `write {resource:"project", action:"save"}` call with the `operations` array (runs in order; returns a `steps` array — check each `ok`):
+
+```
+write {resource:"project", action:"save", options:{projectId,
+  operations: [
+    { fields: { oa_data: <full merged oa_data> } },   // amendmentsStatus + oa_rejections[].argument (read-merge-write)
+    { type: "claim", claim: { claimNumber: "1", claimStatus: "Currently Amended", ... } },
+    { type: "claim", claim: { claimNumber: "7", claimStatus: "Currently Amended", ... } },
+    { type: "section", sectionName: "Conclusion", paragraphs: [ "..." ] }   // ONE remarks section (repeat the op for more)
+  ]}}
+```
+
+## Hand a big save to a background agent
+
+A full `oa_data` — every rejection with its drafted argument, the amendment
+bookkeeping, and the `original_claims` snapshot you must carry through — is a
+large payload, and in the main conversation it costs you **twice**: once in the
+call you write out, and again in the result echoed back. When the content is
+**settled** (the attorney has approved it), delegate the save and keep working.
+
+The two payload shapes here are not equally safe to delegate, and the difference
+matters:
+
+**Claims** (`type: "claim"` / `type: "claims"`) are revision-checked. Write the
+approved claim objects to a file, and have the agent make one call passing
+`baseRev` (the `claimsRev` you loaded). A stale save is then rejected with a 409
+instead of overwriting whoever moved first.
+
+**`oa_data` is NOT revision-checked.** It is saved through `fields`, which is a
+whole-object `$set` — there is no `baseRev` for it and no 409 to catch a race.
+Two writers silently produce one survivor. So for `oa_data`:
+
+- **Give the agent the PATCH, not the merged object.** Put only what you drafted
+  (the per-rejection `argument` / `response_strategy`, `amendmentsStatus`) in the
+  file, and have the agent do the whole read-merge-write itself: load the current
+  `oa_data`, apply your patch over it without dropping any existing keys, save the
+  complete object. That keeps the READ fresh. A merged object computed in the main
+  conversation and saved minutes later silently reverts anything that changed in
+  between — the exact failure `original_claims` cannot survive.
+- **Never run two agents against `oa_data`,** and do not run one while the
+  attorney is editing rejections in the OA editor. With no rev check, the loser's
+  work is simply gone.
+
+A prompt of the right shape:
+
+> Read `<path>/oa-patch.json`. Then: (1) load the current `oa_data` with
+> `read {resource:"project", options:{projectId:"<id>", include:["oa_data"]}}`;
+> (2) apply the patch over it — set only the keys the patch names, drop nothing,
+> and leave `original_claims` and every existing rejection key untouched;
+> (3) save the COMPLETE merged object with
+> `write {resource:"project", action:"save", options:{projectId:"<id>", fields:{oa_data:<merged>}}}`.
+> Do not edit, re-word, re-order or add to any argument text — it is
+> attorney-approved work product. Reply with the rejection count and which keys
+> you set, or the full error if it failed.
+
+**Rules**
+
+- The agent **saves; it does not draft.** Amendments and arguments are legal work
+  product approved by the attorney in the main conversation. An agent asked to
+  "finish" or "improve" anything will write text nobody approved.
+- **Only for saves that are large and settled.** One argument, or a two-claim
+  amendment, costs more to delegate than to call.
+- **One save per agent.** Writing the file is the step that actually saves
+  anything — the agent reads it, so the JSON never passes through the conversation
+  a second time. Pasting the payload into the agent's prompt saves nothing.
+- **Check its result before you rely on the save**, and before you generate the
+  response document. A save you never confirmed is not a save, and Phase 7 prints
+  from whatever is actually stored.
+- **If your host cannot run a background agent,** or the agent cannot reach the
+  Fenix tools, just make the call yourself — that is always the fallback, and a
+  delegated save that never happened is worse than a slow one.
 
 ## Saving the amendment bookkeeping
 
@@ -80,25 +166,33 @@ amendmentsStatus: {
 
 ## Saving the per-rejection arguments
 
-For each rejection you responded to, set two keys on that entry in `oa_data.oa_rejections` (read-merge-write):
+For each rejection you responded to, set on that entry in `oa_data.oa_rejections` (read-merge-write):
 - `response_strategy`: `"amend"` | `"argue"` | `"both"`.
-- `argument`: the drafted argument prose for that rejection.
+- `argument`: the drafted argument prose.
 
-This keeps each argument co-located with the rejection it answers. Do not remove or reorder the existing keys (`status_type`, `status_claims`, `status_refs`, etc.).
+These are **rendered automatically** into the OAR document — each argument is inserted right after that rejection's static boilerplate. Keep the argument as clean prose (blank lines separate paragraphs). Do not remove or reorder the existing rejection keys (`status_type`, `status_claims`, `status_refs`, etc.).
 
-## Saving the remarks
+## Editors (Cowork live artifacts)
 
-Write the Remarks as project `sections`: a claim-status summary section, then one section per rejection (in OA order) containing the approved argument. Save with `save_project({ type: "sections", sections: { ... } })` (bulk) or `save_project({ type: "section", sectionName, paragraphs: [<HTML strings>] })` per section. Keep the section names stable — the OA shell print consumes them.
+For a review/revision pass after the one-by-one drafting, offer a live editor (ask first — never open unprompted):
 
-## Remarks structure (recommended)
+- **Rejections & arguments** — bind the matter with `write {resource:"context", options:{ids: { projectId }, label: "<matter number>"}}`, then have the attorney open the **installed Fenix OA editor** from their artifacts sidebar. **Never write, edit, or substitute anything into the artifact**; see `references/editors.md` in fenix-application. It loads the rejections (and reference labels) and lets the attorney edit each rejection's **type, claims, applied references, response strategy, and argument** (and add/remove rejections), **read-merge-writes the full `oa_data` itself**, and returns a `[OA REJECTIONS SAVED]` diff. When the attorney pastes that diff, **do not re-save** — it already persisted; just apply the delta to your working copy.
+- **Amendments (claims)** — use the `claims-editor` artifact to edit the amended claim text. Save the **clean** amended text with status `Currently Amended`; the document derives the underline/strikethrough markup on print.
 
-1. **Status of the claims** — what is pending, amended, canceled, new; which are allowed/objected.
-2. **Claim amendments** — the marked-up claims (handled by the claims save + the document).
-3. **Arguments**, one heading per rejection, in OA order — for each: restate the rejection briefly, then the approved argument (the element gap for §102/§103, the eligibility/practical-application argument for §101, the spec citations for §112, etc.).
-4. **Conclusion** — request allowance / reconsideration; offer an interview if appropriate.
+## Remarks
 
-Always confirm the full remarks with the attorney before saving.
+Save any standalone remarks (claim-status summary, conclusion) as `sections`. **Two shapes — pick the right one (a wrong shape costs a failed save + retry):**
+- **One section** (the usual case): `write {resource:"project", action:"save", options:{type: "section", sectionName: "Conclusion", paragraphs: ["<html paragraph>", "..."]}}`.
+- **All sections at once:** `write {resource:"project", action:"save", options:{type: "sections", sections: { "Conclusion": {...}, "Status of the Claims": {...} }}}` — here `sections` is a **map of name → content**, never a single section.
+
+In a batch `operations` array, save each remarks section with its own `type: "section"` op (`sectionName` + `paragraphs`); do **not** put a single section under `type: "sections"`. The per-rejection arguments live on `oa_data` (above) and are auto-inserted — do not duplicate them in `sections`.
 
 ## Assembling the response document
 
-After the amendments and arguments are saved, assemble the Word response document per **Phase 7** of `oa-response.md`: `get_oa_shell_doc({ projectId })` returns a direct `downloadUrl` to the formatted Fenix shell; download it to an authorized folder (or use `delivery: "base64"` if you can't download a URL), use your docx skill to insert the saved arguments and amended-claim text into the blanks, and present the filled document to the attorney. The attorney does not need to download or upload anything.
+Because the amended-claim markup and the per-rejection arguments are rendered from the saved data, the generated OAR document already contains them — there is no manual hand-filling for those:
+
+1. `write {resource:"oa", action:"generate-shell", options:{projectId}}` → returns a direct `downloadUrl` to the formatted OAR document (now populated with the marked-up claims and the arguments).
+2. Download it and review. Use your docx skill only for any residual blanks the template leaves that are **not** driven by saved data (e.g. signature/date).
+3. Present the document to the attorney. (If you can't download a URL, pass `delivery: "base64"`.)
+
+**Avoiding "the file got truncated."** The OAR document from `write {resource:"oa", action:"generate-shell"}` is generated **whole** — treat it as the finished file, not a draft to rebuild. Do **not** read its full text back and regenerate the `.docx` from that: a long document gets truncated on read, so the rebuilt file silently loses whatever fell past the cutoff. For the residual blanks only (signature/date), make **targeted, in-place edits** to the downloaded file (find-and-replace the specific text/field with your docx skill) and leave the rest byte-for-byte untouched — never re-emit the whole document. After editing, reopen it and confirm the last section (signature block / conclusion) is present before presenting it.

package/skills/fenix-office-action/references/oa-response.md

@@ -1,32 +1,32 @@
 # Office Action Response Workflow
 
-**Version: 4**
+**Version: 25**
 
 This is the end-to-end workflow for responding to a USPTO Office Action. Work through the phases in order. **Each drafting phase ends with attorney approval before anything is saved** — you draft, the attorney approves, then you save. This is legal work product; never save amendments or arguments the attorney has not approved.
 
 ## Invariants (always)
 
-- **Never pass `clientDb`.** It is inferred from the connector's API key. Passing it is an error.
-- **Never auto-generate a document.** Only call `print_patent({ type: "oa_shell" })` when the attorney explicitly asks for the Word document.
+- **Never pass `clientDb`.** The tools no longer accept it — the firm is fixed by the connector you signed in to (each firm authenticates to its own MCP endpoint), so there is nothing to override.
+- **Never auto-generate a document.** Only call `read {resource:"patent-document", options:{type: "oa_shell"}}` when the attorney explicitly asks for the Word document.
 - **Approval gate before every save.** Show the draft, ask for changes, save only after the attorney confirms.
 - **Never fabricate prior-art content.** Only distinguish a reference whose disclosure text you actually have (see Phase 3).
 
 ## Phase 1 — Identify the matter and the OA project
 
-1. Identify the matter: `get_project({ identifier })` (exact app/matter number) or `get_project({ query })` (keyword). Confirm the matter with the attorney.
+1. Identify the matter: `read {resource:"project", options:{identifier}}` (exact app/matter number) or `read {resource:"project", options:{query}}` (keyword). Confirm the matter with the attorney.
 2. The response includes a `projects` array. Look for an existing Office-Action-response project. If one exists, use its `projectId`.
 3. If none exists, create one: `list_project_types` → `create_project` (matter/app number, notification date, due date, type, and the assignee's **initials** — pass the initials directly; the backend resolves them to the user, so you do **not** need to look the user up first) → `assign_project` only if WA1/WA2 need changing. (The `fenix-project` skill covers the intake flow.)
 
 ## Phase 2 — Pull the Office Action facts from USPTO
 
-1. `populate_project_from_uspto({ projectId })`. If `matter.applicationNum` is missing it will tell you — ask the attorney for the application number and pass it as `applicationNum`.
-2. Load the full state: `get_project({ projectId, include: ["matter", "claims", "oa_data"] })`.
+1. `write {resource:"project", action:"populate-from-uspto", options:{projectId}}`. If `matter.applicationNum` is missing it will tell you — ask the attorney for the application number and pass it as `applicationNum`.
+2. Load the full state: `read {resource:"project", options:{projectId, include: ["matter", "claims", "oa_data"]}}`.
 3. **Report to the attorney and stop:** OA date and type (Non-Final / Final / Restriction), examiner, the rejections grouped by statute, which claims are rejected/objected/allowed, the cited references, and whether claims/spec/figures amendments are flagged. Let the attorney confirm the picture before you analyze.
 
 ## Phase 3 — Pull the cited-reference text
 
-1. `import_oa_references({ projectId })` — downloads the cited references and returns a **compact list** (`references[]` with `citationId`, `label`, `number`, `pubType`, `fileUrl`, `ocrTextChars`). It does **not** return the full text (that would flood the context). The response also includes the project `dashboardUrl` (→ Citations tab) you can share.
-2. For each reference you actually need to read — usually the ones the examiner applied against the claims you are arguing — call `get_reference_text({ citationId })`. It walks a fallback chain and returns whichever source worked (`source` tells you which):
+1. `write {resource:"oa", action:"import-references", options:{projectId}}` — downloads the cited references and returns a **compact list** (`references[]` with `citationId`, `label`, `number`, `pubType`, `fileUrl`, `ocrTextChars`). It does **not** return the full text (that would flood the context). The response also includes the project `dashboardUrl` (→ Citations tab) you can share.
+2. For each reference you actually need to read — usually the ones the examiner applied against the claims you are arguing — call `read {resource:"reference-text", options:{citationId}}`. It walks a fallback chain and returns whichever source worked (`source` tells you which):
    - **`epo`** — clean structured claims + description in `text`; use it directly.
    - **`google_patents_url`** — read the `url` with your web tools.
    - **`pdf_url`** — download the `downloadUrl` to a local `.pdf` and read it with your pdf/Read tools (don't WebFetch it). (`source: "pdf_base64"` returns the bytes inline only if you can't download a URL.)
@@ -40,19 +40,32 @@ Read `references/oa-analysis.md`. For each rejection, classify it into a sub-typ
 
 ## Phase 5 — Draft and save the amendments
 
-Read `references/oa-drafting.md`. Draft amended claim text with the correct claim status. Confirm with the attorney, then save: amended claims via `save_project({ type: "claims" })` (and you **must** check `parseVerification.ok`), and the amendment bookkeeping into `oa_data.amendmentsStatus`.
+Read `references/oa-drafting.md`. Draft amended claim text with the correct claim status. Confirm with the attorney, then save: amended claims via `write {resource:"project", action:"save", options:{type: "claims"}}` (and you **must** check `parseVerification.ok`), and the amendment bookkeeping into `oa_data.amendmentsStatus`.
 
-## Phase 6 — Draft and save the remarks
+## Phase 6 — Draft the arguments, one rejection at a time
 
-Read `references/oa-drafting.md`. Write the Remarks: a claim-status summary followed by one argument section per rejection, using the analysis from Phase 4. Confirm with the attorney, then save the per-rejection argument text into `oa_data.oa_rejections[i]` and the final prose as project `sections`.
+Read `references/oa-drafting.md`. Draft the arguments **one rejection at a time** (like the figure-description flow), not all in a single dump:
 
-## Phase 7 — Assemble the response document
+For each rejection, in OA order:
+1. Draft the argument from the Phase-4 analysis (the §102/§103 element gap, the §101 eligibility/practical-application argument, the §112 spec citations, etc.) and the firm's scaffolds.
+2. **Present that one argument to the attorney and END TURN.** Wait for confirmation or edits.
+3. Once approved, move to the next rejection — hold the approved arguments, don't save yet.
 
-Once the amendments and arguments are drafted, saved, and approved, assemble the actual response document. The Fenix shell is the firm's formatted template, but it leaves the arguments and amended-claim text **blank** — you fill those in (the attorney does not need to download or upload anything):
+After all arguments are approved, save them in **one** read-merge-write: set each `oa_data.oa_rejections[i].argument` (and `response_strategy`) on the full `oa_data` and save once. Also save any standalone remarks as `sections` (use the exact save shape in `references/oa-drafting.md` — getting it wrong wastes a retry).
 
-1. `get_oa_shell_doc({ projectId })` → returns a direct `downloadUrl` (presigned, ~1 hour) to the shell.
-2. **Download** `downloadUrl` into a folder you are authorized to write to — it is a direct, public file URL, so save it to disk; do **not** WebFetch it (WebFetch returns text and cannot handle a binary `.docx`). If your environment cannot download a URL to a file, call `get_oa_shell_doc({ projectId, delivery: "base64" })` and write the returned `base64` to a local `.docx` instead.
-3. Use your **docx skill** to insert the drafted arguments and amended claims into the blanks. You already have this content from Phases 4–6 and from the saved project data (`oa_data.oa_rejections[].argument`, `oa_data.amendmentsStatus`, `claims`, `sections`).
-4. Present the filled `.docx` to the attorney for review. Share the `dashboardUrl` so they can open the case in Fenix.
+### Required before printing — offer the arguments editor
 
-(If the attorney only wants the blank shell, `print_patent({ type: "oa_shell" })` still returns just the download link.)
+Once the arguments are saved, you **must offer the arguments editor before generating any document.** This is a required step; do not skip it and do not jump straight to printing. Say it explicitly, e.g.:
+
+> "The arguments are saved. Want me to open the **OA rejections & arguments editor** so you can review and revise them all together before I generate the response? (Or I can generate it now.)"
+
+If yes, open the `oa-arguments-editor` live artifact (see `references/oa-drafting.md`) — it lets the attorney adjust each rejection's type, claims, applied references, response strategy, and argument (and add/remove rejections), saves itself, and returns a `[OA REJECTIONS SAVED]` diff to paste back (apply the diff; do not re-save). Only move to Phase 7 after the attorney has used the editor or explicitly declined it. (Amendments are reviewed in the `claims-editor`; markup is derived on print.)
+
+## Phase 7 — Generate and review the response document
+
+Only after you have offered the arguments editor (Phase 6) and the attorney has used or declined it, generate the response document. Fenix renders the **amended-claim markup** (underline/strikethrough, derived from the saved clean claims) and the **per-rejection arguments** (inserted after each boilerplate) directly from the saved data — so the document already contains them. There is no manual hand-filling for those.
+
+1. `write {resource:"oa", action:"generate-shell", options:{projectId}}` → returns a direct `downloadUrl` (presigned, ~1 hour) to the formatted OAR document, populated with the marked-up claims and the arguments.
+2. **Download** `downloadUrl` to a folder you can write to — it is a direct, public file URL, so save it to disk; do **not** WebFetch it. If your environment cannot download a URL, call `write {resource:"oa", action:"generate-shell", options:{projectId, delivery: "base64"}}` and write the `base64` to a local `.docx`.
+3. **Scan the document for anything left to fill.** Read the downloaded `.docx` and find any remaining blanks, highlighted fields, bracketed placeholders, or template variables (e.g. `[ … ]`, `{{ … }}`, highlighted runs, and signature / date / customer-number / attorney-docket blanks). List exactly what you found and **ask the attorney whether to fill each one in, and with what** — then apply the answers with your **docx skill**. Do not silently leave them or guess values.
+4. Present the document to the attorney for review. Share the `dashboardUrl` so they can open the case in Fenix.

package/skills/fenix-project/SKILL.md

@@ -6,7 +6,7 @@ description: >-
 
 # Fenix Project
 
-**Skill version: 2** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+**Skill version: 4** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
 
 ## Triggers
 
@@ -16,11 +16,12 @@ description: >-
 
 ## Customization
 
-Before applying any workflow in this skill, read the `CUSTOMIZE.md` file in this skill directory. If it contains anything other than the placeholder text "place custom instructions here", treat its contents as user overrides that take precedence over the default instructions in this SKILL.md and its reference files.
+User overrides for this skill live in a `CUSTOMIZE.md` file in this skill directory. This file is **not shipped with the skill** -- it belongs to the user. **If `CUSTOMIZE.md` does not already exist in this skill directory, create it now** containing exactly the single line `place custom instructions here`. **If it already exists, never overwrite it** -- it holds the user's own instructions.
+
+Before applying any workflow in this skill, read `CUSTOMIZE.md`. If it contains anything other than the placeholder text "place custom instructions here", treat its contents as user overrides that take precedence over the default instructions in this SKILL.md and its reference files.
 
 Apply the custom overrides **only as long as the result still satisfies every structured-output contract** this skill depends on, including:
 - the JSON shapes passed to `save_project` (claims, figures, sections)
-- the `[EDITOR SUBMIT - <type>]` clipboard prefixes produced by the HTML editors
 - the figure ElementSchema (`type`, `label`, `number`, `text`) and component numbering rules
 - the spec section names and ordering required by the save/print tools
 

package/skills/fenix-project/VERSION

@@ -1 +1 @@
-2
+4

package/skills/fenix-project/references/create-project.md

@@ -1,9 +1,19 @@
 # Create Project
 
-**Version: 2**
+**Version: 4**
 
 1. **Collect**  --  matter/app number, notification date, project type ('list_project_types'), due date, assignee initials
 2. **Confirm**  --  show all values. Ask 'Ready to create  --  any changes?' **END TURN**
 3. **Create**  --  'create_project' once confirmed. Pass the assignee **initials** directly  --  the backend resolves initials to the user automatically (no need to call 'get_user_by_initials'). If the initials are not recognised, create_project returns an error so you can ask for the correct initials.
 
+## The notification date is the date the USER gives you  --  never today
+
+`notificationDate` is a REQUIRED field and it is **whatever date the user states** for this filing or action  --  the date on the office action, the date the notice was received, the filing/receipt date for a new application. If the user gives you a date at any point during intake, that date is the notificationDate; do **not** quietly substitute today's date, and do not put the user's date in `dueDate` instead.
+
+**Why it matters: it is the one field that tells two projects on the same matter apart.** A matter can carry several projects  --  two office actions, an application and its continuation, refilings  --  and they share a matter number and an invention title, so in every list and in the editor's matter switcher they look identical. The notification date is the disambiguator. Getting it wrong (or defaulting it to today) leaves the user with two rows they cannot tell apart and cannot reliably pick between.
+
+If the user has not given a date, **ask for it** rather than inventing one. For a brand-new application with no notice, ask which date they want recorded (filing date, receipt date); it still has to be a real, deliberate value, because it is what will distinguish this project later.
+
+`dueDate` is a DIFFERENT field  --  the response/action deadline. Keep the two separate; if the user gives only one date, confirm which it is before creating.
+
 If any field is missing: render a React form with all fields. On submit show confirmation block, then 'create_project'.