autonomic-bot
f283a371bb
Sanitized single-commit public mirror of recipe-maintainer. - Removed test-ssh/.testenv (live creds); added test-ssh/.testenv.example placeholders. - Removed plans/ and planned-updates/ (deployment-planning docs) so no client/ deployment domains appear in the public repo. - All other secret stores were already gitignored. - docs.coopcloud.tech retained as a submodule (public upstream).
52 lines
3.0 KiB
Markdown
52 lines
3.0 KiB
Markdown
---
|
|
description: Check all maintained recipes and recommend what to upgrade
|
|
allowed-tools: [Bash, Read, Write, Glob, Grep, WebFetch, WebSearch]
|
|
---
|
|
|
|
# Recipe Overview
|
|
|
|
Check the status of recipes, initialize any that aren't set up yet, check each one for available upgrades, and recommend which recipe to focus on today.
|
|
|
|
Read and follow the instructions in `.claude/commands/includes/logging.md`.
|
|
Read and follow the instructions in `.claude/commands/includes/guidelines.md`.
|
|
|
|
## Arguments
|
|
|
|
This skill accepts an optional space-separated list of recipe names as `$ARGUMENTS`. If provided, only check those recipes. If no arguments are given, read the full list from `maintained-recipes.md`.
|
|
|
|
## Steps
|
|
|
|
1. **Determine the recipe list**:
|
|
- If `$ARGUMENTS` is non-empty, use those recipe names as the list.
|
|
- Otherwise, read `maintained-recipes.md` from the workspace root and parse out the recipe names (lines starting with `- `).
|
|
|
|
2. **Check initialization status** for each recipe in the list — a recipe is considered initialized if `recipe-info/<recipe>/recipe.toml` exists.
|
|
|
|
3. **For every recipe** (initialized or not), check for available upgrades:
|
|
- Check for local changes first: `git -C ~/.abra/recipes/<recipe> status --short`
|
|
- If clean (or recipe not yet locally cloned), run: `abra recipe fetch <recipe> --force`
|
|
- Get the latest published version: `abra recipe versions <recipe> -m` (first line only)
|
|
- Check for available upgrades: `abra recipe upgrade <recipe> -m -n`
|
|
- If the recipe has uncommitted local changes, note this and skip the fetch/upgrade check for that recipe.
|
|
- For initialized recipes, also read `recipe-info/<recipe>/upstream.md` for release notes URLs and briefly summarise any available upgrade's headline changes.
|
|
- Note any breaking changes or operator action required.
|
|
|
|
4. **Build a summary table** across all recipes:
|
|
|
|
| Recipe | Initialized | Current Version | Upgrades Available | Breaking Changes | Priority |
|
|
|--------|-------------|----------------|-------------------|-----------------|----------|
|
|
|
|
For the Priority column, rank each recipe based on:
|
|
- **High**: security fixes available, or significantly behind upstream (multiple major versions)
|
|
- **Medium**: new features or minor version bumps available
|
|
- **Low**: only patch-level updates, or already up to date
|
|
- **Not initialized**: use this only if the recipe has no published versions at all (i.e. can't even be checked)
|
|
|
|
5. **Recommend which recipe to work on today**:
|
|
- Pick the highest-priority recipe that has upgrades available.
|
|
- Explain why (security fixes, how far behind, breaking changes that will only get harder to handle later, etc.).
|
|
- For initialized recipes with upgrades, suggest running `/recipe-upgrade-plan <recipe>`.
|
|
- For uninitialized recipes with high-priority upgrades pending, suggest running `/recipe-init <recipe>` first.
|
|
- If multiple recipes are high priority, list them in recommended order.
|
|
- If everything is up to date, say so and suggest running `/recipe-review` on a recipe that could use improvement instead.
|