The central trade-off is how much work remains after sending a command: checking the resulting state, resolving uncertain outcomes and maintaining the integration when the application changes. That work determines whether a successful demonstration becomes a repeatable business process.
Section 5 asks when a hybrid API-and-browser workflow should change.
New API coverage does not settle the migration decision.
The review identified a missing counterexample: a working browser step can remain worthwhile when replacing and revalidating it costs more than the expected savings.
Initial draftOriginal English excerpt
There is no benefit in preserving this split if the API later covers document generation with adequate permissions and result checking.
The draft treated closing a coverage gap as sufficient reason to retire the browser step.
If the API later covers document generation with adequate permissions and result checking, the original coverage gap disappears. Retiring the browser step then depends on whether the expected maintenance and recovery savings justify migration and revalidation costs.
The revision separates capability coverage from the economics of changing a working system.
Public-source analysis, 10 October 2026. The workflow is illustrative; no deployment or comparative performance experiment was conducted. This case does not establish a general Toolkit quality advantage.
Already have a report? Follow a real update.
See an existing coding-agent procurement report, the source details it missed, and the revisions those checks produced. Original drafts and limits remain available.
Choose Lite where author checks fit the use. Choose Full to bind selected reviews and revision decisions to the delivery version. Let your agent recommend from the task; length is secondary.
If repository access is unavailable, upload the files or paste the instructions. Native Skill installation is optional.
Use Research Toolkit:
https://github.com/rrrrrredy/research-toolkit
Read SKILL.md and load the methods by stage.
Research question: [Include the question, audience, and intended use.]
Scope and length: [Include scope, information cutoff, length and counting unit.]
Existing material: [Attach files or links, including any existing report.]
Recommend Lite or Full for the task, including whether reviews and revisions
need to stay bound to the delivery version; explain why and respect my choice.
Use the context to establish the brief; ask only about consequential gaps.
Read required sources, check important claims and calculations, and develop
comparisons, counterevidence and conclusions for the intended reader.
Reuse existing research and correct affected passages when material changes.
Lite completes the author checklist; Full adds the chosen review, revision
and delivery checks. State the review actually performed.
Deliver the complete report with usable citations and a short change note
when revising. Maintain working records yourself, separately from the report.
Use MCP/CLI for saved progress and checks when connected.
Replace the bracketed text with your research request. Include any known audience, scope, length, time cutoff, or required sources.
Reading or uploading the methods does not start MCP or run an independent review. The tools need local stdio MCP support; the plugin also requires its package format.
Full uses a degraded self-review when no reviewer backend is configured. Choose an external command or compatible endpoint for another opinion; Astra in a separate context can provide independent review, including for an author using the same model; no additional outside reviewer is required. External calls send the supplied materials to that service and consume its account usage. Lite retains a final checklist and skips review.