agentsclimarketplace
Sign in

Patent bilingual qa

Skill orionoxe/patent-agent-skills/patent-bilingual-qa

Patent bilingual QA for translating or reviewing patent claims, specifications, office actions, and prosecution papers. Use for source-target alignment, patent terminology consistency, scope-changing omissions or additions, claim dependencies, reference numerals, numbers, units, formulas, and bilingual DOCX redlines.From its SKILL.md

Install
npx -y skills add orionoxe/patent-agent-skills --skill patent-bilingual-qa

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, 950 tokens by cl100k_base, as published. Nobody here has run it

Patent Bilingual QA

Treat every translation as a scope-preservation review. The deliverable is an auditable bilingual record, not merely fluent target-language prose.

Modes

  • Translate + QA: create a target draft, then run the full review.
  • Existing-translation QA: compare an existing target against the authoritative source.
  • Terminology audit: review only defined terms and repeated technical concepts.

Steps

1. Fix the translation brief

Record the source of truth, target language, filing jurisdiction, document type, application or matter identifier, confidentiality constraints, client style guide, approved glossary, and prior family translations.

If the authoritative source, target language, or document type is unknown, ask for it before substantive work. Treat a machine-readable copy as convenience evidence; page images or the filed document remain authoritative where OCR is uncertain.

Completion criterion: templates/translation-brief.md is complete and every input file is listed with a SHA-256 hash.

2. Build the segment map

Assign stable IDs before translating or reviewing:

  • CLM-<claim>-<limitation> for claim limitations.
  • SPEC-<section>-<paragraph> for specification paragraphs.
  • FIG-<figure>-<item> for drawing text and reference numerals.
  • OA-<ground>-<paragraph> for office-action passages.

Preserve one source segment per row. Split a segment only when the legal or technical relationship remains explicit. Never merge separate claim limitations into an untraceable target sentence.

Completion criterion: every source segment is represented exactly once in the segment map, including headings, tables, formulas, footnotes, and drawing labels.

3. Establish the termbase

Apply the precedence rules in references/terminology-policy.md. Record each selected term, source, status, subject field, and any forbidden alternatives.

Completion criterion: every defined term and every technical noun phrase repeated three or more times has a termbase entry or an explicit no-entry decision.

4. Translate or load the target

Preserve claim logic before naturalness: actors, objects, modifiers, conditions, alternatives, sequence, polarity, ranges, and open or closed transitions. Mark source ambiguity as [SOURCE-AMBIGUITY] rather than resolving it silently.

When reviewing an existing translation, keep the received file immutable. Make proposed edits in a copy with tracked changes or a side-by-side issue register.

Completion criterion: every target segment is linked to its source segment and all unresolved translation choices are marked.

5. Run the four-pass QA

Read references/qa-rules.md and apply all four passes:

  1. Coverage and alignment.
  2. Scope and logic.
  3. Mechanical invariants.
  4. Terminology and target-language quality.

Run scripts/check_invariants.py on text-exported source and target files. Its findings are candidates for human review, not automatic legal conclusions.

Completion criterion: each segment has a recorded status and every script finding is resolved, accepted with rationale, or left as an explicit blocker.

6. Classify and propose corrections

Use the issue severities and output contract in references/output-contract.md. Every issue must show source text, target text, proposed correction, rationale, confidence, and reviewer decision.

Apply P2 editorial corrections to a working copy when they do not affect meaning, and log them. Keep P0 scope-critical and P1 material corrections as proposals until a reviewer accepts them.

Completion criterion: no issue is missing an owner or disposition; no P0 issue is silently incorporated into the clean target.

7. Deliver the review package

Produce the files required by references/output-contract.md. If DOCX input is involved, use the available document-editing capability for tracked changes and comments. Preserve the original file.

Completion criterion: the package includes the authoritative-source hashes, segment map, termbase, issue register, review summary, and redline; a clean target is labeled draft until P0/P1 decisions are closed.

Guardrails

  • Confidential material stays within user-authorized systems. Public web searches use abstracted terminology, not unpublished invention details.
  • A cited term or rule carries its source and retrieval date. Current official sources outrank remembered practice.
  • Back translation is an anomaly detector only.
  • Filing, certification, and final scope decisions remain with the responsible patent professional.

References

  • Read references/qa-rules.md for every full review.
  • Read references/terminology-policy.md whenever terminology is selected or changed.
  • Read references/output-contract.md before creating deliverables.
  • Read references/official-sources.md when a term or jurisdiction rule needs external verification.

What ships with it: 13 files

13.4 KB alongside SKILL.md, 1 of them executable

references/

scripts/

templates/

tests/

Gives 0 of the 12 instructions most legal skills give in 950 tokens

Counted across 234 of the 234 authors here whose files we hold, read 2026-08-07

  • Use text operators for text fieldsin 11 of 234, across 6 files
  • Consult qualified counsel before usein 11 of 234, across 3 files
  • Use PatentSearch API for patent searchesin 10 of 234, across 5 files
  • Confirm jurisdiction, employment type, and required clausesin 9 of 234, across 2 files
  • Choose a document template and tailor role-specific termsin 9 of 234, across 2 files
  • Validate compensation, benefits, and compliance requirementsin 9 of 234, across 2 files
  • Add signature, confidentiality, and IP assignment terms as neededin 9 of 234, across 2 files
  • Open the implementation playbook for detailed templatesin 9 of 234, across 2 files
  • Use TSDR for trademark data retrievalin 9 of 234, across 4 files
  • Ask for clarification if required inputs are missingin 8 of 234, across 2 files
  • Set the USPTO_API_KEY environment variablein 8 of 234, across 3 files
  • Use the uspto-opendata-python library for PEDSin 8 of 234, across 3 files

Said here and by no other author read

  • ask for missing authoritative source target language or document type
  • record the translation brief and hash every input file
  • assign stable segment ids to all source text
  • never merge separate claim limitations into one sentence
  • create a termbase entry for repeated technical noun phrases
  • mark source ambiguity rather than resolving it silently

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,645. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.