fenix-claude-plugin 0.1.0 → 0.1.1

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "fenix",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Fenix patent automation for Claude — MCP connector plus patent drafting, office-action, and project skills. Provide one API key; the server infers your firm (client + database).",
   "author": {
     "name": "Fenix AI",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fenix-claude-plugin",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Fenix patent automation plugin for Claude Code — MCP connector plus patent drafting, office-action, and project skills.",
   "license": "UNLICENSED",
   "homepage": "https://claude.fenix.ai",

package/skills/fenix-application/SKILL.md

@@ -6,7 +6,7 @@ description: >-
 
 # Fenix Application
 
-**Skill version: 11** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+**Skill version: 13** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
 
 ## Triggers
 
@@ -42,6 +42,7 @@ Custom instructions may freely change tone, phrasing, default counts, section pr
 ## Contents
 - `references/patent.md`  --  3-phase workflow
 - `references/claims.md`  --  claims drafting + verification
+- `references/claim1-method-drafting.md`  --  house style for an independent method claim 1 (skeleton, wherein rules, verb/lexicon, budgets, procedure)
 - `references/figures.md`  --  Phase 1+2 figure workflow
 - `references/spec.md`  --  spec section workflow
 - `references/editors.md`  --  exact INITIAL_CONTENT shapes + submit handling for the 3 HTML editors (read this instead of the editor HTML)
@@ -89,7 +90,7 @@ Trigger when the user asks to review, audit, red-line, or check a patent applica
 ## Draft a patent application
 
 Read `references/patent.md` for the 3-phase workflow overview. Phase-specific references:
-- **Claims**: `references/claims.md`, `references/patent-safe.md`
+- **Claims**: `references/claims.md`, `references/claim1-method-drafting.md` (method claim 1 house style), `references/patent-safe.md`
 - **Figures**: `references/figures.md`, `references/figures-guidance.md`
 - **Spec**: `references/spec.md`, `references/spec-guidance.md`, `references/figure-description.md`
 - **Disclosure interview**: `references/disclosure.md`

package/skills/fenix-application/VERSION

@@ -1 +1 @@
-11
+13

package/skills/fenix-application/assets/claims_editor.html

@@ -59,7 +59,6 @@ function figBody(bd,prev,fig){
   var c1=elt("div","field"); c1.appendChild(elt("label",null,"Figure Number")); var nn=document.createElement("input"); nn.className="f-num"; nn.value=fig.number||""; c1.appendChild(nn); r.appendChild(c1);
   var c2=elt("div","field"); c2.appendChild(elt("label",null,"Type")); var sel=document.createElement("select"); sel.className="f-type"; ["Flowchart","Device","Placeholder"].forEach(function(o){ var op=document.createElement("option"); op.textContent=o; sel.appendChild(op); }); sel.value=fig.type||"Flowchart"; c2.appendChild(sel); r.appendChild(c2); bd.appendChild(r);
   var fb=elt("div","field"); fb.appendChild(elt("label",null,"Brief Description")); var bi=document.createElement("input"); bi.className="f-brief"; bi.value=fig.briefDescription||""; bi.oninput=function(){ prev.textContent=(bi.value||"").slice(0,70); }; fb.appendChild(bi); bd.appendChild(fb);
-  var fi=elt("div","field"); fi.appendChild(elt("label",null,"Introductory Sentence")); var ii=document.createElement("input"); ii.className="f-intro"; ii.value=fig.introductory||""; fi.appendChild(ii); bd.appendChild(fi);
   var lbl=elt("label",null,fig.type==="Device"?"Components":"Steps"); lbl.style.marginTop="6px"; bd.appendChild(lbl);
   var tbl=document.createElement("table"); tbl.innerHTML="<thead><tr><th style='width:70px'>#</th><th style='width:170px'>Label</th><th>Description text</th><th style='width:34px'></th></tr></thead>"; var tbody=document.createElement("tbody"); tbl.appendChild(tbody); bd.appendChild(tbl);
   var arr=(fig.type==="Device")?(fig.components||[]):(fig.steps||[]); arr.forEach(function(e){ figRow(tbody,e.number,e.label,e.text); });
@@ -78,7 +77,7 @@ window.onload=function(){ var items=toItems()||[]; if(EDITOR_TYPE==="claims"){ i
 function collect(){
   var accs=document.querySelectorAll("#acc .acc");
   if(EDITOR_TYPE==="claims"){ var out=[]; accs.forEach(function(a){ var n=a.querySelector(".c-num").value.trim(); var t=a.querySelector(".c-txt").value; var orig=a.__claim||{}; if(n||t.trim()){ out.push({ claimNumber:n, claimStatus:orig.claimStatus||"original", claimType:orig.claimType||"", claimText:t.split(/\n/), parent:orig.parent||"", independentParent:orig.independentParent||"" }); } }); return "[EDITOR SUBMIT - claims]\n"+JSON.stringify(out,null,2); }
-  if(EDITOR_TYPE==="figures"){ var figs=[]; accs.forEach(function(a){ var type=a.querySelector(".f-type").value; var isDev=(type==="Device"); var rows=Array.from(a.querySelectorAll("tbody tr")).map(function(tr){ return {type:isDev?"component":"step",number:tr.querySelector(".r-num").value.trim(),label:tr.querySelector(".r-lab").value.trim(),text:tr.querySelector(".r-txt").value.trim(),name:tr.querySelector(".r-lab").value.trim()}; }); figs.push({number:a.querySelector(".f-num").value.trim(),type:type,briefDescription:a.querySelector(".f-brief").value.trim(),introductory:a.querySelector(".f-intro").value.trim(),steps:isDev?[]:rows,components:isDev?rows:[]}); }); return "[EDITOR SUBMIT - figures]\n"+JSON.stringify(figs,null,2); }
+  if(EDITOR_TYPE==="figures"){ var figs=[]; accs.forEach(function(a){ var type=a.querySelector(".f-type").value; var isDev=(type==="Device"); var rows=Array.from(a.querySelectorAll("tbody tr")).map(function(tr){ return {type:isDev?"component":"step",number:tr.querySelector(".r-num").value.trim(),label:tr.querySelector(".r-lab").value.trim(),text:tr.querySelector(".r-txt").value.trim(),name:tr.querySelector(".r-lab").value.trim()}; }); figs.push({number:a.querySelector(".f-num").value.trim(),type:type,briefDescription:a.querySelector(".f-brief").value.trim(),steps:isDev?[]:rows,components:isDev?rows:[]}); }); return "[EDITOR SUBMIT - figures]\n"+JSON.stringify(figs,null,2); }
   var secs={}; accs.forEach(function(a){ var nm=a.querySelector(".s-name").value.trim(); var tx=a.querySelector(".s-txt").value; if(nm){ var paras=tx.split(/\n\n+/).map(function(p){return p.trim();}).filter(Boolean).map(function(p){return "<p>"+p.replace(/\n/g," ")+"</p>";}); secs[nm]={paragraphs:paras}; } }); return "[EDITOR SUBMIT - sections]\n"+JSON.stringify(secs,null,2);
 }
 function go(){ var result=collect(); var done=function(){ document.getElementById("st").textContent="\u2713 Copied  --  paste into chat."; }; if(navigator.clipboard){ navigator.clipboard.writeText(result).then(done).catch(fb); } else { fb(); } function fb(){ var el=document.createElement("textarea"); el.value=result; el.style.cssText="position:fixed;top:0;left:0;opacity:0;"; document.body.appendChild(el); el.select(); try{ document.execCommand("copy"); done(); }catch(e){ document.getElementById("st").textContent="Copy failed."; } document.body.removeChild(el); } }

package/skills/fenix-application/assets/figures_editor.html

@@ -59,7 +59,6 @@ function figBody(bd,prev,fig){
   var c1=elt("div","field"); c1.appendChild(elt("label",null,"Figure Number")); var nn=document.createElement("input"); nn.className="f-num"; nn.value=fig.number||""; c1.appendChild(nn); r.appendChild(c1);
   var c2=elt("div","field"); c2.appendChild(elt("label",null,"Type")); var sel=document.createElement("select"); sel.className="f-type"; ["Flowchart","Device","Placeholder"].forEach(function(o){ var op=document.createElement("option"); op.textContent=o; sel.appendChild(op); }); sel.value=fig.type||"Flowchart"; c2.appendChild(sel); r.appendChild(c2); bd.appendChild(r);
   var fb=elt("div","field"); fb.appendChild(elt("label",null,"Brief Description")); var bi=document.createElement("input"); bi.className="f-brief"; bi.value=fig.briefDescription||""; bi.oninput=function(){ prev.textContent=(bi.value||"").slice(0,70); }; fb.appendChild(bi); bd.appendChild(fb);
-  var fi=elt("div","field"); fi.appendChild(elt("label",null,"Introductory Sentence")); var ii=document.createElement("input"); ii.className="f-intro"; ii.value=fig.introductory||""; fi.appendChild(ii); bd.appendChild(fi);
   var lbl=elt("label",null,fig.type==="Device"?"Components":"Steps"); lbl.style.marginTop="6px"; bd.appendChild(lbl);
   var tbl=document.createElement("table"); tbl.innerHTML="<thead><tr><th style='width:70px'>#</th><th style='width:170px'>Label</th><th>Description text</th><th style='width:34px'></th></tr></thead>"; var tbody=document.createElement("tbody"); tbl.appendChild(tbody); bd.appendChild(tbl);
   var arr=(fig.type==="Device")?(fig.components||[]):(fig.steps||[]); arr.forEach(function(e){ figRow(tbody,e.number,e.label,e.text); });
@@ -78,7 +77,7 @@ window.onload=function(){ var items=toItems()||[]; if(EDITOR_TYPE==="claims"){ i
 function collect(){
   var accs=document.querySelectorAll("#acc .acc");
   if(EDITOR_TYPE==="claims"){ var out=[]; accs.forEach(function(a){ var n=a.querySelector(".c-num").value.trim(); var t=a.querySelector(".c-txt").value; var orig=a.__claim||{}; if(n||t.trim()){ out.push({ claimNumber:n, claimStatus:orig.claimStatus||"original", claimType:orig.claimType||"", claimText:t.split(/\n/), parent:orig.parent||"", independentParent:orig.independentParent||"" }); } }); return "[EDITOR SUBMIT - claims]\n"+JSON.stringify(out,null,2); }
-  if(EDITOR_TYPE==="figures"){ var figs=[]; accs.forEach(function(a){ var type=a.querySelector(".f-type").value; var isDev=(type==="Device"); var rows=Array.from(a.querySelectorAll("tbody tr")).map(function(tr){ return {type:isDev?"component":"step",number:tr.querySelector(".r-num").value.trim(),label:tr.querySelector(".r-lab").value.trim(),text:tr.querySelector(".r-txt").value.trim(),name:tr.querySelector(".r-lab").value.trim()}; }); figs.push({number:a.querySelector(".f-num").value.trim(),type:type,briefDescription:a.querySelector(".f-brief").value.trim(),introductory:a.querySelector(".f-intro").value.trim(),steps:isDev?[]:rows,components:isDev?rows:[]}); }); return "[EDITOR SUBMIT - figures]\n"+JSON.stringify(figs,null,2); }
+  if(EDITOR_TYPE==="figures"){ var figs=[]; accs.forEach(function(a){ var type=a.querySelector(".f-type").value; var isDev=(type==="Device"); var rows=Array.from(a.querySelectorAll("tbody tr")).map(function(tr){ return {type:isDev?"component":"step",number:tr.querySelector(".r-num").value.trim(),label:tr.querySelector(".r-lab").value.trim(),text:tr.querySelector(".r-txt").value.trim(),name:tr.querySelector(".r-lab").value.trim()}; }); figs.push({number:a.querySelector(".f-num").value.trim(),type:type,briefDescription:a.querySelector(".f-brief").value.trim(),steps:isDev?[]:rows,components:isDev?rows:[]}); }); return "[EDITOR SUBMIT - figures]\n"+JSON.stringify(figs,null,2); }
   var secs={}; accs.forEach(function(a){ var nm=a.querySelector(".s-name").value.trim(); var tx=a.querySelector(".s-txt").value; if(nm){ var paras=tx.split(/\n\n+/).map(function(p){return p.trim();}).filter(Boolean).map(function(p){return "<p>"+p.replace(/\n/g," ")+"</p>";}); secs[nm]={paragraphs:paras}; } }); return "[EDITOR SUBMIT - sections]\n"+JSON.stringify(secs,null,2);
 }
 function go(){ var result=collect(); var done=function(){ document.getElementById("st").textContent="\u2713 Copied  --  paste into chat."; }; if(navigator.clipboard){ navigator.clipboard.writeText(result).then(done).catch(fb); } else { fb(); } function fb(){ var el=document.createElement("textarea"); el.value=result; el.style.cssText="position:fixed;top:0;left:0;opacity:0;"; document.body.appendChild(el); el.select(); try{ document.execCommand("copy"); done(); }catch(e){ document.getElementById("st").textContent="Copy failed."; } document.body.removeChild(el); } }

package/skills/fenix-application/assets/spec_editor.html

@@ -59,7 +59,6 @@ function figBody(bd,prev,fig){
   var c1=elt("div","field"); c1.appendChild(elt("label",null,"Figure Number")); var nn=document.createElement("input"); nn.className="f-num"; nn.value=fig.number||""; c1.appendChild(nn); r.appendChild(c1);
   var c2=elt("div","field"); c2.appendChild(elt("label",null,"Type")); var sel=document.createElement("select"); sel.className="f-type"; ["Flowchart","Device","Placeholder"].forEach(function(o){ var op=document.createElement("option"); op.textContent=o; sel.appendChild(op); }); sel.value=fig.type||"Flowchart"; c2.appendChild(sel); r.appendChild(c2); bd.appendChild(r);
   var fb=elt("div","field"); fb.appendChild(elt("label",null,"Brief Description")); var bi=document.createElement("input"); bi.className="f-brief"; bi.value=fig.briefDescription||""; bi.oninput=function(){ prev.textContent=(bi.value||"").slice(0,70); }; fb.appendChild(bi); bd.appendChild(fb);
-  var fi=elt("div","field"); fi.appendChild(elt("label",null,"Introductory Sentence")); var ii=document.createElement("input"); ii.className="f-intro"; ii.value=fig.introductory||""; fi.appendChild(ii); bd.appendChild(fi);
   var lbl=elt("label",null,fig.type==="Device"?"Components":"Steps"); lbl.style.marginTop="6px"; bd.appendChild(lbl);
   var tbl=document.createElement("table"); tbl.innerHTML="<thead><tr><th style='width:70px'>#</th><th style='width:170px'>Label</th><th>Description text</th><th style='width:34px'></th></tr></thead>"; var tbody=document.createElement("tbody"); tbl.appendChild(tbody); bd.appendChild(tbl);
   var arr=(fig.type==="Device")?(fig.components||[]):(fig.steps||[]); arr.forEach(function(e){ figRow(tbody,e.number,e.label,e.text); });
@@ -78,7 +77,7 @@ window.onload=function(){ var items=toItems()||[]; if(EDITOR_TYPE==="claims"){ i
 function collect(){
   var accs=document.querySelectorAll("#acc .acc");
   if(EDITOR_TYPE==="claims"){ var out=[]; accs.forEach(function(a){ var n=a.querySelector(".c-num").value.trim(); var t=a.querySelector(".c-txt").value; var orig=a.__claim||{}; if(n||t.trim()){ out.push({ claimNumber:n, claimStatus:orig.claimStatus||"original", claimType:orig.claimType||"", claimText:t.split(/\n/), parent:orig.parent||"", independentParent:orig.independentParent||"" }); } }); return "[EDITOR SUBMIT - claims]\n"+JSON.stringify(out,null,2); }
-  if(EDITOR_TYPE==="figures"){ var figs=[]; accs.forEach(function(a){ var type=a.querySelector(".f-type").value; var isDev=(type==="Device"); var rows=Array.from(a.querySelectorAll("tbody tr")).map(function(tr){ return {type:isDev?"component":"step",number:tr.querySelector(".r-num").value.trim(),label:tr.querySelector(".r-lab").value.trim(),text:tr.querySelector(".r-txt").value.trim(),name:tr.querySelector(".r-lab").value.trim()}; }); figs.push({number:a.querySelector(".f-num").value.trim(),type:type,briefDescription:a.querySelector(".f-brief").value.trim(),introductory:a.querySelector(".f-intro").value.trim(),steps:isDev?[]:rows,components:isDev?rows:[]}); }); return "[EDITOR SUBMIT - figures]\n"+JSON.stringify(figs,null,2); }
+  if(EDITOR_TYPE==="figures"){ var figs=[]; accs.forEach(function(a){ var type=a.querySelector(".f-type").value; var isDev=(type==="Device"); var rows=Array.from(a.querySelectorAll("tbody tr")).map(function(tr){ return {type:isDev?"component":"step",number:tr.querySelector(".r-num").value.trim(),label:tr.querySelector(".r-lab").value.trim(),text:tr.querySelector(".r-txt").value.trim(),name:tr.querySelector(".r-lab").value.trim()}; }); figs.push({number:a.querySelector(".f-num").value.trim(),type:type,briefDescription:a.querySelector(".f-brief").value.trim(),steps:isDev?[]:rows,components:isDev?rows:[]}); }); return "[EDITOR SUBMIT - figures]\n"+JSON.stringify(figs,null,2); }
   var secs={}; accs.forEach(function(a){ var nm=a.querySelector(".s-name").value.trim(); var tx=a.querySelector(".s-txt").value; if(nm){ var paras=tx.split(/\n\n+/).map(function(p){return p.trim();}).filter(Boolean).map(function(p){return "<p>"+p.replace(/\n/g," ")+"</p>";}); secs[nm]={paragraphs:paras}; } }); return "[EDITOR SUBMIT - sections]\n"+JSON.stringify(secs,null,2);
 }
 function go(){ var result=collect(); var done=function(){ document.getElementById("st").textContent="\u2713 Copied  --  paste into chat."; }; if(navigator.clipboard){ navigator.clipboard.writeText(result).then(done).catch(fb); } else { fb(); } function fb(){ var el=document.createElement("textarea"); el.value=result; el.style.cssText="position:fixed;top:0;left:0;opacity:0;"; document.body.appendChild(el); el.select(); try{ document.execCommand("copy"); done(); }catch(e){ document.getElementById("st").textContent="Copy failed."; } document.body.removeChild(el); } }

package/skills/fenix-application/references/claim1-method-drafting.md

@@ -0,0 +1,110 @@
+# Method Claim 1 Drafting Guide
+
+**Version: 13**
+
+House style for drafting an **independent method claim 1**, especially for AI/ML
+inventions. Use this whenever you draft a method independent claim. (Apparatus/CRM/
+system independents mirror this claim, moving hardware into those claims only.)
+
+## The canonical skeleton
+Every claim 1 is **one sentence**, three steps:
+
+```
+1. A method for [broad field], comprising:
+   obtaining [input artifact(s)], wherein [definitional clause establishing antecedents];
+   generating, using a [named model], [novel intermediate artifact] based on [input(s)],
+       wherein [clause that carries the inventive distinction]; and
+   generating, using a [named model], a synthetic [output] based on [intermediate artifact],
+       wherein the synthetic [output] [nexus clause tying output to the target/input].
+```
+
+Worked exemplar (the cleanest instance):
+```
+1. A method for media generation, comprising:
+   obtaining an input video depicting an object and a target three-dimensional (3D) point
+       track indicating a target motion of the object;
+   generating, using a 3D conditioning model, a two-dimensional (2D) motion guidance based
+       on the target 3D point track; and
+   generating, using a media generation model, a synthetic video based on the input video
+       and the 2D motion guidance, wherein the synthetic video depicts the object with the
+       target motion.
+```
+
+## Preamble
+- Minimal, generic field-of-use: `A method for [two-word field], comprising:` — or the barest `A method comprising:` when a field label adds nothing. Training claims: `A method for training a machine learning model, comprising:`.
+- **Never** put purpose, advantage, problem, or intended-result language in the preamble (it gives the examiner a claim-construction hook and does no limiting work).
+- Do not repeat "the method" before "comprising."
+
+## Step architecture (the job of each limitation)
+- **Step 1 -- obtaining (context, never novelty).** Always first, always the gerund "obtaining," always conventional. Introduces every input artifact/parameter the later steps need, with a `wherein` defining them and locking relationships (e.g. "wherein the first image and the second image depict a same scene from different perspectives"). It must create an antecedent for everything later steps reference -- and nothing more. **If a step-1 element is never used again, delete it.**
+- **Step 2 (optionally 3) -- transformation (all of the novelty).** Creates the **one novel intermediate artifact** that distinguishes the invention. Keep the verb phrase generic ("generating, using a [model],"); the inventive content rides in the **object of the verb + its `wherein` clause**. Coin a name for the artifact, define it in the `wherein`, and make the spec use the same name verbatim. *If you cannot state the novelty as a single intermediate artifact + one `wherein`, the invention is not yet distilled -- keep working before drafting.*
+- **Final step -- tangible result (detectability, never novelty).** Produces a concrete, observable output (synthetic video/image/media item, 3D model, trained model) and closes with a **nexus `wherein`** tying the output back to the target parameter from step 1 (e.g. "wherein the synthetic video depicts the object with the target motion"). The nexus clause does three jobs: makes infringement detectable from the output alone, supplies the §101 technical-result anchor, and stitches the claim into one story. **Do not omit it.**
+- **Step-count discipline.** Three steps is the default. Four only when there are genuinely two transformations or a required UI act. More steps = more non-infringement arguments; six steps is a known failure mode.
+
+## Wherein clauses (the workhorse of the style)
+The style works through `wherein` clauses on steps, not extra steps. Exactly three sanctioned uses:
+- **(a) Definitional** -- defines a coined term at first use ("wherein the modification plan comprises structured editing text including a plurality of steps..."). Substitutes for a glossary; blocks a narrower spec import.
+- **(b) Inventive-distinction** -- carries the point of novelty inside an otherwise generic step ("wherein each of the first attention output and the second attention output is based on both the first prompt and the second prompt"). Keeps the verb broad while making the distinction explicit for §102/§103.
+- **(c) Nexus/result** -- the closing clause above. States what the output *is* ("depicts," "has"), never what the method *achieves* (no "thereby improving...").
+
+Stacking is bounded: **≤3 `wherein` clauses total** across the claim. More reads like a spec paragraph -- push the rest to dependents. **Never smuggle a step into a `wherein`** ("wherein the system then transmits...") -- steps are steps.
+
+## Verb set (deliberately tiny)
+`obtaining` (always step 1) · `generating` (every transformation and output step) · `training` (training claims) · `encoding` (only where the encoding itself is inventive) · and sparingly `identifying`, `selecting`, `creating`, `causing display of`. That is the whole set.
+Every verb must be: a present participle; performable by a **single software actor**; free of implied hardware, sequence, or location. **Resist domain verbs** in claim 1 -- no "synthesizing," "inferring," "denoising," "rendering," "transmitting," "segmenting," "concatenating." If a specific operation matters, it goes in a **dependent**.
+
+## Lexicon (use / instead of / why)
+- `obtaining` not `receiving`/`getting` -- actor- and source-neutral (covers receive, retrieve, or generate internally; "receiving" invites divided-infringement arguments).
+- `generating` not `creating`/`computing`/`calculating` -- reads on any way of bringing the artifact into existence.
+- `based on` not `in response to`/`as a function of`/`using only` -- boilerplate makes it "based at least in part on," so the causal link stays open; "in response to" adds an unwanted timing limitation.
+- `using a [name] model` (participial, comma-set-off) not `by a processor`/`via` -- attributes the step to a model without adding a hardware actor. **No "by a processor" in method claims** -- hardware lives in the system claim.
+- `synthetic [image/video/media item]` not `output`/`result`/`modified X` -- a concrete, detectable thing distinct from the input.
+- `input [video/prompt/media item]` not `received X`/`original X` -- standard term for step-1 artifacts.
+- `target [style/motion/shape/camera path]` not `desired`/`intended`/`specified` -- "desired/intended" is subjective-intent profanity; "target" is objective and pairs with the nexus clause.
+- `first / second` not `a plurality of` (in claim 1) -- enumerate when two artifacts need separate downstream handling; save "a plurality of" for dependents.
+- `indicating` / `representing` / `depicting` not `containing`/`encoding`/`describing` -- an input *indicates* a parameter, a token/embedding *represents* content, an image/video *depicts* subject matter.
+- `causing display of` not `displaying` -- keeps the claim infringeable by a server that never renders pixels.
+
+Spell out then abbreviate dimensional terms on first use ("three-dimensional (3D) point track"), then use the abbreviation. Per the firm's patent-safe rules, claim 1 contains **no absolutes** (always, only, must), **no subjective intent** (designed to, intended to), and **no novelty talk**. Always cross-check `references/patent-safe.md`.
+
+## Length, breadth, element budget
+- **Length: 60-120 words.** Below ~60 it usually fails to recite the distinction; above ~120 you are paying scope for words that belong in dependents.
+- **Element budget: 4-8 coined noun phrases** (inputs, parameters, models, intermediates, outputs). Introduce a noun only if a later limitation uses it. **Name at most two models** (one conditioning/auxiliary, one generation).
+- **Breadth is achieved by what is absent:** no hardware, no numeric thresholds, no data formats, no ordering language ("then," "after"), no user, no network, no second actor. **Single-actor test:** if any step could be performed by a customer while another is performed by the vendor, redraft until one party running software does everything.
+
+## Naming & antecedent discipline
+- Introduce every artifact with "a/an" exactly once, thereafter always "the."
+- Enumerate parallel artifacts as "a first X and a second X" in the **same obtaining step** so both antecedents exist before either is used.
+- Keep coined names **rigidly identical** -- "the combined sequence of tokens" never becomes "the token sequence."
+- After any edit, **re-trace every "the" back to its "a."** Most defects are antecedent failures introduced by editing without re-checking the chain.
+
+## Anti-patterns (do not)
+1. Put hardware in the method claim ("by a processor-based system" on every step).
+2. Recite numeric limits in claim 1 (a published design-around invitation).
+3. Let the preamble promise a benefit.
+4. Let the preamble outrun the body (e.g. a "media generation" preamble over an all-audio body -- pick "audio generation" or generalize the body).
+5. Hard-code an embodiment choice in an independent that a dependent then varies.
+6. Duplicate dependents across the set.
+7. Leave step-1 elements unused by later steps.
+
+## Drafting procedure
+1. **Name the novel intermediate artifact first.** State it as "the insight is [artifact] built from [inputs] that lets [model] produce [output]." If you can't, return to the disclosure.
+2. **Draft the middle step** around that artifact: "generating, using a [model], [artifact] based on [input], wherein [the distinction]." Coin the name here; this `wherein` is where novelty lives.
+3. **Draft the final step:** "generating, using a [generation model], a synthetic [output] based on [artifact]," + the nexus `wherein` tying the output to the target parameter.
+4. **Draft the obtaining step last:** collect every input/parameter the other steps referenced, introduce each with "a/an," add one definitional `wherein`. Delete anything not used downstream.
+5. **Choose the preamble:** "A method for [two-word field], comprising:" -- or "A method comprising:" if a field label limits nothing.
+6. **Audit against the budgets:** ≤4 steps, ≤120 words, ≤8 coined nouns, ≤3 `wherein` clauses, 0 hardware, 0 numbers, 0 second actors, verbs from the set above. Anything over budget moves to a dependent.
+7. **Re-trace antecedents end to end,** then draft dependents by re-opening the step verbs ("wherein obtaining the [X] comprises:" / "further comprising:"), one concept per dependent.
+8. **Sweep against `references/patent-safe.md`** (no absolutes, intent, or novelty talk) and confirm the spec uses the claim's coined terms verbatim.
+
+## Fill-in template
+```
+1. A method for [field], comprising:
+   obtaining [a first input] and [a second input / a parameter], wherein [the input(s)]
+       [depict(s)/indicate(s)] [relationship or target];
+   generating, using a [conditioning/auxiliary model], [the novel intermediate artifact]
+       based on [the input(s)], wherein [the artifact] [the inventive distinction]; and
+   generating, using a [generation model], a synthetic [output] based on [the first input]
+       and [the intermediate artifact], wherein the synthetic [output] [depicts/has] [the
+       target] [indicated by the parameter].
+```

package/skills/fenix-application/references/claims.md

@@ -1,12 +1,14 @@
 # Claims Workflow
 
-**Version: 11**
+**Version: 13**
 
 ## Before drafting
 Read `references/patent-safe.md` for language guidelines.
+**For an independent METHOD claim 1 (especially AI/ML inventions), read `references/claim1-method-drafting.md`** -- the house style: the 3-step canonical skeleton (obtaining -> transformation -> tangible result), the `wherein`-clause rules, the verb set + lexicon, the word/element/length budgets, antecedent discipline, anti-patterns, and a step-by-step drafting procedure + fill-in template. Apply it when drafting any method independent claim.
 
 ## One claim at a time
 (a) Draft -> (b) show -> ask "Does Claim N look right?"  --  **END TURN** -> (c) after reply: revise or move to next
+**Do NOT save after each claim** -- it is slow. Accumulate the confirmed claims and **save the whole set once** at the end of the pass (see Save below).
 
 ## Order
 First independent -> its dependents -> next independent -> its dependents

package/skills/fenix-application/references/editors.md

@@ -1,6 +1,6 @@
 # Editors — how to drive them
 
-**Version: 11**
+**Version: 13**
 
 This skill ships three accordion HTML editors in `assets/`. **You never need to open or read the editor HTML** — everything you need to pre-fill and read them back is below.
 
@@ -30,14 +30,15 @@ Output: `[EDITOR SUBMIT - claims]` then a JSON array of the same schema. Strip t
 INITIAL_CONTENT = array of figure objects:
 ```
 [
-  { "number": "1", "type": "Flowchart", "briefDescription": "...", "introductory": "...",
+  { "number": "1", "type": "Flowchart", "briefDescription": "...",
     "steps": [ { "number": "100", "label": "receive", "text": "receiving a request" } ], "components": [] },
-  { "number": "2", "type": "Device", "briefDescription": "...", "introductory": "...",
+  { "number": "2", "type": "Device", "briefDescription": "...",
     "steps": [], "components": [ { "number": "200", "label": "processor", "text": "a processor" } ] }
 ]
 ```
 - `type` is "Flowchart" | "Device" | "Placeholder".
 - Flowchart figures use `steps`; Device figures use `components`. Each row is `{ number, label, text }`.
+- There is no per-figure introductory-sentence field. The figure's introductory/opening sentence is generated from its `briefDescription` during spec drafting — do not collect or pass it.
 Output: `[EDITOR SUBMIT - figures]` then a JSON array of figure objects. Strip the prefix; call `save_project({ type: "figures", figures: [...] })`.
 
 ## spec_editor.html

package/skills/fenix-application/references/figure-description.md

@@ -1,6 +1,6 @@
 # Figure Description Protocol
 
-**Version: 11**
+**Version: 13**
 
 You are a patent drafting assistant. Your task is to write a detailed textual description of a figure (e.g., FIG. 1) for inclusion in the Detailed Description section of a patent application.
 

package/skills/fenix-application/references/figures-guidance.md

@@ -1,6 +1,6 @@
 # Figures Guidance
 
-**Version: 11**
+**Version: 13**
 
 ## Figure List
 

package/skills/fenix-application/references/figures.md

@@ -1,6 +1,6 @@
 # Figures Workflow
 
-**Version: 11**
+**Version: 13**
 
 ## Phase 1  --  List
 1. `get_project({ projectId, include: ["figures"] })`  --  note ALL figures including Placeholders
@@ -11,7 +11,8 @@
 
 ## Phase 2  --  Content (one figure at a time)
 Skip Placeholders (type="Placeholder" or empty steps/components).
-For each: read `references/figures-guidance.md` -> generate -> show  --  **END TURN** -> confirm -> `save_project({ type: "figure", figure })`
+For each: read `references/figures-guidance.md` -> generate -> show  --  **END TURN** -> confirm, then move to the next figure.
+**Do NOT save after each figure** -- it is slow. Accumulate the confirmed figures and **save the whole set once** at the end of the pass with `save_project({ type: "figures", figures: allFigures })` (include every figure, existing + new).
 
 ## Numbering
 - Flowchart steps: 100, 105, 110...
@@ -22,7 +23,8 @@ For each: read `references/figures-guidance.md` -> generate -> show  --  **END T
 `{ type, label, number, text, name, action, angle, flipX, flipY }`
 
 ## Editor (accordion)
-**Always ask the user whether they want to open the figures editor to review/edit all figures at once** -- e.g. "Want me to open the figures editor so you can review them all together?" Only open it if they say yes. To open it, open `assets/figures_editor.html` with `INITIAL_CONTENT` set to the full figures JSON array. Each figure is a collapsible accordion item; opening one reveals its number, type, brief, intro, and a steps/components table with add/remove rows. The user can also add/remove whole figures. On `[EDITOR SUBMIT - figures]`, strip the prefix and call `save_project({ type: "figures", figures: [...] })` with the returned array.
+**Always ask the user whether they want to open the figures editor to review/edit all figures at once** -- e.g. "Want me to open the figures editor so you can review them all together?" Only open it if they say yes. To open it, open `assets/figures_editor.html` with `INITIAL_CONTENT` set to the full figures JSON array. Each figure is a collapsible accordion item; opening one reveals its number, type, brief description, and a steps/components table with add/remove rows. There is no introductory-sentence field -- the figure's introductory/opening sentence is generated from its brief description during spec drafting. The user can also add/remove whole figures. On `[EDITOR SUBMIT - figures]`, strip the prefix and call `save_project({ type: "figures", figures: [...] })` with the returned array.
 
 ## After all figures
 Run `scripts/calculate_figure_layout.py` with the figures JSON -> check `warnings` array and `readyToPrint` flag. **Do NOT print automatically.** Only call `print_patent(type=drawings)` if the user explicitly asks for the drawings file. After figures are saved and the layout is clean, simply tell the user the figures are ready and ask whether they want the drawings file generated.
+**When you do run `print_patent(type=drawings)`, always show the user the returned download URL/link in your reply** -- do not run the print silently. Surface the link (e.g. "Drawings ready: <url>") so they can open it.

package/skills/fenix-application/references/patent-review.md

@@ -1,6 +1,6 @@
 # Patent Application Review
 
-**Version: 11**
+**Version: 13**
 
 Structured pre-filing review. Catches structural defects, malformed claims, patent profanity, and missing spec support.
 

package/skills/fenix-application/references/patent-safe.md

@@ -1,6 +1,6 @@
 # Patent Language Guidelines
 
-**Version: 11**
+**Version: 13**
 
 This file is the single source of truth for Fenix patent language and profanity rules.
 Both the patent drafting workflow (references/claims.md) and the patent review workflow (references/patent-review.md) reference this file for profanity guidance.

package/skills/fenix-application/references/patent.md

@@ -1,13 +1,13 @@
 # Patent Drafting Workflow
 
-**Version: 11**
+**Version: 13**
 
 ## Phase overview
-- **Phase 1  --  Claims**: Read `references/claims.md` from the fenix-application skill -> one-by-one -> `save_project(type=claims)`
-- **Phase 2  --  Figures**: `save_project(type=figures)` list -> `save_project(type=figure)` per figure -> run `scripts/calculate_figure_layout.py` (pipe figure JSON) -> check warnings. Only run `print_patent(type=drawings)` if the user explicitly asks for the drawings file.
-- **Spec**: `get_project({ projectId, include: ["claims","figures","sections"] })` -> generate each section (see `references/spec.md`) -> `save_project(type=section)` per section. Only run `print_patent(type=spec)` if the user explicitly asks for the spec document.
+- **Phase 1  --  Claims**: Read `references/claims.md` -> draft one-by-one (confirm each) -> save the whole set **once** at the end with `save_project(type=claims)`. Do not save after each claim.
+- **Phase 2  --  Figures**: agree the figure list (`save_project(type=figures)`), then draft each figure's content one-by-one (confirm each) and save the whole set **once** at the end with `save_project(type=figures)`. Do not save per figure. Then run `scripts/calculate_figure_layout.py` (pipe figure JSON) -> check warnings.
+- **Spec**: `get_project({ projectId, include: ["claims","figures","sections"] })` -> generate each section (see `references/spec.md`) -> `save_project(type=section)` per section as the user confirms it.
 
-**Do not print (generate a document/file) automatically.** Printing is a separate, explicit step -- only call `print_patent` when the user asks for the drawings, the spec document, or an export.
+**Do not print (generate a document/file) automatically.** Printing is a separate, explicit step -- only call `print_patent` when the user asks for the drawings, the spec document, or an export. **After any `print_patent` call, always show the returned download URL/link in your reply** -- never run a print and leave the result unshown.
 
 ## Intake
 1. Matter  --  `get_project({ identifier })` (exact) or `get_project({ query })` (keyword search)
@@ -15,4 +15,6 @@
 3. Disclosure  --  user describes or run `references/disclosure.md` interview
 4. Phase  --  ask which to start
 
+**Use the imported data as-is -- do NOT drop or stub any of it.** When a template/source is imported, the response carries real figure data (brief descriptions, components, stencils/placeholders, steps, numbering) and sections. Carry every field through to `save_project` exactly as imported; only fill in genuinely missing pieces. Never replace an imported brief description, component list, stencil/placeholder, or section with a placeholder, an old stub, or invented content. If a field looks empty, confirm with the user rather than substituting a stub.
+
 Call `save_project(name, disclosure, templateId|sourceProjectId)` after intake.

package/skills/fenix-application/references/spec-guidance.md

@@ -1,6 +1,6 @@
 # Spec Section Guidance
 
-**Version: 11**
+**Version: 13**
 
 ## Background
 

package/skills/fenix-application/references/spec.md

@@ -1,6 +1,6 @@
 # Spec Drafting Workflow
 
-**Version: 11**
+**Version: 13**
 
 ## Start
 `get_project({ projectId, include: ["claims","figures","sections"] })`  --  loads claims, figure list, and any previously saved sections.
@@ -31,8 +31,9 @@ Summarize claim 1: what it does, the key technical mechanism, and the tangible o
 ### Per-figure Detailed Description (Figure N sections)
 Read `references/figure-description.md` for the full protocol. Key rules:
 - At least two paragraphs per figure.
-- Flowchart: opening paragraph -> one paragraph per step ("In block [number], the process includes [step text].").
-- Device: opening paragraph introducing components -> one paragraph per component ("The [label] [number] [action/description].").
+- **The opening/introductory paragraph is generated from the figure's `briefDescription`** (there is no separate per-figure introductory field). e.g. "FIG. [N] [shows/illustrates] [briefDescription]. ..."
+- Flowchart: opening paragraph (from brief description) -> one paragraph per step ("In block [number], the process includes [step text].").
+- Device: opening paragraph (from brief description) introducing components -> one paragraph per component ("The [label] [number] [action/description].").
 - Reference each component by number on first mention.
 - Skip Placeholder/stencil figures (type="Placeholder" or empty steps/components).
 
@@ -45,4 +46,4 @@ Read `references/spec-guidance.md` for the drafting prompt for each section.
 ## Notes
 - Claims are already saved  --  do not include them as a section here.
 - For the one-at-a-time flow, use `save_project(type=section)` directly after the user confirms each section. For a full review pass, use the accordion editor above and save all at once with `save_project(type=sections)`.
-- **Do NOT print automatically.** After all sections are saved, tell the user the specification is complete and ask whether they want the Word document generated. Only call `print_patent(type=spec)` when the user explicitly asks for it.
+- **Do NOT print automatically.** After all sections are saved, tell the user the specification is complete and ask whether they want the Word document generated. Only call `print_patent(type=spec)` when the user explicitly asks for it. **When you do, show the returned download URL/link in your reply** (e.g. "Specification ready: <url>") -- never run the print and leave the result unshown.

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

@@ -1,12 +1,12 @@
 ---
 name: fenix-office-action
 description: >-
-  Office action response workflow: identify matter, verify or create project, generate OA response shell.
+  Office action response workflow: identify matter, populate the OA from USPTO, pull the cited references, analyze the rejections, and draft amendments and remarks (attorney-approved), then generate the OA response shell.
 ---
 
 # Fenix Office Action
 
-**Skill version: 1** (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
 
@@ -27,14 +27,32 @@ Apply the custom overrides **only as long as the result still satisfies every st
 Custom instructions may freely change tone, phrasing, default counts, section preferences, review emphasis, and similar. If a custom instruction would break a required format, follow the default format and tell the user which customization could not be applied and why.
 
 ## Contents
-- `references/oa-response.md`  --  step-by-step OA response workflow
+- `references/oa-response.md`  --  the end-to-end 7-phase OA response workflow (read this first)
+- `references/oa-analysis.md`  --  rejection analysis: classify each rejection, choose amend vs. argue, map claim elements against the cited art
+- `references/oa-drafting.md`  --  how to draft and save amendments and remarks (claim-status conventions + exact save contracts)
 
 ## When to use this skill
 
-Trigger whenever the user wants to generate an office action response shell or start working on an OA response:
+Trigger whenever the attorney wants to respond to an Office Action:
 - "office action response" / "OA response" / "respond to office action"
-- "generate the OA shell" / "set up a new OA project" / "we got an office action"
+- "we got an office action" / "set up a new OA project" / "generate the OA shell"
 
 ## How to use
 
-Read `references/oa-response.md` for the complete 4-step workflow: identify matter -> check for existing project -> create project if needed -> generate shell with `print_patent(type=oa_shell)`.
+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.
+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.**
+5. Draft + save amendments (`references/oa-drafting.md`). **Attorney approval before saving.**
+6. Draft + save remarks (`references/oa-drafting.md`). **Attorney approval before saving.**
+7. Assemble the response document: `get_oa_shell_doc` returns the formatted shell as base64; fill it with your docx skill (see `references/oa-drafting.md`). `print_patent({ type: "oa_shell" })` still returns just the blank shell link if that is all that is wanted.
+
+## Invariants
+
+- **Never pass `clientDb`**  --  it is inferred from the API key.
+- **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.
+- **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 @@
-1
+4

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

@@ -0,0 +1,103 @@
+# Office Action Rejection Analysis
+
+**Version: 4**
+
+This file is how you turn the imported `oa_data` into a response strategy. The method is **classify → select → fill**:
+
+1. **Classify** each rejection into a sub-type (not just the statute, but *which kind* of §101/§103/§112 rejection).
+2. **Select** the response approach and, where applicable, the matching argument scaffold below.
+3. **Fill** the scaffold from the project's `oa_data`, `claims`, and the cited references' disclosure text.
+
+Then present the per-rejection strategy to the attorney and **stop for approval before drafting** (Phase 5). Defaults below are recommendations — the attorney decides amend vs. argue.
+
+## Reading the data
+
+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`).
+- `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`.
+
+Always ground citations in the live MPEP (https://www.uspto.gov/web/offices/pac/mpep/index.html) — pull the current section text rather than relying on memory, since guidance changes.
+
+## Start every analysis with an overview and a claim-1 map
+
+Before working rejection-by-rejection, orient the attorney with two things:
+
+1. **Invention overview (1 paragraph).** A single tight paragraph: what the invention is and the problem it solves, drawn from the claims and the specification.
+
+2. **Claim 1 limitation table.** Map each limitation of independent claim 1 to the art the examiner applied and your validity read:
+
+   | Claim 1 limitation | Examiner's cited reference + location | Does the cited part actually disclose the limitation? (valid / questionable / no — why) |
+   |---|---|---|
+   | _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.
+
+Present the overview + table to the attorney, then proceed to the per-rejection analysis below.
+
+## §101 — Subject-matter eligibility (MPEP 2106)
+
+**Classify** the rejection into the Alice/Mayo step it turns on, and the abstract-idea grouping it asserts:
+- **Mental process** — steps that could be performed in the human mind (MPEP 2106.04(a)(2)(III)).
+- **Mathematical concept** — a formula/calculation (MPEP 2106.04(a)(2)(I)).
+- **Organizing human activity** — commercial/legal interactions, managing behavior (MPEP 2106.04(a)(2)(II)).
+
+**Default strategy:** argue eligibility first (Step 2A prong 1 — not directed to the exception; prong 2 — integrated into a practical application), and optionally amend to recite the technical improvement concretely. Argument scaffolds:
+
+- **Step 2A prong 2 — practical application / technical improvement:** identify the concrete improvement the claim provides and tie it to the specification. Frame the improvement at the system level (e.g. reduced latency, memory utilization, power, processing cycles, accuracy). *Enfish* (improvement to computer functionality itself) and *Core Wireless* (specific improved interface) are anchor cases for "improvement," not "abstract idea."
+- **Step 2B — not well-understood, routine, conventional:** under *Berkheimer*, the examiner must support a WURC finding with a record citation (spec statement, court decision, publication, or official notice — MPEP 2106.05(d)). If they did not, say so.
+
+**AI-specific (see the AI Patenting Handbook):** For AI inventions, push the practical-application argument by (1) showing the claim is not merely a mental process automated by a computer, (2) connecting the AI output to a system-level technical improvement, and (3) avoiding framing limitations with mental-process verbs (predict/identify/evaluate) where a more technical framing is accurate. Training-claim limitations can help eligibility but watch enforceability. Consult the handbook's §101 prosecution section (mental-process, organizing-human-behavior, mathematical-concept rejections) for the current USPTO study insights.
+
+## §102 — Anticipation (MPEP 2131)
+
+**Default strategy:** distinguish the single reference, or amend to add a distinguishing element with spec support.
+
+**Element-by-element mapping (required):** A §102 rejection fails if the single reference does not disclose **every** element of the claim, arranged as claimed. Using the reference's `plainText`:
+1. List each element/limitation of the rejected independent claim.
+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.
+
+## §103 — Obviousness (MPEP 2141–2145)
+
+**Classify** the weakest point of the combination and **select** the matching scaffold:
+- **No articulated reasoning / no motivation to combine (MPEP 2142–2144, KSR):** a rejection needs "articulated reasoning with rational underpinning" (*In re Kahn*, *KSR*). If the OA gives only a conclusory motivation, argue it is insufficient.
+- **References teach away / contradict each other:** if combining the references defeats a reference's stated purpose, the combination is improper.
+- **Missing element:** if no cited reference (alone or combined) teaches a particular limitation, there is no prima facie case (*In re Royka* — all limitations must be taught/suggested).
+- **Improper hindsight (MPEP 2145(X)(A)):** if the only place the motivation appears is the applicant's own specification, the combination is impermissible hindsight.
+- **Apparatus — structure vs. function (MPEP 2114):** for apparatus claims, argue the prior-art structure does not inherently possess the functionally-defined limitations (*In re Schreiber*).
+- **Official notice (MPEP 2144.03):** if the examiner took official notice of a fact not "capable of instant and unquestionable demonstration," traverse it.
+
+**Default strategy:** attack the combination on its weakest point above; or amend around it. Do the same element-by-element mapping as §102 across the combination, citing each reference's `plainText`.
+
+## §112 — Disclosure and definiteness
+
+- **§112(a) written description / enablement (MPEP 2161–2164):** default amend toward what the spec supports; argue with citation to the supporting paragraphs. Flag any amendment that risks **new matter**.
+- **§112(b) indefiniteness / antecedent basis (MPEP 2171–2174):** default amend to cure (add antecedent basis, clarify the term). Argue only where the term is definite in context, citing the spec.
+- **§112(f) means-plus-function (MPEP 2181–2186):**
+  - If the OA *interprets* a non-"means" term under §112(f) and you disagree, argue the term is not a generic placeholder (it connotes structure) — compare to terms courts found not to invoke §112(f) ("circuit," "detent mechanism," etc., MPEP 2181.I.A).
+  - If §112(f) applies and the OA says the spec lacks corresponding structure/algorithm, point to the specification's algorithm(s)/paragraphs that perform the function (*Net MoneyIN*).
+
+## Restriction / election (MPEP ch. 800)
+
+If `claim_dispositions.restriction_or_election` is populated: elect a group (with or without traverse). If traversing, argue the groups are not independent/distinct or that examining them together is not an undue search burden (MPEP 803, 806, 818).
+
+## Double patenting (MPEP 804)
+
+Require the examiner to make the claim-by-claim showing 804 demands (identify the specific pair of claims, the differences, and the obviousness/anticipation showing). A bulk or conclusory double-patenting statement is not a proper rejection. Consider a terminal disclaimer only on the attorney's instruction.
+
+## Objections and procedural items
+
+- **Claim objections / objected claims:** address formally; if a claim is "allowable but for its dependency," note it will be rewritten in independent form.
+- **Title objection:** propose an amended, descriptive title.
+- **Improper final rejection:** if the final action does not address the claims as previously amended, request withdrawal of finality.
+- **Allowed claims:** confirm them in the remarks; do not amend.
+
+## Output of this phase
+
+For each rejection, produce: the sub-type, the recommended approach (amend / argue / both), the affected claims, the references involved, and the gist of the argument (with the element gap for §102/§103). Record nothing yet — present to the attorney for approval first.

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

@@ -0,0 +1,104 @@
+# Office Action Response Drafting & Save Contracts
+
+**Version: 4**
+
+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).
+
+## 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" })` |
+
+## Save efficiently — batch in ONE call
+
+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:
+
+```
+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
+  ]
+})
+```
+
+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.
+
+## 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:
+
+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> } })`.
+
+Never send a partial `oa_data`.
+
+## 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
+
+`save_project({ type: "claims", claims: [ ... ] })` where each claim is:
+
+```
+{ claimNumber: "1", claimStatus: "Currently Amended", claimType: "independent",
+  claimText: ["...limitation...", "...limitation..."], parent: "", independentParent: "" }
+```
+
+- 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`.
+
+**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.
+
+## Saving the amendment bookkeeping
+
+Populate `oa_data.amendmentsStatus` (read-merge-write the full `oa_data`):
+
+```
+amendmentsStatus: {
+  amend: [<claim numbers currently amended>],
+  canx:  [<claim numbers canceled>],
+  added: [<new claim numbers>],
+  pending_claims: [<all claim numbers pending after this response>],
+  pending_claims_ind: [<the independent claim numbers among those>]
+}
+```
+
+## 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):
+- `response_strategy`: `"amend"` | `"argue"` | `"both"`.
+- `argument`: the drafted argument prose for that rejection.
+
+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.).
+
+## Saving the remarks
+
+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.
+
+## Remarks structure (recommended)
+
+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.
+
+Always confirm the full remarks with the attorney before saving.
+
+## 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.

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

@@ -1,10 +1,58 @@
 # Office Action Response Workflow
 
-**Version: 1**
+**Version: 4**
 
-Read this before generating an OA response shell.
+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.
 
-1. **Identify matter**  --  `get_project({ identifier })` (exact app/matter number) or `get_project({ query })` (keyword). Confirm with user.
-2. **Check for existing project**  --  the `get_project` response includes a 'projects' array. Look for a project with an OA-response type. If one exists, use its ID.
-3. **Create project if none exists**  --  'list_project_types', collect notification date, due date, and assignee initials, then 'create_project'.
-4. **Generate shell**  --  `print_patent({ type: "oa_shell", projectId })` fetches the latest USPTO documents (soft-fail if unavailable) and generates the Word OA response shell. Returns a download URL.
+## 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.
+- **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.
+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"] })`.
+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):
+   - **`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.)
+   - **`ocr_text`** — captured OCR `text`; use as-is.
+   - **`none`** — ask the attorney for the passages (last resort; see `note`).
+3. Pull text only for the references you need — not all of them. Never draft a §102/§103 distinction that relies on a reference whose text you could not obtain. Do not fabricate reference contents.
+
+## Phase 4 — Analyze the rejections
+
+Read `references/oa-analysis.md`. For each rejection, classify it into a sub-type, propose a default strategy (amend / argue / both), and — for §102/§103 — map each claim element against the cited reference's disclosure text. **Present the per-rejection strategy to the attorney and stop for approval before drafting.**
+
+## 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`.
+
+## Phase 6 — Draft and save the remarks
+
+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`.
+
+## Phase 7 — Assemble the response document
+
+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):
+
+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.
+
+(If the attorney only wants the blank shell, `print_patent({ type: "oa_shell" })` still returns just the download link.)

package/skills/fenix-project/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: fenix-project
 description: >-
-  Project creation and management: form-based intake, assignee verification, confirmation flow.
+  Project creation and management: form-based intake (pass assignee initials directly; the backend resolves them) and confirmation flow.
 ---
 
 # Fenix Project
 
-**Skill version: 1** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+**Skill version: 2** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
 
 ## Triggers
 
@@ -27,7 +27,7 @@ Apply the custom overrides **only as long as the result still satisfies every st
 Custom instructions may freely change tone, phrasing, default counts, section preferences, review emphasis, and similar. If a custom instruction would break a required format, follow the default format and tell the user which customization could not be applied and why.
 
 ## Contents
-- `references/create-project.md`  --  project creation intake workflow (assignee verification, field collection, confirmation, create)
+- `references/create-project.md`  --  project creation intake workflow (field collection, confirmation, create; assignee resolved from initials by the backend)
 
 ## When to use this skill
 
@@ -38,4 +38,4 @@ Trigger whenever the user wants to create a new project in Fenix:
 
 ## How to use
 
-Read `references/create-project.md` for the 4-step intake flow: verify assignee -> collect five fields (matter/app number, notification date, project type, due date, assignee initials) -> confirm with user -> call 'create_project'.
+Read `references/create-project.md` for the intake flow: collect the five fields (matter/app number, notification date, project type, due date, assignee initials) -> confirm with user -> call 'create_project'. Pass the assignee initials directly; the backend resolves them to the user (no get_user_by_initials step).

package/skills/fenix-project/VERSION

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

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

@@ -1,10 +1,9 @@
 # Create Project
 
-**Version: 1**
+**Version: 2**
 
-1. **Verify assignee**  --  'get_user_by_initials'. If no match, ask user to correct initials.
-2. **Collect**  --  matter/app number, notification date, project type ('list_project_types'), due date, assignee initials
-3. **Confirm**  --  show all five values. Ask 'Ready to create  --  any changes?' **END TURN**
-4. **Create**  --  'create_project' once confirmed
+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.
 
-If any field is missing: render a React form with all five fields. On submit show confirmation block, then 'create_project'.
+If any field is missing: render a React form with all fields. On submit show confirmation block, then 'create_project'.