Govly

View saved version →

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

# Govly Daily Pursuit Radar

Produce a concise, evidence-backed digest of the best opportunity matches from the user's Govly saved searches. Keep scheduled runs read-only.

## Prepare the run

Collect or recover these settings from the current chat:

- Saved-search scope: exact saved-search IDs, exact names, or all visible opportunity saved searches.
- Scoring rubric: weighted criteria, scoring anchors, hard disqualifiers, and minimum reporting score.
- Coverage limits: maximum matches to inspect per search and maximum finalists to open in detail.
- Reporting preference: daily or weekly window, desired result count, and output detail.

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

Read [references/templates.md](references/templates.md) when setting up a rubric, scheduled prompt, or final report.

## Build the candidate set

1. Call `list_opportunity_saved_searches` and follow `meta.nextCursor` until it is null.
2. 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.
3. 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.
4. Treat these as cached saved-search matches, not a live replay of the search.
5. Deduplicate matches by canonical opportunity ID. Preserve every saved search that matched each opportunity.
6. Exclude clearly closed, expired, cancelled, or otherwise inactionable records unless the user explicitly requested historical review.
7. If any pagination or coverage cap prevents a complete pull, label the report `Partial coverage` and state which searches were truncated.

## Detect changes

Compare the current candidate set with the most recent successful report in the same chat when that context is available.

- Label an unseen opportunity `New`.
- Label an existing opportunity `Changed` only when a material field changed, such as status, deadline, buyer, scope summary, value, set-aside, or attachments.
- Suppress unchanged opportunities when the scheduled prompt requests changes only.
- Label the report `First run` when no reliable prior snapshot is available.

Do not claim durable cross-chat state. A standalone scheduled run may not have the prior chat context needed for change detection.

## Apply the scoring rubric

1. Evaluate hard disqualifiers before weighted criteria.
2. 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`.
3. Require weights to total 100 unless the customer explicitly defines another calculation. Do not silently normalize a malformed rubric.
4. Score only from returned Govly evidence and customer-provided context.
5. Mark unavailable evidence `Unknown`. Do not convert missing evidence into zero unless the rubric explicitly says to do so.
6. Keep score and confidence separate:
   - `High`: most high-weight criteria have direct evidence.
   - `Medium`: the score depends on some summaries or unresolved fields.
   - `Low`: one or more high-weight criteria lack evidence.
7. Use the saved-search result's opportunity payload and `aiSummary` for the first scoring pass.
8. 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.
9. 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.

When an AI summary conflicts with source metadata or a document, prefer the source and disclose the conflict.

## Produce the digest

Lead with the result, not the retrieval process. Include:

1. Run status: complete, partial coverage, first run, or setup needed.
2. Number of saved searches reviewed, candidate matches found, unique opportunities scored, and finalists reported.
3. A ranked table with status, score, confidence, opportunity, buyer, deadline, matched searches, and one-sentence rationale.
4. A short score breakdown for each finalist with evidence, risks, unknowns, and recommended next action.
5. A `Not reported` note for disqualified or below-threshold candidates, using aggregate counts rather than a noisy list.

If nothing qualifies, say so plainly and include the coverage summary. Do not pad the report with low-scoring results.

## Preserve safety and scope

- Use only read tools during a scheduled run.
- Never call `follow_entity`, `mark_not_interested`, inbox mutation tools, saved-search update tools, workspace mutation tools, or comment tools from this workflow.
- Treat the original scheduling request as authorization to read and report, not authorization for future mutations.
- Do not send results to email, Slack, or another destination unless the user explicitly requests it and an authorized connector is available.
- Do not present model judgment as a source fact. Show the evidence behind every material score.
- Do not report a first page as the complete result set.

Referenced files: 2

View saved version →

---
name: govly-recompete-watch
description: Create an on-demand or scheduled, read-only Govly watch for awards approaching their period-of-performance end, inspect related records, and identify evidence-backed successor or recompete opportunities. Use for recompete pipeline monitoring, incumbent and buyer tracking, expiring-award review, and successor-opportunity discovery. Do not use for general saved-search scoring or SLED meeting intelligence.
---

# Govly Recompete Watch

Identify awards that may create future recompete demand and search for successor opportunities. A likely recompete is an analytical conclusion, not a source fact, unless a returned record explicitly says so.

## Prepare the watch

Collect or recover these settings from the current chat:

- Market scope: federal, SLED, international, or a specified combination.
- Award scope: exact saved award-search IDs or names when available; otherwise target buyers, incumbents, keywords, NAICS, PSC, and minimum value.
- Expiration window: period-of-performance end or potential end dates to monitor.
- Opportunity scope: status, buyer or topic terms, posted or modified window, and result cap.
- Reporting preference: daily or weekly cadence, changes-only behavior, and finalist cap.

Prefer configured award saved searches for repeatable monitoring, especially when they already encode a period-of-performance end window. For interactive use, ask one concise question when a missing setting materially changes the search. For a scheduled run, do not invent a market, expiration window, or award scope; return a setup-needed message naming the missing settings.

Read [references/templates.md](references/templates.md) when configuring the watch, creating a scheduled prompt, or formatting the report.

## Build the expiring-award set

### Use configured award saved searches

1. Call `list_award_saved_searches` and follow pagination until no more results remain.
2. Match configured IDs exactly. Match names exactly when possible; ask about ambiguity during an interactive run and skip ambiguous names during a scheduled run.
3. Call `execute_award_saved_search` for each selected search so the watch uses live results rather than a cached list.
4. Follow every returned cursor until it is null or the configured coverage cap is reached.

### Fall back to direct award search

If no suitable award saved search is configured:

1. Call `search_awards` using the customer's market, buyer, recipient, keyword, NAICS, PSC, amount, and other supported filters.
2. Do not use the award `dateRange` as a period-of-performance expiration filter. It filters award action dates.
3. Follow `meta.nextCursor` until it is null or the coverage cap is reached.
4. Filter the returned award `dates` client-side against the configured `period_of_performance_end_date` or `period_of_performance_potential_end_date` window.
5. Report when missing period-of-performance dates prevent an award from being evaluated.

Deduplicate by canonical award ID while preserving the source searches or criteria that matched. Label capped or incomplete pulls `Partial coverage`.

## Investigate the strongest candidates

1. Prioritize awards using timing, value, target-buyer fit, scope fit, and evidence completeness. Do not turn these priorities into a precise probability unless the customer supplies a validated model.
2. Call `show_award` for the strongest candidates, up to the configured detail cap.
3. Inspect related opportunities returned by the award detail before running broader searches.
4. Search for open successor opportunities with `search_opportunities` using combinations of the award's contract or reference number, buyer, program or scope terms, and classifications.
5. Use the same market as the monitored award unless the user explicitly asks for cross-market analysis.
6. Apply a bounded posted or modified window when the watch is intended to report new activity.
7. Follow `meta.nextCursor` until it is null or the configured cap is reached.
8. Call `show_opportunity` only when its details materially affect the evidence grade.

Deduplicate successor opportunities by canonical opportunity ID. Preserve all awards they may relate to.

## Grade recompete evidence

Use the strongest label supported by returned evidence:

- `Confirmed successor`: an opportunity or explicit relationship cites the predecessor award, contract number, incumbent effort, or recompete directly.
- `Strong candidate`: the buyer and scope materially match, timing aligns with the award end window, and multiple additional facts support succession.
- `Possible candidate`: buyer, topic, classification, or timing overlaps, but the record lacks enough evidence for a strong relationship.
- `No open successor found`: the bounded search found no supported match. This does not mean no recompete exists or will occur.

Never infer a guaranteed recompete from an award end date alone. Keep source facts, analytical interpretation, and missing evidence separate.

## Detect changes

Compare canonical IDs and material fields with the most recent successful report in the same chat when that context is available.

- Label a newly monitored award or opportunity `New`.
- Label a record `Changed` when period-of-performance dates, value, buyer, status, deadline, scope, or relationship evidence materially changes.
- Suppress unchanged records only when the configured watch requests changes-only output.
- Label the report `First run` when no reliable prior snapshot is available.

Do not claim durable cross-chat state.

## Produce the recompete watch

Lead with the highest-priority market developments. Include:

1. Run status: complete, partial coverage, first run, or setup needed.
2. Coverage: award searches or filters, market, expiration window, candidate awards, and opportunity queries.
3. `Awards approaching end`: award, buyer, incumbent or recipient, value, end date, evidence completeness, and why it merits attention.
4. `Successor opportunities`: evidence label, opportunity, deadline, linked award, supporting facts, and uncertainty.
5. `No supported successor yet`: priority awards with no open match and the bounded searches performed.
6. `Watch gaps`: missing dates, incomplete pagination, capped searches, ambiguous saved searches, or unavailable details.

If no award falls in scope or no successor is found, say so plainly and include the coverage summary. Do not pad the report with unsupported matches.

## Preserve safety and scope

- Use only read tools during a scheduled run.
- Never call follow, inbox mutation, saved-search mutation, workspace mutation, comment, or opportunity mutation tools from this workflow.
- Treat the scheduling request as authorization to read and report, not authorization for future mutations.
- Do not send results to email, Slack, or another destination unless the user explicitly requests it and an authorized connector is available.
- Do not describe a candidate as confirmed without a direct source relationship.
- Do not report a first page as the complete result set.

Referenced files: 2

View saved version →

---
name: govly-sled-market-watch
description: Create an on-demand or scheduled, read-only Govly market watch that finds SLED public meetings and signals by customer keywords, searches open SLED opportunities in confirmed target places, and highlights evidence-backed connections. Use for state and local market monitoring, meeting intelligence, early demand signals, and topic-based opportunity alerts. Do not use for general saved-search scoring or federal recompete analysis.
---

# Govly SLED Market Watch

Monitor state and local public-sector signals and open opportunities without changing Govly records. Separate facts returned by Govly from inferred connections.

## Prepare the watch

Collect or recover these settings from the current chat:

- Topic groups: keywords, phrases, acronyms, products, programs, and exclusions.
- Signal scope: content types and lookback window. Default to public meetings when the user asks for meeting intelligence.
- Place scope: exact states, counties, cities, agencies, or confirmed Govly place IDs.
- Opportunity scope: posted or modified lookback, status, and maximum results to inspect.
- Reporting preference: daily or weekly cadence, changes-only behavior, and result cap.

For interactive use, ask one concise question when an unresolved setting would materially change the search. For a scheduled run, do not guess missing topics or geography; return a setup-needed message that names what is missing.

Read [references/templates.md](references/templates.md) when configuring a watch, creating a scheduled prompt, or formatting the report.

## Resolve the target geography

1. Use `search_places` for each named place. Prefer exact matches, then expected partial matches.
2. Treat semantic matches as suggestions, not confirmed geography. Ask the user to confirm them during an interactive run; skip ambiguous semantic matches during a scheduled run and report the gap.
3. Use `list_places` when the user wants to browse available places or when enumeration is more reliable than name search.
4. Preserve the selected Govly place IDs and the display names used in the report.
5. Remember that signal search does not accept a hard jurisdiction filter. Place scope for signals must be applied from returned evidence after the search. State this limitation when it affects coverage.

## Find public-sector signals

1. Call `search_signals` separately for each topic group so the report can identify what matched.
2. Put the substantive topic in `query`. Do not use signal categories as a substitute for keyword or topic search.
3. When the user asks for meetings, set `contentTypes` to `meeting`. Add other requested content types, such as hearing, law, policy, regulatory, event, news, or analysis, only when they fit the watch.
4. Apply the configured `dateRange` exactly.
5. Follow page-based pagination until no more results remain or the configured coverage cap is reached.
6. Post-filter returned signals to the confirmed place scope using explicit jurisdiction, agency, location, and source evidence. Keep a borderline result only when the report clearly labels the geographic uncertainty.
7. Deduplicate by canonical signal ID. Preserve all matching topic groups.
8. Call `show_signal` only for the highest-value signals whose details materially affect the report.

If a coverage cap truncates a query, label the signal section `Partial coverage` and name the truncated topic groups.

## Find open SLED opportunities

1. Call `search_opportunities` for each topic group with `searchType` set to `sled` and `status` set to `open` unless the user requests another status.
2. Pass confirmed target IDs through `placeIds`. Use `placeIdsNone` only when the user explicitly wants opportunities with no assigned place.
3. Apply the configured posted, modified, or response-date window rather than treating an unbounded search as a daily change feed.
4. Follow `meta.nextCursor` until it is null or the configured cap is reached.
5. Deduplicate opportunities by canonical opportunity ID and preserve every matching topic group.
6. Call `show_opportunity` only for the highest-value results or records needed to evaluate a potential signal connection.

Label incomplete pagination or capped searches `Partial coverage`.

## Detect changes

Compare current canonical IDs and material fields with the most recent successful report in the same chat when that context is available.

- Label a previously unseen record `New`.
- Label a record `Changed` only when a meaningful field changed, such as date, status, buyer, scope, location, deadline, or source details.
- Suppress unchanged records only when the configured watch requests changes-only output.
- Label the report `First run` when no reliable prior snapshot is available.

Do not claim durable cross-chat state.

## Evaluate possible connections

Connect a signal to an opportunity only when the returned evidence supports the relationship. Use these labels:

- `Strong connection`: the records share a specific agency or place, a materially matching topic or program, compatible timing, and at least one additional identifier or source detail.
- `Possible connection`: the records share a relevant agency, place, or topic, but lack a direct reference or enough detail.
- `Parallel activity`: the records concern the same broad market but do not support a direct relationship.

Never present timing or keyword overlap as proof that a meeting caused an opportunity. Quote or paraphrase the specific evidence used, and keep inference visibly separate from source facts.

## Produce the market watch

Lead with the market development, not the retrieval process. Include:

1. Run status: complete, partial coverage, first run, or setup needed.
2. Coverage: topic groups, date windows, confirmed places, signal results, and unique opportunities.
3. `Early signals`: meeting or signal, date, place or agency, matched topic, why it matters, and source.
4. `Open opportunities`: opportunity, buyer, place, deadline, matched topic, and one-sentence relevance.
5. `Potential connections`: evidence label, the connected records, supporting facts, uncertainty, and recommended monitoring action.
6. `Watch gaps`: ambiguous places, missing jurisdiction evidence, capped queries, or unavailable details.

If nothing qualifies, say so plainly and include the coverage summary. Do not manufacture a trend from sparse results.

## Preserve safety and scope

- Use only read tools during a scheduled run.
- Never call follow, inbox mutation, saved-search mutation, workspace mutation, comment, or opportunity mutation tools from this workflow.
- Treat the scheduling request as authorization to read and report, not authorization for future mutations.
- Do not send results to email, Slack, or another destination unless the user explicitly requests it and an authorized connector is available.
- Do not claim exhaustive jurisdiction coverage because `search_signals` cannot hard-filter by place.
- Do not report a first page as the complete result set.

Referenced files: 2