Update to Jade Note

{
  "description": "Run Jade Note Catch Up for a selected existing category, summarize its saved wiki and note maintenance, or undo a specific Catch Up run. Use when the user explicitly asks for Catch Up or regeneration of the category wiki, not merely to summarize or read category context.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 433
    }
  ],
  "name": "jade-note-catch-up",
  "skill_md_contents": "---\nname: jade-note-catch-up\ndescription: Run Jade Note Catch Up for a selected existing category, summarize its saved wiki and note maintenance, or undo a specific Catch Up run. Use when the user explicitly asks for Catch Up or regeneration of the category wiki, not merely to summarize or read category context.\n---\n\n# Run category Catch Up\n\nCatch Up generates and replaces a category's saved wiki and may update note\nimportance and explicit links. Inbox runs may also move high-confidence notes to\nexisting categories. This is a saved maintenance operation using Jade Note's\nconfigured AI provider, not a read-only summary. The user's scope and constraints\ntake precedence over this workflow.\n\n## Resolve the category and scope\n\n- Use `list_categories` to identify the requested existing writable category.\n  Ask which one if the target is missing or ambiguous; do not create a category\n  or run account-wide maintenance as a side effect.\n- Read `ensure_fresh_category_context` to inspect the current wiki, freshness,\n  changed-note context, and category instructions. If that tool is unavailable,\n  use `get_category_wiki` for context and instructions; do not misrepresent its\n  freshness. Follow local conventions without changing category instructions.\n- Briefly explain the run's scope, including importance/link maintenance and\n  possible Inbox moves. An explicit request to run Catch Up authorizes that run;\n  do not add a redundant confirmation step. A request only to review or summarize\n  the category stays read-only and should use context tools instead.\n- If the user asks for a wiki-only regeneration, forbids moves or importance/link\n  changes, or requires a pre-apply preview, do not call `refresh_category_wiki`:\n  it has no switches that guarantee those restrictions and applies immediately.\n  Explain that limitation and offer a read-only draft; obtain clarification before\n  performing maintenance that conflicts with the stated scope.\n\n## Execute and reconcile\n\n- Call `refresh_category_wiki` with the resolved category and a fresh UUID\n  `idempotency_key`. Keep `force=false` unless the user requests regeneration even\n  when the saved snapshot is current. Use `max_notes` only when the user requests\n  a bound or an established category convention provides one; honor the live\n  schema's limits and report the returned source-note count.\n- The tool runs Catch Up immediately. It does not require `preview_note_update`\n  or `apply_note_update`; never follow it with a second, separately synthesized\n  batch of importance updates, links, or moves.\n- Preserve the request's key and arguments for safe retries of that exact run.\n  After an uncertain response, retry only with the same key, and use\n  `get_category_maintenance_receipt` if a real receipt ID is known. Do not generate\n  a new key or force another run just because the first response was lost.\n- Interpret the returned status, summary, maintenance details, source-note count,\n  and preview reasons. A skipped/current result is not a newly completed run.\n  A receipt's change preview describes that run; it is not an unapplied proposal.\n- Read `get_category_maintenance_receipt` using the returned `receipt_id` when\n  present and `get_category_wiki` to verify saved state. Use `get_note` for specific\n  changed notes when confirming an important move or resolving a discrepancy.\n  Report failures or uncertain verification without claiming success.\n\n## Report and offer Undo\n\nSummarize what the returned run actually did: wiki refresh, importance changes,\nlinks, Inbox moves, skipped candidates/reasons, and any source coverage limit.\nUse returned IDs or links. Category instructions are not regenerated by Catch Up.\n\nWhen a successful run's receipt reports Undo is available, tell the user they can\nrevert the remaining Catch Up changes using that receipt. Keep its ID for the\nfollow-up. Do not mention credit refunds, the Undo expiry date, or claim that\nlater edits block Undo; the operation preserves later edits to individual fields.\n\nOn an explicit Undo request, resolve the exact run's receipt (ask if ambiguous),\ninspect it with `get_category_maintenance_receipt`, and call\n`undo_category_maintenance` with that `receipt_id`. Never undo Catch Up note by\nnote or use `restore_note_version`. For `partially_undone`, explain the returned\nskipped fields alongside reverted changes. For unavailable/already-undone results,\nreport that status without attempting a replacement rollback.\n\nUse current connected tool schemas. Report entitlement, access, empty-category,\ngeneration, or conflict errors and stop the affected run; do not bypass them with\nmanual maintenance, repeated forced runs, or changes to the user's plan.\n"
}