---
description: Fetch a Co-op Cloud recipe and check for available upgrades
argument-hint: <recipe-name>
allowed-tools: [Bash, Read, Write, Glob, Grep, WebFetch, WebSearch]
---

# Recipe Check

Fetch the latest version of a Co-op Cloud recipe and check for available upgrades.

The recipe name is: $ARGUMENTS

Read and follow the instructions in `.claude/commands/includes/logging.md`.
Read and follow the instructions in `.claude/commands/includes/guidelines.md`.

## Steps

1. **Fetch the recipe** — check for uncommitted local changes first (see guidelines). If clean, run `abra recipe fetch $ARGUMENTS --force`. If there are local changes, skip the fetch and note that you're using the local checkout.

2. **Show current released versions**:
   ```
   abra recipe versions $ARGUMENTS -m
   ```

3. **Check for available upgrades** (machine-readable, non-interactive):
   ```
   abra recipe upgrade $ARGUMENTS -m -n
   ```

4. **Lint the recipe** to surface any config issues:
   ```
   abra recipe lint $ARGUMENTS -C
   ```

5. **Look up upstream release notes**:
   - Check if `recipe-info/$ARGUMENTS/upstream.md` exists in the workspace.
   - If it exists, read it to get the release notes URLs for each image/service.
   - If it does NOT exist, try to discover the upstream project and release notes URLs:
     - Read the recipe's `compose.yml` to identify all images.
     - For each image, search for its GitHub repository and releases page.
     - Create `recipe-info/$ARGUMENTS/upstream.md` with the discovered URLs (follow the format of existing upstream.md files in sibling recipe directories).
     - Also create the `recipe-info/$ARGUMENTS/tests/` directory if it doesn't exist.
   - For any services that have available upgrades, fetch the release notes page and summarise what changed between the current version and the upgrade version(s).
   - Pay special attention to and explicitly call out:
     - **Breaking changes** — API removals, renamed/removed config options, changed defaults, dropped support for older runtimes/dependencies
     - **Required migration steps** — database migrations, data format changes, manual upgrade procedures
     - **Config changes needed by the operator** — new required environment variables, changed variable names/formats, new secrets, changed ports or volume paths, deprecated settings that will stop working
     - **Dependency version requirements** — e.g. "now requires PostgreSQL 15+", "minimum Redis 6.2"
   - If any of the above are found, present them in a clearly marked "**Operator Action Required**" section per service, separate from the general changelog summary. Use warnings/bold to make these impossible to miss.

6. **Summarise the results** for the user:
   - Current version(s) of the recipe
   - Any available image tag upgrades
   - **Operator Action Required** items first (breaking changes, config changes, migrations) — prominently highlighted
   - For each upgrade: a summary of what changed (from release notes), with a link to the full release notes
   - Any lint warnings or errors

7. **Suggest next steps** — if upgrades are available, suggest the user run `/recipe-upgrade-plan $ARGUMENTS` to create a detailed upgrade plan.