Recipe Catalog
A recipe is the use-case prompt — the instructions the agent follows. Every recipe is runner-agnostic: it reads its configuration from environment variables and uses generic instructions, so you can run it on any runner.
Four recipes ship today. The full prompts (and fully worked examples) live in task-recipes/prompts/.
Blast Radius
Scores the production blast radius of a pull request (0–100) and posts a ranked report.
What it does. Extracts changed function names from the PR diff, resolves them to Hud function_ids, pulls their production metrics (invocations, latency percentiles, error rates) plus the endpoints they feed, and combines six weighted factors — including an AI assessment of code-change risk — into a single 0–100 score with a Low / Medium / High / Critical risk level. If no Hud-tracked functions are touched, it exits early.
Output. A GitHub-Markdown report: headline score, collapsible affected-endpoints and affected-functions tables (ranked by traffic), a score breakdown, and a machine-readable RESULT_JSON block. Typically posted as a PR comment.
Blast Radius report posted on a PR
Key configuration (defaults shown):
| Setting | Default | Purpose |
|---|---|---|
LOOKBACK_DAYS | 7 | Metrics window |
MAX_FUNCTIONS / MAX_ENDPOINTS | 80 | Row limits to keep queries fast |
MAX_SERVICES | 3 | Cap on services analyzed |
| Scoring weights | sum to 1.0 | Tune the emphasis (traffic, latency, code-change risk, …) |
Best paired with: GitHub Actions or gh-aw, triggered on pull_request. → Worked example · Prompt
Weekly Report
A multi-phase deep-insights report on production health, with optional self-heal.
What it does. Runs six sequential phases: (1) analyze production data for regressions, (2) generate a concrete fix per ongoing issue, (3) attribute contributors via git blame and map them to Slack handles, (4) a quality pass that de-duplicates and enforces gates, (5) optionally apply the best fix as a draft PR, and (6) format and post the report to Slack. Supports weekly (week-over-week) and audit (absolute health check) modes.
Output. A formatted Slack report (Block Kit), plus an optional draft self-heal PR.
Weekly deep-insights report delivered to Slack
Key configuration:
| Variable | Purpose |
|---|---|
INVESTIGATION_MODE | weekly (default) or audit |
HUD_SERVICES | Comma-separated services to scope (empty = all) |
SLACK_BOT_TOKEN / SLACK_CHANNEL | Slack delivery (needs chat:write, users:read.email) |
SELF_HEAL | true (default) / false — whether to open a fix PR |
PROMPT_DIR | Path to the deep-insights/ phase prompt files |
This is a multi-file recipeThe Weekly Report references phase prompt files under
deep-insights/. Your runner must copy those files and setPROMPT_DIRto point at them. See the runner's "multi-file or multi-env prompts" notes in Choosing a Runner.
Best paired with: gh-aw or GitHub Actions on a schedule:. → Worked example · Prompt
Dead-Code Cleanup
Finds functions with zero production invocations and removes them via PR.
What it does. Discovers all local source functions for your services, checks invocations across all services over a lookback window (shared code called elsewhere isn't dead), and computes the zero-invocation set. It then applies safety checks — skipping public API exports, framework hooks/decorators, dynamic references, event handlers, and interface implementations — filters out functions whose files aren't in the checkout, removes what's left, cleans up unused imports, and opens a PR. Optionally files a Jira ticket.
Output. A pull request (labeled HUD) removing the dead functions, with collapsible Removed / Skipped / Methodology sections. Optional Jira ticket.
Dead-code cleanup pull request
Key configuration:
| Variable | Purpose |
|---|---|
SERVICE_NAMES | Services to scan (auto-discovered if unset) |
LOOKBACK_DAYS | Invocation window (default 60) |
MAX_LINES_CHANGED | Cap PR diff size (default 300) |
BASE_BRANCH | PR base (default main) |
JIRA_PROJECT_KEY / JIRA_HOST | Optional Jira integration |
De-duplicationThe recipe skips work if an open PR with the
HUDlabel (or an open Jira ticket) already exists for the repo, so re-running it won't pile up duplicate PRs.
Best paired with: Cursor (with GitHub + Atlassian MCPs) or GitHub Actions. → Worked example · Prompt
Rollback Check
Analyzes a recent deployment for regressions and returns ROLLBACK / INVESTIGATE / WARN / CLEAN.
What it does. Builds a per-version endpoint-ownership map (newest-wins), compares each version's owned endpoints against a historical baseline for error-rate and latency regressions, attributes regressions to recently deployed or newly invoked functions, checks non-owned endpoints for collateral damage, and inspects forensic traces to classify root cause (code vs. outbound vs. environmental). It then applies a decision matrix to reach a verdict.
Output. A structured verdict (the worst across all analyzed versions) — ROLLBACK, INVESTIGATE_OUTBOUND, INVESTIGATE_ENVIRONMENTAL, WARN, or CLEAN — with per-version detail and Hud forensic links.
Rollback Check verdict
Notable: uses the hud MCP tools directly (hud-get-schema, hud-query, hud-get-forensics, hud-get-skill) and can fan out per-service analysis to subagents.
Best paired with: a Claude routine — a skill for on-demand checks during an incident, or a scheduled remote task to gate every deploy. → Worked example · Prompt
Scoping by team
Large monorepos often want one recipe scoped per team rather than one global run. The repo includes cross-cutting team-splitting patterns — driving scope from a config file, GitHub Teams, or package.json ownership — that you can layer onto any recipe.
Building your own
Recipes are just prompts. To build a custom one, start from an existing prompt in task-recipes/prompts/ (or write from scratch), document its env vars at the top, and pair it with a runner. Contribution guidelines are in CONTRIBUTING.md.