Code Repository to Patent Delivery
Positioning
This skill is used to organize completed code projects into materials that patent attorneys can continue to draft and judge. The core goal is not to translate code into patent language, but to organize real implementations, technical problems, technical solutions, technical effects, and evidence locations into traceable invention patent drafts.
The default jurisdiction is Chinese invention patents, which are mainly applicable to software, algorithms, Agent systems, scheduling optimization, state representation, authentication, memory, context orchestration, file systems and other implementations mainly based on code.
Recommended main workflow:
text
User Materials + Code Repository
↓
Input Maturity Judgment + archive Directory
↓
Project Boundary and Dependency Profile
↓
Solution-Code Evidence Mapping
↓
Algorithm/Software Specification-Style Technical Disclosure Document
↓
Claim Layout Card + Claim-Evidence Matrix
↓
Invention Patent Draft + Draft Self-Check List
Start Gate
Before starting to read the code, confirm the following:
- Is there already a list of candidate patent solutions?
- Does the candidate list only have names, or does it already include technical problems, core implementations, technical effects, and code scope?
- Is the goal of this task a technical disclosure document, claim layout card, invention patent draft, or candidate solution mining?
- Are there PRDs, requirement descriptions, meeting minutes, client disclosure templates, existing application styles, or format requirements from patent attorneys?
- What is the archiving theme for this task, which will be used to create
archive/YYYY-MM-DD-Theme/
Patent titles are not technical solutions. If the user only provides a title or one-sentence direction, do not directly write a disclosure document or draft.
Input Maturity Diversion
| Level | Input Status | Default Action |
|---|
| T0 Name List | Only patent names, titles, or one-sentence directions | Output "Patent Title Reverse Clarification Card" and wait for user confirmation |
| T1 Direction List | Has names and business directions, but lacks technical problems, implementation paths, or effects | First supplement candidate explanations, code evidence directions, and pending confirmation questions |
| T2 Technical Solution List | Already has technical problems, core implementations, target effects, and preliminary module scope | Enter targeted retrieval, generate code evidence mapping and disclosure documents |
| T3 Evidence-Based Solution List | Already has technical solutions, code paths, key processes, and evidence levels | Review evidence and then continue to generate disclosure documents, layout cards, or drafts |
| No List | User wants to mine patent points from code | First output a list of candidate patentable solutions, then draft after manual screening |
Unconfirmed T0/T1 or automatically mined results can only be used as candidate directions, and cannot be written as customer-confirmed technical solutions.
Material Priority
When executing, read user-provided materials first, then read the code. Recommended order:
- Candidate patent solution list or title list
- PRD, product plan, requirement description
- Communication minutes, audio transcriptions, customer supplementary instructions
- Technical disclosure templates, existing application documents, patent attorney format requirements
- Code repository README, architecture documents, directory descriptions
- Source code, configuration, testing, deployment, and runtime files
If the user provides a template or sample, first extract the chapter structure, step numbers, drawing habits, and technical effect writing methods, then generate deliverables. If no template is provided, follow
references/algorithm-software-disclosure-format.md
and built-in templates.
Mandatory Specifications
Only read corresponding files when necessary, avoid loading all references into the context at once.
| Problem to Solve | File to Read |
|---|
| Algorithm/software disclosure structure, S1...Sn, code evidence post-positioning rules | references/algorithm-software-disclosure-format.md
|
| Project technical solution profile, dependency boundaries, distinction between self-developed and 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
|
| Quick access to layout card, draft, and self-check writing | references/patent-drafting-quick-reference.md
|
| Complete drafting basis, claim hierarchy, and abstract rules required | references/patent-drafting-spec.md
|
This file only retains entry points, diversion, routing, and strong rules; detailed rules will be prioritized in
in the future.
Template Routing
| Target Deliverable | Template |
|---|
| Patent Title Reverse Clarification Card | templates/patent-title-clarification-card-template.md
|
| Algorithm/Software Invention Patent Technical Disclosure Document | 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 Draft | templates/invention-patent-draft-template.md
|
| Invention Patent Draft Self-Check List | templates/invention-patent-draft-self-check-template.md
|
is a directly fillable delivery skeleton;
is the execution rules and judgment criteria. Do not merge the two.
Core Strong Rules
- Judge input maturity first, then read code details.
- User-provided solutions, templates, and samples take precedence over AI's own inferences.
- Candidate directions without manual confirmation cannot directly enter the disclosure document or patent draft.
- First create a project boundary and dependency profile to avoid writing default capabilities of third-party libraries, model platforms, or frameworks as the applicant's innovation.
- Code evidence mapping and technical disclosure document body must be layered.
- The default structure of the disclosure document body is algorithm/software specification-style, not a code inventory report.
- File paths, function names, field names, test files, and internal event names are by default included in evidence mapping or appendices; only necessary evidence summaries are retained in the body.
- The invention content is prioritized to be organized into technical problems, overall solutions, steps S1...Sn, further limitations, and technical effects.
- Specific implementation methods use example scenarios to expand input, model/state, steps, parameters, output, and alternative implementations.
- The code architecture must be understood, but the final body should be translated into technical objects, relationships, states, actions, sequences, and outputs, without displaying technical selections or module lists.
- The step numbers S1...Sn in
05-Technical Disclosure Document
05B-Claim-Evidence Matrix
06-Invention Patent Draft
- When the target is a draft, first generate the layout card and evidence matrix by default, then generate the complete draft.
- Level A evidence can enter the independent claim framework; Level B evidence is prioritized for dependent claims or preferred embodiments; Level C evidence can only enter pending confirmation items or alternative embodiments.
- The abstract is controlled within 300 words by default, without using commercial promotional language.
- Formal application documents still require review by patent attorneys.
Output Levels
| Level | Applicable Scenario | Main Deliverables |
|---|
| L0 Title Reverse Clarification | User only provides patent name, title, or one-sentence direction | Patent Title Reverse Clarification Card + Manual Confirmation Record |
| L1 Code Evidence Mapping | Candidate solutions exist, need to judge whether they fall within code implementation | Solution-Code Evidence Mapping Table |
| L2 Technical Disclosure Document | Currently the most recommended main deliverable | Algorithm/Software Specification-Style Technical Disclosure Document + Necessary Evidence Appendices |
| L2.5 Claim Layout | Need to advance to the application document layer but stabilize the claim tree first | Claim Layout Card + Claim-Evidence Matrix |
| L3 Invention Patent Draft | Complete draft required before agent writing | Specification Draft + Claim Draft + Abstract + Self-Check List |
| L4 Patentable Solution Mining | User has not summarized candidate solutions yet | Candidate Solution List + Priority Recommendations + Manual Screening Record |
Standard Execution Sequence
Tailor execution according to the target level, there is no need to output all files each time.
- Pre-read user materials to confirm the target level and template requirements.
- Create
archive/YYYY-MM-DD-Theme/
- Judge input maturity: clarify first for T0/T1, mine first if there is no list.
- Read project README, PRD, architecture, and dependency files to form a boundary profile.
- Read code around confirmed solutions, extract evidence and grade it.
- Translate engineering implementations into S1...Sn, technical features, technical effects, and alternative implementations.
- Generate the disclosure document, with the body adopting a specification-style structure and evidence placed at the end.
- If application document layer is required, generate layout card and evidence matrix.
- If a complete draft is required, generate the invention patent draft and self-check list.
- Output questions to be confirmed by R&D, patent attorneys, or application entities.
Recommended Delivery Files
text
archive/YYYY-MM-DD-Theme/
├── 00-Input Materials Summary.md
├── 01-Patent Title Reverse Clarification Card-Pending Confirmation.md
├── 01A-Manual Confirmation Record.md
├── 02-Project Boundary and Dependency Profile.md
├── 03-Project Technical Solution Profile.md
├── 04-Solution Code Evidence Mapping-<Solution Name>.md
├── 05-Technical Disclosure Document-<Solution Name>.md
├── 05A-Claim Layout Card-<Solution Name>.md
├── 05B-Claim-Evidence Matrix-<Solution Name>.md
├── 06-Invention Patent Draft-<Solution Name>.md
├── 06A-Invention Patent Draft Self-Check List-<Solution Name>.md
└── 07-R&D Supplementary Question List.md
If in candidate solution mining mode, first output
03-Candidate Patentable Solution List-Pending Manual Screening.md
and
04-Priority Application Recommendations.md
, then enter targeted retrieval after user confirmation.
Default Structure of Disclosure Document
The technical disclosure document for software, algorithm, and Agent system solutions uses the following order by default:
- Basic Solution Information
- Technical Field
- Background Technology
- Invention Content
- Description of Drawings
- Specific Implementation Methods
- Technical Effects
- Alternative Implementation Methods
- Code Evidence Summary and Appendix Index
- Items to be Confirmed by R&D / Patent Attorneys
If multiple code paths, function names, or field names appear consecutively in the body, rewrite them by moving them to
04-Solution Code Evidence Mapping-<Solution Name>.md
or evidence appendices.
Input/Output
Input
- Required: At least two of code files or project directories, technical descriptions, innovation point explanations, candidate patent solutions; if only patent names are provided, handle according to L0.
- Optional: PRD, requirement description, meeting minutes, technical field, application scenarios, drawing preferences, output level, application entity information, candidate inventors, priority information, customer templates.
Output
- Patent Title Reverse Clarification Card
- List of Candidate Patentable Solutions
- Project Boundary and Dependency Profile
- Solution Code Evidence Mapping Table
- Algorithm/Software Specification-Style Technical Disclosure Document
- Claim Layout Card
- Claim-Evidence Matrix
- Invention Patent Draft
- Invention Patent Draft Self-Check List
- List of Pending Confirmation Items