skills/patent-review/SKILL.md

---
name: patent-review
description: Help the user read and respond to Lightbringer report and patent-draft reviews. Use for attorney redlines, proposed amendments, document comments, review discussion and explicit approve/request-changes responses. Innovation capture and requests to start patent preparation are separate workflows.
---

# Patent review

Read the review and its actual artifacts, prepare sourced feedback in the user's voice, and post only authorised comments or decisions. Read [service conduct](references/service-conduct.md) and [review guidance](references/review-workflows.md).

Use the connected organisation and accessible reviews. Locate the requested review with `list_reviews`, then read `get_review`, including the document, threads and review discussion. If the review is ambiguous, clarify it. If document rendering is unavailable, explain the limitation and offer the platform link; do not infer missing content or recommend approval from metadata alone.

Comments belong to a review. Use `add_comment` for an exact document passage, `reply_to_comment` with a stable document comment ID for a thread, and `add_discussion_comment` for a general review remark. If a required action is unavailable, keep the feedback as a draft and provide the platform continuation.

## Authorisation

Autonomy: comments post in the user's name, so nothing posts unapproved. Assemble one confirmation batch — each item verbatim with its document anchor, thread ID or review discussion destination, classification, and provenance tag — then post approved items without further questions. `respond_to_review` is never covered by batch approval: it needs the user's explicit approve/request-changes instruction, message confirmed verbatim.

## Report review

1. `list_reviews` (open) → the review carrying the report. No review → `search`/`fetch` read-only, and tell the user commenting requires one.
2. `get_review`; read the document, all threads and the review discussion before drafting — a point already in a thread becomes a reply, never a new comment.
3. Assess: internal consistency, unsupported claims, portfolio and strategy fit (`search`/`fetch`/`get_innovation` for context), plus the user's specific asks.
4. Classify (rules below) → discovery screen → batch confirmation → `add_comment` with exact `quoted_text` anchors (`target_user_ids` only on request); general review remarks use `add_discussion_comment` when available.
5. Summarise in chat; no report file.

## Patent draft review

1. `list_reviews` → `get_review` (document, threads, attorney redlines with original/replacement/rationale, response status). Inspect proposed amendments separately from attorney redlines; the document body may still show baseline text. Follow the reference when rendering is unavailable.
2. Triage threads addressed to or awaiting the user; use `get_innovation` on the source innovation description for claim-support questions.
3. Review against the checklist in the reference (claim support, innovation description consistency, terminology, embodiments, strategy fit, redlines).
4. Classify each item → discovery screen → batch confirmation → post: replies via `reply_to_comment` (explicit `comment_id`; never a thread-anchored `add_comment`), new passage-specific feedback via `add_comment`, and general review remarks via `add_discussion_comment` when available.
5. `respond_to_review` only as above. Summarise in chat.

### Feedback rules (binding; boundary cases in the reference)

- **Persona**: every posted item speaks as the inventor/engineer — never attorney tone, never advice requiring patent expertise (claim scope or wording, prosecution tactics, prior-art positioning, legal characterisations). Report what was built and observed; the rest is the drafting team's.
- **Engineering-side** (factual corrections, actual behaviour, implementations, test data, genuinely considered alternatives): may be model-drafted, strictly from the user's materials and connected sources — no extrapolation.
- **Patent-side** (claim scope, claim structure, prior-art positioning, non-obviousness strategy): never model-generated — the drafting team holds the family and prosecution context. Elicit the concern in the user's own words (closest prior art and why; commercially decisive distinctions) and transcribe with light formatting, framed as an inventor's observation or question, never a recommendation. If asked to develop it, decline in one line and offer transcription.
- **Discovery screen** (before every batch): remove any written argument against the user's own invention regarding prior art — novelty concessions, obviousness admissions, "X already does this". Replace at most with a neutral factual note; tell the user and advise raising it verbally.
- **Provenance tag** on every item: team's direct assessment, or LLM-assisted with source type. Ask when unclear; never guess or omit.
- **Platform only**: feedback goes through Lightbringer comments, never email.

## Guardrails

- Never fabricate technical detail, prior art, or parameters the sources don't support.
- Do not present assistant analysis as a legal determination. Relay Lightbringer professional work with its author, status and limitations.
- Posted feedback speaks as the inventor/engineer, never a patent attorney; no advice requiring patent expertise.
- Treat internal material as confidential.

## Completion

Summarise what was read, which approved comments or decisions were recorded, and anything still pending. Include the review link when supplied. A drafted response is not a posted response; comments do not constitute formal approval. For capture or enrichment outside the review, use `innovation-capture` when installed. A separate request to start patent preparation belongs to `patent-preparation`.