Agent prompts and integration recipes
Each prompt is a complete starting point. Replace bracketed values with your choices; do not put passwords, API secrets or webhook secrets in the prompt. The code blocks have a copy button. The documentation index, complete text and OpenAPI let an agent inspect contracts instead of guessing routes.
Weekly digest: configure first
Using Signailist MCP, prepare a weekly digest in my connected workspace.
Read https://docs.signailist.com/llms.txt and
https://docs.signailist.com/developers-recipes first.
Read the endpoint/tool contracts at https://docs.signailist.com/developers-api
or https://docs.signailist.com/openapi.json; the full documentation is
https://docs.signailist.com/llms-full.txt.
Topic: [topic]. Sources: [URLs or existing source names].
Schedule: Monday at 09:00, timezone Asia/Tbilisi, covering the previous seven days.
Output: English, at most 7 important stories, each with a source link and a short
factual summary. Use openai/gpt-6-luna if list_models says it is available;
otherwise show the available models and ask me to choose. No images.
Destination: [existing Telegram or Discord destination]. Require approval before sending.
Call capabilities, get_integration and budget first. Inspect existing sources,
topics, templates, targets and schedules. Reuse matching configuration and avoid
duplicates. If a source or destination is ambiguous, ask me to select it.
Create/configure a template with textAiModel and periodDays=7, source-to-topic
assignments, and a weekly schedule using the documented fields.
Save new sources and the schedule paused. Report their names/IDs, the source
readiness, timezone, planned next run and remaining setup steps. Check budget
estimates before proposing any paid trial; explain that an estimate is not a quote.
Do not enable collection, trigger AI, publish or enable the schedule in this step.
The agent uses list_sources, list_topics, get_source_topic_tracking, list_templates, list_targets and list_schedules, then create_template, track_source_topics and create_schedule as needed. Some list responses use stored field names such as is_active; write requests use the documented write fields. list_schedules lists rule rows; the create/update response includes the nested schedule. Keep that response when you need its timezone and next run.
A weekly write body looks like this. Replace all *_ID values using real IDs from this workspace. The date of the next run is computed by the server, not copied from this example.
{
"name": "Weekly digest",
"triggerMode": "schedule",
"topicId": "TOPIC_ID",
"templateId": "TEMPLATE_ID",
"publicationTargetId": "TARGET_ID",
"minAiScore": 0.5,
"schedule": {
"kind": "weekly",
"weekdays": [1],
"time": "09:00",
"timezone": "Asia/Tbilisi",
"sourceIds": ["SOURCE_ID"]
},
"confirmationMode": "site",
"generateText": true,
"generateImage": false,
"checkPublishedDuplicates": true,
"isActive": false,
"clientMutationId": "weekly-digest-setup-1"
}
ISO weekdays run from Monday 1 to Sunday 7. A connected destination is required even for an approval-first rule. Discord uses confirmationMode: "site". Scheduled source selection, template period and collection state must agree; no saved materials means no usable digest input.
Run a trial, then enable recurrence
After reviewing the setup, give a separate instruction with the scope of the work you authorize:
For the weekly digest we just configured in Signailist, show the selected sources,
available budget and estimated trial cost. If the required permissions and balance
are present, enable collection for those sources and collect/prepare their materials.
Wait for source readiness and AI jobs; do not treat queue acceptance as completion.
Create one draft from actual processed item IDs and generate text once, without
images or publication. Use stable idempotency keys; after a timeout inspect the
existing job rather than submitting a new paid intent. Show the resulting draft,
actual spending and any unresolved errors. Leave the recurring schedule disabled.
Then, when ready:
Enable the existing weekly schedule [name/ID] in Signailist using its reviewed
sources, destination, timezone and approval mode. First confirm that publish scope
is present and the workspace owner has set suitable financial limits. Do not create
a replacement schedule or increase the budget. Keep publication approval enabled.
Report whether collection and the schedule are each enabled and the next run time.
If publish is absent, the owner must grant it; the agent cannot elevate itself. Schedule activation is distinct from approving a document. For sending a draft, inspect get_document, save changes with expectedRevision, approve the exact latest revision, then publish_document with a stable logicalPublicationId. Regenerating the text invalidates the old approval. Check get_delivery and the actual destination if a send is uncertain; a new idempotency key is not a safe duplicate-prevention strategy.
Connect an external system
Help integrate my system with Signailist.
Read https://docs.signailist.com/llms.txt,
https://docs.signailist.com/developers-api and
https://docs.signailist.com/developers-webhooks.
Use https://docs.signailist.com/openapi.json as the endpoint contract.
Input system: [system]. Text material fields: [fields].
Result receiver: [public HTTPS URL]. Desired result: [preprocessed text or AI digest].
Inspect existing configuration and budget. Propose the mapping to externalId,
version, title, text and publishedAt. Prepare a private external source and a
processing.completed subscription with includeResult=true, using existing objects
where suitable. Ask the owner to issue the REST intake key scoped to that source;
never request secrets in chat or store them in source control.
Generate code that reads credentials from environment variables, sends JSON batches
of at most 50 items with stable Idempotency-Key values, records each item's receipt,
verifies timestamp/raw-body HMAC, and deduplicates webhook event IDs.
Explain that processing.completed is preprocessing, not proof of finished AI scoring.
Do not upload real data or start paid work before I authorize the trial.
The intake curl example, TypeScript client, Python client and signature verifier are download links. An intake key is for REST; a source-restricted key cannot configure its own source or manage webhooks.
Publish under an existing budget
Use Signailist MCP to prepare publication of [digest ID] to [destination].
Read https://docs.signailist.com/developers-api and
https://docs.signailist.com/billing. Inspect granted scopes, budget, job status,
latest document revision and provider preview. Use the owner's existing daily
limits and do not change them. If the scope, balance or provider connection is
missing, explain the exact remaining setup step.
After my authorization to send, approve the reviewed latest revision and publish it
once with a stable logicalPublicationId and idempotency key. Check the delivery
receipt; do not resend an unknown outcome without inspecting the destination and
explicitly accepting duplicate risk. Report the outcome and actual ledger charges.
Continuous unattended publication requires explicit publication permission and a compatible provider/approval configuration. A user-owned schedule executes on Signailist; it does not require the agent conversation to remain open. Provider revocation and insufficient funds can stop the workflow and require the owner to intervene.