# Guidellm Weekly Summary

> Summarize GuideLLM team activity from GitHub PRs and issues over the past week into a concise, externally shareable nested-list update. Use when the user asks for a weekly summary, team activity update, status digest, or changelog-style overview of vllm-project/guidellm.

- Skill: `vllm-project/guidellm-weekly-summary` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add vllm-project/guidellm-weekly-summary`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vllm-project/guidellm-weekly-summary/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: vllm-project (https://skillmd.com/u/vllm-project)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/vllm-project/guidellm-weekly-summary

---


# GuideLLM Weekly Activity Summary

Generate a concise, externally shareable summary of GuideLLM work from the past week using GitHub data for `vllm-project/guidellm` only.

## When to use

Apply when the user asks for a weekly summary, team activity update, status digest, or similar overview of GuideLLM progress.

## Data collection

**Do not invent ad-hoc `gh` queries.** Run the bundled fetch script, then write from its JSON.

1. Determine the current date/time with `date` (do not guess).

2. Use a rolling **past 7 days** window ending today unless the user specifies another range.

3. From this skill directory, fetch activity (stdout = JSON, stderr = progress):

   ```bash
   bash scripts/fetch_activity.sh
   ```

   Custom window examples:

   ```bash
   bash scripts/fetch_activity.sh --days 14
   bash scripts/fetch_activity.sh --since 2026-07-16 --until 2026-07-23
   ```

   If the working directory is the repository root instead of the skill root:

   ```bash
   bash .agents/skills/guidellm-weekly-summary/scripts/fetch_activity.sh
   ```

4. Parse the JSON: `window`, `releases`, `pull_requests`, and `issues`. Prefer release `overview`/`body`, and PR/issue `body`, `labels`, and `state` over titles alone when inferring what shipped or changed.

5. Skip noise (trivial dependency bumps, pure formatting, bot-only churn — see `author_is_bot`) unless it is the main story.

6. Run `bash scripts/fetch_activity.sh --help` only if you need flags beyond the examples above.

### Script notes

- **`scripts/fetch_activity.sh`** — Fetches PRs and issues updated in the window, plus GitHub releases published in the window; normalizes fields; truncates bodies; emits one JSON document on stdout.
- Each release includes `name`, `tag`, `url`, `published_at`, `overview` (first Overview paragraph when present), and a truncated `body`.
- Draft releases are omitted; prereleases are omitted unless `--include-prereleases` is passed.
- Bodies are truncated (default 800 chars) and scrubbed to save tokens. Raise `--body-max` only when a specific item needs more detail.

## Writing rules

- Write for an **external** audience: clear, professional, no internal jargon or private details.
- Lead with **what changed and why it matters**, not with PR numbers or titles.
- Treat GitHub links, PR/issue numbers, and titles as **secondary references** for readers who want more detail—not as the primary narrative.
- Group by theme (features, fixes, docs, infra) over chronological dumps.
- Keep it concise: a few nested bullets per theme, not a full changelog.

## Output format (required)

- The summary content itself uses **nested markdown lists only** — **no headers** (`#`, `##`, etc.) inside the report.
- Use markdown that pastes cleanly into docs: `**bold**`, `[text](url)` links, `` `inline code` ``, and `-` nested lists.
- **CRITICAL — show raw markdown, not rendered text:** Wrap the entire summary in a single fenced code block tagged `markdown` so the user sees and can copy the literal characters (`**`, `-`, `[]()`, backticks) instead of formatted rich text. Do not also emit a rendered version outside the fence.
- **Releases first:** If `releases` is non-empty, open the list with one top-level bullet per release **before** the categorized activity bullets. Use the release `name` (e.g. GuideLLM v0.7.3) and 1–2 sentences of highlights drawn primarily from `overview` (and `body` only if needed for a second sentence). Do not dump the full changelog. Link the release as a secondary ref.
- If there were no releases in the window, omit the release bullet and start with thematic activity as usual.
- Response shape:

````
```markdown
- **Release: GuideLLM vX.Y.Z** — One or two sentences of release highlights in plain language
  - More detail: [GuideLLM vX.Y.Z](https://github.com/vllm-project/guidellm/releases/tag/…)
- **Theme or area** — one-line outcome in plain language
  - Supporting detail on what landed or progressed
  - Optional secondary refs: [PR title](url), [#123](url)
- **Another theme** — one-line outcome
  - Supporting detail
  - Secondary refs as needed
```
````

- Top-level bullets = release callouts (when present), then themes/outcomes.
- Nested bullets = brief supporting detail and secondary GitHub refs.
- Do not open with a title/header line; start the fenced block directly with the list.
- If the week was quiet, say so in one top-level bullet and list only notable items.
- Optional one-line preface outside the fence is fine (e.g. date range from `window.since` → `window.until`); the copy-paste body must be only inside the fence.

## Example response

Preface (optional): `GuideLLM activity, 2026-07-27 → 2026-08-03:`

Then the fenced block containing:

```
- **Release: GuideLLM v0.7.3** — Patch release that clears a transitive dependency CVE path and includes small reliability and docs polish around plot output and backend error handling
  - More detail: [GuideLLM v0.7.3](https://github.com/vllm-project/guidellm/releases/tag/v0.7.3)
- **Benchmarking UX** — Sweep runs can now target clearer stop conditions, making short validation jobs easier to reason about
  - Refined how duration and request caps interact in the CLI
  - More detail: [Clarify constraint handling for sweep profiles](https://github.com/vllm-project/guidellm/pull/…)
- **Reliability** — Fixed a failure mode that dropped partial results when a backend timed out mid-run
  - Users keep completed request metrics instead of an empty report
  - Tracking: [#…](https://github.com/vllm-project/guidellm/issues/…)
```

## Checklist before responding

- [ ] Used `scripts/fetch_activity.sh` (not hand-written `gh` searches)
- [ ] Window is past 7 days (or user-specified) and based on script/`date` output
- [ ] Scope is `vllm-project/guidellm` only
- [ ] If `releases` is non-empty, release name + 1–2 highlight sentences appear first
- [ ] Narrative leads; links/titles are secondary
- [ ] Nested lists only; no headers inside the report
- [ ] Entire summary is inside a ```` ```markdown ```` fence so raw markdown is visible for copy-paste
- [ ] Tone is externally shareable