mcpbeat Sign in

Light Patent Disclosure Agent Skill

>- 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 not submit filings, does not guarantee novelty, grant, allowance, validity or registration, and emits no Light research findings or back-edges.

14k tokens
context cost
the whole folder, loaded on every use
5
files
ships runnable scripts
0
copies elsewhere
how many repositories repackaged it
505
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Light0305/Light-skills --skill light-patent-disclosure

The instruction itself

11 sections, as written by the author

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

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

before patent-point mining, public search, claim-ladder drafting or attorney

handoff. It contains the detailed interview, search and QC rules.

Non-negotiable boundaries

  • This skill is not legal advice and never certifies READY_TO_FILE.

Deliver only DRAFT, NEEDS_USER_INPUT, or READY_FOR_ATTORNEY_REVIEW.

  • Do not guarantee grant, novelty, inventive step, non-infringement, validity,

ownership, freedom to operate, or registration outcome.

  • 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.

  • 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.

  • 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.

  • 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:

  • title and technical field;
  • background and nearest known approaches;
  • technical problem;
  • summary of the technical solution;
  • beneficial technical effects;
  • figure list and programmatic figure sources;
  • detailed embodiments, variants and fallback implementations;
  • draft patent points or draft claims with element-level support;
  • 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,

then run:

python scripts/disclosure_gate.py --packet patent-disclosure-packet.json --base <project-root> --as-of 2026-07-05
python scripts/disclosure_gate.py --selftest

The gate must pass before saying the packet is ready for attorney review. It

checks risk triage, inventor-known prior art, public search coverage, claim

ladder, support mapping, figure source, QC flags and anti-overclaim language.

A failed gate means fix the packet, lower the claim, or mark the missing fact.

ACT / ASK / NEVER

ACT:

  • bind every invention feature and draft claim element to source artifacts;
  • use official/current sources for jurisdiction-specific requirements;
  • produce counsel-facing open questions, not hidden assumptions;
  • generate figures as Mermaid/Graphviz/PlantUML/SVG or other auditable vector

sources;

  • record prior-art search limits instead of pretending completeness.

ASK:

  • jurisdiction and filing route;
  • whether public disclosure has already happened and when;
  • ownership/inventor facts that are not in the repository;
  • whether to redact trade secrets before outside review;
  • whether a risky broad claim should be narrowed or left as counsel question.

NEVER:

  • submit, file, sign, pay fees, or interact with patent offices on the user's

behalf;

  • promise grant/allowance/registration, novelty, inventive step or FTO;
  • turn generated pictures into patent drawings;
  • infer inventorship, ownership, disclosure dates or legal status from code

alone;

  • route this skill into the Light research DAG.

Other skills for the same job

different authors, same section of the catalogue
Clinical Trial Protocol Skill
by anthropics
vendor ×2

Generate clinical trial protocols for medical devices or drugs. This skill should be used when users say "Create a clinical trial protocol", "Generate protocol for [device/drug]", "Help me design a clinical study", "Research similar trials for [intervention]", or when developing FDA submission documentation for investigational products.

105k tokens scripts
Autoresearch
by OpenRaiser
×1

Orchestrates end-to-end autonomous AI research projects using a two-loop architecture. The inner loop runs rapid experiment iterations with clear optimization targets. The outer loop synthesizes results, identifies patterns, and steers research direction. Routes to domain-specific skills for execution, supports continuous agent operation via Claude Code /loop and OpenClaw heartbeat, and produces research presentations and papers. Use when starting a research project, running autonomous experiments, or managing a multi-hypothesis research effort.

15k tokens
Infinite Gratitude
by lingxling
×1

Multi-agent research skill for parallel research execution (10 agents, battle-tested with real case studies).

328 tokens
Edge Candidate Agent
by BaggaT236
×1

Generate and prioritize US equity long-side edge research tickets from EOD observations, then export pipeline-ready candidate specs for trade-strategy-pipeline Phase I. Use when users ask to turn hypotheses/anomalies into reproducible research tickets, convert validated ideas into `strategy.yaml` + `metadata.json`, or preflight-check interface compatibility (`edge-finder-candidate/v1`) before running pipeline backtests.

32k tokens scripts
Minecraft Plugin Development
by github
vendor

Use this skill when building or modifying Minecraft server plugins for Paper, Spigot, or Bukkit, including plugin.yml setup, commands, listeners, schedulers, player state, team or arena systems, persistent progression, economy or profile data, configuration files, Adventure text, and version-safe API usage. Trigger for requests like "build a Minecraft plugin", "add a Paper command", "fix a Bukkit listener", "create plugin.yml", "implement a minigame mechanic", "add a perk or quest system", or "debug server plugin behavior".

13k tokens
GPT 5 4 Prompting
by openai
vendor

Internal guidance for composing Codex and GPT-5.4 prompts for coding, review, diagnosis, and research tasks inside the Codex Claude Code plugin

3k tokens
Openai Docs
by openai
vendor

Use when the user asks how to build with OpenAI products or APIs, asks about Codex itself or choosing Codex surfaces, needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; use OpenAI docs MCP tools for non-Codex docs questions, use the Codex manual helper first for broad Codex self-knowledge, and restrict fallback browsing to official OpenAI domains.

20k tokens scripts
Harness Engineering
by muratcankoylan

This skill should be used when designing autonomous agent harnesses: research loops, evaluation scaffolds, locked and editable surfaces, durable logs, novelty gates, pruning, rollback, PR preparation, and human approval boundaries.

3k tokens

How to use it

Copy the folder

Take light0305/light-patent-disclosure from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.