ESEste sitio está disponible en español.
PTEste site está disponível em português.
gst_irl_sweep reads a populated IRL, drives up to nine GST engines from what the workbook answers, and returns one dossier whose claims cite the rows they came from. One optional argument; everything else is read from the document itself.
Assumes a working connector (set one up) and familiarity with running a prompt from its argument form.
Other GST prompts take arguments you type. This one takes the artifact the engagement already produces, the populated IRL, and treats it as the input to every applicable engine at once. It removes the re-keying step between the workbook and the tools.
Trusted input, one audit surfaceA populated GST IRL is trusted input: the IRL schema exists precisely to feed these tools. The sweep runs no hashing, caching, or citation-verification machinery; its dossier says "per the IRL" and never claims server-side verification. The audit surface is section (J), a model-authored list of every gap, elided tool, assumption and conversion the run carries.
Two prompts bookend the engagement. The first issues the ask; the last reads the answer. Step 02 happens off-platform, in the partner's inbox, unless the evidence is already in front of you.
Run gst_irl_create with the engagement's shape. It returns the paste-ready checklist in chat and a fillable workbook, configured the way you asked: sections included or dropped, individual questions removed, custom per-section requests added. Removals leave reference-ID gaps rather than renumbering, so a recipient quoting 2-04 still means the same question next quarter.
Ask list_irl_requests first if you want the exact key for a question you mean to drop
Seven columns: reference, request, status, file location, comments, notes, response. Four of them carry authored content: GST pre-populates research into Comments and sources into File Location; the recipient answers in Response and confirms in Status. Ingestion reads Response and Comments as one continuous answer, which is why a row that only points at a filename cannot open an analysis gate.
When the evidence is already in context (a data-room export, remitted documents, public filings), gst_irl_populate authors the fills itself and builds the populated workbook via fill_information_request_list_xlsx. Every answer carries a sourcing reference; rows the evidence cannot answer stay blank, and the blanks are the follow-up ask. It stops at the artifact: a human review sits between fill and ingest by design.
The workbook has to become text before it can be swept. The Information Request List Extractor does that conversion in your browser: it emits exactly the body shape the prompt expects, reproducibly, from the same bytes every time, including the header preamble the sweep infers the target from. Nothing is uploaded and nothing is installed.
Attaching the workbook and letting the model read it also works, but it is a reconstruction rather than a conversion: the result varies between runs on the same file, and a large workbook can truncate. Prefer the extractor when the answer has to be reproducible. With a repo checkout, the same conversion is a command.
npm -w @gst/mcp-server run irl:extract -- <filled-irl.xlsx>Invoke gst_irl_sweep and paste the markdown into filledIrl, or leave it blank when the IRL is already attached or pasted in the conversation. Before extracting anything, the prompt measures how much of the workbook is actually answered and halts only on a blank template; see what comes back.
Each tool-backed section closes with a deeplink that opens the same calculation in the Hub with its inputs set, so an assumption can be adjusted there without re-entering the engagement. The evidence stays in the conversation for the follow-on prompts in section 06.
The form has a single field, and even that one is optional. Everything the old eight-argument workflow asked for is now read from the IRL itself or from the conversation.
The whole markdown body
Optional, minimum 200 characters when supplied. Leave it blank and the prompt uses the IRL already attached or pasted in the conversation, asking for a paste only when nothing arrived. Pasting into a single-line field collapses line breaks; the run still works.
Header line, then row 0-01
Read from the > Target: line in the IRL header, falling back to the company-name row. The one thing a sweep cannot proceed without; if neither exists, it asks.
Sell-side · Buy-side · Value Creation · Unspecified
Read from the > Engagement context: header line, falling back to row 0-02. Voice only: it never changes which tools run, so a sell-side framing cannot quietly suppress an unflattering section. Absent or Unspecified means universal voice.
Taken from the conversation
Used when you have stated them in the session; otherwise the synthesis memo is attributed generically and the engagement is labelled by target name.
The dossier opens by stating the inferred target name, engagement context, and the source each was read from; correct either conversationally and the run continues.
Test bodyA partial IRL for a fictional target ships with this guide: Northwind Analytics, B2B analytics, $15.2M ARR, Series B, California. Paste it into filledIrl to exercise the workflow before running it on a live engagement.
The IRL workflow is three prompts, one job each. There is no mode argument to choose; the choice is which prompt you invoke.
Northwind Analyticsbuy-side.xlsx; unattributable rows stay blank as the follow-up ask.filledIrl: <the IRL markdown, or blank>
unknown and null are honest inputs where the IRL is silent.filledIrl: <the IRL markdown, or blank>
record: irl-extract fence plus one payload fence per gate-passing tool.The predecessor is still listedgst_irl_ingestion (the eight-argument workflow with audit levels, body hashing and server-side provenance) remains registered unchanged while the sweep is live-verified. Its removal is scheduled, together with prepare_irl_body, validate_irl_provenance and compose_dossier_envelope. Start new work on the sweep.
Before any of it, a fill-ratio check: the prompt walks the ten canonical sections (00–09) and counts substantive answers. One threshold, not a grading scale.
Halts: that is the blank request template, not a filled IRL. The run says so and asks you to confirm before proceeding.
Proceeds, whatever the ratio. It is stated as the first sentence of the dossier, and thin or empty sections are named in (J). A sparse IRL produces a sparse dossier with an honest gap list: the correct result, not an error.
Sections C through H only appear when the workbook supports them. The benchmark needs ARR plus an engineering-cost or hosting signal; the debt estimate needs at least one substantively answered row about the codebase (a file pointer or a caveat is not signal). Regulatory exposure needs a named framework, or a conditional trigger firing on what the IRL says about AI systems or critical infrastructure. Anything skipped is named, with its reason, in (J). The agenda, the cost-governance read and the radar always run.
Read (J) before the restThe gap list carries unanswered high-value rows with their concrete follow-up, elided tools with the predicate that failed, every conversion and assumption the run applied, and any inference you should confirm. The dossier says "per the IRL" and never claims server-side verification; this list is what makes that honest. No gaps reported against a partially-filled IRL indicates a problem with the run, not a clean workbook.
The extract record is a structured description of the target, produced by gst_irl_extract and carried in the conversation. Six of the GST prompts check for it before running and resolve their inputs from it instead of from the arguments you typed.
Given only its five form fields, it benchmarks against partner-supplied inputs and returns the debt estimate as extraction-only with null incident data; there is nothing to compute it from.
The same prompt resolves its inputs from the record, cites the reference each one came from, and states which branch produced every number.
The kickoff agenda, handoff memo, architecture layer review, comparable-engagements memo and regulatory exposure brief behave the same way. Run the extraction first and the rest of the session reads from it.
Per answered row: the workbook reference verbatim, the request text verbatim, the status, an answer excerpt capped at 240 characters, and a normalised value with its conversion basis where one exists. Consumers match on the request text, so there is no lookup table to keep in sync.
The record is context-borne: there is no server copy and no cache behind it. Its _meta block dates and versions itself, because nothing server-side can supply that later.
The record's excerpts are extraction-time verbatim spans and every consumer states that plainly. Keep the filled IRL alongside the record when a later session needs to check a claim against the source.
Four conditions a first run commonly hits.
Claude Desktop renders each argument as a single-line field, so a multi-line markdown body collapses to one long line.
Processed normally: every word survives in order, and matching normalises whitespace anyway. Nothing is refused and nothing acts on it.
The engines accept unknown sentinels and null fields where the workbook does not determine a value.
That is the honest input, not a failure. Each one is named in (J) with the follow-up that would resolve it.
A tool errored mid-sweep, or a required input was absent from the IRL and could not be substituted.
The sweep continues and the section reports the error verbatim. A missing input becomes a follow-up in (J) rather than an inferred value.
The workbook header carried free text instead of a canonical label, or row 0-02 stated a posture the header contradicted.
Section (A) names the inference and its source. Correct it in chat: voice is the only thing that changes; the tools already ran the same either way.
The intake checklist, its taxonomy, and the workbook.
Read articleFirst query, prompt argument forms, and pinned resources.
Open guideTool and prompt reference, OAuth scopes, and rate limits.
Read docs