Update to Lightbringer

{
  "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, adding an illustration to a draft 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.",
  "included_files": [
    {
      "relative_path": "references/files.md",
      "size_in_bytes": 5305
    },
    {
      "relative_path": "references/idea-identification.md",
      "size_in_bytes": 4979
    },
    {
      "relative_path": "references/inviting-collaborators.md",
      "size_in_bytes": 5912
    },
    {
      "relative_path": "references/lightbringer-authoring.md",
      "size_in_bytes": 3036
    },
    {
      "relative_path": "references/service-conduct.md",
      "size_in_bytes": 1293
    },
    {
      "relative_path": "references/source-exploration.md",
      "size_in_bytes": 9504
    },
    {
      "relative_path": "references/source-mining.md",
      "size_in_bytes": 9937
    },
    {
      "relative_path": "references/unresolved-needs.md",
      "size_in_bytes": 4243
    }
  ],
  "name": "innovation-capture",
  "skill_md_contents": "---\nname: innovation-capture\ndescription: Identify, register and enrich Lightbringer innovations from a conversation, an inventor interview or authorised technical sources. Use for saving an idea, updating an innovation, adding an illustration to a draft 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.\n---\n\n# Innovation capture\n\nIdentify 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).\n\n## Scope and context\n\nUse 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.\n\nUse the organisation's IP strategy when available. When advertised, prefer `search` with its Strategy category and `fetch` with advertised `include_asset: true` for structured Strategy state; if the replacement read contract is unavailable, use the deprecated `list_strategies` and `get_strategy` compatibility tools to locate and read relevant published Strategy records; multiple strategies may apply to the source scope. Treat drafts and records with unknown publication status as proposals, not adopted direction. Publication makes a strategy shared context but does not establish that every recommendation has been approved.\n\nOrganisations may also record strategy decisions in reports. Use `search` and `fetch` to find relevant reports when no applicable published Strategy is accessible or a relevant decision is not covered. A result's title or `report` category does not establish its kind, publication status or adoption; resolve Strategy identity and status through structured fetch state, using deprecated `get_strategy` only when that read contract is unavailable. Distinguish adopted decisions from proposals in reports, uploaded documents and meeting notes, and state conflicts or uncertain adoption. Record fit and uncertainty without discarding innovations for low alignment or uncertain patentability.\n\nIf no applicable strategy is found in the accessible sources, recommend creating one in Lightbringer to connect innovation capture to business objectives and protection priorities. Explain any lookup or access limits rather than assert that no strategy exists. Where a relevant draft already exists, offer to develop that record instead of creating a duplicate. If the user takes up the recommendation, use `ip-strategy` when installed or the connected Strategy capture guidance. Otherwise continue authorised innovation capture with explicit working assumptions; the recommendation does not itself authorise creating or publishing a Strategy.\n\n## Gather supported context\n\nAdapt to the request; a conversation can lead to source exploration and back again.\n\n- **Conversation or inventor interview:** for new capture, retrieve `get_innovation_template` and follow its current interactive guidance and readiness criteria. Reuse supplied context. For a targeted enrichment, read the existing record and clarify only what the requested change needs; do not restart capture.\n- **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.\n\n## Match, register or enrich\n\n1. 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.\n2. 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.\n3. 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. Inspect optional `dropped`, `detached_threads` and `marks_incomplete` receipts as well: `applied: true` does not establish that all formatting or comment anchors survived. Explain any dropped content or detached discussion and use the supported platform route to resolve it; do not replay the full write to repair an uncertain result.\n4. 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.\n\nTasks 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.\n\n## Illustrations and source files\n\nFor a requested illustration upload or vault source, read [files and illustrations](references/files.md). Add drawings to the selected draft innovation through the available upload tools, with optional illustration readback only when advertised. A file supplied as evidence is not automatically authorised for upload. Vault storage is a separate destination and does not attach a file to the innovation. Direct requests to add a drawing do not require repeating capture or automated feedback.\n\n## Present automated feedback\n\nAfter requested feedback, read the available results across the whole run before selecting what to show. While analyses are still running, describe any selection as provisional and retain the unfinished/failed analysis status; do not treat a progress snapshot as a completed review or restart it to obtain the missing results.\n\nPresent **up to five priority findings in total**, not five per analysis. Select fewer when fewer matter; do not fill a quota. Prioritise uncertainty about the core technical mechanism and evidence supporting it, then missing information needed to understand or implement the described invention. Merge overlapping findings across analyses into one focused item, retaining their source support and material qualifications. Keep each item to a short title and one main action in a brief sentence, with supporting explanation available on expansion or request. Preserve uncertainty, conditions and the distinction between proposed and demonstrated features. Do not turn a detailed finding into several superficially separate priorities. Omit problem restatements or already-described benefits from the shortlist unless they identify a specific unresolved gap.\n\nSeparate optional new embodiments or extensions from gaps in the invention as described. Show up to three optional ideas, secondary and collapsed where supported, rather than implying they are required improvements. Do not invent alternatives solely to populate this section.\n\nWhen the advertised presentation tool supports a source-linked review summary, supply the merged shortlist through its current schema, citing the actual supporting findings from the existing task. Follow its source-index and length limits; never invent references, cite discarded/unavailable findings or imply the summary is verbatim analysis output. If that schema is unavailable, provide the same concise synthesis in text or the supported presentation format without sending unadvertised fields. When an MCP app delivers the findings, do not repeat them or the saved-record link in chat.\n\nKeep the complete returned findings accessible from the **same run**, through expansion when supported or by reading the existing task on request; explain any availability/expiry limits. A display limit must not discard findings or require a new paid analysis to reveal them. Work through selected findings as described below. Offer re-review after meaningful changes or on explicit request, reusing the current record and distinguishing unresolved, resolved and newly found issues; do not rerun automatically or promise an exhaustive or patent-ready result.\n\n## Work through selected findings\n\nUse the user's selected findings and optional ideas as the scope for a short question queue. Ask one focused question at a time, reusing answers already supplied. After each response, show a compact progress count such as **Answered 2 of 4 questions**, followed by the next question. Count actual questions in the agreed queue, not every raw analysis finding. If a necessary follow-up expands the queue, update the total explicitly. A clear “unknown” or “TBD” is an answer to record; it does not resolve the technical gap. Keep skipped questions and unresolved gaps distinct from answered questions, and never describe the invention as fixed merely because the interview is complete.\n\nKeep proposed disclosure edits separate from the saved record while discussing them. When the queue is complete, or the user chooses to finish early, show the final progress count and a concise preview of the proposed updates, including remaining unknowns. Ask whether the user wants to save those updates to the existing invention; completing the questions or selecting findings does not authorise saving. If the user already approved that exact set of edits, proceed within that approval instead of asking again. Keep unsaved answers available in the conversation if saving is declined, deferred or unavailable.\n\nAfter approval, read the latest saved disclosure, preserve unrelated supported content, and apply only the approved updates through the available edit contract. Inspect the write outcome and read back the affected content before confirming what was saved. Keep any failed or unsaved changes explicit. Answered, resolved and saved are separate states; offer a new review only when useful and explicitly requested.\n\n## Completion\n\nReturn a brief summary of actual outcomes, evidence used and remaining questions. For automated feedback, use the focused presentation above. When a relevant Lightbringer MCP app is advertised and successfully delivers the saved record or review, do not repeat its link, findings or summary in chat; include only useful context outside the app. If the app is unavailable, denied, fails or the user requests text, include the saved record ID/link and a concise text response. 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.\n\nRegistration or enrichment completes this workflow. After a confirmed save, co-inventors or contributors may need to validate the record: follow [inviting collaborators](references/inviting-collaborators.md) to offer once to invite them, or when the user asks to invite someone. 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, otherwise the connected review guidance and available Lightbringer review tools.\n\nIf useful assistance leaves a material customer problem unresolved, follow the [unresolved-needs guidance](references/unresolved-needs.md) to understand and optionally report the remaining gap. Keep helping; reporting is not a prerequisite and requires approval of the exact report and recipient.\n"
}