* fix(skills): move version into metadata and normalize to semver 29 skills declared `version` at the top level of their frontmatter. The schema reads it from `metadata`, so tooling that follows the schema either misses it or has to special-case the top level. Three motion skills also declared `version: 1.0`, which is not a valid semantic version; normalized to `1.0.0`. No behavioral change — frontmatter metadata only. * fix(skills): state activation triggers in skill descriptions 148 skills described what they cover but never named the situation that should trigger them. Since the description is what Claude matches against to decide whether to load a skill, a description without a trigger makes activation guesswork — the skill is either missed or loaded at the wrong time. Added a "Use when ..." clause to each, derived from the skill's own body (most already stated the trigger under "## When to Use" or in the opening line; that intent is now reflected in the frontmatter where it is actually read from). Descriptions were only appended to; no existing wording was removed. * fix(skills): sync activation triggers into the Codex skill mirror 10 of the skills whose descriptions changed are also mirrored under `.agents/skills/`, where the description was previously a verbatim copy. Left alone, the two surfaces would disagree about when the skill applies. Only the description line is synced; the Codex copies keep their reduced frontmatter, since that validator accepts only name, description, metadata, license, and allowed-tools. * fix(skills): correct three activation clauses from review - autonomous-loops: the clause pulled new loop work into a skill that its own body marks as a compatibility shim retained for one release. It now points at the canonical continuous-agent-loop instead. - continuous-learning: the description carried the v1 routing directive twice; collapsed to one. - homelab-pihole-dns: the clause fired on any broken home DNS. Narrowed to tasks that actually involve Pi-hole. * chore: retain current main lockfile --------- Co-authored-by: Çağrı Solakoğlu <cagri.solakoglu@vtcenerji.com> Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
6.2 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| uspto-database | USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs. Use when a task needs official United States patent or trademark records from USPTO systems. |
|
USPTO Database
Use this skill when a task needs official United States patent or trademark records from USPTO systems.
When to Use
- Searching granted patents or pre-grant publications.
- Checking patent application status, file-wrapper data, assignments, or public prosecution history.
- Looking up trademark status, documents, or assignment history.
- Building reproducible prior-art, portfolio, or IP landscape research logs.
- Comparing USPTO records with secondary tools such as Google Patents, Lens.org, Semantic Scholar, or company patent pages.
Do not use this skill to give legal advice. Treat it as a data-gathering and record-verification workflow.
Source Selection
Prefer official USPTO or USPTO-supported surfaces first:
- Open Data Portal (ODP): current home for migrated USPTO datasets and APIs.
- Patent File Wrapper: public patent application bibliographic data and file wrapper records.
- PatentSearch API: PatentsView search API for granted patents and pre-grant publication datasets.
- TSDR Data API: trademark status and document retrieval.
- Patent and Trademark Assignment Search: ownership transfer records.
- PTAB data in ODP: Patent Trial and Appeal Board proceedings.
Use secondary sources only as convenience indexes. When the answer matters, cross-check the official record.
Authentication and Secrets
Many USPTO API flows require an API key. Store keys in environment variables or a secret manager, never in committed files or pasted transcripts.
Common environment names:
export USPTO_API_KEY="..."
export PATENTSVIEW_API_KEY="..."
For PatentSearch, send the key with the X-Api-Key header. For TSDR, follow
the current USPTO API Manager instructions and rate-limit guidance.
PatentSearch Workflow
Use PatentSearch for broad patent and pre-grant publication search when the question is about trends, inventors, assignees, classifications, dates, or portfolio slices.
Workflow:
- Identify the endpoint from the current PatentSearch reference or Swagger UI.
- Build a JSON query with explicit filters.
- Request only the fields needed for the analysis.
- Sort and paginate deterministically.
- Record the endpoint, query body, date, data currency note, and result count.
Python request skeleton:
import os
import requests
API_KEY = os.environ["PATENTSVIEW_API_KEY"]
BASE = "https://search.patentsview.org/api/v1"
payload = {
"q": {
"_and": [
{"patent_date": {"_gte": "2024-01-01"}},
{"assignees.assignee_organization": {"_text_any": ["Google", "Alphabet"]}},
]
},
"f": ["patent_id", "patent_title", "patent_date"],
"s": [{"patent_date": "desc"}],
"o": {"per_page": 100, "page": 1},
}
response = requests.post(
f"{BASE}/patent/",
headers={"X-Api-Key": API_KEY, "Content-Type": "application/json"},
json=payload,
timeout=30,
)
response.raise_for_status()
print(response.json())
Before reusing a query, verify current endpoint names, field paths, request parameters, and API-key availability in the live PatentSearch docs.
Trademark/TSDR Workflow
Use TSDR when the task needs trademark case status, documents, images, owner history, or prosecution events.
Workflow:
- Normalize the serial number or registration number.
- Check the current TSDR API instructions and required API-key header.
- Fetch status first, then documents only if needed.
- Respect the lower rate limit for PDF, ZIP, and multi-case downloads.
- Capture retrieval date and serial/registration identifier in the output.
For large trademark pulls, prefer documented bulk-data flows rather than screen-scraping public pages.
File Wrapper and Prosecution History
For application status, transaction history, and prosecution documents:
- Start with ODP Patent File Wrapper search.
- Use exact identifiers when available: application number, publication number, patent number, or party name.
- Record whether the record is a granted patent, pre-grant publication, or pending application.
- Cross-check document dates and status against the record detail page before citing them.
Assignment Workflow
For patent or trademark ownership:
- Search official assignment data by patent/application/registration number, assignor, assignee, or reel/frame when available.
- Record conveyance text, execution date, recordation date, and parties.
- Distinguish assignment records from current legal ownership conclusions.
- If ownership is material, flag the result for attorney or subject-matter review.
Reproducible Output
Every USPTO research pass should include a log table:
| Source | Date searched | Identifier/query | Filters | Results | Notes |
| --- | --- | --- | --- | ---: | --- |
| PatentSearch | 2026-05-11 | `assignee=Alphabet AND date>=2024` | patent endpoint | 118 | API docs checked before run |
| TSDR | 2026-05-11 | `serial=90000000` | status only | 1 | API-key flow, no document bulk pull |
For final writeups, separate:
- official record facts
- inferred analysis
- secondary-source convenience matches
- unresolved gaps or records that require legal review
Review Checklist
- Did you use an official USPTO or USPTO-supported source first?
- Did you verify current endpoint and field names before running code?
- Are API keys kept out of files, shell history, and output logs?
- Does the query log include the date searched and exact request shape?
- Are rate limits respected?
- Are legal conclusions avoided or explicitly escalated?
- Are secondary sources labeled as secondary?