How the Iteration Mechanism for Existing Patent Disclosures Works in patent-disclosure-skill

The repository implements a non-destructive, timestamped iteration workflow that uses iteration_context.md to orchestrate merge or correction operations while iteration_dialog_log.py maintains a comprehensive audit trail with local and UTC timestamps for every change.

The patent-disclosure-skill repository manages evolving intellectual property documents through a robust iteration mechanism for existing patent disclosures designed to preserve complete revision histories. This system prevents destructive overwrites by automatically generating timestamped file versions and logging every merge or correction step in a centralized Markdown record.

Core Architecture of the Iteration Mechanism

The iteration mechanism operates through three coordinated components: context definition, template execution, and audit logging.

Iteration Context and Template Selection

Every iteration begins when the agent reads iteration_context.md in the prompts directory. According to the source code, this file defines the protocol for determining whether the current iteration requires merging new material using merger.md or applying corrections using correction_handler.md. The context file mandates specific inputs including the baseline disclosure markdown, any new content sections, and conditional updates to figure_plan.yaml when modifying figures for utility or appearance patents.

Output Generation and Timestamping

Each iteration produces immutable outputs following the strict naming convention {caseName}_{YYYYMMDDHHmmss}.md, ensuring chronological ordering and preventing accidental version conflicts. The companion mermaid_render.py utility then converts this markdown into a formatted .docx document suitable for formal submission, generating both the markdown source and rendered document simultaneously.

Audit Logging with iteration_dialog_log.py

After generating outputs, the system invokes iteration_dialog_log.py to append structured entries to 交底书修订对话记录.md (Disclosure Revision Conversation Log). As implemented in iteration_dialog_log.py, the script captures local and UTC timestamps, the iteration type (merge or correct), user-provided summaries, and the complete list of artifacts produced during that cycle.

Step-by-Step Iteration Workflow

The complete iteration mechanism follows this deterministic sequence:

1. Read iteration context - The agent loads iteration_context.md to determine whether to invoke the merger or correction template.

2. Prepare inputs - Gather the baseline disclosure markdown, new material additions, and update figure_plan.yaml when modifying patent figures.

3. Execute template - Process the content through either merger.md for combining new material or correction_handler.md for error remediation.

4. Generate timestamped files - Write the new disclosure as {caseName}_{YYYYMMDDHHmmss}.md and generate the companion .docx via mermaid_render.py.

5. Log the iteration - Call iteration_dialog_log.py with the case directory, iteration kind, and artifact list to append the revision record.

6. Report results - Return the new file paths and iteration summary to the user.

Practical Implementation Examples

Logging a Merge Iteration

Use this command after combining new claims or embodiments with the existing disclosure:

python skills/patent-disclosure/tools/iteration_dialog_log.py \
  --case-dir "outputs/Case123" \
  --kind merge \
  --user "Added claims for the new embodiment and updated Fig-2." \
  --summary "Merged new claims and refreshed Figure 2." \
  --artifacts "Case123_20240904_120500.md,Case123_20240904_120500.docx"

Logging a Correction Iteration

Use this command after fixing errors or clarifying existing content:

python skills/patent-disclosure/tools/iteration_dialog_log.py \
  --case-dir "outputs/Case123" \
  --kind correct \
  --user "Fixed typo in claim 5 and clarified scope of Fig-3." \
  --summary "Corrected typo and clarified Figure-3 description." \
  --artifacts "Case123_20240904_131200.md,Case123_20240904_131200.docx"

Programmatic Workflow Integration

This Python example demonstrates the complete iteration mechanism from context reading to logging:

from datetime import datetime
from pathlib import Path
import os

# Step 1: Read iteration_context.md (agent determines merge vs correct)

# Step 2: Load the latest disclosure markdown

base_md = Path("outputs/Case123/Case123_20240830_150000.md").read_text()

# Step 3: Append new material (e.g., new claims)

new_claims_text = "## New Claims\n1. A method comprising..."

merged_md = base_md + "\n\n" + new_claims_text

# Step 4: Write new timestamped file

timestamp = datetime.now().strftime("%Y%m%d%H%M%S")
new_md_path = Path(f"outputs/Case123/Case123_{timestamp}.md")
new_md_path.write_text(merged_md)

# Step 5: Generate .docx via mermaid_render.py

os.system(f"python skills/patent-disclosure/tools/mermaid_render.py -i {new_md_path}")

# Step 6: Log the iteration via iteration_dialog_log.py

os.system(
    f"python skills/patent-disclosure/tools/iteration_dialog_log.py "
    f"--case-dir outputs/Case123 --kind merge "
    f'--user "Added new claims" --summary "Merged new claims" '
    f'--artifacts "Case123_{timestamp}.md,Case123_{timestamp}.docx"'
)

Key Files in the Iteration Mechanism

File	Purpose	Source Link
iteration_context.md	Defines the iteration protocol, required inputs, and template selection logic	View on GitHub
iteration_dialog_log.py	Automates logging of each merge/correct iteration into 交底书修订对话记录.md	View on GitHub
merger.md	Template for merge-type iterations that combine new material with existing disclosures	View on GitHub
correction_handler.md	Template for correction-type iterations that fix errors in existing content	View on GitHub
mermaid_render.py	Generates formatted .docx documents and optional diagrams from markdown output	View on GitHub

Summary

• Non-destructive versioning - Every iteration creates a new timestamped file rather than overwriting previous drafts, preserving complete historical states.
• Automated audit trails - The iteration_dialog_log.py script ensures every merge and correction is recorded with precise timestamps and artifact references in 交底书修订对话记录.md.
• Template-driven workflow - The system distinguishes between additive changes (merge) and corrective changes (correction) through dedicated templates defined in iteration_context.md.
• Figure plan integration - Updates to figure_plan.yaml are tracked alongside content changes when modifying patent drawings for utility or appearance patents.

Frequently Asked Questions

How does the iteration mechanism prevent overwriting previous patent disclosure versions?

The system enforces a strict timestamped naming convention {caseName}_{YYYYMMDDHHmmss}.md for every output file. As specified in iteration_context.md, each iteration generates a new file with the current datetime suffix rather than modifying existing files, ensuring immutable version history and preventing accidental data loss.

What is the difference between merge and correction iterations?

Merge iterations utilize merger.md to add new material such as additional claims, embodiments, or technical descriptions to an existing disclosure. Correction iterations use correction_handler.md to fix errors, clarify language, or modify existing content without adding new structural elements. The iteration_dialog_log.py script records which type was performed via the --kind parameter.

How is the revision history structured and accessed?

All revisions are logged in a single Markdown file named 交底书修订对话记录.md located within the case directory. Each entry includes local and UTC timestamps, the iteration type, user-provided change summaries, and complete artifact filenames. This creates a chronological, human-readable audit trail accessible without specialized software.

When should figure_plan.yaml be updated during an iteration?

Update figure_plan.yaml whenever the iteration modifies patent figures, including adding new drawings, updating existing figure numbers, or changing reference numerals in utility or appearance patents. The iteration_context.md file mandates this update as part of the input preparation step when visual content changes accompany textual modifications.

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