Proposal Workflows

# Solicitation Intelligence and Compliance

## User Input
- **Target solicitation:** [GovTribe opportunity link, solicitation number, or RFI/RFQ/RFP title plus agency]
- **Company context:** [Optional offeror, capability, or pursuit context]

## Goal
Use GovTribe MCP tools to produce a source-backed readout of a solicitation, RFI, RFQ, RFP, amendment, attachment package, or related notice.
Identify scope, deadlines, submission rules, eligibility constraints, evaluation factors, required forms or attachments, compliance risks, and unanswered questions.
Return a copyable markdown briefing, not a DOCX, XLSX, slide deck, workbook, or uploaded file.

## Required Input
The user must provide enough information to resolve one solicitation or source package.

Accept any of the following:
- GovTribe opportunity or government-file link
- Solicitation number, notice ID, RFI/RFQ/RFP title, or amendment identifier
- Opportunity title plus agency, buyer, jurisdiction, or other disambiguating detail
- File-package context supplied by the host client

Input rules:
- If the input resolves cleanly to one target, proceed immediately.
- If several notices or amendments match, identify the likely candidates and ask for the minimum detail needed to choose one.
- Do not guess dates, mandatory requirements, evaluation factors, or submission rules.
- Treat missing files, inaccessible attachments, and ambiguous amendments as explicit risks.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Date filtering", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for search behavior, exact lookup, file retrieval, vector-store retrieval, search-context management, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation instead of pretending the step was completed.

2. Resolve the target solicitation.
   - Use `Search_GovTribe` first when the record type is unclear or the user provides a GovTribe URL that could point to a notice, file, award, IDV, vehicle, or state/local record.
   - Use `Search_Federal_Contract_Opportunities` for federal opportunities, solicitations, RFIs, RFQs, RFPs, sources sought notices, presolicitations, amendments, and notice IDs.
   - Use `Search_State_And_Local_Contract_Opportunities` for state or local procurement notices.
   - Favor exact quoted lookup for solicitation numbers, notice IDs, titles, and file names.
   - Request fields that support scope, dates, buyer, set-aside, NAICS/PSC or category, place of performance, points of contact, descriptions, summary, related files, and related awards or vehicles when available.

3. Pull source files and snippets.
   - Use `Search_Government_Files` for files tied to the resolved target or parent records.
   - If the resolved record already includes attached `government_files`, use those file IDs or names to narrow the file search.
   - Prioritize solicitation documents, amendments, Q&A, attachments, PWS/SOW/SOO, Section L, Section M, pricing instructions, clauses, forms, and exhibits.
   - If snippets are not enough for a requested fact or compliance conclusion, use `Add_To_Vector_Store`, then `Search_Vector_Store`.
   - If file text, snippets, vector-store upload, or vector-store search are unavailable or unauthorized, continue only with retrieved record summaries and file metadata. Say clearly that clause-level requirements were not directly verified.
   - If a host client does not expose file upload, document creation, or code execution tools, keep working with GovTribe MCP snippets and vector-store search results only.

4. Extract the solicitation readout.
   - Separate confirmed facts from assumptions and inferences.
   - Capture scope, buyer, due date, question deadline, site visit or conference rules, submission method, page limits, volume structure, required forms, pricing requirements, eligibility, set-aside, vehicle or ordering path, and evaluation factors.
   - Call out amendment impacts only when the source evidence shows a change.
   - If company context was provided, identify company-specific fit or compliance risks without turning the output into a full bid/no-bid review.

5. Perform a final source and risk pass.
   - Confirm every deadline, mandatory instruction, evaluation factor, and pass/fail requirement has a supporting source.
   - Mark any item as unresolved when the available evidence does not support a direct answer.
   - Do not infer missing clauses or mandatory requirements from attachment names, record summaries, or similar solicitations.
   - Do not promise to create or attach a workbook, DOCX, XLSX, slide deck, or other artifact.

## Output Format
Return the answer in this order:

1. **Solicitation Readout**
   - Identify the resolved target and explain how it was resolved.

2. **Key Facts**
   - Use a 2-column markdown table for buyer, title, solicitation number, notice type, due date, question deadline, site visit or conference rules, set-aside, NAICS/PSC or category, place of performance, and source-package status.

3. **Scope and Requirement Summary**
   - Summarize the work in plain language.
   - Quote only short source language where exact wording changes compliance or interpretation.

4. **Submission and Compliance Rules**
   - Use a copyable markdown table.
   - Recommended columns: `Requirement`, `Source`, `Required Action`, `Risk If Missed`, `Status`.

5. **Evaluation Factors**
   - Use a compact markdown table when factors or subfactors are available.
   - Include pass/fail factors separately from scored or adjectival factors.

6. **Compliance Risks and Open Questions**
   - List missing files, unclear amendments, hard deadlines, mandatory attendance, eligibility gaps, unusual formats, pricing constraints, and questions the team should resolve.

7. **Recommended Next Actions**
   - Provide practical next steps for capture, proposal, pricing, contracts, or BD owners.

8. **Overall Confidence**
   - State confidence and explain what evidence would raise or lower it.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to the specific claims they support, especially deadlines, mandatory rules, evaluation factors, and risks.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or state that the goal cannot be fully completed from the available evidence.
- If a statement is an inference rather than a directly supported fact, label it as an inference.

# Proposal Compliance Checklist

## User Input
- **Target solicitation:** [GovTribe opportunity link, solicitation number, or source package]
- **Compliance focus:** [Optional checklist focus such as submission, eligibility, pricing, or Section L/M]
- **Company context:** [Optional offeror, certification, vehicle, or team context]

## Goal
Use GovTribe MCP tools to build a source-backed proposal compliance checklist or matrix from a resolved solicitation, notice, amendment, or file package.
The output must be a copyable markdown table or CSV-ready table that a proposal manager can paste into another tool.
Do not create, upload, or promise an XLSX workbook, DOCX document, slide deck, or generated file artifact.

## Required Input
The user must provide a target solicitation, GovTribe link, file package, or enough context to resolve one source package.

Optional input may include:
- A checklist focus such as submission instructions, Section L, Section M, pricing, forms, eligibility, attachments, or pass/fail requirements
- Offeror, team, certification, vehicle-access, or capability context
- Desired table columns, owner/status conventions, or review-gate language

Input rules:
- If the target is not resolvable, ask for the minimum detail needed to proceed.
- If source coverage is incomplete, still produce a scoped checklist and label missing-source risk clearly.
- Do not invent owners, statuses, page counts, deadlines, or requirement IDs unless the user asks for placeholders.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for exact lookup, related-record filtering, file retrieval, vector-store retrieval, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation in the checklist scope.

2. Resolve the target and source package.
   - Use `Search_GovTribe` first when the record type is unclear.
   - Use `Search_Federal_Contract_Opportunities` or `Search_State_And_Local_Contract_Opportunities` for solicitations, RFIs, RFQs, RFPs, sources sought notices, and related opportunity records.
   - Use exact quoted identifiers for solicitation numbers, notice IDs, amendment names, file names, and titles.
   - Request enough fields to support due dates, buyer context, set-aside or eligibility, descriptions, files, related awards or vehicles, points of contact, and source URLs.

3. Retrieve the files that drive compliance.
   - Use `Search_Government_Files` for solicitation files, amendments, Q&A, instructions, evaluation factors, PWS/SOW/SOO, attachments, forms, exhibits, pricing sheets, and clauses.
   - If the resolved opportunity or notice includes attached `government_files`, use those file IDs or names to narrow the file search before broader text queries.
   - Use `Add_To_Vector_Store`, then `Search_Vector_Store`, only when snippets are not enough to extract checklist rows accurately.
   - If file text, snippets, vector-store upload, or vector-store search are unavailable or unauthorized, produce a best-effort checklist from retrieved record summaries and file metadata only, then mark clause-level rows as `Not directly verified`.
   - Track which source each checklist row came from.

4. Extract discrete compliance items.
   - Prioritize mandatory submission rules, deadlines, format rules, volume rules, page limits, representations, certifications, pricing instructions, attachments, deliverables, pass/fail criteria, evaluation factors, and eligibility constraints.
   - Keep source wording short and only where exact language matters.
   - Label derived checklist rows as `Inferred from source` only when the requirement is not stated as a discrete item but follows directly from source text.

5. Build the copyable matrix.
   - Use a markdown table that is also CSV-ready.
   - Include clear status values such as `Open`, `Met`, `Risk`, `Not Applicable`, or `Unknown` when useful.
   - Use `Not directly verified` for items that appear likely from record summaries, file names, or user context but were not confirmed in retrieved source text.
   - If company context was provided, identify offeror-specific pass/fail risks and evidence gaps.

## Output Format
Return the answer in this order:

1. **Checklist Scope**
   - Identify the resolved target, source coverage, and any known missing files.
   - State whether the checklist is source-text verified or best-effort from record summaries and file metadata.

2. **Compliance Checklist**
   - Use a required copyable markdown table.
   - Recommended columns: `ID`, `Requirement`, `Source`, `Due / Applies To`, `Required Response`, `Owner`, `Status`, `Risk`.
   - Keep table cells concise enough to paste into spreadsheets or proposal tools.

3. **Pass / Fail and Hard-Gate Risks**
   - List mandatory attendance, submission method, eligibility, set-aside, vehicle access, late-submission, certification, and format risks.

4. **Evaluation and Scoring Crosswalk**
   - Include only when evaluation factors are available.
   - Recommended columns: `Factor`, `What Evaluators Want`, `Proposal Response Needed`, `Source`, `Risk`.

5. **Open Questions**
   - List source gaps, ambiguous amendment changes, missing attachments, unclear response formats, or company-context unknowns.

6. **Next Proposal Actions**
   - Provide owner-ready actions the team can take next.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to individual checklist rows, not only to the table heading.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or state that the checklist is partial.
- If a statement is an inference rather than a directly supported fact, label it as an inference.

# Annotated Proposal Outline Starter

## User Input
- **Target solicitation:** [GovTribe opportunity link, solicitation number, or source package]
- **Company context:** [Optional offeror, solution, win-theme, or past-performance context]
- **Outline focus:** [Optional volume, response type, or writer focus]

## Goal
Use GovTribe MCP tools to create a source-backed, writer-facing markdown outline starter for a solicitation, RFI, RFQ, RFP, amendment, or source package.
Map outline sections to requirements, evaluation factors, source evidence, likely proof points, compliance notes, and unresolved capture inputs.
Return a markdown outline starter only; do not create, upload, or promise a DOCX, workbook, slide deck, or generated file artifact.

## Required Input
The user must provide a target solicitation, GovTribe link, file package, or enough context to resolve one source package.

Optional input may include:
- Company, solution, win-theme, past-performance, teammate, or product context
- Desired volume or response focus, such as technical, management, past performance, oral presentation, RFI response, or executive summary
- Known page limits, format rules, or proposal strategy constraints

Input rules:
- If the target cannot be resolved, ask for the minimum detail needed to proceed.
- Do not draft final proposal prose unless the user asks separately; this workflow creates an outline starter.
- Keep compliance requirements separate from writing guidance.

## Workflow

### Steps
1. Call `Documentation` once with `collections=["govtribe-for-agents"]`, `article_names=["Choose a search mode and write queries", "Manage search context", "Filter by related records and hierarchies", "Vector-store content retrieval", "Troubleshoot search results"]`, and `max_tokens=12000`.
   - Treat the returned guide articles as binding for exact lookup, file retrieval, vector-store retrieval, and troubleshooting.
   - Use each selected tool schema as the source of truth for exact arguments, fields, filters, relationship fields, sorts, and response shapes.
   - If the connected MCP client does not expose a named tool, use the closest available GovTribe record, file, or vector-search tool the client provides. If no equivalent tool is available, state that limitation in the outline scope.

2. Resolve the target solicitation and source package.
   - Use `Search_GovTribe` when the record type is unclear.
   - Use `Search_Federal_Contract_Opportunities` or `Search_State_And_Local_Contract_Opportunities` for opportunity records.
   - Use exact quoted lookup for solicitation numbers, titles, notice IDs, amendment names, and file names.
   - Request fields that support scope, due dates, descriptions, buyer context, files, set-aside, vehicle or ordering path, and related records.

3. Retrieve outline-driving source evidence.
   - Use `Search_Government_Files` for source files, instructions, evaluation criteria, PWS/SOW/SOO, Q&A, attachments, forms, exhibits, and amendments.
   - If the resolved opportunity or notice includes attached `government_files`, use those file IDs or names to narrow the file search before broader text queries.
   - Use `Add_To_Vector_Store`, then `Search_Vector_Store`, only when snippets are not enough to map outline sections to requirements.
   - If file text, snippets, vector-store upload, or vector-store search are unavailable or unauthorized, create a partial outline starter from retrieved record summaries and file metadata only, and label every section that is not source-text verified.
   - Preserve source references for each major outline section.

4. Identify outline structure and evidence needs.
   - Extract required volumes, sections, factors, subfactors, page limits, submission instructions, evaluation priorities, work requirements, deliverables, certifications, and required attachments.
   - Map each outline section to source requirements and likely evaluator concerns.
   - If company context is provided, add candidate win themes, past-performance hooks, solution proof points, and gaps as clearly labeled inputs.
   - If company context is not provided, use neutral placeholders instead of invented claims.

5. Build the annotated starter.
   - Use markdown headings and copyable tables.
   - Make it useful to writers, reviewers, and proposal managers without assuming a document-generation skill exists.
   - Keep it as an outline starter, not draft proposal prose.
   - For each major section, state whether the evidence basis is opportunity summary, file metadata, extracted file text, user-provided context, or placeholder.
   - Label every unsupported idea as a placeholder, assumption, or open capture input.

## Output Format
Return the answer in this order:

1. **Outline Scope**
   - Identify the resolved target, source coverage, and outline focus.

2. **Compliance-to-Outline Map**
   - Use a markdown table.
   - Recommended columns: `Source Requirement`, `Evaluation / Instruction`, `Outline Section`, `Writer Action`, `Risk`.

3. **Annotated Outline Starter**
   - Use nested markdown headings.
   - For each section include:
     - `Purpose`
     - `Source Requirements`
     - `Suggested Content`
     - `Evidence / Proof Points Needed`
     - `Compliance Notes`
     - `Open Questions`

4. **Win Theme and Proof-Point Inputs**
   - Include only source-backed or user-provided themes.
   - Mark placeholders clearly.

5. **Writer Risks and Review Gates**
   - List compliance, evidence, page-limit, evaluation, and unanswered-source risks.

6. **Next Actions**
   - Provide practical actions for proposal manager, volume lead, capture, pricing, contracts, and SMEs.

## Citation Rules
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, dates, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to outline sections, compliance rows, and source requirements they support.

## Grounding Rules
- Base claims only on provided context or GovTribe MCP tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the outline or state that it is a partial starter.
- If a statement is an inference rather than a directly supported fact, label it as an inference.