What does Responder Quick Start teach first?
It teaches the seller-side minimum loop: start supervisor, enable the Responder role, validate the built-in example hotline, then create your own registration draft with schemas and examples.
What this page gets you to
From zero to one reviewable Hotline registration
- · Start supervisor and isolate local runtime state
- · Register and enable the Responder role
- · Validate the built-in example Hotline first
- · Create your own process or HTTP Hotline draft
- · Submit review and inspect status
01
Install dependencies and boot the supervisor
All seller-side commands run from the client repo. The same supervisor can host caller and responder roles, but using a separate runtime directory makes the first test easier to inspect.
bash
git clone --recursive https://github.com/hejiajiudeeyu/delegated-execution-dev.git
cd delegated-execution-dev/repos/client
npm install
export DELEXEC_HOME="$HOME/.delexec-responder-en"
export OPS_PORT_SUPERVISOR=8189
DELEXEC_HOME="$DELEXEC_HOME" OPS_PORT_SUPERVISOR="$OPS_PORT_SUPERVISOR" npm run ops -- startWarningIf you already ran the Caller quick start, either reuse the same supervisor intentionally or choose a different
DELEXEC_HOME and port to avoid mixing state accidentally.02
Register a Responder identity
Local mode does not require a hosted platform. If you do want review and Marketplace-style routing, bootstrap against your own or hosted platform endpoint instead.
bash
Local onlynpm run ops -- auth register --local --email [email protected]bash
Platform-backednpm run ops -- bootstrap --email [email protected] --platform http://127.0.0.1:808003
Enable the Responder role
Once enabled, the runtime prepares the responder controller and the registration slots needed for Hotline drafts.
bash
npm run ops -- enable-responder --display-name "Acme Workspace Tools"04
Validate the built-in example Hotline first
This keeps the first debug loop narrow. Prove the responder path works before you blame your own adapter, schema, or implementation.
bash
npm run ops -- add-example-hotline
BASE="http://127.0.0.1:${OPS_PORT_SUPERVISOR:-8079}"
curl -s -X POST "$BASE/requests/example" -H 'content-type: application/json' -H "X-Ops-Session: $OPS_SESSION" -d '{}'ExpectedA successful response here proves the caller, supervisor, and responder loop is already healthy.
05
Create your own Hotline registration
A Hotline is an adapter plus contract metadata. The most important pieces are Hotline ID, summary, input_schema, output_schema, and examples.
bash
Process adapternpm run ops -- add-hotline --type process --hotline-id your.namespace.tool-name.v1 --display-name "Workspace summarizer" --command "node ./my-tool/index.js"bash
HTTP adapternpm run ops -- add-hotline --type http --hotline-id your.namespace.tool-name.v1 --display-name "Workspace summarizer" --endpoint http://127.0.0.1:9000/runDraft locationThe generated registration draft is written to
$DELEXEC_HOME/hotline-registration-drafts/*.registration.json so you can refine summary, schemas, examples, and risk notes before review.06
Submit review and understand the review payload
Once the local draft works, send it to the review path. That is where schema validation, review tests, and Marketplace-facing checks happen.
bash
npm run ops -- submit-review --hotline-id your.namespace.tool-name.v1json
Typical review payload shape{
"responder_id": "responder_xxx",
"hotline_id": "your.namespace.tool-name.v1",
"template_ref": "local.delegated-execution.workspace-summary.v1",
"title": "Workspace summarizer",
"summary": "Summarize a target workspace into a short agent-readable report.",
"input_schema": {
"type": "object",
"required": ["text"],
"properties": {
"text": { "type": "string", "description": "user prompt" }
}
},
"output_schema": {
"type": "object",
"required": ["summary"],
"properties": {
"summary": { "type": "string", "description": "workspace summary" }
}
}
}json
One common failure shape{
"status": "FAILED",
"error": {
"code": "SCHEMA_VALIDATION_FAILED",
"message": "output_schema is missing required property definitions"
}
}ImportantNo platform is still a valid setup. In that case your Hotline remains callable in local or private self-hosted environments through the supervisor catalog, but it will not appear on the public Marketplace.
07
Check status and runtime health
A published capability is only useful if it is actually online. Status checks are the shortest way to confirm the runtime and registration are both healthy.
bash
npm run ops -- status
curl -s "$BASE/responder" -H "X-Ops-Session: $OPS_SESSION" | jqWhat to do next
You now have the seller-side minimum loop. The next decision is whether to improve the capability contract for review quality or to inspect the same system from the Caller side.
Improve the contract
Better summary, input_schema, output_schema, and examples directly improve whether Callers can understand and trust the capability.
Switch to the buyer side
A strong Responder should also understand the Caller workflow, because that is how your Hotline will actually be discovered and invoked.
Responder FAQ
Responder Quick Start common questions
These questions cover the first seller-side decisions that matter most for publishing a Hotline, and they are also emitted as English FAQ schema.
Do I need a hosted platform to publish a Hotline?
No. You can run a Hotline locally or in a private self-hosted environment first. A hosted or self-hosted platform is only needed when you want broader review, routing, or Marketplace-style discovery.
Which fields matter most when I publish a Hotline?
The most important fields are summary, input_schema, output_schema, examples, and risk notes. They determine whether Callers can understand the capability and whether review can trust the published surface.