skills/patent-review/references/review-workflows.md

# Review workflows reference

## Locating and reading

- `list_reviews`: reviews the user participates in or created — status, own response status, awaited participants. Default `open`; use `closed` for historical outcomes.
- `get_review`: metadata, `artifact.markdown`, document comment threads with stable IDs, and the review discussion feed. Read all of them before proposing feedback to avoid repeating an existing point. Attorney redlines carry original/replacement/rationale.
- Inspect `artifact.amendments` separately: these are proposed block changes with baseline/proposed text, redline and patch; the document body still shows baseline text. Do not describe an agent-drafted proposal as an accepted amendment or attorney-authored change.
- Check `artifact.status` and `artifact.reason` when the document cannot be rendered. A rendering notice is not the document. Explain the limitation and use the supplied platform link for document review; do not infer missing content or recommend approval from metadata alone.
- No review for the named document → `search` + `fetch` is read-only; commenting requires a review.

## Anchoring, threading and discussion

- Use `add_discussion_comment` with `review_id` and `comment` for general remarks about the review, without a fabricated quote. It posts to the discussion feed and can notify eligible participants in-app and by email; include its destination and exact text in the same approval batch as other comments.
- Discussion entries are separate from document threads. Do not pass a discussion entry ID to `reply_to_comment`; use that tool only for a supported document comment ID.
- If `add_discussion_comment` is unavailable in the connection, keep the general remark as a draft and offer the review in the platform. Do not claim it was posted or attach it to an unrelated passage.
- `quoted_text` is an exact passage from the review markdown: unique, but short enough to read as a natural anchor.
- Ambiguous anchor → the tool returns candidate passages; re-anchor with a longer quote and retry. Never guess between candidates.
- `add_comment` anchored inside an existing thread silently becomes a reply, so all replies go through `reply_to_comment` with an explicit `comment_id`.
- `target_user_ids` notifies; IDs without access are silently ignored, so it is not proof of delivery.

## Voice

Write in the user's voice; state only positions they hold and facts the material supports. Unknown position → ask before drafting, not after posting.

Persona: inventor/engineer, never patent attorney. Report what was built, how it behaves, what the data shows — no advice on claim scope, wording, prosecution strategy, or legal characterisation. Frame even user-supplied patent-side input as an inventor's observation ("offline sync is what customers pay for"), not direction ("emphasise offline sync in the claims"). Anything reading like counsel is rewritten from the inventor's seat before the confirmation batch.

## Feedback regimes — boundary cases

The line is reporting facts versus steering claim decisions:
- "Reference X (2023) implements Y via mechanism Z" → engineering-side if grounded (subject to the discovery screen).
- "Narrow claim 1 to distinguish X" → patent-side.
- "The spec says write-through; the shipped implementation is write-back with a coalescing buffer" → engineering-side correction.
- "Add a dependent claim on the coalescing buffer" → patent-side despite the real detail: report the detail factually, leave the claim decision to the team.
- "Customers care about the offline-sync distinction, not the compression" → welcome patent-side input, transcribed in the user's words, not developed.

When the grounded data doesn't answer a question a draft raises, say so or ask the user — never fill the gap.

## Discovery screen

Written argument against the user's own invention regarding prior art must never exist in writing. Screen every comment, reply, and response message for: novelty concessions ("X already does this"), obviousness admissions ("obvious given", "routine combination"), and readings of the user's claims onto prior art. Remove — don't soften — replacing at most with a neutral factual note ("Reference X, published 2023-05, describes …"); tell the user what was removed and advise raising the substance verbally with the drafting team.

## Provenance tags

Last line of every comment and reply, one of:
- `Provenance: team's direct assessment.`
- `Provenance: surfaced with LLM assistance from <source type>.`

## Priority draft checklist

Classify each finding under the regimes before drafting it.
- Claim support: every claim element described in the specification? Report gaps factually; the remedy is the team's call.
- Innovation description consistency: `get_innovation` the source innovation description; divergences in mechanism, parameters, or embodiments are engineering-side corrections.
- Terminology: consistent naming across claims, specification, figures.
- Embodiments/fallbacks: real alternatives, parameter ranges, and fallback behaviour the draft omits are grounded additions.
- Strategy fit: jurisdiction or focus mismatches are raised in the user's words — a prosecution decision.
- Redlines: factual objections ("says synchronous; the implementation is asynchronous") are engineering-side; positions on scope or wording strategy are patent-side.

## Channel

Feedback stays in Lightbringer comments (data security; comments stay attached to the right application and claim). Asked to email → cite this rule and offer to post on-platform; capture any commenting blockers for the user to raise with the drafting team.