feat(automations): inject the member's Automations into the prompt, like marketplace skills - #3556
Merged
Merged
Conversation
Marketplace skills reach the agent as a catalog: Den serves skill://index.json, the local server renders <available_skills> with each skill's exact capability, and it rides in every system prompt. That is why an agent can list all five skills instantly with no tool calls. Automations only had prose naming the capabilities, so "what automations do I have?" cost a round trip and editing one meant listing first to find its id. Give them the same treatment: a new automation://index.json resource on the Den agent MCP, read through the same connection and rendered as <available_automations> with each id, schedule, state, next run, and last run. One deliberate difference from skills. Skills are near-static; an Automation's next run is stale the moment a run fires. So the index is stamped with when it was captured and the guidance is explicit: use the listing to know what exists and which id to act on, but re-read through a capability before reporting any status, next run, or result — and never quote the listed values as current truth. A bounded index also reports how many it left out instead of implying the list is complete, and no usable connection renders nothing rather than asserting the member owns none. The MCP transport the skill catalog used is extracted so both indexes speak to the connection the same way instead of a second copy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
![diff-warden[bot]](https://avatars.githubusercontent.com/u/118544361?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warden security clearance: clear. No new security issues found in this diff (b2c3c4377e137f0a56c5a5aefb3518e4d32763a6). Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #3554. That PR taught the agent that Automation capabilities exist. This one gives it the same treatment marketplace skills already get: the member's actual Automations, in the prompt.
Why
Marketplace skills reach the agent as a catalog, not prose — Den serves
skill://index.json, the local server renders<available_skills>with each skill's exact<capability>, and it rides in every system prompt. That is why an agent can enumerate all five skills instantly, with zero tool calls.Automations had only the static guidance from #3554 naming the capabilities. So "what automations do I have?" cost a round trip, and editing one meant listing first just to find its id.
What changed
skill://index.jsonautomation://index.jsonreadOpenWorkConnectSkillCatalog, 30s cache, candidate fallbackreadOpenWorkAutomationCatalog, 15s cache, same fallbackGET /experimental/connect/skillsGET /experimental/connect/automationsconnect-skills→<available_skills>automations→<available_automations>Each entry carries
<id>,<name>,<state>,<schedule>,<next-run>,<last-run>— so the agent can answer status questions immediately and act on an existing Automation by its exact id.The MCP transport the skill catalog used (initialize → notifications/initialized →
resources/read, session headers, SSE payload parsing) is extracted toconnect-mcp-transport.tsso both indexes speak to the connection the same way rather than a second copy drifting from the first.The one deliberate difference from skills
Skills are near-static. An Automation's next run is stale the moment a run fires — so an injected catalog is a confident-liar machine if you treat it like the skill index.
Three rules encode that, and each has a test:
fetchedAttravels with the index and is rendered into the prompt. The guidance says: use the listing to know what exists and which id to act on, but re-read throughlistAutomations/getAutomation/listAutomationRuns/getAutomationRunbefore reporting any status, next run, or result, and never quote<next-run>or<last-run>as current truth.omitted+total, rendered as "15 further Automation(s) are not listed here … page through all 40". A silent truncation would read as a complete list.openwork-cloudconnection renders an empty string, not "you own none". Only a real empty result says that.Safety
ownerMemberId's own Automations, and is skipped entirely when no member identity resolves.<available_skills>: names and instructions are authored by the user or a marketplace, so they are declared subordinate to the system prompt. Values are XML-escaped — a test feedsIgnore previous instructions & <script>…and asserts it cannot forge a tag or close the block early.Checks
Run on
b2c3c4377:pnpm --dir apps/server typecheck— passedpnpm --filter @openwork-ee/den-api typecheck:automations— passedsrc/mcp/**is outside the automations tsconfig, so I ran it explicitly) — passed. It caught a real defect:memberIdentityis nullable there, and the index is now skipped rather than dereferencing it.connect-automation-catalogtests — 5 passedautomation-indextests — 3 passed, plus runner protocol 11 passednode:sqliteresolution error that reproduces identically on unmodifieddev(615 passed / 1 failed). Not introduced here, not claimed as passing.No dependency changes, so
pnpm-lock.yamlis untouched.Not covered
I could not exercise this against a live Cloud MCP connection, so the resource read and the end-to-end injection are verified by types, unit tests, and by mirroring the skill catalog's proven path — not by a live run. Worth a manual pass: with Cloud connected, ask a thread what Automations you have and confirm it answers without a tool call, then ask it to change one and confirm it acts on the right id.
🤖 Generated with Claude Code