Element-Based Lawsuit Document Generator

Problem context

Converting a traditional narrative lawsuit document into a court-style element-based form often requires manually separating the case type, parties, amounts, dates, and requested relief before filling a fixed template. When the source material is a .txt, .md, .docx, .pdf, or scanned image, this process is repetitive and prone to missed fields, especially checkboxes and table regions.

How it works

The skill targets 11 professional categories, 58 case types, and 104 templates, including complaints, answers, applications, and opinion statements. The pipeline includes:
- File parsing: reads text, documents, and PDF files, and can use OCR to extract text from images when needed.
- Case classification: matches keywords offline without relying on an external model, and returns candidate case types when confidence is low.
- Template retrieval: uses local templates first, and can download blank templates from the template repository and cache them on first use.
- Element extraction: distinguishes element-based input from traditional narrative input, then extracts key fields such as parties, amounts, and dates.
- Region filling: writes fields into the corresponding template regions using a paragraph-region index, and uses before_checkbox to target specific checkboxes so multiple □ marks on the same line are less likely to be checked by mistake.

Limits

It is best suited for cases where the underlying facts are already clear and the goal is to produce a standardized element-based document. If the source document is ambiguous, the case type is hard to identify, the template region is missing, or image recognition is poor, manual review is still required. The skill emphasizes local processing and does not upload document content, but image OCR and PDF parsing depend on optional dependencies.