Publish patent-application-drafting-skill skill to marketplace
Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources. Confidence: high Scope-risk: narrow Directive: Keep private/internal skills out of the public marketplace. Tested: Marketplace validation passed.
This commit is contained in:
KeyInfo Bot
@@ -243,6 +243,18 @@
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "开发工具"
|
||||
},
|
||||
{
|
||||
"name": "专利申请撰写",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./plugins/codex/plugins/专利申请撰写"
|
||||
},
|
||||
"policy": {
|
||||
"installation": "AVAILABLE",
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "文档处理"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -243,6 +243,18 @@
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "开发工具"
|
||||
},
|
||||
{
|
||||
"name": "专利申请撰写",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./plugins/专利申请撰写"
|
||||
},
|
||||
"policy": {
|
||||
"installation": "AVAILABLE",
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "文档处理"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
{
|
||||
"name": "专利申请撰写",
|
||||
"version": "0.1.0",
|
||||
"description": "在根据发明人访谈内容撰写中文专利技术交底书或专利申请文件时使用，尤其适用于软件、人工智能、系统、设备、方法、模型训练、数据处理、视觉监控或工程类发明。也可用于用户收集发明思路、确认技术内容的完整性、准备专利交底书、起草权利要求书/说明书/摘要/附图、将其转换为Word格式，以及评估发明的新颖性、创造性和实用性。",
|
||||
"author": {
|
||||
"name": "EAPIL",
|
||||
"url": "https://git.playones.com/arechen/EapilSkillMarket"
|
||||
},
|
||||
"homepage": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"repository": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"license": "Proprietary",
|
||||
"keywords": [
|
||||
"eapil",
|
||||
"codex-skill",
|
||||
"专利申请撰写"
|
||||
],
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "patent-application-drafting-skill",
|
||||
"shortDescription": "在根据发明人访谈内容撰写中文专利技术交底书或专利申请文件时使用，尤其适用于软件、人工智能、系统、设备、方法、模型训练、数据处理、视觉监控或工程类发明。也可用于用户收集发明思路、确认技术内容的完整性、准备专利交底书、起草权利要求书/说明书/摘要/附图、将其转换为Word格式，以及评估发明的新颖性、创造性和实用性。",
|
||||
"longDescription": "在根据发明人访谈内容撰写中文专利技术交底书或专利申请文件时使用，尤其适用于软件、人工智能、系统、设备、方法、模型训练、数据处理、视觉监控或工程类发明。也可用于用户收集发明思路、确认技术内容的完整性、准备专利交底书、起草权利要求书/说明书/摘要/附图、将其转换为Word格式，以及评估发明的新颖性、创造性和实用性。",
|
||||
"developerName": "EAPIL",
|
||||
"category": "文档处理",
|
||||
"capabilities": [
|
||||
"Read",
|
||||
"Write"
|
||||
],
|
||||
"defaultPrompt": [
|
||||
"使用 patent-application-drafting-skill 帮我完成这个任务。"
|
||||
],
|
||||
"websiteURL": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"privacyPolicyURL": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"termsOfServiceURL": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"brandColor": "#2563EB",
|
||||
"screenshots": []
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,152 @@
|
||||
---
|
||||
name: patent-application-drafting
|
||||
description: Use when drafting Chinese patent technical disclosures or patent application documents from inventor interviews, especially for software, AI, system, device, method, model-training, data-processing, visual monitoring, or engineering inventions. Use when the user wants to collect an invention idea, confirm technical completeness, prepare a patent disclosure, draft claims/specification/abstract/drawings, convert to Word, or review novelty, inventiveness, and practical applicability.
|
||||
---
|
||||
|
||||
# Patent Application Drafting
|
||||
|
||||
## Purpose
|
||||
|
||||
Use this skill to turn an inventor's rough technical idea into a complete Chinese patent drafting package. The process must first confirm the technical solution is complete and effective, then produce the disclosure, claims, specification, abstract, drawings, Word documents, and a three-requirements review as requested.
|
||||
|
||||
This skill is for drafting support, not a substitute for a licensed attorney's final filing review.
|
||||
|
||||
## Core Rule: Confirm Before Drafting
|
||||
|
||||
Do not rush into final drafting from an incomplete invention idea. First gather and confirm:
|
||||
|
||||
1. applicant and inventor information;
|
||||
2. product/system/application scenario;
|
||||
3. existing technical problem;
|
||||
4. complete technical solution and data/control flow;
|
||||
5. essential technical features;
|
||||
6. optional/alternative embodiments;
|
||||
7. technical effects and measurable indicators;
|
||||
8. implementation examples;
|
||||
9. public disclosure status;
|
||||
10. filing strategy: one core application or divisional/portfolio split.
|
||||
|
||||
If the inventor says they are still explaining, listen and only summarize briefly. Start structured drafting only after they clearly say the technical framework is complete or ask to begin sorting.
|
||||
|
||||
For the detailed interview checklist, read `references/inventor-interview.md` when gathering facts.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Intake and Listening
|
||||
|
||||
Identify whether the user is:
|
||||
|
||||
- still describing the invention;
|
||||
- asking for technical-solution sorting;
|
||||
- asking for a disclosure draft;
|
||||
- asking for formal patent application documents;
|
||||
- asking for drawings, Word files, or three-requirements review.
|
||||
|
||||
When the inventor is still describing, respond with short confirmations and record key points. Do not over-structure until asked.
|
||||
|
||||
### 2. Technical Completeness Check
|
||||
|
||||
Before drafting a disclosure or application, check whether the invention includes:
|
||||
|
||||
- the starting condition or input;
|
||||
- the processing modules/steps;
|
||||
- how each step is triggered;
|
||||
- what data is generated, selected, labeled, trained, transmitted, or stored;
|
||||
- how the system knows success/failure or confidence;
|
||||
- what is executed locally vs cloud/server/platform;
|
||||
- how the result is deployed or used;
|
||||
- what is new compared with conventional practice;
|
||||
- why the solution produces a technical effect.
|
||||
|
||||
If any key part is missing, ask focused questions. Prefer 3-6 concrete questions rather than a long questionnaire.
|
||||
|
||||
### 3. Technical Disclosure Draft
|
||||
|
||||
After confirmation, create a disclosure document with:
|
||||
|
||||
- invention name candidates;
|
||||
- technical field;
|
||||
- background technology;
|
||||
- technical problems;
|
||||
- technical solution overview;
|
||||
- complete implementation process;
|
||||
- system/module composition;
|
||||
- core innovation points;
|
||||
- technical effects;
|
||||
- alternative embodiments;
|
||||
- recommended claim layout;
|
||||
- drawing suggestions;
|
||||
- business/engineering examples;
|
||||
- open issues for confirmation.
|
||||
|
||||
Use the structure in `references/drafting-outputs.md`.
|
||||
|
||||
### 4. Formal Application Draft
|
||||
|
||||
When the user asks for formal application files, draft:
|
||||
|
||||
- claims;
|
||||
- specification;
|
||||
- abstract;
|
||||
- drawing descriptions;
|
||||
- optional separate drawing source/figure notes.
|
||||
|
||||
Use one application with multiple statutory categories unless the user requests a portfolio split. For software/AI/system inventions, normally include method claims, system claims, electronic device claims, and computer-readable storage medium claims.
|
||||
|
||||
Keep the independent claim focused on the minimum necessary closed loop. Put implementation details, thresholds, versioning, manual review, privacy, rollback, and scenarios in dependent claims.
|
||||
|
||||
### 5. Drawings
|
||||
|
||||
Prepare drawings as simple black-and-white patent flowcharts/block diagrams:
|
||||
|
||||
- no color, shading, icons, or decorative elements;
|
||||
- boxes, diamonds, arrows, and reference numerals where appropriate;
|
||||
- figure captions outside the drawing image unless the user asks otherwise;
|
||||
- each figure can be a separate PNG for Word insertion.
|
||||
|
||||
If the user asks to generate images, use the image generation tool. If the user asks for Word, insert the figures into a separate DOCX and add captions.
|
||||
|
||||
### 6. Word Deliverables
|
||||
|
||||
When asked for Word files, use the Documents skill if available. Produce at least:
|
||||
|
||||
- formal text DOCX: claims, specification, abstract;
|
||||
- figure DOCX: drawings with captions.
|
||||
|
||||
Attempt render/visual QA. If rendering fails because LibreOffice/soffice is unavailable, still deliver the DOCX and state that visual render QA could not be completed.
|
||||
|
||||
### 7. Three-Requirements Review
|
||||
|
||||
When asked to review patentability, analyze:
|
||||
|
||||
- novelty: whether the full combination is likely not identically disclosed;
|
||||
- inventiveness: closest prior-art combinations and why the solution is not a simple aggregation;
|
||||
- practical applicability: whether the solution can be manufactured/used and produces technical effects.
|
||||
|
||||
For high-stakes filing decisions or actual novelty search, browse or use official patent databases if the user asks for a search. Without a search, clearly state the review is preliminary and not a formal search conclusion.
|
||||
|
||||
Use `references/quality-review.md` for the review checklist.
|
||||
|
||||
## Drafting Principles
|
||||
|
||||
- Protect the technical mechanism, not only the business scenario.
|
||||
- Convert business needs into objective technical problems.
|
||||
- Avoid claim language that depends only on "improving user experience" or management rules.
|
||||
- For AI inventions, identify training data generation, labeling, model training, model deployment, inference, feedback, and technical constraints.
|
||||
- For edge/cloud systems, clearly separate端侧、云端、平台、设备、用户反馈、OTA and data-security roles.
|
||||
- Add alternatives so claims are not tied to one model, one vendor, one threshold, or one business scenario.
|
||||
- Keep file names clear and Chinese-friendly when working in a Chinese patent workspace.
|
||||
|
||||
## Output Naming
|
||||
|
||||
Use descriptive filenames such as:
|
||||
|
||||
- `技术交底书.md`
|
||||
- `正式申请文件-权利要求书.md`
|
||||
- `正式申请文件-说明书.md`
|
||||
- `正式申请文件-说明书摘要.md`
|
||||
- `正式申请文件-附图草图.md`
|
||||
- `正式申请文件-文本.docx`
|
||||
- `正式申请文件-附图.docx`
|
||||
|
||||
When multiple inventions are present, prefix filenames with a short invention title.
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Patent Application Drafting"
|
||||
short_description: "Draft Chinese patent disclosures, applications, drawings, Word files, and patentability reviews from inventor interviews."
|
||||
default_prompt: "Help me turn this invention idea into a complete patent disclosure and application draft. First interview me to confirm the technical solution is complete."
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
# Drafting Output Structures
|
||||
|
||||
## Technical Disclosure Structure
|
||||
|
||||
Use this order unless the user's company template differs:
|
||||
|
||||
1. 发明名称
|
||||
2. 技术领域
|
||||
3. 背景技术
|
||||
4. 要解决的技术问题
|
||||
5. 技术方案概述
|
||||
6. 完整实现过程
|
||||
7. 系统组成或模块结构
|
||||
8. 核心创新点
|
||||
9. 技术效果
|
||||
10. 可替代实施方式
|
||||
11. 建议权利要求保护方向
|
||||
12. 附图建议
|
||||
13. 需要进一步确认的问题
|
||||
14. 业务或工程实施例
|
||||
15. 初步保护重点判断
|
||||
|
||||
## Formal Application Package
|
||||
|
||||
### Claims
|
||||
|
||||
Recommended for AI/software/system inventions:
|
||||
|
||||
1. Method independent claim.
|
||||
2. Method dependent claims:
|
||||
- data screening;
|
||||
- confidence/conflict/misreport/missed-report criteria;
|
||||
- dataset structure;
|
||||
- large-model annotation;
|
||||
- label-to-training-sample conversion;
|
||||
- manual supplement;
|
||||
- model training/compression/quantization;
|
||||
- training trigger;
|
||||
- OTA/version/rollback;
|
||||
- privacy/security;
|
||||
- feedback loop.
|
||||
3. System independent claim.
|
||||
4. System dependent claims.
|
||||
5. Electronic device claim.
|
||||
6. Computer-readable storage medium claim.
|
||||
|
||||
Independent claim drafting rule:
|
||||
|
||||
- include only the minimum closed loop;
|
||||
- avoid overlimiting to one scenario, model vendor, exact threshold, or business example;
|
||||
- use "at least one" and alternatives where appropriate;
|
||||
- keep the technical relation between steps explicit.
|
||||
|
||||
### Specification
|
||||
|
||||
Use:
|
||||
|
||||
1. 技术领域
|
||||
2. 背景技术
|
||||
3. 发明内容
|
||||
- 要解决的技术问题
|
||||
- 技术方案
|
||||
- 有益效果
|
||||
4. 附图说明
|
||||
5. 具体实施方式
|
||||
|
||||
Concrete embodiments should support every claim feature, especially:
|
||||
|
||||
- where data comes from;
|
||||
- how data is selected;
|
||||
- how labels are generated;
|
||||
- how labels are transformed into training samples;
|
||||
- where training happens;
|
||||
- how the model is delivered;
|
||||
- how feedback triggers another round.
|
||||
|
||||
### Abstract
|
||||
|
||||
Keep the abstract concise:
|
||||
|
||||
- name the method/system;
|
||||
- list core steps;
|
||||
- state the technical effect;
|
||||
- suggest the main figure.
|
||||
|
||||
## Drawing Set
|
||||
|
||||
For system/process inventions, prepare:
|
||||
|
||||
1. overall system architecture;
|
||||
2. local/edge-side screening flow;
|
||||
3. dataset generation flow;
|
||||
4. large-model annotation and sample conversion flow;
|
||||
5. model training and deployment/OTA flow;
|
||||
6. feedback closed-loop flow.
|
||||
|
||||
Drawings should be black-and-white line diagrams. Do not put figure captions inside image content unless explicitly requested.
|
||||
|
||||
## Word Packaging
|
||||
|
||||
Common deliverables:
|
||||
|
||||
- `正式申请文件-文本.docx`: claims + specification + abstract.
|
||||
- `正式申请文件-附图.docx`: each figure on its own page, with captions under the figure.
|
||||
|
||||
If possible, render-check DOCX pages. If rendering is unavailable, structurally verify paragraph count, image count, and captions.
|
||||
+96
@@ -0,0 +1,96 @@
|
||||
# Inventor Interview Checklist
|
||||
|
||||
Use this when collecting or confirming an invention. Ask only the questions needed for the current gap; do not dump the whole checklist unless the user asks.
|
||||
|
||||
## A. Basic Information
|
||||
|
||||
1. Applicant/company name.
|
||||
2. Inventor names if known.
|
||||
3. Product/system name.
|
||||
4. Industry and application scenario.
|
||||
5. Filing goal: core protection, quick grant, defensive disclosure, portfolio layout, or enforcement.
|
||||
6. Public disclosure: sale, demo, website, paper, WeChat article, exhibition, tender, customer delivery.
|
||||
|
||||
## B. Existing Technology
|
||||
|
||||
Confirm:
|
||||
|
||||
- how existing systems usually work;
|
||||
- which step/module causes the problem;
|
||||
- why current algorithms/devices/processes cannot solve it;
|
||||
- whether the problem is technical rather than only business/management;
|
||||
- closest known competitor or internal old version.
|
||||
|
||||
Convert business complaints into technical problems:
|
||||
|
||||
- low accuracy, high false positive/false negative rate;
|
||||
- high computing/storage/bandwidth cost;
|
||||
- weak scenario adaptation;
|
||||
- long training/deployment cycle;
|
||||
- unstable recognition/control;
|
||||
- difficult data generation/labeling;
|
||||
- poor compatibility or difficult operation.
|
||||
|
||||
## C. Technical Solution
|
||||
|
||||
For method/process inventions, confirm:
|
||||
|
||||
1. input data or trigger condition;
|
||||
2. step sequence;
|
||||
3. each step's executor;
|
||||
4. each step's output;
|
||||
5. judgment thresholds or rules;
|
||||
6. exception handling;
|
||||
7. feedback loop;
|
||||
8. final output or deployment.
|
||||
|
||||
For system/device inventions, confirm:
|
||||
|
||||
1. modules/components;
|
||||
2. data/control connections;
|
||||
3. local/cloud/server division;
|
||||
4. model/data/rule storage;
|
||||
5. update or synchronization mechanism;
|
||||
6. security and permission mechanism.
|
||||
|
||||
For AI inventions, confirm:
|
||||
|
||||
1. data source and data screening;
|
||||
2. label source and label structure;
|
||||
3. teacher/student model relation if any;
|
||||
4. training method: supervised, fine-tuning, distillation, compression, quantization;
|
||||
5. inference location;
|
||||
6. model versioning and deployment;
|
||||
7. feedback, active learning, or retraining trigger;
|
||||
8. evaluation metrics.
|
||||
|
||||
## D. Essential vs Optional Features
|
||||
|
||||
Ask:
|
||||
|
||||
- Without which features would the solution fail?
|
||||
- Which features are only preferred optimizations?
|
||||
- Which model/vendor/threshold/module can be replaced?
|
||||
- Can the same method be used in other scenarios?
|
||||
- Is manual review required or only optional?
|
||||
|
||||
## E. Technical Effects
|
||||
|
||||
Collect measurable or at least evaluable effects:
|
||||
|
||||
- uploaded data volume reduced;
|
||||
- manual labeling reduced;
|
||||
- accuracy/recall/F1 improved;
|
||||
- false alarm/missed alarm reduced;
|
||||
- model adaptation cycle shortened;
|
||||
- edge inference latency kept within threshold;
|
||||
- memory/model size controlled;
|
||||
- deployment reliability improved.
|
||||
|
||||
## F. Completion Gate
|
||||
|
||||
Before drafting claims, the agent should be able to state in one paragraph:
|
||||
|
||||
"The invention solves [technical problem] by [essential technical means], producing [technical effects], and the minimum protectable closed loop is [steps/modules]."
|
||||
|
||||
If this cannot be stated, keep interviewing.
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
# Patent Draft Quality and Three-Requirements Review
|
||||
|
||||
## Draft Completeness Review
|
||||
|
||||
Before saying a draft is ready, check:
|
||||
|
||||
1. The title matches the real inventive concept.
|
||||
2. Claims, specification, abstract, and drawings use consistent terminology.
|
||||
3. Each independent claim has a complete technical closed loop.
|
||||
4. Every claim feature is supported in the specification.
|
||||
5. The background states technical defects, not only business pain.
|
||||
6. Technical effects correspond to technical features.
|
||||
7. Alternatives avoid tying protection to one vendor, model, threshold, or scenario.
|
||||
8. Implementation examples are concrete enough to show enablement.
|
||||
9. Drawings cover all important flows/modules.
|
||||
10. Confidential/public disclosure status is noted for the user to confirm.
|
||||
|
||||
## Novelty Review
|
||||
|
||||
Without a formal search, phrase the conclusion as preliminary.
|
||||
|
||||
Assess whether a single prior-art reference is likely to disclose all essential features in combination.
|
||||
|
||||
For AI/edge/cloud inventions, compare:
|
||||
|
||||
- local difficult-sample screening;
|
||||
- scene-specific dataset generation;
|
||||
- large model as teacher/labeler;
|
||||
- label-to-sample conversion;
|
||||
- scene/device-specific expert model training;
|
||||
- OTA delivery;
|
||||
- closed-loop feedback.
|
||||
|
||||
If the invention's novelty depends on a combination, keep that combination in the independent claim.
|
||||
|
||||
## Inventiveness Review
|
||||
|
||||
Identify possible closest prior art:
|
||||
|
||||
- active learning or low-confidence sample selection;
|
||||
- pseudo-labeling or teacher/student training;
|
||||
- knowledge distillation;
|
||||
- edge AI model deployment;
|
||||
- cloud training and OTA update;
|
||||
- visual monitoring event detection.
|
||||
|
||||
Then explain why the invention is not a simple aggregation:
|
||||
|
||||
- it solves edge computing constraints and scene adaptation together;
|
||||
- local screening reduces upload and labeling cost;
|
||||
- large-model semantic labeling supplies fine-grained labels unavailable to the edge model;
|
||||
- label conversion bridges semantic understanding and trainable small-model categories;
|
||||
- device/scene binding makes model results different for identical hardware in different scenes;
|
||||
- feedback closes the training/deployment loop.
|
||||
|
||||
## Practical Applicability Review
|
||||
|
||||
Confirm:
|
||||
|
||||
- devices/platforms can be implemented with known hardware/software;
|
||||
- inputs, processing, outputs, and deployment are clear;
|
||||
- the solution can be used in industrial/business scenarios;
|
||||
- technical effects can be measured or observed.
|
||||
|
||||
## Common Risk Points
|
||||
|
||||
1. Claim only says "use AI" or "select model by scene" without a technical mechanism.
|
||||
2. "Online training" is not supported by trigger conditions or data flow.
|
||||
3. Large model output is not connected to small model training samples.
|
||||
4. Effects are business-only, such as "better management", without technical metrics.
|
||||
5. Embodiments overfocus on one business scenario and narrow the invention.
|
||||
6. Claims overlimit to one named model/vendor.
|
||||
7. Drawings include decorative images instead of technical diagrams.
|
||||
|
||||
## Recommended Final Summary
|
||||
|
||||
Use a concise conclusion:
|
||||
|
||||
- 新颖性：较好/一般/存在风险, with reason.
|
||||
- 创造性：强/中等/偏弱, with closest-risk combinations and defense.
|
||||
- 实用性：强/可满足/需补充, with implementation basis.
|
||||
|
||||
Add concrete recommendations before filing.
|
||||
Reference in New Issue
Block a user