light-patent-disclosure

# 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 effects;
6. figure list and programmatic figure sources;
7. detailed embodiments, variants and fallback implementations;
8. draft patent points or draft claims with element-level support;
9. novelty/difference table;
10. open questions for attorney or patent agent review.

Claims are only drafts for review. Keep terminology consistent with the
description and avoid over-broad elements unsupported by artifacts.

### 7. Run the machine gate before delivery

Create a packet following
[`templates/patent-disclosure-packet.example.json`](templates/patent-disclosure-packet.example.json),
then ru