Lightbringer

View saved version →

---
name: innovation-capture
description: Identify, register and enrich Lightbringer innovations from a conversation, an inventor interview or authorised technical sources. Use for saving an idea, updating an innovation, extracting innovations from documents or engineering work, and patent mining. Exploration alone does not authorise saving; patent-preparation requests and document reviews are separate workflows.
---

# Innovation capture

Identify innovations and, when requested, register or enrich traceable records. An innovation can be a vague idea or a detailed technical description; it does not need to be patent-ready. Read [service conduct](references/service-conduct.md).

## Scope and context

Use the connected organisation and the user's existing technical context. Establish which sources are in scope and whether the user wants analysis, registration or an update. Carry out requested saves without asking for the same approval again. Clarify an ambiguous record, source scope or requested change before acting. An exploration-only request does not authorise saving findings.

Use the adopted IP strategy when available. Retrieve relevant strategy reports through `search` and `fetch`; distinguish proposed changes in uploaded documents or meeting notes from the adopted strategy. Record fit and uncertainty without discarding innovations for low alignment or uncertain patentability.

## Gather supported context

Adapt to the request; a conversation can lead to source exploration and back again.

- **Conversation or inventor interview:** reuse what the user already supplied. Ask focused questions about missing context, one theme at a time: the idea, problem, proposed approach, implementation, observed benefit and evidence. Separate facts, inferences and open questions.
- **Source exploration or patent mining:** read [source exploration](references/source-exploration.md). Investigate the authorised material, trace supporting evidence and retain identified innovations even when incomplete. Do not require a broad mining exercise for a single idea.

## Match, register or enrich

1. Search for the same concept with `search` and `list_innovations`; read likely matches with `get_innovation` or `fetch`. Compare the idea and mechanism, not just titles. Reuse an existing record, including a previously rejected one when factual enrichment is relevant and permitted. Preserve decisions and sources; never create a duplicate to bypass a restriction.
2. For a new record, retrieve `get_innovation_template` and read [authoring guidance](references/lightbringer-authoring.md). Draft from supported context and call `register_innovation` directly only when registration is authorised. Registration validates before creating anything. Validation errors mean nothing was registered: correct the reported fields using supported facts before retrying. On success, report the saved record and any non-blocking warnings; do not register again because of warnings. If the schema cannot represent the available information honestly, retain the innovation in the summary as pending registration and identify the missing inputs.
3. For an existing record, read its latest content with `get_innovation` and use `update_innovation` with complete replacement text for the sections being changed. Preserve earlier supported content. Follow the tool's section names; they differ from the registration payload fields. Inspect each section's `applied`/`error` result and report any unsaved changes. Do not re-register an existing record to validate an update.
4. If refinement is requested, use `start_innovation_feedback`. This is automated analysis of the description, not a novelty search or professional assessment. The response contains one `task_id`, `status`, `progress`, and available per-analysis `results`. While `queued` or `running`, poll `get_task_status` with that same `task_id`; it returns the same contract. Stop at `succeeded`, `partially_succeeded`, or `failed`, and report failures alongside available findings. Findings have readable `title` and `description` fields, with optional categories and supporting details. A `findings_error` means the findings could not be returned; report this limitation rather than claiming there were no findings or continuing to poll a terminal task. Ending the wait does not cancel analysis. Apply authorised improvements supported by the evidence; leave remaining gaps explicit.

Tasks and findings expire 30 days after creation; reading does not consume them or extend retention. Use `list_tasks`, optionally filtered by `invention_id`, to recover a lost task ID in the connected organisation. Follow `next_cursor` even if access filtering returns an empty page; listing reports recorded status without polling. `delete_task` permanently removes the user’s task and findings when requested, in any execution state, with write consent. Deletion does not cancel the analysis, delete the innovation or withdraw a service request.

## Completion

Return a chat summary of findings and actual outcomes. Include saved record IDs/links, the evidence used, related records and remaining questions. For exploration, state source coverage and distinguish identified innovations, unresolved problems and sources with no findings. Clearly separate analysis-only findings and failed or pending saves from registered records. A file is optional; local filesystem access is not required. Drawing descriptions do not establish that files were uploaded.

Registration or enrichment completes this workflow. For an explicit request to have Lightbringer prepare a selected innovation for patent filing, continue with `patent-preparation` when installed, retaining the user's stated intent. If that skill is unavailable, follow the connected `request_patent_preparation` instructions for that separate request. For review comments or decisions, use `patent-review` when installed or the connected review guidance.

Referenced files: 5

View saved version →

---
name: patent-preparation
description: Request Lightbringer's preparation of a selected innovation for patent filing and explain the returned status and next steps. Use when the user explicitly wants Lightbringer to patent an innovation or start patent preparation. Registration, general patent-service questions and review responses are separate workflows.
---

# Patent preparation

Record the user's request for Lightbringer to prepare a selected innovation for patent filing. Completion means the service confirms that preparation was requested. Read [service conduct](references/service-conduct.md).

## Identify the innovation

Use the connected organisation and resolve the selected record with `list_innovations` or `search`; read it with `get_innovation`. Clarify an ambiguous selection. If the innovation is not registered, use `innovation-capture` when installed, retaining the user's patenting intent for that concept. If capture guidance is unavailable, follow `get_innovation_template` and call `register_innovation` with supported content as part of the requested preparation. Registration validates before saving: report any missing inputs or validation errors before attempting preparation. Successful registration can include non-blocking warnings; report them without re-registering the record.

Refinement is optional. Offer it only when the user asks for it or the service reports a blocking requirement. Do not require automated feedback, a completeness interview or revisions before recording an explicit preparation request. For requested refinement or a service-reported blocker, carry the record ID and relevant gaps into the capture workflow, preserving the user's preparation intent. Do not invent technical detail or register a duplicate.

## Record the preparation request

1. Establish explicit intent to have Lightbringer prepare this innovation for patent filing. A request to finish a description, explore sources or register findings is not that intent. Do not ask for the same decision again when the user has already expressed it clearly.
2. Explain that the action requests Lightbringer's patent-preparation workflow and triggers notification emails to the assigned specialist and inventor. Call `request_patent_preparation` with the selected record identifier, using the connected tool schema.
3. Report the actual returned status and record link: `outcome="requested"` means preparation was newly requested; `outcome="already_requested"` means it was already requested and the call made no new request. Neither confirms completed preparation or email delivery. This is a professional service request: there is no `task_id`, and `get_task_status` does not track preparation or filing milestones. Do not treat the innovation ID as a task ID. State any requirements or next action supplied by the service. If the tool is unavailable or the request fails, explain that preparation has not been confirmed and offer the same record in the Lightbringer application or a continuation with the team.

## Completion and continuation

A recorded preparation request does not establish that a separate invention disclosure was created, a paid engagement was accepted or a patent was filed. Report those outcomes only if the service explicitly confirms them. Payment and acceptance steps require a human handoff.

For a subsequent review from the patent team, use `patent-review` when installed or the connected review guidance. General advice, strategy, novelty assessments and other professional-service requests are outside this workflow; use the service's available instructions and continuation routes.

Referenced files: 1

View saved version →

---
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`.

Referenced files: 2