/light-patent-disclosure

name: light-patent-disclosure
description: >-
  Prepare evidence-backed patent invention disclosure materials for attorney or
  patent-agent review. Use when the user asks for 专利点挖掘, 技术交底书, 现有技术/查新记录,
  claim/patent-point support mapping, invention disclosure drafts, patent figures,
  or a handoff package for a software/research/project invention. This is an
  off-DAG engineering/IP handoff skill: it does not provide legal advice, does
  not submit filings, does not guarantee novelty, grant, allowance, validity or
  registration, and emits no Light research findings or back-edges.

Patent disclosure handoff

Turn a real project or research result into an attorney-reviewable invention disclosure packet: what problem is solved, what technical means solve it, why it differs from nearby work, what embodiments support the breadth, what figures are needed, and what counsel still needs to decide.

Read [`references/patent-resource-map.md`](references/patent-resource-map.md) before jurisdiction- or filing-sensitive work. It records the peer skills, official sources, borrowed mechanisms and honest boundaries. Read [`references/patent-interview-and-search.md`](references/patent-interview-and-search.md) before patent-point mining, public search, claim-ladder drafting or attorney handoff. It contains the detailed interview, search and QC rules.

Non-negotiable boundaries

1. This skill is not legal advice and never certifies `READY_TO_FILE`. Deliver only `DRAFT`, `NEEDS_USER_INPUT`, or `READY_FOR_ATTORNEY_REVIEW`. 2. Do not guarantee grant, novelty, inventive step, non-infringement, validity, ownership, freedom to operate, or registration outcome. 3. Preserve uncertainty. If a search, date, assignee, inventor, public disclosure, foreign-filing rule, or priority fact is not verified, write `UNKNOWN`, `PLANNED`, or `UNAVAILABLE` with the next check. 4. Evidence comes from real artifacts: repository files, design docs, lab notes, papers, experiment logs, issue discussions or user-supplied records. Keep relative locators and SHA-256. Do not invent implementation details. 5. Patent figures must be programmatic/vector/manual sources such as Mermaid, Graphviz, PlantUML or SVG. Do not use AI-generated bitmap images for patent drawings. 6. Keep the skill off the research DAG. It has no stage, no `STAGE_GATES`, no `ROUTES`, no `light.findings.v1`, and no scientific back-edge.

Workflow

1. Intake the decision facts and risk triage

Ask for or mark `UNKNOWN`:

• jurisdiction and intended route: CN invention/utility model, US provisional,

US nonprovisional, PCT, EP, or undecided;

• owner/applicant, inventors/contributors, employment or sponsor constraints;
• public disclosures, papers, demos, GitHub releases, sales, thesis defense,

posters, standards submissions, and their dates;

• deadline, prior filings, priority claim, secrecy/export/confidentiality risk;
• whether a licensed attorney or patent agent will review the output.

Record `risk_triage` for public disclosure, ownership/inventorship, foreign-filing/secrecy and trade-secret redaction. Stop for the user when a public disclosure, ownership dispute, foreign filing strategy, secrecy review, or filing deadline could change the next action.

2. Build the evidence packet

Scan only files placed in scope. For each source artifact record:

• `id`, relative `path`, `sha256`, freshness/date if known;
• what claim element or embodiment it supports;
• whether private or third-party confidential content must be redacted before

sharing with outside counsel.

If the source is a paper, product demo, notebook, API contract, dataset or diagram, bind the exact locator. Do not let chat memory become evidence.

3. Mine patent points with problem-solution-effect discipline

For each candidate patent point, write:

• technical problem, not business desire;
• concrete technical means, algorithm, architecture, protocol, data structure,

control loop, signal processing, model pipeline, hardware arrangement or UI interaction rule;

• technical effect and measurable advantage;
• distinguishing features versus the closest known work;
• fallback embodiments, alternatives, parameter ranges and failure cases;
• support artifact IDs for every feature.

Prefer one strong, defensible invention story over a pile of vague features. Ask targeted questions for tacit knowledge that the repo cannot show. Keep a short inventor interview log: problem, failed alternatives, key insight, constraints, contributors, disclosure dates and known prior art.

4. Do prior-art / novelty-context work honestly

Search the relevant official or public sources available in the current environment, then record:

• databases/pages searched, query strings, date, filters and failures;
• nearest results with locators and relationship to the invention;
• whether the search is `VERIFIED`, `PLANNED`, `UNKNOWN`, or `UNAVAILABLE`.

Keep `inventor_known_prior_art` separate from `prior_art`. The former is what the team already knows; the latter is the agent-run public search log. A verified public search records `searched_sources`; if non-patent literature is not searched, write why.

Do not call this a legal novelty opinion. If search coverage is shallow, say so and list the missing source or professional search still needed.

5. Build the claim ladder

Before drafting final sections, write a claim strategy:

• broadest defensible technical point;
• dependent/fallback positions and why each is narrower;
• enablement support summary: embodiments, variants, parameter ranges, edge

cases and alternatives;

• artifact support for every strategy item.

If the broad point is unsupported, narrow it or mark it as counsel question.

6. Draft the disclosure for counsel

Use a plain, editable structure:

1. title and technical field; 2. background and nearest known approaches; 3. technical problem; 4. summary of the technical solution; 5. beneficial technical