Update to Govly

{
  "name": "govly-daily-pursuit-radar",
  "description": "Create an on-demand or scheduled, read-only digest of Govly opportunity saved-search matches, deduplicate results, and rank them with a customer-provided scoring rubric. Use for daily or weekly pursuit radar, capture-team digests, saved-search scoring, and identifying new or materially changed matches. Do not use for SLED meeting intelligence or recompete monitoring.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 489
    },
    {
      "relative_path": "references/templates.md",
      "size_in_bytes": 2373
    }
  ],
  "skill_md_contents": "---\nname: govly-daily-pursuit-radar\ndescription: Create an on-demand or scheduled, read-only digest of Govly opportunity saved-search matches, deduplicate results, and rank them with a customer-provided scoring rubric. Use for daily or weekly pursuit radar, capture-team digests, saved-search scoring, and identifying new or materially changed matches. Do not use for SLED meeting intelligence or recompete monitoring.\n---\n\n# Govly Daily Pursuit Radar\n\nProduce a concise, evidence-backed digest of the best opportunity matches from the user's Govly saved searches. Keep scheduled runs read-only.\n\n## Prepare the run\n\nCollect or recover these settings from the current chat:\n\n- Saved-search scope: exact saved-search IDs, exact names, or all visible opportunity saved searches.\n- Scoring rubric: weighted criteria, scoring anchors, hard disqualifiers, and minimum reporting score.\n- Coverage limits: maximum matches to inspect per search and maximum finalists to open in detail.\n- Reporting preference: daily or weekly window, desired result count, and output detail.\n\nFor interactive use, ask one concise question for any setting that materially changes the result. For a scheduled run, do not guess missing saved-search scope or rubric rules; return a short setup-needed message naming the missing settings.\n\nRead [references/templates.md](references/templates.md) when setting up a rubric, scheduled prompt, or final report.\n\n## Build the candidate set\n\n1. Call `list_opportunity_saved_searches` and follow `meta.nextCursor` until it is null.\n2. Match configured names exactly. If multiple searches share or closely resemble a requested name, ask the user during an interactive run; skip the ambiguous search and report it during a scheduled run.\n3. For every selected search, call `list_opportunity_saved_search_results` and follow `meta.nextCursor` until it is null or the configured coverage cap is reached.\n4. Treat these as cached saved-search matches, not a live replay of the search.\n5. Deduplicate matches by canonical opportunity ID. Preserve every saved search that matched each opportunity.\n6. Exclude clearly closed, expired, cancelled, or otherwise inactionable records unless the user explicitly requested historical review.\n7. If any pagination or coverage cap prevents a complete pull, label the report `Partial coverage` and state which searches were truncated.\n\n## Detect changes\n\nCompare the current candidate set with the most recent successful report in the same chat when that context is available.\n\n- Label an unseen opportunity `New`.\n- Label an existing opportunity `Changed` only when a material field changed, such as status, deadline, buyer, scope summary, value, set-aside, or attachments.\n- Suppress unchanged opportunities when the scheduled prompt requests changes only.\n- Label the report `First run` when no reliable prior snapshot is available.\n\nDo not claim durable cross-chat state. A standalone scheduled run may not have the prior chat context needed for change detection.\n\n## Apply the scoring rubric\n\n1. Evaluate hard disqualifiers before weighted criteria.\n2. Use the scale and anchors supplied by the customer. If the rubric uses 0-5 ratings and weights totaling 100, calculate each contribution as `weight * rating / 5`.\n3. Require weights to total 100 unless the customer explicitly defines another calculation. Do not silently normalize a malformed rubric.\n4. Score only from returned Govly evidence and customer-provided context.\n5. Mark unavailable evidence `Unknown`. Do not convert missing evidence into zero unless the rubric explicitly says to do so.\n6. Keep score and confidence separate:\n   - `High`: most high-weight criteria have direct evidence.\n   - `Medium`: the score depends on some summaries or unresolved fields.\n   - `Low`: one or more high-weight criteria lack evidence.\n7. Use the saved-search result's opportunity payload and `aiSummary` for the first scoring pass.\n8. Call `show_opportunity` only for the highest-ranked candidates that could make the final report. Default to at most 10 detail reads unless the user configures another cap.\n9. Use `document_read` only when the rubric requires evidence from an attachment and the user has asked for that depth. Cite the document or page used.\n\nWhen an AI summary conflicts with source metadata or a document, prefer the source and disclose the conflict.\n\n## Produce the digest\n\nLead with the result, not the retrieval process. Include:\n\n1. Run status: complete, partial coverage, first run, or setup needed.\n2. Number of saved searches reviewed, candidate matches found, unique opportunities scored, and finalists reported.\n3. A ranked table with status, score, confidence, opportunity, buyer, deadline, matched searches, and one-sentence rationale.\n4. A short score breakdown for each finalist with evidence, risks, unknowns, and recommended next action.\n5. A `Not reported` note for disqualified or below-threshold candidates, using aggregate counts rather than a noisy list.\n\nIf nothing qualifies, say so plainly and include the coverage summary. Do not pad the report with low-scoring results.\n\n## Preserve safety and scope\n\n- Use only read tools during a scheduled run.\n- Never call `follow_entity`, `mark_not_interested`, inbox mutation tools, saved-search update tools, workspace mutation tools, or comment tools from this workflow.\n- Treat the original scheduling request as authorization to read and report, not authorization for future mutations.\n- Do not send results to email, Slack, or another destination unless the user explicitly requests it and an authorized connector is available.\n- Do not present model judgment as a source fact. Show the evidence behind every material score.\n- Do not report a first page as the complete result set.\n"
}