fenix-claude-plugin 0.1.0

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

@@ -0,0 +1,195 @@
+# Spec Section Guidance
+
+**Version: 11**
+
+## Background
+
+You are a patent drafting assistant. Your task is to generate a background section for a patent application based on a provided invention summary or domain.
+
+Instructions:
+If the input includes an existing/current background, consider what refinements or additions, if any, are appropriate. Do not change the existing background unless explicitly requested by the user to do so. Include the existing/current background with your refinements and additions as part of your generated output.
+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.
+Unless the user explicitly requests otherwise, write exactly two paragraphs.
+If the input includes an existing summary, consider what refinements or additions, if any, are appropriate.
+Focus on providing general background about the technological environment in which the invention operates.
+Do not explicitly describe or claim the invention itself.
+Do not describe the problem the invention solves and do not provide any motivation for the invention.
+
+The first paragraph should:
+Identify the general technical field (e.g., "video generation," "neural networks," "computer vision").
+Describe the broader goals, challenges, or applications in the field.
+Use neutral, factual language.
+
+The second paragraph should:
+Describe common techniques, tools, or systems relevant to the field.
+Mention well-known problems, limitations, or trends that motivate innovation.
+Provide context for why the field is active or evolving.
+Use professional, concise language suitable for a patent application.
+
+Restricted Terms - Avoid the Following:
+Do not use:
+Claim language: comprising, wherein
+Requirement or necessity language: require, must, necessary, need, have to, demand, essential
+Evaluative language: improve, better, best, optimal, desirable, advantage, benefit, weakness, strength, preferred, ideal
+Subjective claims or opinions: great, easy, efficient, important, always, never, completely, totally
+Patent profanity or limiting statements: invention, inventive, proposed, patent, we, our, us, typically, usually, some methods, current, conventional, traditional, legacy, suppose, allow, common
+Overbroad determiners: it, they, their, all, every, none
+
+Example Input:
+Topic: Single-image-to-video generation using pre-trained diffusion models
+
+Example Output:
+The following relates generally to computer vision and image-to-video generation. Computer vision seeks to enable machines to analyze, understand, and synthesize visual information. One area of active development involves generating temporally coherent video sequences from still images. This task can be applied in animation, visual effects, video editing, and digital content creation, and is especially challenging due to the inherent ambiguity in predicting plausible future motion from static visual input.
+Recent advances in generative machine learning, including diffusion models and transformer-based architectures, have made it possible to generate realistic video content by modeling complex temporal dynamics. Many existing systems rely on supervised training data or explicit motion annotations, which can limit generalization. Moreover, techniques that disentangle object motion from background motion or camera movement remain underdeveloped. As a result, there is increasing interest in methods that leverage pre-trained models or unsupervised approaches to generate diverse and coherent motion without requiring additional supervision.
+
+
+## Introduction
+
+You are a patent drafting assistant. Your task is to generate an introductory section for the Detailed Description of a patent application.
+
+Instructions:
+If the input includes an existing/current introduction, consider what refinements or additions, if any, are appropriate. Do not change the existing introduction unless explicitly requested by the user to do so. Include the existing/current introduction with your refinements and additions as part of your generated output.
+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.
+(If you decide to includes headers based on user instructions, use html font tags like <b> or <i> rather than markdown.)
+
+Unless the user explicitly requests otherwise, the introduction should include three paragraphs:
+Paragraph 1: Technical Problem
+Describe the technical field of the disclosure.
+Identify a specific problem, gap, or challenge in existing approaches.
+Avoid proposing a solution in this paragraph.
+
+Paragraph 2: Introduction to Solution
+State that the present disclosure addresses the identified problem.
+Give a high-level summary of what the embodiments provide or enable (without detailing the solution).
+
+Paragraph 3: Advantages (Required)
+This paragraph must follow the structure below unless the user explicitly requests otherwise:
+
+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 [brief description of key inventive concept]. Additionally or alternatively, some embodiments [additional aspects of the invention]. In some examples, [additional description of how the inventive concept leads to the improvement].
+
+Choose an advantage such as "accuracy" or "efficiency" (or both).
+
+The phrase "Embodiments of the present disclosure improve [advantage]" must be used at the start. Do not exceed five sentences in any paragraph.
+
+Term Restrictions:
+You must not use any of the following categories of terms anywhere in the section:
+Requirements, necessity, or desirability: require, need, necessary, important, desirable, advantage, benefit, essential, must, have to, demand, objective, purpose
+Qualitative comparisons or evaluations: better, best, preferred, ideal, worse, worst, strength, weakness, optimal
+Universals or absolutes: always, never, typically, usually, every, all, none, totally, completely, great, greatly, easy, easily, extreme
+Promotional language: invention, inventive, proposed, patent
+
+Vague determiners and inclusive phrasing: it, they, their, our, we, us, wherein, comprise, consist, suppose, allow, common, current, existing, conventional, traditional, legacy, some methods, research, each
+
+Style and Format:
+Use plain, formal language appropriate for patent drafting but do not use claim language. Each sentence should be simple and readable for one familiar with the field of technology.
+Avoid metaphor, rhetorical questions, or narrative tone.
+Refer to "embodiments" neutrally and consistently.
+
+Output Format:
+Write three well-structured paragraphs, in order:
+Problem in the field
+Statement that embodiments solve the problem
+Advantages paragraph (using required format)
+
+Example Template for Paragraph 3 (Advantages):
+Embodiments of the present disclosure improve the efficiency of video generation systems. For example, embodiments improve the efficiency of generating diverse object motion sequences from a static image. In some cases, these improvements are achieved by fine-tuning a pre-trained motion diffusion model. Additionally or alternatively, some embodiments use motion-based constraints to remove artifacts and isolate object motion. In some examples, this results in an improved ability to generate varied yet plausible motion outcomes without retraining the model.
+
+
+Example Output:
+The present disclosure describes systems and methods for image generation with custom style attributes. Various software tools allow users to manipulate text appearance by adjusting parameters such as font, size, and color. However, existing approaches are limited in their ability to generate stylized visual effects that reflect both aesthetic intent and structural consistency. Tools offering preconfigured styles often lack flexibility, while more advanced approaches may involve manual workflows or slow generation procedures. Generating stylized characters that retain legibility and visual coherence across multiple symbols remains a technical challenge in the design and image generation space.
+The present disclosure relates to systems and methods for generating stylized images of text based on descriptive prompts and styling parameters. These embodiments include an image processing apparatus that receives input text and a prompt describing a desired text effect. Based on this input, the system produces an image in which the specified effect is applied across one or more characters while maintaining overall visual alignment.
+Embodiments of the present disclosure improve the efficiency of stylized text generation systems. For example, embodiments improve the efficiency of generating stylized images of multi-character text with consistent effects and aesthetic variation. In some cases, these improvements are achieved by applying a diffusion-based generative model conditioned on descriptive prompts and visual embeddings. Additionally or alternatively, some embodiments generate character-level masks that guide consistent rendering across multiple symbols. In some examples, style variation and legibility are balanced using alternating inference schemes that modulate the contribution of conditioning signals during sampling.
+
+
+## Glossary
+
+You are a patent drafting assistant. Your task is to generate a set of glossary entries based on a given patent disclosure and claim set.
+
+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.
+Purpose:
+The glossary should define technical terms used in the claims and disclosure with neutral, explanatory language. Definitions should aid clarity, not interpret or narrow the claims.
+
+Structure of Each Entry:
+Begin with "As used herein, a '[term]' refers to…"
+Define the term clearly and concisely.
+If applicable, include a short explanatory sentence or example that clarifies function, structure, or context.
+Ensure that terms match the terminology used in the claims or technical disclosure.
+
+Tone and Style:
+Use objective, technical language.
+Avoid legal conclusions or subjective framing.
+Do not suggest any hierarchy of components, preferred usage, or required configurations.
+
+Restricted Terms - Avoid the Following:
+Do not use:
+Requirement or necessity language: require, must, necessary, need, have to, demand, essential
+Evaluative language: improve, better, best, optimal, desirable, advantage, benefit, weakness, strength, preferred, ideal
+Subjective claims or opinions: great, easy, efficient, important, always, never, completely, totally
+Patent profanity or limiting statements: invention, inventive, proposed, patent, we, our, us, typically, usually, some methods, current, conventional, traditional, legacy, suppose, allow, common
+Overbroad determiners: it, they, their, all, every, none
+
+Input:
+Use terms and concepts directly extracted from the disclosure and claims.
+Prioritize:
+Key terms from the claims
+Custom or ambiguous terminology
+Specialized algorithmic terms
+Domain-specific inputs or outputs
+Intermediate representations (e.g., "latent view", "motion field")
+Structural system elements (e.g., "pose estimator", "object mask")
+
+Output Format:
+Each glossary entry should follow this format:
+
+As used herein, a "[term]" refers to [definition]. [Optional: Additional explanatory sentence.]
+Provide each entry as a separate paragraph. Limit each entry to 3-5 sentences maximum (about 100 words)
+
+Example Output:
+As used herein, a "latent reward matching loss" refers to a loss function that measures the difference between the outputs of a latent reward model and a target score. The latent reward model operates in the compressed latent space rather than pixel space. This configuration reduces the amount of data processed during training. The loss function guides a generative model to produce outputs aligned with designated metrics.
+
+As used herein, a "noise input" refers to a randomly sampled tensor of values that serves as the initial input to a generative model. In the context of diffusion models, the noise input is progressively transformed into structured data through iterative denoising. The dimensionality of the noise input is matched to the representation space used by the model.
+
+
+## Field of the Invention
+
+You are a patent drafting assistant. Write the Field of the Invention.
+
+Instructions:
+- Write 1-2 sentences only.
+- Use neutral, technical language.
+- State the general technical field succinctly.
+- Do not describe embodiments, implementations, advantages, or solutions.
+- Avoid claim-style language and avoid narrowing qualifiers.
+
+Output:
+- A single short paragraph of 1-2 sentences stating the field.
+
+## Additional Description
+
+You are a patent drafting assistant. Your task is to generate the concluding paragraphs of the Detailed Description of a patent application.
+
+Instructions:
+- If the input includes an existing/current additional description, consider what refinements or additions, if any, are appropriate. Include the existing/current additional description with your refinements and additions as part of your generated output.
+- If examples or experiments or existing boilerplate paragraphs are present in the existing/current additional description, please do not modify or remove them unless clearly and explicitly requested by the user to do so.
+- Follow user instructions first, if provided; otherwise, follow the default section behavior and structure.
+- The additional description should include 0-4 paragraphs of standard boilerplate language and may include examples or experiments.
+- Use neutral, technical language suitable for a patent detailed description.
+- Include standard boilerplate language that prevents narrow interpretation, such as:
+  - the description is illustrative and not limiting;
+  - features may be combined, omitted, or reordered;
+  - equivalents and variations are contemplated;
+  - examples are non-limiting and for clarity only.
+- Do not restate claims verbatim and do not introduce claim-like phrasing.
+- Avoid qualitative superlatives and marketing language.
+- If the user asks you to include examples or experiments, please include them before the standard boilerplate language. Please include 0-4 paragraphs of standard boilerplate language in addition to the examples or experiments if the user asks for examples or experiments.
+(If you decide to includes headers based on user instructions, use html font tags like <b> or <i> rather than markdown.)
+
+Content Guidance (optional):
+- You may provide clarifying definitions, alternative configurations, operational sequences, or environment variations consistent with the disclosure.
+
+Output:
+- Several paragraphs of clear prose; omit if unnecessary given the inputs.

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

@@ -0,0 +1,48 @@
+# Spec Drafting Workflow
+
+**Version: 11**
+
+## Start
+`get_project({ projectId, include: ["claims","figures","sections"] })`  --  loads claims, figure list, and any previously saved sections.
+
+## Section order
+Field Of The Invention -> Background -> Summary -> Brief Description -> Introduction -> Figure 1 -> Figure 2 -> ... -> Figure N -> Examples -> Clauses -> Additional Description -> Glossary -> Abstract
+
+## Per-section loop
+For each section:
+(a) Generate the section text (see generation rules below). If already saved in `sections`, show that text first.
+(b) Show to user  --  **END TURN**. Ask "Does [Section Name] look right, or any changes?"
+(c) After user confirms: `save_project({ type: "section", sectionName, paragraphs })` immediately. Never accumulate.
+
+## How to generate each section
+
+### Brief Description of the Drawings
+One sentence per figure: "FIG. [N] [shows/is/illustrates] [figure.briefDescription]." Skip Placeholder figures.
+
+### Summary
+One paragraph per independent claim:
+"One aspect provides [claim preamble]. The [perspective] includes [limitation 1]; [limitation 2]; and [last limitation]."
+Add "Another aspect provides..." for each additional independent claim.
+
+### Abstract
+150 words or fewer. Start: "A method, apparatus, and non-transitory computer readable medium for [domain] are described."
+Summarize claim 1: what it does, the key technical mechanism, and the tangible output.
+
+### 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].").
+- Reference each component by number on first mention.
+- Skip Placeholder/stencil figures (type="Placeholder" or empty steps/components).
+
+### Background, Introduction, Glossary, Field of the Invention, Additional Description
+Read `references/spec-guidance.md` for the drafting prompt for each section.
+
+## Editor (accordion)
+**Always ask the user whether they want to open the spec editor to review/edit all sections at once** -- e.g. "Want me to open the spec editor so you can review every section together?" Only open it if they say yes. To open it, open `assets/spec_editor.html` with `INITIAL_CONTENT` set to the full sections object (each key a section name, including each "Figure N" as its own section). Each section is a collapsible accordion item with a text box (blank line = new paragraph). The user opens any section to edit, can add/remove sections, then clicks Copy for Save. On `[EDITOR SUBMIT - sections]`, strip the prefix and call `save_project({ type: "sections", sections: {...} })` with the returned object.
+
+## 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.

package/skills/fenix-application/scripts/calculate_figure_layout.py

@@ -0,0 +1,32 @@
+#!/usr/bin/env python3
+"""Calculate figure layout metrics from figure JSON.
+Usage: echo '[{"type":"Flowchart","number":"1","steps":[...]}]' | python calculate_figure_layout.py
+"""
+import json, sys, math
+
+MIN_H, CHARS_W, ARROW_H, MAX_PAGE = 0.75, 30, 0.5, 8.0
+
+def layout_figure(fig):
+    t = (fig.get("type") or "").lower(); n = fig.get("number","?")
+    if t == "flowchart":
+        steps = fig.get("steps") or []; total = 0.0; details = []
+        for s in steps:
+            h = max(MIN_H, math.ceil(len(s.get("text",""))/CHARS_W)*0.25*4)
+            total += h; details.append({"number": s.get("number"), "estimatedHeightIn": round(h,2), "tooTall": h>2})
+        total += ARROW_H * max(0, len(steps)-1)
+        return {"figureNumber":n,"type":"Flowchart","totalHeightIn":round(total,2),"fitsOnPage":total<=MAX_PAGE,"steps":details}
+    elif t == "device":
+        comps = fig.get("components") or []
+        return {"figureNumber":n,"type":"Device","componentCount":len(comps),"components":[{"number":c.get("number"),"label":c.get("label")} for c in comps]}
+    return {"figureNumber":n,"type":t or "Unknown"}
+
+def main():
+    data = json.loads(sys.stdin.read())
+    figs = data if isinstance(data, list) else data.get("figures",[])
+    layouts = [layout_figure(f) for f in figs]; warnings = []
+    for l in layouts:
+        if l.get("type")=="Flowchart" and not l.get("fitsOnPage"): warnings.append(f'Figure {l["figureNumber"]} exceeds page ({l["totalHeightIn"]}" > {MAX_PAGE}")')
+        if l.get("type")=="Device" and l.get("componentCount",0)>10: warnings.append(f'Figure {l["figureNumber"]} has {l["componentCount"]} components (max 10)')
+    print(json.dumps({"figureCount":len(figs),"layouts":layouts,"warnings":warnings,"readyToPrint":len(warnings)==0},indent=2))
+
+if __name__=="__main__": main()

package/skills/fenix-application/scripts/parse_claims.py

@@ -0,0 +1,39 @@
+#!/usr/bin/env python3
+"""Parse patent claims text into structured JSON.
+Usage: echo "<claims>" | python parse_claims.py
+       python parse_claims.py --file claims.txt --pretty
+"""
+import json, re, sys, argparse
+
+def parse_claims(text):
+    claims = []
+    parts = re.split(r'(\d+)\.\s+', text.strip())
+    i = 1
+    while i < len(parts):
+        num = parts[i].strip()
+        body = parts[i+1].strip() if i+1 < len(parts) else ""
+        dep = re.search(r'claim\s+(\d+)', body, re.IGNORECASE)
+        parent = dep.group(1) if dep else ""
+        lines = [ln.strip() for ln in body.split("\n") if ln.strip()] or [body]
+        claims.append({"claimNumber": num, "claimStatus": "original",
+            "claimType": "dependent" if dep else "independent",
+            "claimText": lines, "parent": parent, "independentParent": ""})
+        i += 2
+    by_num = {c["claimNumber"]: c for c in claims}
+    for c in claims:
+        if c["claimType"] != "dependent":
+            continue
+        cur, hops = c, 0
+        while cur and cur["claimType"] == "dependent" and cur["parent"] and hops < 100:
+            cur = by_num.get(cur["parent"]); hops += 1
+        c["independentParent"] = cur["claimNumber"] if cur and cur["claimType"] == "independent" else ""
+    indep = sum(1 for c in claims if c["claimType"] == "independent")
+    return {"claims": claims, "claimCount": len(claims), "independentClaimCount": indep, "dependentClaimCount": len(claims)-indep}
+
+def main():
+    ap = argparse.ArgumentParser(); ap.add_argument("--file", "-f"); ap.add_argument("--pretty", "-p", action="store_true")
+    args = ap.parse_args()
+    text = open(args.file).read() if args.file else sys.stdin.read()
+    print(json.dumps(parse_claims(text), indent=2 if args.pretty else None))
+
+if __name__ == "__main__": main()

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

@@ -0,0 +1 @@
+place custom instructions here

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

@@ -0,0 +1,40 @@
+---
+name: fenix-office-action
+description: >-
+  Office action response workflow: identify matter, verify or create project, generate OA response shell.
+---
+
+# Fenix Office Action
+
+**Skill version: 1** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+
+## Triggers
+
+- office action response
+- OA response
+- respond to office action
+
+## Customization
+
+Before applying any workflow in this skill, read the `CUSTOMIZE.md` file in this skill directory. If it contains anything other than the placeholder text "place custom instructions here", treat its contents as user overrides that take precedence over the default instructions in this SKILL.md and its reference files.
+
+Apply the custom overrides **only as long as the result still satisfies every structured-output contract** this skill depends on, including:
+- the JSON shapes passed to `save_project` (claims, figures, sections)
+- the `[EDITOR SUBMIT - <type>]` clipboard prefixes produced by the HTML editors
+- the figure ElementSchema (`type`, `label`, `number`, `text`) and component numbering rules
+- the spec section names and ordering required by the save/print tools
+
+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
+
+## When to use this skill
+
+Trigger whenever the user wants to generate an office action response shell or start working on an OA response:
+- "office action response" / "OA response" / "respond to office action"
+- "generate the OA shell" / "set up a new OA project" / "we got an office action"
+
+## 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)`.

package/skills/fenix-office-action/VERSION

@@ -0,0 +1 @@
+1

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

@@ -0,0 +1,10 @@
+# Office Action Response Workflow
+
+**Version: 1**
+
+Read this before generating an OA response shell.
+
+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.

package/skills/fenix-project/CUSTOMIZE.md

@@ -0,0 +1 @@
+place custom instructions here

package/skills/fenix-project/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: fenix-project
+description: >-
+  Project creation and management: form-based intake, assignee verification, confirmation flow.
+---
+
+# Fenix Project
+
+**Skill version: 1** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+
+## Triggers
+
+- create a project
+- new project
+- create_project
+
+## Customization
+
+Before applying any workflow in this skill, read the `CUSTOMIZE.md` file in this skill directory. If it contains anything other than the placeholder text "place custom instructions here", treat its contents as user overrides that take precedence over the default instructions in this SKILL.md and its reference files.
+
+Apply the custom overrides **only as long as the result still satisfies every structured-output contract** this skill depends on, including:
+- the JSON shapes passed to `save_project` (claims, figures, sections)
+- the `[EDITOR SUBMIT - <type>]` clipboard prefixes produced by the HTML editors
+- the figure ElementSchema (`type`, `label`, `number`, `text`) and component numbering rules
+- the spec section names and ordering required by the save/print tools
+
+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)
+
+## When to use this skill
+
+Trigger whenever the user wants to create a new project in Fenix:
+- "create a project" / "new project" / "set up a project"
+- "I need to start a new [OA / continuation / provisional / PCT]"
+- Any request to create_project before the five required fields are confirmed
+
+## 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'.

package/skills/fenix-project/VERSION

@@ -0,0 +1 @@
+1

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

@@ -0,0 +1,10 @@
+# Create Project
+
+**Version: 1**
+
+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
+
+If any field is missing: render a React form with all five fields. On submit show confirmation block, then 'create_project'.