SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscode2patent

code2patent

Coding & development

View repository

Updated 10-15 20:10

About this skill

Code Repository to Patent Delivery

Positioning

This skill is used to organize completed code projects into materials that a patent attorney can continue drafting and assessing. The core objective is not to translate code into patent language, but to organize the real implementation, technical problem, technical solution, technical effect, and evidence locations into a traceable invention patent draft.

The default jurisdiction is Chinese invention patents, mainly applicable to software, algorithms, Agent systems, scheduling optimization, state representation, authentication, memory, context orchestration, file systems, and other solutions primarily implemented in code.

Recommended main workflow:

用户材料 + 代码仓库
        ↓
输入成熟度判断 + archive 归档目录
        ↓
项目边界与依赖画像
        ↓
方案-代码证据映射
        ↓
算法/软件类说明书式技术交底书
        ↓
权利要求布局卡 + 权利要求-证据矩阵
        ↓
发明专利初稿 + 初稿自检表

Startup Gate

Before starting to read code, first confirm:

  1. Whether there is already a candidate patent solution list.
  2. Whether the candidate list contains only names, or already has technical problems, core implementations, technical effects, and code scope.
  3. Whether the goal this time is a technical disclosure document, a claim layout card, an invention patent draft, or candidate solution mining.
  4. Whether there are PRDs, requirement specifications, meeting minutes, customer disclosure templates, existing application formats, or attorney format requirements.
  5. What the archival topic is for this time, used to create archive/YYYY-MM-DD-主题/。

A patent title is not a technical solution. If the user only provides a title or a one-sentence direction, do not directly write a disclosure document or draft.

Input Maturity Triage

Level Input Status Default Action
T0 Name List Only a patent name, title, or one-sentence direction Output a "Patent Name Reverse Clarification Card" and wait for user confirmation
T1 Direction List There are names and business directions, but technical problems, implementation paths, or effects are missing First complete candidate explanations, code evidence directions, and questions to be confirmed
T2 Technical Solution List Already has technical problems, core implementations, target effects, and preliminary module scope Enter targeted search, generate code evidence mapping and a disclosure document
T3 Evidence-Based Solution List Already has technical solutions, code paths, key flows, and evidence levels After reviewing the evidence, continue generating a disclosure document, layout card, or draft
No List The user wants to mine patent points from code First output a candidate patentable solution list, then draft after manual screening

T0/T1 without manual confirmation or automatically mined results can only serve as candidate directions and must not be written as technical solutions already confirmed by the client.

Material Priority

During execution, first read user-provided materials, then read code. Recommended order:

  1. Candidate patent solution list or title list
  2. PRD, product solution, requirement specification
  3. Communication minutes, recording transcripts, client supplementary explanations
  4. Technical disclosure templates, existing application documents, attorney format requirements
  5. Code repository README, architecture documentation, directory descriptions
  6. Source code, configuration, tests, deployment, and runtime files

If the user provides a template or sample, first extract the section structure, step numbering, figure conventions, and technical effect wording, then generate the deliverable. If no template is provided, follow references/algorithm-software-disclosure-format.md and the built-in template.

Required Reading Specifications

Only read the corresponding file when needed, to avoid loading all references into context at once.

Problem to be handled File to read
Structure of algorithm/software invention disclosure, S1...Sn, rules for placing code evidence later, formula and symbol style references/algorithm-software-disclosure-format.md
Project technical solution profile, dependency boundaries, distinguishing self-developed from third-party capabilities references/project-analysis-spec.md
S/F/E extraction, A/B/C grading, translation from code to patent expression references/code-extraction-spec.md
Quickly enter claim layout card, first draft, and self-check writing references/patent-drafting-quick-reference.md
Need complete drafting basis, claim hierarchy, and abstract rules references/patent-drafting-spec.md

This file only retains entry points, triage, routing, and strong rules; detailed rules are maintained preferentially in references/。

Template Routing

Target deliverable Template
Patent title reverse clarification card templates/patent-title-clarification-card-template.md
Algorithm/software invention patent technical disclosure templates/invention-patent-disclosure-template.md
Claim layout card templates/invention-patent-claim-layout-template.md
Claim-evidence matrix templates/invention-patent-claim-evidence-matrix-template.md
Invention patent first draft templates/invention-patent-draft-template.md
Invention patent first draft self-check table templates/invention-patent-draft-self-check-template.md

templates/ is a directly fillable delivery skeleton;references/ contains execution rules and judgment criteria. Do not merge the two.

Core Strong Rules

  1. First judge input maturity, then read code details.
  2. The solutions, templates, and samples provided by the user take precedence over AI inference.
  3. Candidate directions without manual confirmation do not directly enter the disclosure or patent first draft.
  4. First create a project boundary and dependency profile, to avoid writing third-party libraries, model platforms, or framework default capabilities as the applicant's innovation.
  5. Code evidence mapping and the technical disclosure body must be layered.
  6. The disclosure body by default adopts an algorithm/software specification-style structure, and is not written as a code inventory report.
  7. File paths, function names, field names, test files, and internal event names by default go into the evidence mapping or appendix; the body retains only necessary evidence summaries.
  8. The summary of the invention is preferably organized as technical problem, overall solution, steps S1...Sn, further limitations, and technical effects.
  9. The specific implementation mode uses example scenarios to expand input, model/state, steps, parameters, output, and alternative implementations.
  10. The code architecture must be understood, but the final body should be translated into technical objects, relationships, states, actions, timing, and outputs, without showing technology choices or module lists.
  11. 05-技术交底书、05A-权利要求布局卡、05B-权利要求-证据矩阵、06-发明专利初稿 The S1...Sn step numbering in should remain consistent.
  12. When the goal is a first draft, by default first generate the layout card and evidence matrix, then generate the complete first draft.
  13. Grade A evidence may enter the independent claim skeleton; Grade B evidence preferably enters dependent claims or preferred embodiments; Grade C evidence may only enter pending confirmation items or alternative embodiments.
  14. The abstract by default is controlled within 300 characters and does not use commercial promotional language.
  15. Formal application documents still require review by a patent agent.
  16. For solutions involving scoring, ranking, thresholds, vectors, or graph structures, the main text formulas must first establish a symbol table, dimensions must use subscripts, and symbols must be unique and have the same form across sections. For the style conventions, see references/algorithm-software-disclosure-format.md"Formula and Symbol Style Conventions".
  17. Artifact revisions under the same archive topic do not overwrite the original; they are saved separately with a timestamp suffix and recorded in 08-修订记录.md for traceability; solution-level revisions must not go back to T0/T1 for re-mining.

Output Levels

Level Applicable Scenario Main Artifacts
L0 Patent Title Reverse Clarification The user provides only a patent title, heading, or one-sentence direction Patent title reverse clarification card + manual confirmation record
L1 Code Evidence Mapping There is already a candidate solution, and it is necessary to determine whether it lands on the code implementation Solution-code evidence mapping table
L2 Technical Disclosure Document Currently the most recommended main artifact Algorithm/software-type specification-style technical disclosure document + necessary evidence appendix
L2.5 Claim Layout It is necessary to advance to the application document level, but first stabilize the claim tree Claim layout card + claim-evidence matrix
L3 Invention Patent Draft A complete draft is needed before agent drafting Specification draft + claims draft + abstract + self-check table
L4 Patentable Solution Mining The user has not yet summarized candidate solutions Candidate solution list + priority recommendations + manual screening record

Standard Execution Order

Execute by trimming according to the target level; it is not necessary to output all files every time.

  1. Pre-read the user's materials and confirm the target level and template requirements.
  2. Create archive/YYYY-MM-DD-主题/。
  3. Determine input maturity: for T0/T1, clarify first; if there is no list, mine first.
  4. Read the project README, PRD, architecture, and dependency files to form a boundary profile.
  5. Read the code around the confirmed solution, extract evidence, and classify it.
  6. Translate the engineering implementation into S1...Sn, technical features, technical effects, and alternative embodiments.
  7. Generate the disclosure document; the main text adopts a specification-style structure, with evidence placed afterward.
  8. If the application document level is needed, generate the layout card and evidence matrix.
  9. If a complete draft is needed, generate the invention patent draft and self-check table.
  10. Output the questions to be confirmed by R&D, the patent agent, or the applicant entity.

Recommended Deliverables

archive/YYYY-MM-DD-主题/
├── 00-输入材料摘要.md
├── 01-专利名称反向澄清卡-待确认.md
├── 01A-人工确认记录.md
├── 02-项目边界与依赖画像.md
├── 03-项目技术方案画像.md
├── 04-方案代码证据映射-<方案名>.md
├── 05-技术交底书-<方案名>.md
├── 05A-权利要求布局卡-<方案名>.md
├── 05B-权利要求-证据矩阵-<方案名>.md
├── 06-发明专利初稿-<方案名>.md
├── 06A-发明专利初稿自检表-<方案名>.md
├── 07-研发补充问题清单.md
└── 08-修订记录.md（迭代时生成，非每次必产）

If the current mode is candidate solution mining, first output 03-候选可专利方案清单-待人工筛选.md and 04-优先申请建议.md, and after user confirmation, proceed to targeted search.

Iteration and Version Traceability

Revisions of artifacts under the same archive/YYYY-MM-DD-主题/ directory follow these rules:

  1. Do not overwrite the original: when revising an existing artifact, save it as a new file using "main artifact name + timestamp suffix", for example 05-技术交底书-<方案名>-250622-1430.md. Multiple versions in the same directory constitute the version history, and no subdirectories are created further.
  2. Maintain 08-修订记录.md: record each revision in append-only form, including at least the revision intent, affected artifact files, whether S1...Sn changed, and the timestamp. Create it on the first revision, and only append thereafter.
  3. Access control — do not fall back to re-mining: solution-level incremental revisions only update evidence, steps, or expression on an already-confirmed solution; they must not return to T0/T1 to redo candidate mining or name clarification. If the user wants to change solutions or re-mine, a new archive/YYYY-MM-DD-主题/ directory should be opened, and it must not be mixed with the original solution's files.
  4. Step chain synchronization: if a revision causes S1...Sn to change, the disclosure document, claim layout card, claim-evidence matrix, and invention patent draft must be updated synchronously, and the affected files must be registered in 08-修订记录.md .

Default disclosure document structure

For software, algorithm, and Agent system solutions, the technical disclosure document uses the following order by default:

  1. Basic solution information
  2. Technical field
  3. Background technology
  4. Summary of the invention
  5. Description of the drawings
  6. Detailed embodiments
  7. Technical effects
  8. Alternative embodiments
  9. Code evidence summary and appendix index
  10. Matters pending confirmation by R&D / patent attorney

If multiple code paths, function names, or field names appear consecutively in the main text, it should be rewritten by falling back, moving them into 04-方案代码证据映射-<方案名>.md or the evidence appendix.

Input/Output

Input

  • Required: code files or project directory, technical description, description of innovations, candidate patent solutions; at least two of these categories must be present; if only a patent name is available, handle it as L0.
  • Optional: PRD, requirements specification, meeting minutes, technical field, application scenarios, drawing preferences, output level, applicant entity information, inventor candidates, priority information, client template.

Output

  • Patent name reverse clarification card
  • List of candidate patentable solutions
  • Project boundary and dependency profile
  • Solution code evidence mapping table
  • Algorithm/software-style specification-form technical disclosure document
  • Claim layout card
  • Claim-evidence matrix
  • Invention patent draft
  • Invention patent draft self-check table
  • List of matters pending confirmation