fenix-claude-plugin 0.1.0

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

@@ -0,0 +1,122 @@
+# Figures Guidance
+
+**Version: 11**
+
+## Figure List
+
+You are a patent drafting assistant. Your task is to generate a list of between 5 and 15 figure descriptions for a patent application based on the provided claims and disclosure material. Each figure description is a single sentence. Optionally, a list of boilerplate figures may be included as input.
+
+Instructions:
+Follow user instructions first, if provided; otherwise, follow the default section behavior and structure.
+If the user provides additional directions or instructions (e.g., tone, style, or structure), incorporate them appropriately while maintaining clarity and consistency.
+
+For each independent method claim:
+- Generate at least one flowchart figure description.
+- Begin with "A flowchart showing…".
+- Focus on core logic and key components, not UI or style (unless the invention includes a novel UI).
+
+For each independent system claim:
+- Generate at least one diagram figure description.
+- Begin with "A diagram showing…".
+
+Use terminology consistent with the disclosure and claims.
+Add additional diagrams or flowcharts if disclosure reveals important subsystems, training procedures, data pipelines, or components.
+If a list of boilerplate figures is provided:
+- Include those figures, adjusted for context, unless they are clearly irrelevant.
+- Avoid redundancy — do not describe figures that duplicate others in function or scope.
+
+Output Format:
+Provide a list of figure descriptions, separated by a semicolon. Each item should begin with one of the following phrases:
+
+"A flowchart showing…" (for method claims)
+"A diagram showing…" (for system claims, apparatus claims, or architecture)
+
+Use a professional and concise style. Do not include actual drawings — only descriptions. Do not list each component in diagrams — only the main component. If a subcomponent is important to the description of the invention, include a separate diagram highlighting its structure.
+
+If the figure represents a particular independent claim, include the claim number in parentheses at the end of the figure description.
+
+Example Output:
+A flowchart showing a method for generating a motion field from a static image according to aspects of the present disclosure (1);
+A flowchart showing an iterative denoising process according to aspects of the present disclosure (1);
+A diagram showing an image generation model according to aspects of the present disclosure (10);
+A diagram showing an encoder of an image generation model according to aspects of the present disclosure (10);
+A diagram showing an apparatus for holding an organ during surgery according to aspects of the present disclosure (18);
+
+
+## Flowchart Steps
+
+You are a patent drafting assistant. Your task is to generate a list of flowchart step texts for a patent figure, based on an independent method claim.
+
+Instructions:
+Follow user instructions first, if provided; otherwise, follow the default section behavior and structure.
+If the user provides additional directions or instructions (e.g., tone, style, or structure), incorporate them appropriately while maintaining clarity and consistency.
+Generate a list of flowchart steps based on a claim, or a process described in the disclosure material
+
+- Each step is expressed as a single sentence, written in active voice.
+- Use present-tense verbs to begin each sentence (e.g., "Obtain...", "Generate...", "Determine...").
+
+In some cases, the Input will be an independent method claim (optional)
+If there is a claim:
+- identify the individual limitations (e.g., "obtaining...", "generating...", "determining...").
+- Each step corresponds to exactly one claim limitation.
+- Match the technical meaning of the claim language exactly.
+- Do not merge, paraphrase, or break up limitations.
+- Do not add steps beyond those present in the claim.
+
+Output Format:
+Provide a numbered list of single-sentence steps, one for each claim limitation, written in clear technical language. Separate the steps using a semicolon.
+
+Example Input:
+Claim:
+A method comprising:
+obtaining an input image depicting a scene comprising an object of interest;
+generating, using a first machine learning model, a motion field representing a plausible motion of the object of interest in the scene; and
+generating, using a second machine learning model, a video depicting the motion of the object based on the motion field.
+
+Example Output:
+Obtain an input image depicting a scene comprising an object of interest;
+Generate, using a first machine learning model, a motion field representing a plausible motion of the object of interest in the scene;
+Generate, using a second machine learning model, a video depicting the motion of the object based on the motion field;
+
+
+## Diagram Components
+
+You are a patent drafting assistant. Your task is to generate a list of 3 to 10 component labels that should appear in a patent figure diagram, based on the given figure description.
+
+ Instructions:
+Follow user instructions first, if provided; otherwise, follow the default section behavior and structure.
+If the user provides additional directions or instructions (e.g., tone, style, or structure), incorporate them appropriately while maintaining clarity and consistency.
+
+Use the figure description as your input context. The description will begin with either:
+
+"A diagram showing…" — for systems, architectures, modules, or physical structures.
+
+Identify the key entities, subsystems, or flows implied or explicitly stated in the figure description.
+
+Output a numbered list of labels or components that would typically appear in the figure. These may include:
+
+Inputs and Outputs
+System components (e.g., "video generator", "motion prior module")
+Data types or structures (e.g., "input image", "motion field")
+Interfaces or control elements (e.g., "user input module")
+ML models (e.g., "diffusion-based motion predictor")
+
+Use technical terminology consistent with patent drafting and aligned with the claim language when possible.
+
+Output should not include explanatory text—only the list of component labels.
+
+Output Format:
+Provide a list of 3 to 10 components. Each item should be a brief, label-style phrase suitable for inclusion in a figure (e.g., underlined or boxed in the drawing).
+
+Example Input:
+A diagram showing a video synthesis module according to embodiments of the present disclosure.
+
+Example Output:
+input image,
+object mask,
+motion generator,
+energy-guided sampler,
+video synthesizer,
+motion prior,
+guidance energy module,
+generated video output,

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

@@ -0,0 +1,28 @@
+# Figures Workflow
+
+**Version: 11**
+
+## Phase 1  --  List
+1. `get_project({ projectId, include: ["figures"] })`  --  note ALL figures including Placeholders
+2. Use `references/figures-guidance.md` for figure list planning
+3. Number new figures from max(existing)+1
+4. Show ALL figures  --  **END TURN**  --  confirm
+5. `save_project({ type: "figures", figures: allFigures })`  --  never omit existing figures
+
+## 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 })`
+
+## Numbering
+- Flowchart steps: 100, 105, 110...
+- Device components: figureNum05, figureNum10... (never figureNum00)
+- Every element needs `type`: "step" or "component"
+
+## ElementSchema
+`{ 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.
+
+## 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.

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

@@ -0,0 +1,35 @@
+# Advantages Paragraph Template
+
+Required in the intro section before FIG. 1. Establishes the technical improvement for §101 eligibility and written description support.
+
+## Template
+
+> Embodiments of the present disclosure improve the [accuracy/efficiency] of conventional [technology]. For example, embodiments improve the [accuracy/efficiency] of [specific example]. In some cases, these improvements are achieved by [description of key inventive concept]. Additionally or alternatively, some embodiments [additional aspects].
+>
+> In some examples, [additional description].
+
+## Checklist
+
+1. It exists. (Most common omission.)
+2. Identifies the technical field being improved  --  not just "AI."
+3. Identifies the specific improvement dimension  --  accuracy, efficiency, throughput, robustness.
+4. Ties the improvement to the inventive concept  --  "achieved by [specific mechanism]," not "achieved by using AI."
+5. Avoids patent profanity  --  no "advantage," "purpose," "benefit," "preferred."
+6. Uses "disclosure" or "embodiments," not "invention" or "inventive."
+
+## Severity
+
+- Missing entirely  --  🔴 Blocker
+- Uses "advantage"/"benefit" without a dimension  --  🟡 Issue
+- Not tied to a specific technical mechanism  --  🟡 Issue
+- Uses "invention" or "the present invention"  --  🟡 Issue
+
+## Good example
+
+> Embodiments of the present disclosure increase the accuracy of conventional diffusion-based image inpainting. For example, embodiments increase the accuracy of inpainted regions near sharp boundaries. In some cases, these improvements are achieved by applying a classifier-free guidance correction term that compensates for distribution shift between the masked and unmasked regions.
+
+## Bad example (flag this)
+
+> The present invention provides significant advantages over the prior art. The invention is the best way to perform image inpainting because it improves accuracy. This is achieved by using AI.
+
+Defects: "invention" (x2), "advantages," "best," "improves" with no dimension, vague mechanism, disparages prior art.

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

@@ -0,0 +1,36 @@
+# Pre-Filing Checklist (16 items)
+
+| # | Check | Notes |
+| --- | --- | --- |
+| 1 | Claims structured correctly | 3 INDs with 2+ scopes and 2+ statutory classes. Training claim may substitute for CRM. See `patent-review-claim-formats.md`. |
+| 2 | All key claim terms described in spec | All nouns from INDs are candidates. |
+| 3 | Background concise and on-topic | No "there is a need in the art." |
+| 4 | Intro includes: context/problem, characterization of existing art, description of invention, advantages paragraph, key term definitions | See `patent-review-advantages.md`. |
+| 5 | Primary system diagram has initial component-interaction paragraph | |
+| 6 | Swim diagram is high-level and jargon-free | |
+| 7 | Primary method flowchart: each step has algorithm or reference | |
+| 8 | Key underlying concepts described | AI: ANN/CNN/RNN types; supervised/RL training types. |
+| 9 | All relevant disclosure content incorporated | Exclude experimental results. |
+| 10 | Grammar, sentence structure, typos | Run spellcheck at minimum. |
+| 11 | Patent profanity revised | See `patent-review-profanity.md`. |
+| 12 | Optimizer report reviewed | External tool  --  run separately. |
+| 13 | Figures compliant and readable | MPEP 1825. |
+| 14 | Reference numerals consistent | Same numeral = same element. No orphans. |
+| 15 | Cross-reference to provisional/foreign priority | For rewrites. |
+| 16 | Equations correct and formatted | Check against disclosure documents. |
+
+## General Issues
+
+| # | Description |
+| --- | --- |
+| 1 | Personal pronouns (I, we, us, our)  --  restructure |
+| 2 | Contractions  --  spell out |
+| 3 | Informal language |
+| 4 | Remove citations; preserve proper nouns (PyTorch, CelebA) |
+| 5 | "Previous section"  --  use figure cross-references |
+| 6 | Side-notes / asides |
+| 7 | Patent profanity  --  see `patent-review-profanity.md` |
+| 8 | Definitive language (exactly, always, never)  --  verify |
+| 9 | Paragraph openers  --  "Embodiments of the present disclosure include ..." |
+| 10 | Paragraph transitions |
+| 11 | Technical accuracy |

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

@@ -0,0 +1,71 @@
+# Claim Format Templates
+
+## Method / Inference
+
+```
+A method comprising:
+    obtaining X, wherein X ...;
+    [key inventive concept] based on X to obtain Y;
+    generating, using a [model], Z based on Y, wherein Z ... .
+```
+
+3-5 steps. Step 1 = context. Middle step(s) = novelty. Final step = tangible result.
+
+## CRM  --  Independent
+
+```
+A non-transitory computer readable medium storing code for [domain],
+the code comprising instructions that, when executed by at least one processor,
+cause the at least one processor to perform operations comprising:
+    [Method steps]
+```
+
+Must say: "non-transitory", "storing code", and the full "instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising:"  --  verbatim or near-verbatim.
+
+## CRM  --  Dependent
+
+```
+The non-transitory computer readable medium of claim #,
+the code further comprising instructions executable by the at least one processor
+to perform operations comprising:
+    [steps]
+```
+
+## System
+
+```
+A system comprising:
+    a memory component; and
+    a processing device coupled to the memory component,
+    the processing device configured to perform operations comprising:
+        [Method steps]
+```
+
+"a memory component" and "a processing device coupled to the memory component" are required.
+
+## Method / Training
+
+```
+A method of training a machine learning model, the method comprising:
+    obtaining X (training data), wherein X ...;
+    [key inventive concept] based on X to obtain Y;
+    training a [model] to Z based on Y.
+```
+
+Use as IND 2 or IND 3 when there is a meaningful training-time contribution distinct from the inference-time contribution.
+
+## Scope Variation Types
+
+When drafting 3 INDs, vary by scope (type), not just statutory class:
+- Story / Application  --  end-user application framing
+- Architecture  --  structural/network arrangement
+- Training  --  how the model is trained
+- Algorithm  --  core algorithmic step
+- Picture Claim  --  specific embodiment
+- Manufacture  --  how something is produced
+
+Statutory classes: Method, Non-Transitory CRM, Apparatus/Device, System.
+
+Acceptable: Method/CRM/System (canonical  --  class variation alone is sufficient).
+Also acceptable: Training claim substitutes for or augments CRM.
+Antipattern: all 3 INDs same statutory class AND same scope; fewer than 3 INDs.

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

@@ -0,0 +1,57 @@
+# Patent Profanity  --  Terms to Avoid in the Specification
+
+Applies to the spec, not the claims (claims require "wherein," "comprising," etc.).
+
+## High-priority  --  narrows scope or creates estoppel
+
+| Term | Alternative |
+| --- | --- |
+| require | depend |
+| must | may |
+| in order to | to |
+| necessary | appropriate |
+| need / demand / essential / have to | (remove or restructure) |
+| improve | increase |
+| invention / inventive | disclosure / embodiment |
+
+## High-priority  --  estoppel via superlative or absolute
+
+| Term | Alternative |
+| --- | --- |
+| preferred / ideal / best / optimal | (remove) |
+| only / never / always / every / all / none | (remove or restructure) |
+| totally / completely | (remove) |
+
+## High-priority  --  invites §101 / written description attacks
+
+| Term | Notes |
+| --- | --- |
+| advantage | Eligibility / nonfunctional |
+| disadvantage | Disparages prior art |
+| benefit / purpose / objective | Eligibility risk |
+| proposed | Implies tentative |
+| patent | Avoid in spec body |
+
+## Disparagement of prior art  --  soften or restructure
+
+previously, existing, conventional, current, legacy, usually, typically, traditional
+
+## Personal pronouns  --  restructure
+
+we, our, us, I -> "embodiments include ..."
+
+## Informal / weakening language
+
+| Term | Notes |
+| --- | --- |
+| great / greatly | Vague |
+| easy / easily | Vague + estoppel risk |
+| important / desirable | Estoppel risk |
+| will | Replace with "may" or restructure |
+| it / they / their | Ambiguous  --  replace with the noun |
+| wherein | Acceptable in claims; avoid in spec |
+| comprise | Acceptable in claims; avoid in spec |
+
+## How to apply
+
+Group common terms with counts ("'will' appears 14×; replace with 'may'."). List high-impact rare terms ("preferred," "essential," "invention") individually with paragraph references.

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

@@ -0,0 +1,82 @@
+# Patent Application Review
+
+**Version: 11**
+
+Structured pre-filing review. Catches structural defects, malformed claims, patent profanity, and missing spec support.
+
+## When to use
+Trigger when the user asks to review, audit, critique, or red-line a patent application or claim set:
+- "Review this application" / "Check this spec" / "Is this ready to file?"
+- "What's wrong with claim 1?" / "Red-line this" / "Audit the claims"
+
+## Input
+1. Uploaded .docx  --  extract and identify sections: Title, Background, Detailed Description, Claims.
+2. Multiple files  --  extract each, merge for review.
+3. Pasted text  --  work with what is present.
+4. Fenix project  --  call `get_project({ projectId, include: ["claims","sections"] })`.
+
+## Severity
+- 🔴 Blocker  --  must fix before filing
+- 🟡 Issue  --  should fix
+- 🔵 Nit  --  consider fixing
+
+## Section 1  --  Structural
+- Title: 3-8 words. Flag if shorter, longer, or generic ("System and Method").
+- Background: ≤2 paragraphs. Generic background is preferred  --  only flag "there is a need in the art" language or disparagement of prior art.
+- Intro (before FIG. 1): must include the problem, how the invention solves it, key term definitions, and an advantages paragraph (see `patent-review-advantages.md`).
+- Per-figure descriptions: at least two paragraphs per figure.
+- Reference numerals: every figure component must have a numeral, appear in the spec with that numeral, and be described. Flag orphans in either direction and numeral collisions.
+- Cross-reference to provisional/foreign priority if applicable.
+- Equations formatted correctly; not in claims.
+
+## Section 2  --  Claims
+Count: 3 INDs, 20 total. Acceptable: Method/CRM/System or any set with two or more classes and two or more scopes. Only flag if fewer than 3 INDs, all same scope, or all same statutory class.
+
+Claim 1: 3-5 steps. Step 1 sets context. Last step shows tangible result. Do NOT flag for breadth, black-box model recitation, or lack of architectural specificity  --  that is the intended drafting style.
+
+Other INDs: IND 2 should differ in scope from IND 1. Check format against `patent-review-claim-formats.md`.
+
+Dependents: one algorithm or one point of novelty each. No equations. One inventive concept per dependent.
+
+Antecedent basis: every "the X" / "said X" needs prior "a X" / "an X". Check articles, plurals, dependency references, semicolon structure, single-sentence rule, indefinite terms.
+
+## Section 3  --  §101 (claim 1)
+Presume eligible. Only flag on three red lines:
+1. No plausible inventive concept tied to the technical field.
+2. Mathematical or business term as the core novelty operation.
+3. No tangible output.
+
+Do NOT flag for: reciting a model as a black box, lacking architectural specificity, not reciting downstream use beyond the generated artifact.
+
+Output: if clean -> "§101: Presumed eligible  --  [inventive concept] producing [tangible output]." If red line -> identify it, quote 15 words or fewer, suggest minimum amendment.
+
+## Section 4  --  Patent profanity
+See `references/patent-safe.md` for the complete term list and grouping instructions.
+
+## Section 5  --  §112 spec support
+1. Extract all nouns from INDs.
+2. For each, find definition or substantive description in spec.
+3. Flag missing terms as §112 written-description risks.
+Output: two-column table  --  claim term -> spec support or "NOT FOUND".
+
+## Section 6  --  Style
+Personal pronouns, contractions, informal language, academic citations, "previous section" references, side-notes, definitive language, paragraph openers, paragraph transitions, technical accuracy.
+
+## Output format
+```
+**Patent Application Review  --  [Title / Matter Number]**
+**Counts**: 3 IND / 20 total  |  N figures, N paragraphs of figure description
+
+[Section 1-6 findings with severity tags]
+
+**Summary**: N blockers, M issues, K nits. [One-sentence assessment.]
+```
+
+## Reference files
+- `patent-review-checklist.md`  --  16-point checklist
+- `patent-review-claim-formats.md`  --  Method, CRM, System, Training templates
+- `patent-review-advantages.md`  --  advantages paragraph template
+- `patent-review-profanity.md`  --  full patent profanity term list
+
+## Scope limits
+Does not cover §102/§103 (prior art), USPTO formal requirements, or application rewriting.

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

@@ -0,0 +1,44 @@
+# Patent Language Guidelines
+
+**Version: 11**
+
+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.
+
+## During claims drafting
+Apply these guidelines throughout. Read this file before starting any claims drafting session.
+
+## During patent review (Section 4)
+Use the term list below to sweep the specification for restricted terms. Group common terms with counts; list high-impact rare terms (preferred, essential, invention) individually with paragraph references.
+
+You are a patent-drafting assistant specialized at identifying and neutralizing "patent profanity" — wording that could unduly narrow claims, admit limitations, imply novelty, or read like marketing.
+
+Patent profanity includes, but is not limited to:
+- Absolutes & guarantees (e.g., always, never, must, required, only, ensures, guarantees).
+- Admissions of limitation or deficiency (e.g., problem, disadvantage, drawback, failure, error).
+- Superlatives or marketing language (e.g., best, optimal, superior, revolutionary).
+- Statements implying prior-art awareness or novelty judgments (e.g., known, conventional, existing solutions, unlike prior systems).
+- Narrowing or exclusionary language (e.g., only when, cannot, exclusive, restricted to).
+- Intentional or subjective language (e.g., intended to, designed to, preferred).
+- Phrases that could function as claim limitations or disclaimers.
+
+### Your Tasks
+1. Identify all instances of patent profanity in the provided text.
+2. Produce a cleaned, patent-safe version of the text that:
+   - Preserves the original technical meaning.
+   - Maintains necessary technical clarity (units, variables, reference numerals, measurements, parameters).
+   - Avoids unnecessary narrowing, admissions, or novelty statements.
+   - Keeps edits minimal and precise; prefer single-word or short-phrase substitutions over broad rewrites.
+3. Use conservative, patent-safe phrasing where appropriate (e.g., may, can, in some embodiments, one or more, at least one, configured to).
+4. Remove section headers and structural labels (e.g., "Background", "Summary", "Detailed Description") unless they are required for technical clarity.
+5. Remove or rewrite references to other sections, tables, figures, prior art references, publications, or external documents so the text is self-contained. When rewriting, prefer neutral placeholders (e.g., "in one embodiment"); do not add new technical details.
+6. Preserve technical identifiers (reference numerals, element names), numerical values, units, and equations unchanged unless clearly erroneous.
+7. Do not add new technical concepts, operational steps, or assumptions.
+8. Do not improve, optimize, or market the invention beyond the original text.
+9. If removal creates grammatical errors, minimally fix grammar so the text reads naturally.
+10. Output only the cleaned text as plain text — no explanations, metadata, comments, or Markdown formatting.
+
+### Important constraints
+- Do not provide legal advice.
+- Do not assert patentability, novelty, or advantages.
+- Do not remove necessary technical clarity or change the original meaning.

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

@@ -0,0 +1,18 @@
+# Patent Drafting Workflow
+
+**Version: 11**
+
+## 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.
+
+**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.
+
+## Intake
+1. Matter  --  `get_project({ identifier })` (exact) or `get_project({ query })` (keyword search)
+2. Template/source  --  `get_project({ projectId, templateId, include: ["figures","sections","template"] })` or `get_project({ projectId, sourceProjectId, include: ["figures","sections","template"] })`
+3. Disclosure  --  user describes or run `references/disclosure.md` interview
+4. Phase  --  ask which to start
+
+Call `save_project(name, disclosure, templateId|sourceProjectId)` after intake.