How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

guru-finish-work - Prompt - OpenSmartRoute

Name: guru-finish-work
Author: castbox

Prompt file imported from castbox/guru-trellis (.cursor/commands/guru-finish-work.md). Copyright stays with the author.

Guru Finish Work

Before substantive output, read .trellis/spec/workflow/clear-technical-writing.md in full and apply it within this entry's existing scope. Until that read succeeds, use only short progress messages or concrete missing-dependency diagnostics. State the current action or missing item; make no unverified claim. If the file cannot be read, pause substantive output, then read it and resume the same request when available. No additional approval is needed for that recovery.

Read .trellis/spec/workflow/workflow-contract.md#interaction-budget before confirmation, choice or clarification; the invoked Skill owns the exact action and its confirmation boundary.

On an automatic context/route failure or an explicit independent manual request, read .trellis/workflow.md#manual-gitgithub-operations (Manual Git/GitHub Operations). That global owner defines the boundary; this entry adds no recovery steps and does not turn a manual result into Guru completion.

Read the sole continuation in .trellis/workflow.md and current public Task/Delivery availability through the installed context helpers. Follow its Phase 3.6/3.7 route and mandatory load the applicable owners by stable Skill id:

This is the exclusive finish entry for a Guru task. The upstream-owned trellis-finish-work Skill is not applicable to Guru tasks and must not be loaded or invoked. Do not archive before the current Closure and Finish owners complete their declared transitions.

All GitHub platform operations use authenticated, explicitly repo-bound gh/gh api only. Do not use or fall back to App, MCP, connector, or browser UI; keep Git transport on git.

guru-review-task-delivery
guru-publish-task-delivery
guru-merge-task-delivery
guru-review-task-completion
guru-complete-task-closure
guru-finish-task
guru-cleanup-task-resources

Consume only current public typed exits and their mapped workflow consumers:

Delivery Review ready enters publication; a checked ready_for_merge enters the expected-head Delivery merge. delivered enters Completion, never directly closes the Issue or archives the task.
Completion remaining_work retains the active task; additional_delivery_required enters explicit Delivery Creation and its own Planning under the same TaskId. No-current Delivery can enter validation/Completion without an empty slice. Only completed enters Closure.
Closure closed or no_mutation enters Finish. Only Finish success enters Cleanup; Cleanup cleaned ends the route, while remaining resources stay with the Cleanup owner.

Missing, stale, unknown, multiple, or unmapped exits fail closed. Mapped stale, resume, and reprepare transitions are internal workflow routes, not user choices. Do not add a routine confirmation between them. When the user gives a clear affirmative such as 确认继续 for the exact action just displayed, consume it for that action without asking them to repeat its SHA, digest, PR, or plan identity. Continue mapped internal exits automatically. Each independent Git/GitHub or resource mutation keeps its own exact dialogue-local confirmation; new external authority or a material scope decision may also pause the route. Old Finalizer/PR residue is not a current Delivery DTO. Follow the workflow installation-migration boundary and original transaction owner; unsupported migration preserves the complete old installation and stops. Historical success cannot replace any current gate.

Do not call deterministic closeout scripts directly, reproduce package internals or artifact schemas, or create a handoff artifact. Return the current task state or the concrete declared blocker.

Install guru-finish-work and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Guru Finish Work Before substantive output, read `.trellis/spec/workflow/clear-technical-writing.md` in full and apply it within this entry's existing scope. Until that read succeeds, use only short progress messages or concrete missing-dependency diagnostics. State the current action or missing item; make no unverified claim. If the file cannot be read, pause substantive output, then read it and resume the same request when available. No additional approval is needed for that recovery. Read `.trellis/spec/workflow/workflow-contract.md#interaction-budget` before confirmation, choice or clarification; the invoked Skill owns the exact action and its confirmation boundary. On an automatic context/route failure or an explicit independent manual request, read `.trellis/workflow.md#manual-gitgithub-operations` (Manual Git/GitHub Operations). That global owner defines the boundary; this entry adds no recovery steps and does not turn a manual result into Guru completion. Read the sole continuation in `.trellis/workflow.md` and current public Task/Delivery availability through the installed context helpers. Follow its Phase 3.6/3.7 route and mandatory load the applicable owners by stable Skill id: This is the exclusive finish entry for a Guru task. The upstream-owned `trellis-finish-work` Skill is not applicable to Guru tasks and must not be loaded or invoked. Do not archive before the current Closure and Finish owners complete their declared transitions. All GitHub platform operations use authenticated, explicitly repo-bound `gh`/`gh api` only. Do not use or fall back to App, MCP, connector, or browser UI; keep Git transport on `git`. - `guru-review-task-delivery` - `guru-publish-task-delivery` - `guru-merge-task-delivery` - `guru-review-task-completion` - `guru-complete-task-closure` - `guru-finish-task` - `guru-cleanup-task-resources` Consume only current public typed exits and their mapped workflow consumers: - Delivery Review `ready` enters publication; a checked `ready_for_merge` enters the expected-head Delivery merge. `delivered` enters Completion, never directly closes the Issue or archives the task. - Completion `remaining_work` retains the active task; `additional_delivery_required` enters explicit Delivery Creation and its own Planning under the same TaskId. No-current Delivery can enter validation/Completion without an empty slice. Only `completed` enters Closure. - Closure `closed` or `no_mutation` enters Finish. Only Finish `success` enters Cleanup; Cleanup `cleaned` ends the route, while remaining resources stay with the Cleanup owner. Missing, stale, unknown, multiple, or unmapped exits fail closed. Mapped stale, resume, and reprepare transitions are internal workflow routes, not user choices. Do not add a routine confirmation between them. When the user gives a clear affirmative such as `确认继续` for the exact action just displayed, consume it for that action without asking them to repeat its SHA, digest, PR, or plan identity. Continue mapped internal exits automatically. Each independent Git/GitHub or resource mutation keeps its own exact dialogue-local confirmation; new external authority or a material scope decision may also pause the route. Old Finalizer/PR residue is not a current Delivery DTO. Follow the workflow installation-migration boundary and original transaction owner; unsupported migration preserves the complete old installation and stops. Historical success cannot replace any current gate. Do not call deterministic closeout scripts directly, reproduce package internals or artifact schemas, or create a handoff artifact. Return the current task state or the concrete declared blocker.

{ "prompt": "\n# Guru Finish Work\n\nBefore substantive output, read `.trellis/spec/workflow/clear-technical-writing.md`\nin full and apply it within this entry's existing scope. Until that read succeeds,\nuse only short progress messages or concrete missing-dependency diagnostics.\nState the current action or missing item; make no unverified claim. If the file\ncannot be read, pause substantive output, then read it and resume the same\nrequest when available. No additional approval is needed for that recovery.\n\nRead `.trellis/spec/workflow/workflow-contract.md#interaction-budget` before\nconfirmation, choice or clarification; the invoked Skill owns the exact action\nand its confirmation boundary.\n\nOn an automatic context/route failure or an explicit independent manual request,\nread `.trellis/workflow.md#manual-gitgithub-operations` (Manual Git/GitHub\nOperations). That global owner defines the boundary; this entry adds no recovery\nsteps and does not turn a manual result into Guru completion.\n\nRead the sole continuation in `.trellis/workflow.md` and current public\nTask/Delivery availability through the installed context helpers. Follow its\nPhase 3.6/3.7 route and mandatory load the applicable owners by stable Skill id:\n\nThis is the exclusive finish entry for a Guru task. The upstream-owned\n`trellis-finish-work` Skill is not applicable to Guru tasks and must not be\nloaded or invoked. Do not archive before the current Closure and Finish owners\ncomplete their declared transitions.\n\nAll GitHub platform operations use authenticated, explicitly repo-bound\n`gh`/`gh api` only. Do not use or fall back to App, MCP, connector, or browser\nUI; keep Git transport on `git`.\n\n- `guru-review-task-delivery`\n- `guru-publish-task-delivery`\n- `guru-merge-task-delivery`\n- `guru-review-task-completion`\n- `guru-complete-task-closure`\n- `guru-finish-task`\n- `guru-cleanup-task-resources`\n\nConsume only current public typed exits and their mapped workflow consumers:\n\n- Delivery Review `ready` enters publication; a checked `ready_for_merge`\n enters the expected-head Delivery merge. `delivered` enters Completion,\n never directly closes the Issue or archives the task.\n- Completion `remaining_work` retains the active task; `additional_delivery_required`\n enters explicit Delivery Creation and its own Planning under the same TaskId.\n No-current Delivery can enter validation/Completion without an empty slice.\n Only `completed` enters Closure.\n- Closure `closed` or `no_mutation` enters Finish. Only Finish `success` enters\n Cleanup; Cleanup `cleaned` ends the route, while remaining resources stay\n with the Cleanup owner.\n\nMissing, stale, unknown, multiple, or unmapped exits fail closed. Mapped\nstale, resume, and reprepare transitions are internal workflow\nroutes, not user choices. Do not add a routine confirmation between them.\nWhen the user gives a clear affirmative such as `确认继续` for the exact action\njust displayed, consume it for that action without asking them to repeat its\nSHA, digest, PR, or plan identity. Continue mapped internal exits automatically.\nEach independent Git/GitHub or resource mutation keeps its own exact\ndialogue-local confirmation; new external authority or a material scope decision\nmay also pause the route. Old Finalizer/PR residue is not a current Delivery\nDTO. Follow the workflow installation-migration boundary and original transaction\nowner; unsupported migration preserves the complete old installation and stops.\nHistorical success cannot replace any current gate.\n\nDo not call deterministic closeout scripts directly, reproduce package\ninternals or artifact schemas, or create a handoff artifact. Return the\ncurrent task state or the concrete declared blocker.", "variables": [], "notes": "Before substantive output, read `.trellis/spec/workflow/clear-technical-writing.md` in full and apply it within this entry's existing scope. Until that read succeeds, use only short progress messages or concrete missing-dependency diagnostics. State the current action or missing item; make no unverified claim. If the file cannot be read, pause substantive output, then read it and resume the same request when available. No additional approval is needed for that recovery.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/castbox/guru-trellis", "path": ".cursor/commands/guru-finish-work.md", "ref": "ab854ef29448910c332faadeec3c1a5dd810901d", "url": "https://github.com/castbox/guru-trellis/blob/ab854ef29448910c332faadeec3c1a5dd810901d/.cursor/commands/guru-finish-work.md", "key": "castbox/guru-trellis/.cursor/commands/guru-finish-work.md" } } }

guru-finish-work

About

Guru Finish Work

Install guru-finish-work and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews