fenix-claude-plugin 0.1.3 → 0.2.0

package/skills/fenix-office-action/SKILL.md

@@ -6,7 +6,7 @@ description: >-
 
 # Fenix Office Action
 
-**Skill version: 7** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+**Skill version: 25** (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
 
@@ -40,7 +41,7 @@ Trigger whenever the attorney wants to respond to an Office Action:
 ## How to use
 
 Read `references/oa-response.md` first  --  it is the spine of the workflow. The phases are:
-1. Identify the matter and find/create the OA-response project.
+1. Identify the matter, then CHECK for its Fenix project (`read {resource:"project", options:{identifier or query}}`). If none exists, do not proceed on air -- gather the intake (matter/application number, notification date, project type, due date, assignee initials) and create it with `write {resource:"project", action:"create"}` (the `fenix-project` skill covers the fields; `references/oa-response.md` has the detailed step) before importing anything.
 2. `populate_project_from_uspto`  --  import the OA rejections, dispositions, references, and claims.
 3. `import_oa_references`  --  download the cited references and capture their text (needed for §102/§103 arguments).
 4. Analyze the rejections (`references/oa-analysis.md`)  --  classify, choose strategy, map elements. **Stop for attorney approval.**
@@ -54,5 +55,6 @@ Read `references/oa-response.md` first  --  it is the spine of the workflow. The
 - **Pass assignee initials directly**  --  the backend resolves initials to the user; do not call get_user_by_initials first.
 - **Generate the response document only at Phase 7**, after the amendments and arguments are approved  --  do not assemble or print documents earlier or out of order.
 - **Batch your saves**  --  use one `save_project` call with an `operations` array (oa_data + claims + sections) instead of many separate calls.
+- **Delegate a BIG save**  --  when the attorney has approved a large payload (a full `oa_data`, a whole amended claim set), write it to a file and hand the save to a background agent rather than spending the conversation on it twice. `references/oa-drafting.md` has the shape and the rules -- chiefly that the agent SAVES and does not draft, and that `oa_data` is NOT revision-checked, so the agent must do the read-merge-write itself and only ever ONE agent may touch it.
 - **Approve before saving**  --  amendments and arguments are legal work product; the attorney approves each before you save it.
 - **Never fabricate prior-art content**  --  only distinguish a reference whose disclosure text you actually have (see `import_oa_references`).

package/skills/fenix-office-action/VERSION

@@ -1 +1 @@
-7
+25

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

@@ -1,6 +1,6 @@
 # Office Action Rejection Analysis
 
-**Version: 7**
+**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, 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 `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, query, maxPassages })` (the `citationId` comes from the `import_oa_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.
+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,6 +1,6 @@
 # Office Action Response Drafting & Save Contracts
 
-**Version: 7**
+**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).
 
@@ -12,27 +12,44 @@ You save **clean data**; Fenix renders the document. Save the **amended claim te
 
 | Artifact | Saved to | How |
 |---|---|---|
-| One amended/new claim | `Project.claims` (by claimNumber) | `save_project({ type: "claim", claim })` — **preferred** |
-| Several claims at once | `Project.claims` | `save_project({ type: "claims", 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"}}` |
 
 ## Amendment markup is automatic — save clean text
 
 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.
 
+### 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.
+
 ## Prefer single-claim saves
 
-Amendments usually touch a few claims out of many. Save each amended (or new) claim on its own with `save_project({ 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.
+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, references, and the `original_claims` snapshot, 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"] })`.
+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: `save_project({ projectId, fields: { oa_data: <full merged object> } })`.
+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`. (Single-claim and `type:"claims"` saves write `Project.claims`, not `oa_data`, so they never touch `original_claims`.)
 
@@ -49,10 +66,10 @@ Use these exact `claimStatus` values:
 ## Saving a claim
 
 ```
-save_project({ type: "claim", claim: {
+write {resource:"project", action:"save", options:{type: "claim", claim: {
   claimNumber: "7", claimStatus: "Currently Amended", claimType: "dependent",
   claimText: ["...clean amended limitation...", "..."], parent: "1", independentParent: "1"
-}})
+}}}
 ```
 
 - Independent claims set `claimType: "independent"` and empty `parent`/`independentParent`.
@@ -61,20 +78,78 @@ save_project({ type: "claim", claim: {
 
 ## Save efficiently — batch in ONE call
 
-Save several things in a single `save_project` call with the `operations` array (runs in order; returns a `steps` array — check each `ok`):
+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`):
 
 ```
-save_project({
-  projectId,
+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
 
 Populate `oa_data.amendmentsStatus` (read-merge-write the full `oa_data`):
@@ -101,14 +176,14 @@ These are **rendered automatically** into the OAR document — each argument is
 
 For a review/revision pass after the one-by-one drafting, offer a live editor (ask first — never open unprompted):
 
-- **Arguments** — `get_live_artifacts({ name: "oa-arguments-editor" })`: substitute `__PROJECT_ID__` and `__SERVER_PREFIX__`, write the returned `html` to its `fileName`, and open it. It loads the rejections, lets the attorney edit each `argument` + `response_strategy`, **read-merge-writes the full `oa_data` itself**, and returns a `[OA ARGUMENTS SAVED]` diff. When the attorney pastes that diff, **do not re-save** — it already persisted; just apply the delta to your working copy.
+- **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.
 
 ## Remarks
 
 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): `save_project({ type: "section", sectionName: "Conclusion", paragraphs: ["<html paragraph>", "..."] })`.
-- **All sections at once:** `save_project({ type: "sections", sections: { "Conclusion": {...}, "Status of the Claims": {...} } })` — here `sections` is a **map of name → content**, never a single section.
+- **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`.
 
@@ -116,6 +191,8 @@ In a batch `operations` array, save each remarks section with its own `type: "se
 
 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. `get_oa_shell_doc({ projectId })` → returns a direct `downloadUrl` to the formatted OAR document (now populated with the marked-up claims and the arguments).
+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: 7**
+**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,7 +40,7 @@ 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 the arguments, one rejection at a time
 
@@ -57,15 +57,15 @@ After all arguments are approved, save them in **one** read-merge-write: set eac
 
 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 arguments editor** so you can review and revise them all together before I generate the response? (Or I can generate it now.)"
+> "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 loads the rejections, lets the attorney edit each argument + strategy, saves itself, and returns a `[OA ARGUMENTS 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.)
+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. `get_oa_shell_doc({ 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 `get_oa_shell_doc({ projectId, delivery: "base64" })` and write the `base64` to a local `.docx`.
+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'.