autonomic-botandClaude Opus 4.8
a6efcec720
render() auto-links whole-word recipe mentions in the editorial lead to git.autonomic.zone/recipe-maintainers/<recipe> (single regex pass, longest-name-first, no href corruption). Skill: lead is ~3 short paragraphs (~150-180 words) incl. an 'anything strange worth looking into' paragraph. example-spec.json lead updated to the concise target. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
68 lines
4.9 KiB
Markdown
68 lines
4.9 KiB
Markdown
---
|
||
name: recipe-report
|
||
description: Generate the weekly public "Recipe Report" after the cc-ci /upgrade-all run. Reviews how the upgrade went and the state of every recipe + open PR, classifies what needs attention vs routine, and publishes a self-contained HTML page to report.ci.commoninternet.net (one page per week + a home index). Read-only — reports, never merges or edits PRs. Runs as its own agent (model configured separately from the upgrader; default opus). Invoke as /recipe-report [YYYY-MM-DD].
|
||
---
|
||
|
||
# recipe-report
|
||
|
||
Produce the weekly **"The Recipe Report"** — a public HTML page reviewing the latest `/upgrade-all` run
|
||
and the live state of every recipe + open PR. Served at **https://report.ci.commoninternet.net** (one
|
||
`week-<date>.html` per run + a home-page index). You are **read-only**: you report, you never merge,
|
||
edit, or comment on PRs. The page is **public + unauthenticated** — include only public-safe data
|
||
(recipe names, version bumps, PR titles/links, CI verdicts, concise error summaries); **never** secrets,
|
||
tokens, internal IPs, or raw logs.
|
||
|
||
Helper: `python3 /srv/cc-ci/cc-ci-plan/recipe-report.py {survey|render|publish}` (see its header).
|
||
|
||
## Procedure
|
||
|
||
1. **Pick the date.** `DATE` = the argument, else today (UTC). The `/upgrade-all` summary for that run is
|
||
`/srv/cc-ci/.cc-ci-logs/upgrades/upgrade-all-<DATE>.md`.
|
||
|
||
2. **Survey.** `python3 /srv/cc-ci/cc-ci-plan/recipe-report.py survey <DATE> > /tmp/survey.json`. This
|
||
gives you: the raw `/upgrade-all` summary; for every recipe mirror its open PRs + the `cc-ci/testme`
|
||
verdict; and each recipe's **per-recipe upgrade notes** (`upgrade_notes_md` — the breaking-change /
|
||
**CVE / security** analysis the upgrade did). Read it all.
|
||
|
||
3. **Review & classify — this is a front page, write it like an editor.**
|
||
- **Security first.** Scan the per-recipe `upgrade_notes_md` + the summary (and use your own knowledge
|
||
of the version bumps) for upgrades that fix **CVEs / security issues**. Anything **critical/high**
|
||
leads the page → the `security` bulletin (recipe · CVE id(s) + severity · what it fixes · PR link).
|
||
This is the most important section; be specific about severity and what's exposed if not merged.
|
||
- **Lead / editorial.** Write the `lead` in opus's voice — useful, concrete, opinionated. **~3 short
|
||
paragraphs, ~150–180 words:**
|
||
1. **Fleet state** in a line or two — how healthy, what moved, any trend.
|
||
2. **What to focus on** — security/critical merges first, then the key failures.
|
||
3. **Anything strange worth looking into** — odd or unexpected failures, parser snags, PR-state
|
||
oddities (e.g. a recipe carrying two open PRs to reconcile), drift from the summary, leftover
|
||
artifacts. This is the "editor's eye" paragraph; flag what a careful maintainer would want to notice.
|
||
Lead with the single most important thing; the rest of the page carries the detail.
|
||
- **Needs attention** — GREEN PRs ready to merge + errors/failures to investigate (RED `!testme`,
|
||
recipe bugs). Short, specific prose + links. Flag cross-cutting issues (e.g. two open PRs to reconcile).
|
||
- **Routine** — minor/clean bumps, stale-test PRs (need operator `--with-tests`), up-to-date / skipped.
|
||
|
||
4. **Write the spec** `/tmp/report-spec.json` (shape in the helper header): `date`, `subtitle`
|
||
("Week of <human date>"), `lead` (the editorial, blank-line-separated paragraphs), `security[]`
|
||
(critical-CVE upgrades — may be empty), `needs_attention[]`, `routine[]`, and a **comprehensive
|
||
`table[]`** with EVERY recipe (`recipe`, `change` "a → b", `status`
|
||
GREEN/STALE/FAILED/SKIPPED/UPTODATE, `ci` as a level/result number+info string e.g. `build 154 ✓`
|
||
or `RED · restore` with `ci_url`, `pr`/`pr_url`, `notes`). **CI = link + number/info only; no images.**
|
||
|
||
**Template — match this.** `.claude/skills/recipe-report/example-spec.json` is the gold-standard
|
||
example (the 2026-06-02 report; the operator approved its style/format). **Match its editorial voice,
|
||
structure, field shapes, and level of specificity** — the only deliberate change is the **shorter
|
||
`lead`** described above. Read it before writing your spec.
|
||
|
||
5. **Render & publish.**
|
||
`python3 .../recipe-report.py render /tmp/report-spec.json /tmp/week-<DATE>.html`
|
||
`python3 .../recipe-report.py publish /tmp/week-<DATE>.html <DATE>`
|
||
(publish copies the page to `cc-ci:/var/lib/cc-ci-reports/` and regenerates the index.)
|
||
|
||
6. **Verify & stop.** `curl -fsS https://report.ci.commoninternet.net/week-<DATE>.html` renders and the
|
||
index lists it. Print the report URL and `RECIPE REPORT COMPLETE`, then go idle (one-shot — do not loop).
|
||
|
||
## Guardrails
|
||
- **Read-only.** Never merge/edit/comment on PRs or touch recipes/tests. You only describe + link.
|
||
- **Public-safe.** No secrets/tokens/internal hostnames/raw logs on the page. Summarize errors.
|
||
- One page per run; always regenerate the index so all weeks are listed (newest first).
|