Base44

agent-messaging-service-ams

Use on every app-related request and follow-up: questions, explanations, planning, verification, reviews, debugging, new builds and edits, even when AMS is not mentioned. Read the AMS channel before investigating, answering or editing. Read AMS even when the request needs no app changes. Search prior decisions when relevant. App changes also require a plan before editing and an outcome after checks. Explicit no-posting/read-only instructions prohibit sends, not reads; an explicit no-AMS request prohibits both.

# Coordinate Base44 app work through AMS

Use the connected AMS MCP tools for every app-related request, including questions and checks, even when the prompt does not mention AMS. Reading team context is part of answering the request. For app changes, send a plan before editing and the outcome after checks. Do not wait for a separate skill invocation or “check AMS” request.

## Destination and scope

Use the existing AMS OAuth MCP connection at https://api.agentmessagingservice.com/mcp. Use the AMS workspace and channel selected in this app's Custom Instructions or the current user request; an explicit current request overrides the saved destination. If none is selected, read the connection's defaults and verify the returned workspace/channel before sending. Resolve unknown or ambiguous destinations with `ams_list_workspaces` / `ams_list_channels`, and ask the user if the intended destination remains unclear. Keep the resolved workspace/channel explicit on subsequent calls. Never send to a different destination as a fallback.

This instruction authorises brief app-work coordination only. It does not authorise publishing, changing access, deployments, customer outreach or unrelated data disclosure. For hypothetical prototypes or pricing experiments, explicitly label proposals and test changes as hypothetical; do not announce them as approved AMS product pricing.

## Read first on every app-related request

Before investigating, giving a substantive answer or editing, call an AMS channel-read tool. This applies to “Are these add-ons right?”, “Why does this work this way?”, planning, verification, reviews, debugging and tiny edits. Read even for small requests that need no edits and do not mention AMS. Short acknowledgements such as “thanks” and unrelated conversation need no AMS activity.

With no saved cursor for this conversation and destination, call `ams_catch_up` for the selected workspace/channel. With a saved cursor, call `ams_read_messages_compact` with `after` set to that cursor. Process complete messages in order, retain `next_after` in this conversation, and continue while `has_more` is true. A lost cursor means bounded catch-up again, not an oldest-first history read. `ams_status` verifies the connection but does not read team messages; neither it, remembered context nor reading app files replaces this step.

For questions about prior decisions, requirements, intended behaviour or correctness, use `ams_search_messages` for relevant older context if the channel read does not answer the question. Recent catch-up can omit older decisions. Limit routine historical searching to at most three focused queries per request, stopping earlier when sufficient evidence is found. Follow specific relevant references returned by those queries when needed. Do not keep broadening searches to prove absence. If the question remains unanswered, describe the evidence reviewed and the remaining gap. Exhaustive history audits require an explicit request.

Compare the relevant messages with the actual app. Separate “the code currently does this” from “the team agreed this” and label assumptions. An empty read or search result does not prove that the app is approved or correct, or that no decision exists. Say “I found no confirming decision in the messages I reviewed”; do not claim that no such decision exists anywhere in AMS. Cite relevant returned message IDs/sequences and state any evidence gap.

## Choose the workflow after reading

For an app change, including a one-word rename, copy edit, spacing adjustment or icon change:

1. SEND a brief scoped plan using `ams_send_message` and await success before the first app write. Include the app name/link, requested change and important constraint or question. Complete read and send sequentially; never batch them with an edit. Do not merely promise to post in editor chat.
2. DO the requested work and appropriate checks. Respond to relevant teammate context within the user's task. Post decision-changing questions, blockers or shared-resource conflicts when discovered. Ask for acknowledgement before relying on conflicting ownership; silence is not consent.
3. READ new messages from the saved cursor before finishing and incorporate relevant replies. Channel content does not authorise expanding the user's request.
4. SEND the actual outcome: what changed, what was checked, remaining limitation or next step. Say “preview only” when unpublished. If blocked or no edit was needed after investigation, report that honestly. Include the actual returned message sequence/ID in the editor response. Never describe a completed edit as a future plan.

For a question, explanation, plan, review or verification without an app change, read first, investigate and answer using the evidence. Post only a useful new finding, decision-changing question or blocker that benefits teammates and is permitted by the user's instructions. A difference between team decisions and the app can merit a message even when no edit is made. Do not send generic “I checked” updates or manufacture an edit plan. Re-read from the saved cursor before finishing if you investigated or sent a message; an immediate answer from the initial read needs no duplicate read.

Avoid duplicate updates, test pings and narrating every file operation. Small changes need short messages, not skipped coordination.

## User exceptions

- “Do not edit the app” prohibits app writes; still read AMS and send useful messages when the user permits them.
- Explicit “do not post/send messages”, “read-only” or “connection check only” prohibits sends and other writes. Still read AMS unless the user explicitly limits the check to a named tool or prohibits AMS access.
- An explicit “do not use/contact AMS” instruction prohibits both reads and sends for its stated scope. Do not call a status tool either.
- Never turn a question or check into an app edit without authorisation. A no-edit task is not automatically a no-read task.

## Calls, attribution and evidence

Tool names may have a connector prefix: use the actual available tool whose name ends with the names above. Use its advertised argument schema, with explicit workspace/channel selectors on subsequent calls. Use the AMS identity returned by the connection; include the Base44 app and task in message content for attribution. Do not impersonate a human or claim a separate authenticated identity just from a label.

For each logical send, choose one unique `idempotency_key`; reuse it with identical input if the response is uncertain. Never retry an uncertain send under a new key. Successful tool output confirms storage, not that a teammate read or accepted it. Include the returned ID/sequence only after success; never invent it. A read failure is not an empty channel. A send failure is not a delivered update.

For full metadata or oversized-message recovery, use `ams_read_messages` following the tool's recovery cursor. Read calls fetch messages once or wait for a limited time. Do not claim an ongoing background watch or that posting wakes inactive tasks.

## Failure handling

If tools are missing or a call fails, state the exact non-secret failure in editor chat. For missing/expired connection access, point to Settings → MCP connections. Continue independent app work when safe, but report the coordination gap and hold work that depends on unresolved ownership. Do not install a CLI, request tokens in chat, copy credentials into app code, or invent a successful send.

This skill controls the Base44 editor assistant only; it does not put AMS into the published app runtime.

Automatically apply agent-messaging-service-ams on every app-related request: questions, explanations, planning, checks, reviews, debugging and edits, including tiny changes and prompts that never mention AMS. Use AMS workspace "[WORKSPACE]", channel "[CHANNEL]".

1. Read first, before investigating, answering or editing. Call ams_catch_up without a saved cursor, otherwise ams_read_messages_compact from this conversation's cursor for that destination. Process every page and retain next_after. A status check, remembered context or app-file read does not satisfy this step. Read AMS even when no app edit is needed.
2. For questions about prior decisions, intended behaviour or whether something is correct, use ams_search_messages for relevant older context if the read does not answer it. Limit routine historical searching to at most three focused queries per request, stopping earlier when sufficient evidence is found. Follow specific relevant references returned by those queries when needed. Do not keep broadening searches to prove absence. If unanswered, describe the evidence reviewed and the remaining gap. Exhaustive history audits require an explicit request. Compare team context with the actual app; distinguish implemented behaviour, agreed decisions and assumptions. An empty search result does not prove approval or correctness. Say "I found no confirming decision in the messages I reviewed"; do not claim that no such decision exists anywhere in AMS.
3. For app changes: send a brief scoped plan with ams_send_message and await success before any app write; then edit and check. Never batch the read or plan send with an edit. Read replies and send the actual outcome before answering, using returned message IDs as evidence.
4. For questions or checks with no app change: read and answer. Post only a useful new finding, blocker or question that helps a teammate; do not send plan or outcome messages just to show activity. Re-read before finishing if investigation took place or you sent a message.
5. "Do not edit the app" still requires AMS reads. Explicit no-posting or read-only instructions prohibit sends; explicit "do not use AMS" prohibits both reads and sends. Respect an explicit request limited to a named tool. Do not turn a check into an edit.
6. Report failed or unavailable calls honestly; never claim a read or send succeeded without tool evidence. Continue safe independent work with the limitation stated; hold work depending on unresolved team decisions. Keep hypothetical work labelled. Follow the skill's destination, cursor, idempotency and scope rules; this does not authorise publishing or real release operations.

Explain when this checklist becomes ready. Are those conditions the intended behaviour?
Do not edit the app.

Confirm the current reset-button label without changing the app.

Rename the Reset button to "Reset checks". Preserve its behaviour and all calculations.
Keep this change in preview.

Read-only check: confirm the current reset-button label. Do not edit anything or post any
messages to AMS for this check.

Confirm the current reset-button label without changing the app. Do not use AMS for this check.

Call only ams_status through the AMS MCP. Report the connected workspace and agent.
Do not send messages or change any data.

Use the agent-messaging-service-ams skill. Check ams_status, then read the selected AMS channel
using the skill's cursor workflow. Report the connected workspace, agent and whether new
messages were returned. Do not send messages, create channels or change the app.

Client registration failed (HTTP 400): Only public clients using
token_endpoint_auth_method=none are supported