How to Detect and Handle Missing Materials During Patent Application Drafting

The material_gate tool in handsomestWei/patent-disclosure-skill acts as a pre-flight validator that scans case directories for required artifacts—disclosure documents, schemas, and figure assets—exiting with code 2 if any mandatory material is absent before drafting begins.

Missing technical disclosures or schema files can halt automated patent generation workflows. The open-source handsomestWei/patent-disclosure-skill repository provides a dedicated material_gate utility that automatically detects and reports material gaps before any drafting logic executes. This article examines the validation pipeline implemented in skills/patent-application/tools/material_gate.py to ensure your case directories are complete.

Core Validation Logic in check_case

The gatekeeper functionality resides in the check_case function, spanning lines [42‑87] and [92‑124] of material_gate.py. This method orchestrates a five-stage validation pipeline that returns a dictionary with four critical keys: ok (boolean success flag), type (resolved patent category), missing (list of absent artifacts), and files (located resource paths). The function only returns ok: true when the missing list remains empty.

Locating the Technical Disclosure Document

The first validation stage ensures the presence of a technical disclosure document. The find_disclosure() helper (lines [83‑101]) scans the case directory for files matching either a timestamp pattern (*_YYYYMMDDhhmmss.md|docx) or content markers (# 技术交底书 or **专利类型**).

If no matching document is discovered, the string "disclosure" is appended to the missing list at lines [46‑47], immediately flagging the case as incomplete.

Patent Type Detection and Ambiguity Resolution

When the user omits the --type argument, the tool attempts automatic inference. The detect_type_from_disclosure() method (lines [104‑114]) parses the disclosure file for the line **专利类型**: to determine whether the case represents an invention, utility_model, or design.

If auto-detection fails, the tool falls back to schema-based heuristics implemented at lines [62‑73]:

• Presence of structure_schema.yaml defaults to utility_model
• Presence of appearance_schema.yaml defaults to design
• Absence of both schemas assumes invention

When both structure and appearance schemas coexist without a detectable patent type, the validator adds "ambiguous_type" to the missing list (lines [66‑67]), forcing explicit clarification before proceeding.

Schema and Figure Plan Requirements

The tool enforces schema completeness through the _first_file() utility (lines [63‑68]), which selects the first matching file from predefined name patterns. Missing schemas trigger specific error keys:

• Absent structure_schema.{yaml,json} adds "structure_schema" (lines [54‑56])
• Absent appearance_schema.{yaml,json} adds "appearance_schema" (lines [58‑60])

The validator also locates figure_plan.{yaml,json} to verify that visual asset specifications exist before drafting begins.

Asset Validation for Line Art and Photos

For utility_model and design cases, the tool validates physical assets referenced in the figure plan. The _load_mapping() function (lines [78‑84]) loads the YAML/JSON plan, while in_disclosure_figures() (lines [28‑33]) filters entries marked use_in_disclosure.

Each asset undergoes existence verification via resolve_asset() (lines [17‑25]), which confirms the file path exists on disk. The validator maintains two counters:

• lineart_ok increments for valid technical drawings
• photo_ok increments for valid photographs

If lineart_ok remains zero, "lineart" joins the missing list (lines [99‑100]). For design patents specifically, a zero photo_ok count triggers "photo" addition (lines [115‑116]).

CLI Output and Exit Codes

The command-line interface provides machine-parseable status reporting. When validation fails, the tool prints:

APPLICATION_GATE: ok=0 type=- missing=disclosure,lineart hint=run_disclosure

Exit status 2 indicates material deficiency, while exit code 0 accompanies the success message:

材料齐全，类型=utility_model。继续申请底稿，勿改写交底目录凑文件。

This strict gating prevents downstream drafting logic from executing against incomplete inputs.

Usage Examples

Run the validator against a case directory with automatic patent type detection:

python skills/patent-application/tools/material_gate.py \
  --case-dir outputs/MyCase123

Explicitly specify a utility model to bypass inference:

python skills/patent-application/tools/material_gate.py \
  --case-dir outputs/MyCase123 \
  --type utility_model

Override the disclosure document search with a specific file path:

python skills/patent-application/tools/material_gate.py \
  --case-dir outputs/MyCase123 \
  --disclosure outputs/MyCase123/TechDisclosure_20240101120000.md

Summary

• The material_gate.py script serves as a mandatory pre-flight check for the handsomestWei/patent-disclosure-skill workflow.
• The check_case function returns a structured report containing ok, type, missing, and files keys.
• Validation covers disclosure documents (via find_disclosure), patent type resolution (via detect_type_from_disclosure), schema presence, and figure asset existence (via resolve_asset).
• Missing materials trigger specific error keys including "disclosure", "structure_schema", "appearance_schema", "lineart", "photo", and "ambiguous_type".
• The tool exits with status code 2 when materials are missing, ensuring no drafting occurs against incomplete case directories.

Frequently Asked Questions

What specific file patterns does the tool recognize for technical disclosures?

The find_disclosure() function recognizes files matching *_YYYYMMDDhhmmss.md|docx timestamp patterns, or any markdown/DOCX containing the Chinese headers # 技术交底书 or **专利类型**. If none match, the tool reports "disclosure" as missing.

How does material_gate determine whether a case is an invention, utility model, or design?

The tool first attempts to parse the **专利类型**: field from the disclosure document using detect_type_from_disclosure(). If that fails, it checks for schema files: structure_schema.yaml indicates utility model, appearance_schema.yaml indicates design, and neither defaults to invention. The presence of both schemas without a detected type triggers an "ambiguous_type" error.

What happens if figure assets are referenced but missing on disk?

The resolve_asset() function verifies each line art or photo path specified in the figure plan. Missing assets increment specific counters. For utility models, zero line art adds "lineart" to the missing list; for designs, zero photos adds "photo". The tool exits with code 2 until these assets are provided.

Can I run the validator without specifying the patent type manually?

Yes. When executed without the --type argument, the tool attempts automatic inference from the disclosure document content. If auto-detection succeeds, the resolved type appears in the output; if it fails, the tool relies on schema heuristics or reports "patent_type" as missing when inference is impossible.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}