Update to Lightbringer

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,36 +1,43 @@
 ---
 name: patent-review
-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.
+description: Help the user read and respond to Lightbringer Strategy, report, patent-draft and validation reviews. Use for review instructions, attorney redlines, proposed amendments, document comments, review discussion, validation country selection 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).
+Read the review, its instructions 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 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.
+Use 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`), its type and the available Strategy, report, case and innovation references. Do not relabel a Strategy review as a report, and do not handle an unrecognised review type as a patent draft. When the host presents the review list as a component, let it serve as the list; do not restate every review in chat. Then read `get_review`, including the instructions, the document, threads and review discussion. Show the review's instructions before interpreting the material; if none are recorded, say so instead of supplying a brief. 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. 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.
+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. 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. `set_validation_countries` is not covered by batch approval either: it needs the user's explicit complete selection. These review tools can trigger in-app or email notifications; posting success is not proof of notification delivery.
 
 ## Strategy or report review
 
 1. `list_reviews` (open) → the review carrying the selected Strategy or 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.
+2. `get_review`; read the instructions, 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 against the instructions: 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.
+1. `list_reviews` → `get_review` (instructions, 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).
+3. Review against the instructions and 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.
 
+## Validation review
+
+1. `get_review` → the instructions and the recommended and currently selected countries in `validation`.
+2. Ask for the user's complete intended selection. Do not choose validation scope for the user. An unchanged selection needs no write.
+3. Before `set_validation_countries`, explain that it replaces the whole selection and returns earlier approvals to pending, and that restoring an earlier list does not restore them. Only a reviewer who has not yet approved, or a specialist, can change an open review.
+4. Read back with `get_review` and confirm the saved selection. Selection does not approve the review; approval is a separate `respond_to_review` decision as above. If the selection tool is not advertised, continue in the platform.
+
 ### 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.
@@ -49,4 +56,6 @@
 
 ## 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`.
+Summarise what was read, which approved comments, selections 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, and personal approval does not establish that the review is closed. For capture or enrichment outside the review, use `innovation-capture` when installed. A separate request to start patent preparation belongs to `patent-preparation`.
+
+If useful assistance leaves a material customer problem unresolved, follow the [unresolved-needs guidance](references/unresolved-needs.md). Keep helping; reporting is not a prerequisite and requires approval of the exact report and recipient.