loopengine 0.3.10 → 0.3.11

package/dist/core/system-agents/workflow-examples.js

@@ -0,0 +1,432 @@
+const GMAIL = '@loopengine-co/gmail';
+const SHOPIFY = '@loopengine-co/shopify';
+const HUBSPOT = '@loopengine-co/hubspot';
+const GMAIL_KEYS = ['GMAIL_CLIENT_ID', 'GMAIL_CLIENT_SECRET', 'GMAIL_REFRESH_TOKEN'];
+const SHOPIFY_KEYS = ['SHOPIFY_STORE_DOMAIN', 'SHOPIFY_ADMIN_TOKEN'];
+const GITHUB_APP = 'io.github.github/github-mcp-server';
+const FIRECRAWL_APP = 'io.github.firecrawl/firecrawl-mcp-server';
+const NEW_AGENT = 'A ready-made example, set up as its own agent; you can add it to an agent you have instead.';
+const policiesNote = (what, skill) => `Write ${what} into its ${skill} skill (Advanced → Skills): the agent answers from it and nothing else`;
+const SUPPORT_POLICIES = {
+    id: 'support-policies',
+    description: 'Our shipping, returns, refunds and other customer policies. Read it before telling a customer anything about a policy.',
+    body: `# Our customer policies
+
+Edit this: replace each [bracket] with your own policy. The agent answers customers from this and nothing else.
+
+## Shipping
+- Where we ship: [countries]
+- How long it takes: [e.g. 3–5 business days]
+- Tracking: [when and how customers get it]
+
+## Returns and refunds
+- Return window: [e.g. 30 days from delivery]
+- What can't be returned: [e.g. sale items, opened cosmetics]
+- How refunds are paid: [e.g. to the original payment method, in 5–10 business days]
+
+## Other questions
+- [Order changes and cancellations]
+- [Warranty]
+- [Anything customers often ask]
+`,
+};
+const RETURN_POLICY = {
+    id: 'return-policy',
+    description: 'Our return and refund policy: the window, what qualifies, and how much is refunded. Read it before proposing any refund.',
+    body: `# Our return policy
+
+Edit this: replace each [bracket] with your own policy. The agent proposes refunds from this and nothing else.
+
+- Return window: [e.g. 30 days from delivery]
+- Eligible items: [e.g. unused, in the original packaging]
+- Not eligible: [e.g. sale items, gift cards, personalised items]
+- Damaged or wrong items: [e.g. full refund including shipping, no return needed]
+- Change of mind: [e.g. refund of the item price, customer pays return shipping]
+- Shipping costs: [when they're refunded]
+- Partial refunds: [when you offer one, and how much]
+`,
+};
+const EXPENSE_POLICY = {
+    id: 'expense-policy',
+    description: 'Our expense policy: what can be claimed, the limits, and what a claim needs. Read it before giving any verdict.',
+    body: `# Our expense policy
+
+Edit this: replace each [bracket] with your own policy. The agent checks claims against this and nothing else.
+
+## What can be claimed, and the limits
+- Travel: [e.g. economy flights and trains; taxis when there's no public transport]
+- Hotels: [e.g. up to 150 per night]
+- Meals: [e.g. up to 50 per day when travelling]
+- Equipment and software: [e.g. up to 200 without pre-approval]
+
+## What can't be claimed
+- [e.g. alcohol, fines, personal entertainment]
+
+## What every claim needs
+- An itemised receipt showing the amount, date and merchant
+- [Pre-approval for anything over a limit]
+- Submitted within [e.g. 60 days]
+`,
+};
+/** The parts every example's plan shares. */
+function example(id, category, plan) {
+    return {
+        id,
+        category,
+        plan: {
+            parameters: {},
+            notify: { on: false, reason: '' },
+            gaps: [],
+            target: { kind: 'new', reason: NEW_AGENT },
+            ...plan,
+        },
+    };
+}
+export const WORKFLOW_EXAMPLES = [
+    example('customer-email-replies', 'Customer service', {
+        name: 'Answer customer emails',
+        id: 'answer-customer-emails',
+        summary: 'Checks the support inbox every 10 minutes, looks up each customer\'s order and your policies, and replies. Every reply waits for your approval until you trust it; refund requests are left for a person.',
+        trigger: { kind: 'schedule', description: 'every 10 minutes, for new emails', every: '10m' },
+        steps: [
+            { title: 'Find new customer emails', kind: 'tool', tool: 'gmail_search', ability: GMAIL },
+            { title: 'Read the whole conversation', kind: 'tool', tool: 'gmail_get_thread', ability: GMAIL },
+            { title: 'Look up their order', kind: 'tool', tool: 'shopify_find_orders', ability: SHOPIFY, detail: 'then shopify_get_order for its details' },
+            { title: 'Check our policies', kind: 'other', detail: 'from its support-policies skill' },
+            { title: 'Reply in the thread', kind: 'approval', tool: 'gmail_send', ability: GMAIL },
+            { title: 'Mark the email done', kind: 'tool', tool: 'gmail_modify_labels', ability: GMAIL },
+        ],
+        abilities: [GMAIL, SHOPIFY],
+        rules: [
+            { tool: 'gmail_search', decision: 'allow' },
+            { tool: 'gmail_get_thread', decision: 'allow' },
+            { tool: 'gmail_create_draft', decision: 'allow' },
+            { tool: 'gmail_modify_labels', decision: 'allow' },
+            { tool: 'gmail_send', decision: 'ask' },
+            { tool: 'shopify_create_refund', decision: 'deny' },
+        ],
+        keys: [...GMAIL_KEYS, ...SHOPIFY_KEYS],
+        needsApprovals: true,
+        skill: {
+            description: 'Handle new customer emails in the support inbox: look up each order and our policies, and reply in the thread.',
+            body: `1. Find new emails with gmail_search, query "is:unread in:inbox". Skip newsletters, receipts, automatic notifications and "no-reply" senders: mark those read and move on.
+2. For each customer email, read the whole conversation with gmail_get_thread first.
+3. Work out what they want: order status, a product question, a return or refund, a complaint, or something else.
+4. Look up what you need before answering: the order with shopify_find_orders (by the order number they give, or their email) and shopify_get_order, and our policies in the support-policies skill (open it with Skill).
+5. Reply with gmail_send, passing reply_to_message_id so it stays in the same thread: short, friendly, in the customer's language, using their name, answering the question first and saying what happens next.
+6. Mark the email read with gmail_modify_labels (remove "UNREAD").
+
+- A refund, return or replacement request: reply that it has been passed to the team, then star the email (add "STARRED") instead of acting on it.
+- An angry customer, or one who mentions a lawyer, a chargeback or a safety problem: save a calm reply with gmail_create_draft and star the email for a person.
+- If you can't find the order or the answer, say so and ask for the order number.`,
+        },
+        startMessage: 'Handle new customer emails in the support inbox.',
+        newAgent: {
+            name: 'customer-email-replies',
+            systemPrompt: `You answer customer emails for our business, from our support inbox.
+
+Rules:
+- Refunds, returns and replacements are handled by a person; never promise or make one yourself.
+- Never guess an order detail, a date or a policy. Our policies are in your support-policies skill: answer from it and nothing else.
+- If a customer is angry, or mentions a lawyer, a chargeback or a safety problem, don't promise anything; leave it for a person.
+- Never share one customer's information with anyone else.`,
+        },
+        skills: [SUPPORT_POLICIES],
+        notes: [policiesNote('your policies', 'support-policies')],
+    }),
+    example('refund-approvals', 'Customer service', {
+        name: 'Refund approvals',
+        id: 'refund-approvals',
+        summary: 'Checks the inbox for refund and return requests, checks each against the order and your return policy, and proposes the refund and the reply. Both wait for your approval.',
+        trigger: { kind: 'schedule', description: 'every 10 minutes, for new refund requests', every: '10m' },
+        steps: [
+            { title: 'Find refund and return requests', kind: 'tool', tool: 'gmail_search', ability: GMAIL },
+            { title: 'Read each conversation', kind: 'tool', tool: 'gmail_get_thread', ability: GMAIL },
+            { title: 'Look up the order', kind: 'tool', tool: 'shopify_find_orders', ability: SHOPIFY, detail: 'then shopify_get_order: what was paid, refunded and delivered' },
+            { title: 'Check it against the return policy', kind: 'other', detail: 'from its return-policy skill' },
+            { title: 'Work out the exact amount', kind: 'tool', tool: 'shopify_preview_refund', ability: SHOPIFY },
+            { title: 'Issue the refund', kind: 'approval', tool: 'shopify_create_refund', ability: SHOPIFY },
+            { title: 'Reply to the customer', kind: 'approval', tool: 'gmail_send', ability: GMAIL },
+        ],
+        abilities: [GMAIL, SHOPIFY],
+        rules: [
+            { tool: 'gmail_search', decision: 'allow' },
+            { tool: 'gmail_get_thread', decision: 'allow' },
+            { tool: 'gmail_create_draft', decision: 'allow' },
+            { tool: 'gmail_modify_labels', decision: 'allow' },
+            { tool: 'shopify_preview_refund', decision: 'allow' },
+            { tool: 'shopify_create_refund', decision: 'ask' },
+            { tool: 'gmail_send', decision: 'ask' },
+        ],
+        keys: [...GMAIL_KEYS, ...SHOPIFY_KEYS],
+        needsApprovals: true,
+        skill: {
+            description: 'Handle new refund and return requests: check each against the order and our return policy, propose the refund, and reply.',
+            body: `1. Find requests with gmail_search, query "is:unread in:inbox (refund OR return OR damaged OR broken OR "money back")". Read each conversation with gmail_get_thread. If an email isn't really a refund or return request, leave it unread for the support team.
+2. Find the order with shopify_find_orders (the order number they give, or their email) and read it with shopify_get_order: what was bought, when, how much, what's already been refunded, whether it was delivered.
+3. Check the request against our return policy in the return-policy skill (open it with Skill): the return window, whether the item is eligible, and whether the reason is covered.
+4. Decide what to propose: a full refund, a partial refund, refunding shipping, or no refund (and which part of the policy says so).
+5. Work out the exact amount with shopify_preview_refund. Never state an amount you haven't previewed.
+6. Issue it with shopify_create_refund, with a note giving the policy rule and the facts from the order. A person approves it first.
+7. Once the refund is done, reply with gmail_send (reply_to_message_id set): what was refunded, to which payment method, and that it takes 5–10 business days to arrive. Then mark the email read with gmail_modify_labels.
+
+- If the refund is denied, don't try again; save a reply with gmail_create_draft explaining what you'd suggest instead, and star the email for a person.
+- If the order can't be found, ask the customer for the order number.`,
+        },
+        startMessage: 'Handle new refund and return requests in the support inbox.',
+        newAgent: {
+            name: 'refund-approvals',
+            systemPrompt: `You handle refund and return requests for our store.
+
+Rules:
+- Never refund more than was paid, and never refund an order twice: check its refunds first.
+- Every amount you state comes from a refund preview, and every decision from your return-policy skill; never guess either.
+- If a customer mentions a chargeback, a lawyer or a safety problem, don't act; leave it for a person.`,
+        },
+        skills: [RETURN_POLICY],
+        notes: [policiesNote('your return policy', 'return-policy')],
+    }),
+    example('incident-triage', 'Operations', {
+        name: 'Triage an incident',
+        id: 'triage-incident',
+        summary: 'Takes an alert or a bug report, works out what broke and how bad it is, finds the deploys and changes that likely caused it, and sends you a summary. Opening or commenting on issues waits for approval.',
+        trigger: { kind: 'on_request', description: 'when your alerting tool calls its webhook, or someone passes it an alert in Chat or Slack' },
+        parameters: { alert: { description: 'The alert, error or bug report', required: true } },
+        steps: [
+            { title: 'Summarise it and rate the severity', kind: 'other' },
+            { title: 'Find recent deploys and failed builds', kind: 'tool', tool: 'github_actions_list', detail: 'from the GitHub app' },
+            { title: 'Find recently merged changes', kind: 'tool', tool: 'github_list_pull_requests', detail: 'and github_list_commits for detail' },
+            { title: 'Check whether it\'s already known', kind: 'tool', tool: 'github_search_issues', detail: 'and github_issue_read for a match' },
+            { title: 'Add findings to the issue, or open one', kind: 'approval', tool: 'github_issue_write', detail: 'or github_add_issue_comment' },
+            { title: 'End with the summary', kind: 'other', detail: 'sent to you when the run finishes' },
+        ],
+        abilities: [],
+        apps: [{ id: GITHUB_APP, title: 'GitHub', tools: ['list_commits', 'list_pull_requests', 'actions_list', 'search_issues', 'issue_read', 'issue_write', 'add_issue_comment'] }],
+        rules: [
+            { tool: 'github_issue_write', decision: 'ask' },
+            { tool: 'github_add_issue_comment', decision: 'ask' },
+        ],
+        keys: [],
+        needsApprovals: true,
+        skill: {
+            description: 'Triage an alert, error or bug report: what broke, how bad it is, and the change that likely caused it.',
+            body: `Triage this alert: $alert
+
+1. Summarise it in two sentences: what is failing and who is affected.
+2. Rate the severity: SEV1 (customers can't use the product), SEV2 (a major feature is broken), SEV3 (degraded or a workaround exists), SEV4 (minor).
+3. Find what changed shortly before it started: github_actions_list (method list_workflow_runs) for recent deploys and failed builds, github_list_pull_requests (state closed) for recently merged changes, and github_list_commits (narrowed with since and path) for detail. Match times carefully.
+4. Check whether it's already known with github_search_issues; read a match with github_issue_read (method get).
+5. If an issue already tracks it, add your findings with github_add_issue_comment; otherwise, for SEV1 or SEV2, open one with github_issue_write (method create). Both ask a person first.
+6. End with the summary: what's broken, severity, the most likely cause with links, and one next step (who should look, what to check, or whether to roll back). Keep it short enough to read on a phone.`,
+        },
+        startMessage: 'Triage this alert: $alert',
+        newAgent: {
+            name: 'incident-triage',
+            systemPrompt: `You help the on-call engineer triage incidents.
+
+Our repository on GitHub: [owner/name] (edit this). Pass its owner and repo to every GitHub tool.
+
+Rules:
+- Only read on your own; never roll anything back yourself.
+- Say how sure you are. If the evidence is thin, say what would confirm it instead of guessing.`,
+        },
+        notes: ['Send it alerts: add a webhook to this workflow (Workflows tab) with "Message me the result when it finishes" on, and paste its URL into your alerting tool; or mention it in Slack, or paste an alert into Chat'],
+    }),
+    example('expense-approvals', 'Finance', {
+        name: 'Check expense claims',
+        id: 'check-expense-claims',
+        summary: 'Checks the claims inbox, reads each claim and its receipt, checks it against your expense policy, and sends the approver a one-line verdict. Replies to claimants wait for your approval.',
+        trigger: { kind: 'schedule', description: 'every 15 minutes, for new claims', every: '15m' },
+        steps: [
+            { title: 'Find new claims', kind: 'tool', tool: 'gmail_search', ability: GMAIL },
+            { title: 'Read each claim and its receipt', kind: 'tool', tool: 'gmail_get_thread', ability: GMAIL },
+            { title: 'Check it against the expense policy', kind: 'other', detail: 'from its expense-policy skill' },
+            { title: 'Email the approver the verdict', kind: 'approval', tool: 'gmail_send', ability: GMAIL },
+            { title: 'Mark the claim done', kind: 'tool', tool: 'gmail_modify_labels', ability: GMAIL },
+        ],
+        abilities: [GMAIL],
+        rules: [
+            { tool: 'gmail_search', decision: 'allow' },
+            { tool: 'gmail_get_thread', decision: 'allow' },
+            { tool: 'gmail_create_draft', decision: 'allow' },
+            { tool: 'gmail_modify_labels', decision: 'allow' },
+            { tool: 'gmail_send', decision: 'ask' },
+        ],
+        keys: [...GMAIL_KEYS],
+        needsApprovals: true,
+        skill: {
+            description: 'Check new expense claims in the inbox against our expense policy and send the approver a verdict.',
+            body: `1. Find new claims with gmail_search, query "is:unread in:inbox". Read each with gmail_get_thread.
+2. Read the amount, currency, date, merchant, category and who submitted it, from the email and its receipt (the attachment names show whether a receipt is there).
+3. Check it against our expense policy in the expense-policy skill (open it with Skill): the category is allowed, it's under the limit, the receipt matches the amount and date, and it isn't a duplicate of an earlier claim (search the inbox for the same merchant and amount).
+4. Write a one-line verdict: "Within policy" or "Outside policy: <reason>", then the details you checked.
+5. Email the verdict to the approver at the address in the EXPENSE_APPROVER_EMAIL setting with gmail_send, then mark the claim read with gmail_modify_labels.
+
+- If the receipt is missing or unreadable, draft a reply to the claimant asking for it with gmail_create_draft; don't fill in values.
+- If the policy doesn't cover the case, say which part is unclear rather than deciding.`,
+        },
+        startMessage: 'Check the new expense claims in the inbox.',
+        newAgent: {
+            name: 'expense-approvals',
+            systemPrompt: `You check expense claims against our expense policy, in your expense-policy skill.
+
+Rules:
+- Never approve or pay a claim yourself. A person always decides.
+- Judge only by the policy and the receipt; never fill in a value you can't read.`,
+        },
+        skills: [EXPENSE_POLICY],
+        notes: [policiesNote('your expense policy', 'expense-policy'), 'Set EXPENSE_APPROVER_EMAIL (Environment tab) to the approver\'s address'],
+    }),
+    example('lead-follow-up', 'Sales', {
+        name: 'Lead follow-up',
+        id: 'lead-follow-up',
+        summary: 'Every hour, picks up new leads in HubSpot, researches each on the web, and sends a short, personal first email. Sending and updating the CRM wait for your approval.',
+        trigger: { kind: 'schedule', description: 'every hour, for new leads', every: '1h' },
+        steps: [
+            { title: 'Find new leads', kind: 'tool', tool: 'hubspot_find_contacts', ability: HUBSPOT },
+            { title: 'Skip anyone already being handled', kind: 'tool', tool: 'hubspot_get_contact', ability: HUBSPOT },
+            { title: 'Research them on the web', kind: 'tool', tool: 'firecrawl_search', detail: 'and firecrawl_scrape, from the Firecrawl app' },
+            { title: 'Send a short first email', kind: 'approval', tool: 'gmail_send', ability: GMAIL },
+            { title: 'Log it in HubSpot', kind: 'tool', tool: 'hubspot_add_note', ability: HUBSPOT },
+            { title: 'Update the lead\'s status', kind: 'approval', tool: 'hubspot_update_contact', ability: HUBSPOT },
+        ],
+        abilities: [HUBSPOT, GMAIL],
+        apps: [{ id: FIRECRAWL_APP, title: 'Firecrawl', tools: ['firecrawl_search', 'firecrawl_scrape'] }],
+        rules: [
+            { tool: 'firecrawl_search', decision: 'allow' },
+            { tool: 'firecrawl_scrape', decision: 'allow' },
+            { tool: 'hubspot_add_note', decision: 'allow' },
+            { tool: 'hubspot_update_contact', decision: 'ask' },
+            { tool: 'hubspot_create_contact', decision: 'deny' },
+            { tool: 'gmail_send', decision: 'ask' },
+        ],
+        keys: ['HUBSPOT_ACCESS_TOKEN', ...GMAIL_KEYS],
+        needsApprovals: true,
+        skill: {
+            description: 'Follow up with new leads in HubSpot: research each one and send a short, personal first email.',
+            body: `1. Find new leads with hubspot_find_contacts: lead_status "NEW", created_in_last_days 2.
+2. For each, read hubspot_get_contact. Skip anyone with an owner, recent notes, or a last-contacted date: someone is already on it.
+3. Research them with firecrawl_search and firecrawl_scrape: what their company does, its size, and anything recent that matters (funding, hiring, a launch). Note your sources.
+4. Work out what they most likely need from us, in one sentence.
+5. Send a short first email (under 120 words) with gmail_send: a specific opening based on your research, one sentence on how we help with that need, and one easy question to reply to. A person approves it first.
+6. Log what you sent and found with hubspot_add_note, and set the lead to "ATTEMPTED_TO_CONTACT" with hubspot_update_contact.
+
+- If the lead looks like a competitor, a student or spam, add a note saying so and don't email them.`,
+        },
+        startMessage: 'Follow up with the new leads in HubSpot.',
+        newAgent: {
+            name: 'lead-follow-up',
+            systemPrompt: `You follow up with new leads for our business.
+
+What we sell (edit this):
+- [What your product does, in one sentence]
+- [Who it is for]
+- [The one result customers care about most]
+
+Rules:
+- Never invent facts about a lead. If research finds nothing reliable, write a simple, honest email instead.
+- No pressure tactics, fake urgency or discounts you weren't told about.`,
+        },
+        notes: ['Edit "What we sell" at the top of its instructions (Overview tab)'],
+    }),
+    example('inbox-to-tasks', 'Operations', {
+        name: 'Inbox to tasks',
+        id: 'inbox-to-tasks',
+        summary: 'Checks a shared inbox every 10 minutes and turns each request into a task (a GitHub issue) with an owner and a due date, then tells the sender who is handling it.',
+        trigger: { kind: 'schedule', description: 'every 10 minutes, for new emails', every: '10m' },
+        steps: [
+            { title: 'Find new emails', kind: 'tool', tool: 'gmail_search', ability: GMAIL },
+            { title: 'Read each one', kind: 'tool', tool: 'gmail_get_thread', ability: GMAIL },
+            { title: 'Check for an existing task', kind: 'tool', tool: 'github_search_issues', detail: 'from the GitHub app' },
+            { title: 'Open the task, or add to it', kind: 'tool', tool: 'github_issue_write', detail: 'or github_add_issue_comment' },
+            { title: 'Tell the sender who is handling it', kind: 'approval', tool: 'gmail_send', ability: GMAIL },
+            { title: 'Mark the email done', kind: 'tool', tool: 'gmail_modify_labels', ability: GMAIL },
+        ],
+        abilities: [GMAIL],
+        apps: [{ id: GITHUB_APP, title: 'GitHub', tools: ['search_issues', 'issue_write', 'add_issue_comment'] }],
+        rules: [
+            { tool: 'gmail_search', decision: 'allow' },
+            { tool: 'gmail_get_thread', decision: 'allow' },
+            { tool: 'gmail_modify_labels', decision: 'allow' },
+            { tool: 'github_issue_write', decision: 'allow' },
+            { tool: 'github_add_issue_comment', decision: 'allow' },
+            { tool: 'gmail_send', decision: 'ask' },
+        ],
+        keys: [...GMAIL_KEYS],
+        needsApprovals: true,
+        skill: {
+            description: 'Turn new emails in the shared inbox into tasks (GitHub issues) with an owner and a due date, and tell each sender.',
+            body: `1. Find new emails with gmail_search, query "is:unread in:inbox". Read each with gmail_get_thread.
+2. Decide whether it's a request someone needs to act on. Newsletters, receipts, out-of-office replies and spam are not: mark them read and move on.
+3. Check whether a task already exists with github_search_issues (the sender and subject). If so, add the new details with github_add_issue_comment instead.
+4. Otherwise open one with github_issue_write (method create): a short title starting with a verb, a two-line summary, the sender, the due date (the date they asked for, or 2 working days if they didn't say), and the owner from "Who handles what" as the assignee.
+5. Reply to the sender with gmail_send (reply_to_message_id set): who is handling it and by when. A person approves it first.
+6. Mark the email read with gmail_modify_labels.
+
+- If an email holds several requests, make one task for each.`,
+        },
+        startMessage: 'Turn the new emails in the shared inbox into tasks.',
+        newAgent: {
+            name: 'inbox-to-tasks',
+            systemPrompt: `You turn requests in our shared inbox into tasks, kept as GitHub issues.
+
+Tasks live in this GitHub repository: [owner/name] (edit this). Pass its owner and repo to every GitHub tool.
+
+Who handles what (edit this; GitHub usernames):
+- Billing and invoices: [username]
+- Technical problems: [username]
+- Everything else: [username]
+
+Rules:
+- Never promise a fix or a refund to a sender; only say who is handling it and by when.`,
+        },
+        notes: ['Edit "Who handles what" and the repository at the top of its instructions (Overview tab)'],
+    }),
+    example('weekly-research-digest', 'Research', {
+        name: 'Weekly research digest',
+        id: 'weekly-research-digest',
+        summary: 'Every Monday morning, searches the web for news on the topics you choose and sends you a short digest with links.',
+        trigger: { kind: 'schedule', description: 'Mondays at 09:00', every: '7d', at: '09:00', weekday: 1 },
+        steps: [
+            { title: 'Search for this week\'s news on each topic', kind: 'tool', tool: 'firecrawl_search', detail: 'from the Firecrawl app' },
+            { title: 'Read the most relevant pages', kind: 'tool', tool: 'firecrawl_scrape' },
+            { title: 'Write the digest', kind: 'other', detail: 'sent to you when the run finishes' },
+        ],
+        abilities: [],
+        apps: [{ id: FIRECRAWL_APP, title: 'Firecrawl', tools: ['firecrawl_search', 'firecrawl_scrape'] }],
+        rules: [
+            { tool: 'firecrawl_search', decision: 'allow' },
+            { tool: 'firecrawl_scrape', decision: 'allow' },
+        ],
+        keys: [],
+        needsApprovals: false,
+        notify: { on: true, reason: 'The digest is the result, and no step posts it.' },
+        skill: {
+            description: 'Write this week\'s research digest on the topics to follow.',
+            body: `1. Search the web with firecrawl_search for what happened in the last 7 days on each topic you follow.
+2. Open the most relevant pages with firecrawl_scrape and read them; don't rely on search snippets.
+3. Write the digest: for each topic, up to three items, each with a one-sentence summary, why it matters to us, and the link.
+4. End with "Worth a closer look": the single most important item, and why.
+5. Answer with the digest alone, nothing before or after it: it's sent as it is.`,
+        },
+        startMessage: 'Write this week\'s research digest.',
+        newAgent: {
+            name: 'weekly-research-digest',
+            systemPrompt: `You follow news for our team and write research digests.
+
+Topics to follow (edit this list):
+- [Your industry or market]
+- [Competitors, by name]
+- [Technologies or regulations you care about]
+
+Rules:
+- Only include things published in the period you're asked about, and give each item's date.
+- Prefer original sources over aggregators. Never invent a link.
+- If a topic had no real news, say so in one line.`,
+        },
+        notes: ['Edit "Topics to follow" at the top of its instructions (Overview tab)'],
+    }),
+];
+export function workflowExample(id) {
+    return WORKFLOW_EXAMPLES.find((e) => e.id === id);
+}

package/dist/core/system-agents/workflow-planner.d.ts

@@ -2,7 +2,7 @@ import type { ToolSchema } from '#core/agent-config.js';
 import type { WorkflowParameter } from '#core/workflows.js';
 import type { TriggerSender } from '#core/workflow-triggers.js';
 import type { ModelCall } from '#core/run-agent.js';
-import type { StarterTemplate, TemplateApp } from './templates.js';
+import type { StarterTemplate, TemplateApp, TemplateSkill } from './templates.js';
 export type Decision = 'allow' | 'ask' | 'deny';
 export interface WorkflowStep {
     title: string;
@@ -110,6 +110,14 @@ export interface WorkflowPlan {
     /** Connected apps it adds to the agent, with just the tools its steps
      * use (filled in on Create, from mcpServers). */
     apps?: TemplateApp[];
+    /** Skills it adds besides its own, such as a policy the person fills
+     * in (the examples, core/system-agents/workflow-examples.ts). One the
+     * agent already has is kept as it is. */
+    skills?: TemplateSkill[];
+    /** Non-secret settings it fills in; one the agent already has is kept. */
+    env?: Record<string, string>;
+    /** Setup steps for its checklist, in plain words. */
+    notes?: string[];
 }
 export interface PlannedWebhook {
     /** Whose events: the sender whose signature it checks. "custom" is the
@@ -151,7 +159,7 @@ export interface WorkflowPlannerTools {
     /** A server's tools, when it can be listed without a key (or with one already set). */
     mcpServerTools?(id: string): Promise<unknown>;
 }
-export declare const WORKFLOW_PLANNER_PROMPT = "You turn a workflow a person describes into a plan for a LoopEngine agent.\n\nLoopEngine agents call tools. Tools come from abilities (installable packages: public ones on npm, or the workspace's own private ones) or are built in. Each tool has a permission: allow (runs on its own), ask (waits for a person to approve, edit or deny it) or deny. When nobody is in Chat, questions and approvals go to the agent's messaging app (Slack, Telegram, Lark or email) and the run waits, for days if needed, then carries on.\n\nHow to plan:\n1. Look before you plan: list_agents (what exists, and what each agent's tools and rules are), list_workspace_abilities, search_public_abilities for each kind of step, ability_details for any ability you might use (its exact tool names and the settings it needs), and list_connections.\n2. Split the workflow into steps, in order. For each step:\n   - something to fetch or do: kind \"tool\", with the exact tool name and where it comes from. Pick the source in this order:\n     a. A tool the target agent already has (from list_agents): use it, nothing to install.\n     b. An ability: a workspace ability (list_workspace_abilities) or a public one (search_public_abilities, e.g. \"firecrawl\" or \"web search\" for searching and reading the web). Set \"ability\" to its install spec (the npm name, or a workspace ability's spec) and use the exact tool name from ability_details.\n     c. Only when no ability can do it, and search_mcp_servers is available: an app's MCP server. Search for the app (e.g. \"linear\", \"stripe\"), pick the app's own server (official), else a saved or verified one, then call mcp_server_tools. Set \"mcp\" to the server's id, and \"tool\" to its exact tool name when mcp_server_tools lists them (leave \"tool\" empty when it needs a key first, and say in \"detail\" what the step does). It's set up as a private ability when the workflow is created, which picks its tools and their permissions, so add no rules for MCP tools.\n   - the person chooses or answers (\"ask me which\", \"let me pick\"): kind \"ask\", tool \"system_ask_user\" (built in, no ability). Say what options are offered. It reaches them through the agent's messaging app by itself, so don't add a separate step to post to Slack or another chat first, and don't install a chat ability just to ask.\n   - the person reviews or approves before something happens (\"let me review it\", \"before it's sent\"): kind \"approval\", on the tool that does that thing; its rule becomes \"ask\".\n   - the agent's own work (writing, summarising, choosing): kind \"other\".\n   - nothing found can do it: set \"missing\" to what's needed, and add it to gaps.\n3. Rules: every tool the workflow uses gets one. Reading and searching: allow. Anything a person should see first (sending, publishing, paying, creating something others see): ask. Never set deny unless asked.\n4. Skill: the steps in order, as numbered instructions the agent follows, naming the tools and saying exactly when to stop and ask. Write it so the agent keeps going after each answer or decision.\n5. Trigger: how a run starts. startMessage is what the agent receives when it starts.\n   - schedule: a time or interval (\"every Monday at 9\" is every \"7d\", at \"09:00\", weekday 1).\n   - webhook: when something happens in another service that can call a URL (\"when a Stripe dispute comes in\", \"when a GitHub issue is opened\", \"when a Shopify order is paid\", \"when our app sends a new signup\"). Fill in \"webhook\" (below). Prefer it over polling on a schedule whenever the service sends webhooks.\n   - on_request: started by a person, from Chat, a message, the Run button or an app's API call.\n   A workflow that runs on a schedule and on an event as well: trigger schedule, and fill in \"webhook\" too.\n   webhook: sender (\"stripe\", \"github\", \"shopify\", \"standard\" for Standard Webhooks senders such as Clerk, Resend or Svix, else \"custom\" for the person's own app or any other service); a short name (\"Stripe: new disputes\"); setup: one sentence on what to pick in the sender's webhook settings; filter: which events start a run; mapping: each parameter from a dot path in the payload. What senders send:\n   - Stripe: one endpoint can get many event types, so filter path \"type\", values the event names (charge.dispute.created, checkout.session.completed, invoice.payment_failed, customer.subscription.deleted). The object is at data.object: data.object.id, data.object.customer, data.object.amount, data.object.charge.\n   - GitHub: the event type is chosen in GitHub's settings (Issues, Pull requests, Pushes), so say it in setup; filter path \"action\", values such as opened, closed, created. Fields: issue.number, issue.title, pull_request.number, repository.full_name, sender.login.\n   - Shopify: one webhook per topic (orders/paid, orders/create, customers/create), chosen in Shopify, so say it in setup and use no filter. The body is the object itself: id, name (the order number, like #1001), email, total_price, financial_status.\n   - standard: filter path \"type\" (user.created, email.bounced); fields under data (data.id, data.email_addresses).\n   - custom: whatever the person's app sends; say in setup what to post (JSON with these fields) and use the paths you described. Set \"header\" when the person names the signature header.\n   Every required parameter should come from the payload through mapping; parameters are the only way event details reach the run.\n6. Notify (scheduled and webhook workflows): whether each run's result is sent to the person through the agent's messaging app. true when the result is for them and no step already delivers it (\"tell me\", \"send me\", \"let me know\", a summary or findings that no step posts or emails). false when a step already sends it (posting to a channel, emailing a report): it would arrive twice. false when the work itself is the outcome (answering emails, filing tasks), where a message every run is noise; questions and approvals reach them either way. Say why in one short sentence.\n7. Parameters: if the job is about something that changes from run to run (an order, a ticket, an alert, a customer, a date range), declare it as a parameter: a short snake_case name, a one-line description, and required when a run makes no sense without it. Write $name wherever its value goes, in startMessage and in the skill (\"Check the refund request for order $order_number.\"). Apps and people fill them in when they start a run. A scheduled job that finds its own work (\"check the inbox every 10 minutes\", \"last week's sales\") needs none. Don't make fixed settings, such as the repository or the channel, parameters: write them into the skill.\n8. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and a system prompt saying who it is and what it's for. Give the reason either way.\n9. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings). Not for MCP servers: their keys are asked for on the plan.\n\nThen call save_plan once, with the whole plan. Don't ask the person questions: if something is unclear, plan the most reasonable version and note the assumption in gaps.";
+export declare const WORKFLOW_PLANNER_PROMPT = "You turn a workflow a person describes into a plan for a LoopEngine agent.\n\nLoopEngine agents call tools. Tools come from abilities (installable packages: public ones on npm, or the workspace's own private ones) or are built in. Each tool has a permission: allow (runs on its own), ask (waits for a person to approve, edit or deny it) or deny. When nobody is in Chat, questions and approvals go to the agent's messaging app (Slack, Telegram, Lark or email) and the run waits, for days if needed, then carries on.\n\nHow to plan:\n1. Look before you plan: list_agents (what exists, and what each agent's tools and rules are), list_workspace_abilities, search_public_abilities for each kind of step, ability_details for any ability you might use (its exact tool names and the settings it needs), and list_connections.\n2. Split the workflow into steps, in order. For each step:\n   - something to fetch or do: kind \"tool\", with the exact tool name and where it comes from. Pick the source in this order:\n     a. A tool the target agent already has (from list_agents): use it, nothing to install.\n     b. An ability: a workspace ability (list_workspace_abilities) or a public one (search_public_abilities, e.g. \"firecrawl\" or \"web search\" for searching and reading the web). Set \"ability\" to its install spec (the npm name, or a workspace ability's spec) and use the exact tool name from ability_details.\n     c. Only when no ability can do it, and search_mcp_servers is available: an app's MCP server. Search for the app (e.g. \"linear\", \"stripe\"), pick the app's own server (official), else a saved or verified one, then call mcp_server_tools. Set \"mcp\" to the server's id, and \"tool\" to its exact tool name when mcp_server_tools lists them (leave \"tool\" empty when it needs a key first, and say in \"detail\" what the step does). It's set up as a private ability when the workflow is created, which picks its tools and their permissions, so add no rules for MCP tools.\n   - the person chooses or answers (\"ask me which\", \"let me pick\"): kind \"ask\", tool \"system_ask_user\" (built in, no ability). Say what options are offered. It reaches them through the agent's messaging app by itself, so don't add a separate step to post to Slack or another chat first, and don't install a chat ability just to ask.\n   - the person reviews or approves before something happens (\"let me review it\", \"before it's sent\"): kind \"approval\", on the tool that does that thing; its rule becomes \"ask\".\n   - the agent's own work (writing, summarising, choosing): kind \"other\".\n   - nothing found can do it: set \"missing\" to what's needed, and add it to gaps.\n3. Rules: every tool the workflow uses gets one. Reading and searching: allow. Anything a person should see first (sending, publishing, paying, creating something others see): ask. Never set deny unless asked.\n4. Skill: the steps in order, as numbered instructions the agent follows, naming the tools and saying exactly when to stop and ask. Write it so the agent keeps going after each answer or decision.\n5. Trigger: how a run starts. startMessage is what the agent receives when it starts.\n   - schedule: a time or interval (\"every Monday at 9\" is every \"7d\", at \"09:00\", weekday 1).\n   - webhook: when something happens in another service that can call a URL (\"when a Stripe dispute comes in\", \"when a GitHub issue is opened\", \"when a Shopify order is paid\", \"when our app sends a new signup\"). Fill in \"webhook\" (below). Prefer it over polling on a schedule whenever the service sends webhooks.\n   - on_request: started by a person, from Chat, a message, the Run button or an app's API call.\n   A workflow that runs on a schedule and on an event as well: trigger schedule, and fill in \"webhook\" too.\n   webhook: sender (\"stripe\", \"github\", \"shopify\", \"standard\" for Standard Webhooks senders such as Clerk, Resend or Svix, else \"custom\" for the person's own app or any other service); a short name (\"Stripe: new disputes\"); setup: one sentence on what to pick in the sender's webhook settings; filter: which events start a run; mapping: each parameter from a dot path in the payload. What senders send:\n   - Stripe: one endpoint can get many event types, so filter path \"type\", values the event names (charge.dispute.created, checkout.session.completed, invoice.payment_failed, customer.subscription.deleted). The object is at data.object: data.object.id, data.object.customer, data.object.amount, data.object.charge.\n   - GitHub: the event type is chosen in GitHub's settings (Issues, Pull requests, Pushes), so say it in setup; filter path \"action\", values such as opened, closed, created. Fields: issue.number, issue.title, pull_request.number, repository.full_name, sender.login.\n   - Shopify: one webhook per topic (orders/paid, orders/create, customers/create), chosen in Shopify, so say it in setup and use no filter. The body is the object itself: id, name (the order number, like #1001), email, total_price, financial_status.\n   - standard: filter path \"type\" (user.created, email.bounced); fields under data (data.id, data.email_addresses).\n   - custom: whatever the person's app sends; say in setup what to post (JSON with these fields) and use the paths you described. Set \"header\" when the person names the signature header.\n   Every required parameter should come from the payload through mapping; parameters are the only way event details reach the run.\n6. Notify (scheduled and webhook workflows): whether each run's result is sent to the person through the agent's messaging app. true when the result is for them and no step already delivers it (\"tell me\", \"send me\", \"let me know\", a summary or findings that no step posts or emails). false when a step already sends it (posting to a channel, emailing a report): it would arrive twice. false when the work itself is the outcome (answering emails, filing tasks), where a message every run is noise; questions and approvals reach them either way. Say why in one short sentence.\n7. Parameters: if the job is about something that changes from run to run (an order, a ticket, an alert, a customer, a date range), declare it as a parameter: a short snake_case name, a one-line description, and required when a run makes no sense without it. Write $name wherever its value goes, in startMessage and in the skill (\"Check the refund request for order $order_number.\"). Apps and people fill them in when they start a run. A scheduled job that finds its own work (\"check the inbox every 10 minutes\", \"last week's sales\") needs none. Don't make fixed settings, such as the repository or the channel, parameters: write them into the skill.\n8. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and its system prompt (rule 9). Give the reason either way.\n9. newAgent.systemPrompt: the new agent's standing instructions, read on every run of every workflow it will ever have, so write what's true whatever it's doing: who it works for and its role, in one or two sentences (\"You help the on-call engineer triage incidents.\"); facts every job needs that the person must fill in, as \"[...] (edit this)\" (\"Our repository on GitHub: [owner/name] (edit this).\"); and rules that always hold (\"Never roll anything back yourself.\"). Don't repeat the steps, the tools or the schedule: they're the skill's. Under 15 lines.\n10. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings). Not for MCP servers: their keys are asked for on the plan.\n\nThen call save_plan once, with the whole plan. Don't ask the person questions: if something is unclear, plan the most reasonable version and note the assumption in gaps.";
 export declare function workflowPlannerTools(withMcp?: boolean): ToolSchema[];
 /** lowercase-hyphenated, 2–40 characters. */
 export declare function slugify(value: string, fallback?: string): string;

package/dist/core/system-agents/workflow-planner.js

@@ -30,8 +30,9 @@ How to plan:
    Every required parameter should come from the payload through mapping; parameters are the only way event details reach the run.
 6. Notify (scheduled and webhook workflows): whether each run's result is sent to the person through the agent's messaging app. true when the result is for them and no step already delivers it ("tell me", "send me", "let me know", a summary or findings that no step posts or emails). false when a step already sends it (posting to a channel, emailing a report): it would arrive twice. false when the work itself is the outcome (answering emails, filing tasks), where a message every run is noise; questions and approvals reach them either way. Say why in one short sentence.
 7. Parameters: if the job is about something that changes from run to run (an order, a ticket, an alert, a customer, a date range), declare it as a parameter: a short snake_case name, a one-line description, and required when a run makes no sense without it. Write $name wherever its value goes, in startMessage and in the skill ("Check the refund request for order $order_number."). Apps and people fill them in when they start a run. A scheduled job that finds its own work ("check the inbox every 10 minutes", "last week's sales") needs none. Don't make fixed settings, such as the repository or the channel, parameters: write them into the skill.
-8. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and a system prompt saying who it is and what it's for. Give the reason either way.
-9. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings). Not for MCP servers: their keys are asked for on the plan.
+8. Target: an existing agent only when it already has (or can install) the tools, none of the workflow's rules would change a decision it already has, and the same people would approve. Otherwise a new agent, with a short lowercase-hyphenated name and its system prompt (rule 9). Give the reason either way.
+9. newAgent.systemPrompt: the new agent's standing instructions, read on every run of every workflow it will ever have, so write what's true whatever it's doing: who it works for and its role, in one or two sentences ("You help the on-call engineer triage incidents."); facts every job needs that the person must fill in, as "[...] (edit this)" ("Our repository on GitHub: [owner/name] (edit this)."); and rules that always hold ("Never roll anything back yourself."). Don't repeat the steps, the tools or the schedule: they're the skill's. Under 15 lines.
+10. keys: the setting names its abilities need that list_connections or the agents don't show as set (from ability_details settings). Not for MCP servers: their keys are asked for on the plan.
 
 Then call save_plan once, with the whole plan. Don't ask the person questions: if something is unclear, plan the most reasonable version and note the assumption in gaps.`;
 export function workflowPlannerTools(withMcp = false) {
@@ -410,7 +411,9 @@ export function workflowTemplate(plan) {
             abilities: plan.abilities,
             ...(plan.apps?.length ? { apps: plan.apps } : {}),
             keys: plan.keys,
-            skills: [{ id: plan.id, description: plan.skill.description, body: plan.skill.body }],
+            skills: [{ id: plan.id, description: plan.skill.description, body: plan.skill.body }, ...(plan.skills ?? []).filter((s) => s.id !== plan.id)],
+            ...(plan.env && Object.keys(plan.env).length ? { env: plan.env } : {}),
+            ...(plan.notes?.length ? { notes: plan.notes } : {}),
             // Named after the tool: readable, and made unique if taken.
             rules: plan.rules.map((r) => ({ name: r.tool, tool: r.tool, decision: r.decision })),
             ...(plan.trigger.kind === 'schedule' && plan.trigger.every

package/dist/index.d.ts

@@ -87,6 +87,7 @@ export { STARTER_TEMPLATES, starterTemplate, templateScheduleStart, type Starter
 export { workflowPageHtml } from './web/workflow-page.js';
 export { WorkflowError, checkWorkflowForAgent, createWorkflow, forgetWorkflow, migrateAgentWorkflows, getPlanJob, listAgentWorkflows, planWorkflow, resolveConnections, prepareWorkflowRun, updateWorkflow, startPlanJob, type AgentWorkflowView, type CreatedWorkflow, type PlanJob, type PlannedWorkflow, type WorkflowAgentInfo, type WorkflowCheck, type WorkflowConflict, type WorkflowCreateDeps, type WorkflowMcpDeps, type WorkflowMcpCreateDeps, resolveMcpServers, prepareMcpAbilities, } from './web/workflow-admin.js';
 export { WORKFLOW_PLANNER_PROMPT, planParameters, planWorkflowWithModel, validateWorkflowPlan, workflowTemplate, type WorkflowPlan, type WorkflowPlannerTools, type WorkflowStep } from './core/system-agents/workflow-planner.js';
+export { WORKFLOW_EXAMPLES, workflowExample, type WorkflowExample } from './core/system-agents/workflow-examples.js';
 export { createTrigger, updateTrigger, rotateTrigger, listTriggers, findTriggerByToken, publicTrigger, checkTriggerSettings, verifySenderSignature, parsePayload, valueAt, deliveryId, passesFilter, paramsFromPayload, recordDelivery as recordTriggerDelivery, FileTriggerStore, getTriggerStore, setTriggerStore, TriggerError, type WorkflowTrigger, type PublicTrigger, type TriggerSettings, type TriggerVerify, type TriggerFilter, type TriggerSender, type SignatureAlgorithm, type TriggerDelivery, type TriggerOutcome, type TriggerStore } from './core/workflow-triggers.js';
 export { checkCallbackUrl, callbackSecret, signCallback, deliverCallback, runCallbackPayload, isPrivateAddress, CallbackUrlError, type CallbackDelivery, type RunCallbackEvent } from './core/run-callbacks.js';
 export { WorkflowRunner, FileRunStore, getRunStore, setRunStore, listRuns, getRun, isUnderWay, RunError, type WorkflowRun, type WorkflowRunStatus, type RunStore, type ExecuteRun, type RunOutcome, type StartRunInput } from './core/workflow-runs.js';

package/dist/index.js

@@ -80,6 +80,7 @@ export { STARTER_TEMPLATES, starterTemplate, templateScheduleStart, } from './co
 export { workflowPageHtml } from './web/workflow-page.js';
 export { WorkflowError, checkWorkflowForAgent, createWorkflow, forgetWorkflow, migrateAgentWorkflows, getPlanJob, listAgentWorkflows, planWorkflow, resolveConnections, prepareWorkflowRun, updateWorkflow, startPlanJob, resolveMcpServers, prepareMcpAbilities, } from './web/workflow-admin.js';
 export { WORKFLOW_PLANNER_PROMPT, planParameters, planWorkflowWithModel, validateWorkflowPlan, workflowTemplate } from './core/system-agents/workflow-planner.js';
+export { WORKFLOW_EXAMPLES, workflowExample } from './core/system-agents/workflow-examples.js';
 export { createTrigger, updateTrigger, rotateTrigger, listTriggers, findTriggerByToken, publicTrigger, checkTriggerSettings, verifySenderSignature, parsePayload, valueAt, deliveryId, passesFilter, paramsFromPayload, recordDelivery as recordTriggerDelivery, FileTriggerStore, getTriggerStore, setTriggerStore, TriggerError } from './core/workflow-triggers.js';
 export { checkCallbackUrl, callbackSecret, signCallback, deliverCallback, runCallbackPayload, isPrivateAddress, CallbackUrlError } from './core/run-callbacks.js';
 export { WorkflowRunner, FileRunStore, getRunStore, setRunStore, listRuns, getRun, isUnderWay, RunError } from './core/workflow-runs.js';

package/dist/web/agents-list-page.js

@@ -50,13 +50,13 @@ ${consoleSidebarHtml}
       <div class="le-title"><button type="button" class="le-menu-btn" data-le-menu aria-label="Open navigation">&#9776;</button>
         <div><h1>Agents</h1><p>Every agent under agents/ in this project. Open one to chat with it or change its tools, permissions and settings.</p></div>
       </div>
-      <div style="display:flex;gap:8px;flex-wrap:wrap"><a href="/templates" style="padding:6px 12px;border:1px solid var(--line);border-radius:6px;text-decoration:none;color:var(--ink);font-size:13px">Templates</a><a href="/interview" style="padding:6px 12px;border:1px solid var(--line);border-radius:6px;text-decoration:none;color:var(--ink);font-size:13px">Find your first agent</a>
+      <div style="display:flex;gap:8px;flex-wrap:wrap"><a href="/workflows/new#examples" style="padding:6px 12px;border:1px solid var(--line);border-radius:6px;text-decoration:none;color:var(--ink);font-size:13px">Workflow examples</a><a href="/interview" style="padding:6px 12px;border:1px solid var(--line);border-radius:6px;text-decoration:none;color:var(--ink);font-size:13px">Find your first agent</a>
       <button type="button" id="newAgentBtn" class="primary">New agent</button></div>
     </div>
   </div>
   <div class="le-scroll"><div class="le-page">
     <form id="newAgentForm" style="display:none">
-      <p class="hint" style="margin:0">Not sure what to build? <a href="/templates">Start from a template</a>, or <a href="/interview">find your first agent</a>: a short interview that suggests one and creates it.</p>
+      <p class="hint" style="margin:0">Not sure what to build? <a href="/workflows/new#examples">Start from a workflow example</a>, or <a href="/interview">find your first agent</a>: a short interview that suggests one and creates it.</p>
       <h2>New agent</h2>
       <label>Name <span class="hint">(lowercase, hyphens allowed: becomes agents/&lt;name&gt;/)</span>
         <input type="text" name="name" placeholder="weather-agent" pattern="[a-z0-9]+(-[a-z0-9]+)*" required>

package/dist/web/console-shell.js

@@ -28,8 +28,7 @@ export const consoleSidebarHtml = `<aside class="le-sidebar" aria-label="Console
   <div class="le-nav-label"><span>Agents</span><a href="/agents?new=1">+ New</a></div>
   <ul class="le-agent-list" id="leAgentList"></ul>
   <a class="le-find" href="/interview" data-le-nav="interview">Find your first agent</a>
-  <a class="le-find" href="/templates" data-le-nav="templates">Start from a template</a>
-  <a class="le-find" href="/workflows/new" data-le-nav="workflows">Describe a workflow</a>
+  <a class="le-find" href="/workflows/new" data-le-nav="workflows">New workflow</a>
   <nav class="le-foot" aria-label="Settings">
     <a href="/config?section=models" data-le-nav="models">Models</a>
     <a href="/config?section=apps" data-le-nav="apps">Apps</a>
@@ -174,7 +173,7 @@ export const consoleShellScript = `<script>
   }
 
   var section = params.get('section');
-  var foot = page === 'config' ? (section === 'abilities' || section === 'gateways' ? 'abilities' : section === 'apps' ? 'apps' : section === 'settings' ? 'settings' : 'models') : page === 'interview' || page === 'templates' ? page : '';
+  var foot = page === 'config' ? (section === 'abilities' || section === 'gateways' ? 'abilities' : section === 'apps' ? 'apps' : section === 'settings' ? 'settings' : 'models') : page === 'interview' || page === 'workflows' ? page : '';
   var footLinks = document.querySelectorAll('[data-le-nav]');
   for (var i = 0; i < footLinks.length; i++) {
     if (footLinks[i].getAttribute('data-le-nav') === foot) footLinks[i].setAttribute('aria-current', 'page');

package/dist/web/templates-page.d.ts

@@ -1 +1,2 @@
+/** @deprecated The console redirects /templates to the workflow examples. */
 export declare const templatesPageHtml: string;