Update to Lightbringer

{
  "description": "Help the user read and respond to Lightbringer Strategy, 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.",
  "included_files": [
    {
      "relative_path": "references/review-workflows.md",
      "size_in_bytes": 6381
    },
    {
      "relative_path": "references/service-conduct.md",
      "size_in_bytes": 1599
    }
  ],
  "name": "patent-review",
  "skill_md_contents": "---\nname: patent-review\ndescription: Help the user read and respond to Lightbringer Strategy, 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.\n---\n\n# Patent review\n\nRead 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).\n\nUse the connected organisation and accessible reviews where the user is a participant or creator. Locate the requested review with `list_reviews`, preserving its `target` (`strategy`, `report` or `document`) and available Strategy, report, case and innovation references. Do not relabel a Strategy review as a report. 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.\n\nComments 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.\n\n## Authorisation\n\nAutonomy: 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. Keep the optional response message within 2,000 characters, including any provenance text; if a longer message needs shortening, get approval for the revised text before sending. An approval cannot be withdrawn through this tool. These review tools can trigger in-app or email notifications; posting success is not proof of notification delivery.\n\n## Strategy or report review\n\n1. `list_reviews` (open) → the review carrying the selected Strategy or report. No review → `search`/`fetch` read-only, and tell the user commenting requires one.\n2. `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.\n3. Assess: internal consistency, unsupported claims, portfolio and strategy fit (`search`/`fetch`/`get_innovation` for context), plus the user's specific asks.\n4. 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.\n5. Summarise in chat; no report file.\n\n## Patent draft review\n\n1. `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.\n2. Triage threads addressed to or awaiting the user; use `get_innovation` on the source innovation description for claim-support questions.\n3. Review against the checklist in the reference (claim support, innovation description consistency, terminology, embodiments, strategy fit, redlines).\n4. 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.\n5. `respond_to_review` only as above. Summarise in chat.\n\n### Feedback rules (binding; boundary cases in the reference)\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **Provenance tag** on every item: team's direct assessment, or LLM-assisted with source type. Ask when unclear; never guess or omit.\n- **Platform only**: feedback goes through Lightbringer comments, never email.\n\n## Guardrails\n\n- Never fabricate technical detail, prior art, or parameters the sources don't support.\n- Do not present assistant analysis as a legal determination. Relay Lightbringer professional work with its author, status and limitations.\n- Posted feedback speaks as the inventor/engineer, never a patent attorney; no advice requiring patent expertise.\n- Treat internal material as confidential.\n\n## Completion\n\nSummarise 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`.\n"
}