[Docs] Add copyable Roomote Cookbook recipes

.github/ISSUE_TEMPLATE/cookbook-recipe.yml

@@ -0,0 +1,103 @@
+name: Cookbook recipe
+description: Propose a reusable Roomote workflow for the public Cookbook.
+title: "[Cookbook]: "
+labels: ["documentation", "needs-triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use this form to propose a complete, reusable Roomote workflow for the Cookbook.
+        Start with the [contributing recipes guide](https://docs.roomote.dev/cookbook/template),
+        paste the completed recipe below, and keep credentials, customer data, and
+        private operational details out of the example.
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Preflight
+      options:
+        - label: I searched the existing Cookbook and docs for a duplicate or closely related recipe.
+          required: true
+        - label: I removed secrets, tokens, private keys, customer data, and private repository details.
+          required: true
+        - label: I stated provider support, permission boundaries, and other limitations plainly.
+          required: true
+  - type: textarea
+    id: recipe
+    attributes:
+      label: Recipe
+      description: Paste the completed Markdown recipe from the contributing recipes guide.
+      placeholder: |
+        ---
+        title: Outcome-first recipe title
+        description: One sentence explaining the finished system and why it matters.
+        icon: lucide-icon-name
+        contributor: Name or team
+        contributor_url: https://example.com/contributor
+        contributor_company: Company
+        contributor_company_url: https://example.com/company
+        ---
+
+        ## Overview
+
+        Explain the recurring problem and the outcome this recipe creates.
+
+        - **Trigger**: Trigger type
+        - **Setup time**: About N minutes
+        - **Requires**: Product access, integrations, permissions
+        - **Serves**: Teams or roles
+        - **Cooked By**: Name or team from Company
+
+        ## Ingredients
+
+        - Ingredient
+
+        ## Steps
+
+        1. First step.
+
+        ## Paste-ready configuration
+
+        ```text
+        Configuration or prompt
+        ```
+
+        ## Variations
+
+        - Variation
+    validations:
+      required: true
+  - type: textarea
+    id: validation
+    attributes:
+      label: Validation and limitations
+      description: Explain what you tested, which providers or integrations it requires, and any known limitations.
+    validations:
+      required: true
+  - type: input
+    id: contributor
+    attributes:
+      label: Contributor
+      description: Name the person or team contributing this recipe.
+    validations:
+      required: true
+  - type: input
+    id: contributor_url
+    attributes:
+      label: Contributor URL
+      description: Link to the contributor's public profile or website, if available.
+    validations:
+      required: false
+  - type: input
+    id: contributor_company
+    attributes:
+      label: Contributor company
+      description: Name of the contributor's company, if applicable.
+    validations:
+      required: false
+  - type: input
+    id: contributor_company_url
+    attributes:
+      label: Contributor company URL
+      description: Link to the contributor's company website, if available.
+    validations:
+      required: false

.github/workflows/docs.yml

@@ -0,0 +1,44 @@
+name: Docs
+
+on:
+  push:
+    branches: [main, develop]
+    paths:
+      - "apps/docs/**"
+      - "pnpm-lock.yaml"
+      - "pnpm-workspace.yaml"
+      - ".github/actions/setup-environment/**"
+      - ".github/workflows/docs.yml"
+  pull_request:
+    branches: [main, develop]
+    paths:
+      - "apps/docs/**"
+      - "pnpm-lock.yaml"
+      - "pnpm-workspace.yaml"
+      - ".github/actions/setup-environment/**"
+      - ".github/workflows/docs.yml"
+
+permissions:
+  contents: read
+
+env:
+  NODE_VERSION: 24.13.1
+  PNPM_VERSION: 10.29.3
+
+jobs:
+  docs:
+    name: Validate docs
+    runs-on: blacksmith-4vcpu-ubuntu-2404
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
+      - name: Setup environment
+        uses: ./.github/actions/setup-environment
+        with:
+          frozen-lockfile: 'true'
+          node-version: ${{ env.NODE_VERSION }}
+          pnpm-version: ${{ env.PNPM_VERSION }}
+      - name: Check generated Cookbook index
+        run: pnpm --filter @roomote/docs check-cookbook-index
+      - name: Validate docs and links
+        run: pnpm --filter @roomote/docs check

apps/docs/README.md

@@ -20,10 +20,10 @@ and assets all live in this directory and do not depend on `@roomote/web`.
 
 ## Local development
 
-Install the Mintlify CLI (`mint`) globally, then run the dev server:
+The docs scripts download a pinned Mintlify CLI automatically, so no global
+install is required. Run the dev server with:
 
 ```bash
-npm install -g mint
 pnpm --filter @roomote/docs dev
 ```
 

apps/docs/automations.mdx

@@ -12,6 +12,10 @@ or a communications provider when an automation depends on those services.
 Automations are most useful when your team already trusts the normal task
 review flow and wants Roomote to keep an eye on repeated work.
 
+<Tip>
+  Unsure of how Automations can help? Get inspiration from the [Cookbook](/cookbook).
+</Tip>
+
 ## Before you turn them on
 
 Make sure the basics are in place:
@@ -93,6 +97,11 @@ automation to test it immediately.
 
 The deployment cap is 25 custom automations.
 
+See [Schedule maintenance](/cookbook/scheduled-housekeeping)
+for three copyable custom automation prompts, or
+[draft a product-updates newsletter](/cookbook/product-updates-newsletter) with
+a custom MCP server and a natural-language schedule.
+
 The **Scheduling timezone** setting is available on both the Automations and
 Deployment settings pages. It applies to all scheduled automations and to
 natural-language schedule interpretation. Existing deployments continue using
@@ -136,6 +145,10 @@ Start with a low-risk channel first. Auto-response can feel noisy if the
 channel mixes casual discussion with requests that should become Roomote
 tasks.
 
+See how channel instructions and launch criteria work together in the
+[vendor outage triage](/cookbook/vendor-outage-triage) and
+[support channel](/cookbook/support-channel) recipes.
+
 ## Manager automations
 
 The manager section controls the shared Manager Channel plus recurring
@@ -228,6 +241,9 @@ For Gitea, repository webhook resync includes the `workflow_run` event so
 Actions completions reach Roomote; host matching uses the deployment
 `GITEA_BASE_URL`.
 
+Follow the [CI failure auto-fix recipe](/cookbook/ci-failure-auto-fix) for a
+copyable noise-control configuration.
+
 ## Add instructions to reduce noise
 
 Several automations include an **Additional instructions** field. Use it to

apps/docs/cookbook/ci-failure-auto-fix.mdx

@@ -0,0 +1,49 @@
+---
+title: Fix CI failures
+description: Keep the build green by having Roomote verify and fix CI breakages automatically.
+contributor: Matt Rubens
+contributor_url: https://github.com/mrubens
+contributor_company: Roomote
+contributor_company_url: https://roomote.dev
+---
+
+## Overview
+
+When CI fails on your default branch, Roomote reacts immediately. It checks
+that the failure is real, reproduces the failing job inside the repository's
+environment, finds the root cause, opens a PR with the fix, and posts one
+summary to the Manager Channel. The team finds a green PR waiting instead of a
+red branch. This is a built-in automation, so the recipe is one toggle plus
+clear instructions.
+
+- **Trigger**: Webhook
+- **Setup time**: About 10 minutes
+- **Requires**: Admin access, source control, Manager Channel
+- **Serves**: Engineers
+- **Cooked By**: [Matt Rubens](https://github.com/mrubens) from [Roomote](https://roomote.dev)
+
+## Ingredients
+
+- [CI Failure Triage](/automations#manager-automations)
+- A Manager Channel destination configured under **Automation output**
+- An environment for every repository you want triaged. Repositories outside an environment are skipped.
+
+## Steps
+
+1. Set the Manager Channel under **Settings > Automations > Automation output**.
+2. Enable **CI Failure Triage**.
+3. Confirm each repository you care about belongs to a configured environment.
+5. Use **Run now** to test the configuration, or wait for the next default-branch failure.
+
+## Variations
+
+- Keep experimental repositories out of environments to exclude them from triage.
+- Route the summary to a dedicated `#ci-triage` channel instead of the shared Manager Channel.
+
+CI Failure Triage reacts only to failures on the default branch. It supports
+GitHub Actions, GitLab Pipelines, Azure DevOps builds, Bitbucket Pipelines, and
+Gitea Actions. GitLab requires Pipeline Hooks on the webhook, and Bitbucket
+requires the Pipelines OAuth scope.
+
+**Pairs well with:** [scheduled housekeeping](/cookbook/scheduled-housekeeping) ·
+[vendor outage triage](/cookbook/vendor-outage-triage)

apps/docs/cookbook/index.mdx

@@ -0,0 +1,27 @@
+---
+title: Cookbook
+icon: cooking-pot
+description: Copyable recipes for turning Roomote automations, skills, and integrations into standing team systems.
+---
+
+Roomote's abilities go way beyond ad hoc prompt → PR interactions. With integrations and automations, you can put many of your team's workflows on autopilot, from investigation to resolution and beyond.
+
+This cookbook collects proven recipes to help you boost your team's productivity
+and the quality of your output.
+
+{/* cookbook-recipes:start */}
+| Recipe | Use to |
+| --- | --- |
+| [Draft product updates](/cookbook/product-updates-newsletter) | Turn recent product work into a customer-ready draft |
+| [Evaluate outage impact](/cookbook/vendor-outage-triage) | Filter vendor status noise by comparing each incident with your real code, regions, and feature usage. |
+| [Fix CI failures](/cookbook/ci-failure-auto-fix) | Keep the build green by having Roomote verify and fix CI breakages automatically. |
+| [Schedule maintenance](/cookbook/scheduled-housekeeping) | Turn flaky-test scans, feature-flag audits, and dependency reviews into recurring Roomote work. |
+| [Triage customer issues](/cookbook/support-channel) | Give support escalations a repeatable path through production evidence, data, and code. |
+{/* cookbook-recipes:end */}
+
+## Contribute a recipe
+
+Have a Roomote workflow other teams could reuse? Start with
+[contributing recipes](/cookbook/template), fill in every section, and open a
+[Cookbook recipe issue](https://github.com/RooCodeInc/Roomote/issues/new?template=cookbook-recipe.yml)
+on the Roomote repository.

apps/docs/cookbook/product-updates-newsletter.mdx

@@ -0,0 +1,73 @@
+---
+title: Draft product updates
+description: Turn recent product work into a customer-ready draft
+contributor: Bruno Bergher
+contributor_url: https://github.com/brunobergher
+contributor_company: Roomote
+contributor_company_url: https://roomote.dev
+---
+
+## Overview
+
+Product-update emails are chronically late because someone has to remember what
+shipped, translate commit-speak into customer language, and then fight the
+email tool. This automation does all three: every week it reads merged PRs
+across your product repositories, writes the newsletter, and creates a draft in
+Resend through a custom MCP server, ready for review.
+
+It's how we actually generate the ones we send every Friday.
+
+- **Trigger**: Schedule
+- **Setup time**: About 30 minutes
+- **Requires**: Admin access, custom Resend MCP server
+- **Serves**: PMs, Founders, Marketing
+- **Cooked By**: [Bruno Bergher](https://github.com/brunobergher) from [Roomote](https://roomote.dev)
+
+## Ingredients
+
+- A [custom automation](/automations#custom-automations)
+- An environment covering the product repositories
+- The Resend MCP server configured under **Settings > Integrations**, with a Resend API key
+- A report destination such as `#product-updates`, so the draft lands in a replyable thread
+
+## Steps
+
+1. Add the Resend MCP server and confirm its tools are available in the environment.
+2. Create a custom automation named **Product Updates Newsletter**. Choose **Custom schedule**, enter `Mondays at 9am`, and select the environment.
+3. Paste the prompt below.
+4. Set the report destination to `#product-updates`.
+5. Use **Run now** to generate the first draft, then calibrate its tone by replying in the thread.
+
+## Automation prompt
+
+```text
+Write this week's product-updates newsletter.
+
+1. Collect the PRs merged to the default branch in the last 7 days across the
+   product repositories.
+2. Keep only customer-visible changes: features, improvements, and fixes a
+   user would notice. Skip refactors, internal tooling, and dependency bumps.
+3. Write the newsletter:
+   - a one-line subject
+   - a two-sentence introduction
+   - one short section per change: what is new, why it matters, how to try it
+   Use plain language. Do not include ticket numbers or internal codenames.
+4. Using the Resend MCP server, create a DRAFT broadcast with this content for
+   the "Product updates" audience. Do not send it.
+5. Post the draft content and the Resend draft link in this thread for review.
+
+If nothing customer-visible shipped this week, say so in the thread and skip
+the draft. Do not pad the newsletter.
+```
+
+## Variations
+
+- Without Resend, remove step 4 and post ready-to-paste Markdown for any email tool.
+- Run monthly with `first Monday of the month at 9am`.
+- Use separate automations for customer notes and a technical internal changelog.
+
+This recipe showcases custom MCP servers, natural-language scheduling, and
+replyable automation threads. Review the draft before sending it; the automation
+is deliberately instructed to create a draft, not send a broadcast.
+
+**Pairs well with:** [scheduled housekeeping](/cookbook/scheduled-housekeeping)