Skip to content

Prompts for your coding agent

Repodar only watches. When a repository has something to fix, its page has a Prompts section with two prompts you can paste into a coding agent (Claude Code, Cursor, Codex, Copilot) running in a checkout of that repository. Each is plain Markdown, generated from what Repodar already knows.

Repodar sends nothing to any AI. It does not call a model, open pull requests or touch your repository: the prompt is text on the page, and what you do with it is up to you.

The upgrade prompt

Covers every open end-of-life and versions-behind finding for a runtime, a framework or the Docker base image, plus a server that runs a newer runtime than the repository pins. It contains:

  • what Repodar knows: runtimes with the exact version and where each came from, frameworks, package managers and lockfiles, CI workflows, the deploy target and the Docker base image;
  • one numbered item per upgrade: current → target, why (end-of-life date, majors or releases behind, severity), every file Repodar saw that pins or declares the version (.php-version, composer.json require.php, the Dockerfile FROM line, a workflow's setup-php step, .nvmrc, package.json engines…), the official upgrade guide when there is one, and a branch name such as chore/upgrade-laravel-12;
  • where Repodar knows a framework's supported runtimes (Laravel, Symfony, Django, Rails, Spring Boot, Next.js, Nuxt), a compatibility note: the runtime moves only as far as the current framework supports ("Laravel 10 supports PHP 8.1–8.3; go to PHP 8.3 now, 8.5 after Laravel 12"), then the framework is upgraded, then a last pull request finishes the runtime. The table is small and static, so the prompt always says to verify it against the framework's docs;
  • for PHP observed on Laravel Forge: install the new PHP on the server before merging (Forge: server → PHP → "Install new PHP version"), switch the site's PHP version at deploy time, and, for a site with push-to-deploy, switch first or merge during a maintenance window, because the site deploys the moment the pull request merges;
  • rules and a checklist the agent prints for every pull request.

The target comes from endoflife.date: the newest LTS line for products that mark one (Node.js, Django, Symfony, Java), when it is newer than what runs now; otherwise the newest release, so the prompt never suggests a downgrade. Rust and Deno 2, which support only their latest release, target that. A finding stored before LTS data was kept says "the newest supported version (confirm on endoflife.date)" until the next scan.

The vulnerability-fix prompt

Covers every open vulnerability finding, grouped by package: ecosystem, installed version, direct or transitive when the lockfile and manifest say so, each advisory (GHSA, CVE, PKSA or OSV id, severity, summary, link) and the version that fixes it when the advisory names one. Production dependencies come first; dev-only dependencies follow in a section marked optional, the same default as the daily digest.

Its rules, smallest change first: (a) update the package itself within the existing constraints (composer update vendor/package, npm update package, pnpm update package); (b) if the constraints block the fix, bump the nearest direct dependency that pulls it in; (c) only then an override: npm overrides, pnpm pnpm.overrides in package.json (or overrides in pnpm-workspace.yaml), bun overrides. Composer has no safe override for a security fix, so conflict, replace and inline aliases are out. A package with no published fix gets an issue, not a pull request. Nothing is ever downgraded and no audit is turned off.

One pull request per change

Both prompts ask for one pull request per upgrade or per package, on its own branch, with the lockfile regenerated, CI green and a short description that names any manual follow-up. If tests fail for a reason the change does not explain, the agent is told to stop and report rather than force it. Small pull requests are easier to review and to revert, and one failing upgrade does not block the others.

Fetching a prompt from the command line

Each prompt is also served as Markdown, with the same sign-in as the repository page:

curl -fsS -b "<your session cookie>" https://repodar.dev/app/repos/<repo id>/prompts/upgrade.md
curl -fsS -b "<your session cookie>" https://repodar.dev/app/repos/<repo id>/prompts/vulns.md

The repository id is the last part of the repository page's URL. The response is text/markdown; charset=utf-8 and never cached. When there is nothing to do it is one sentence: upgrade.md says "Nothing is behind. Echo has nothing to say." and vulns.md says "No open vulnerabilities. Echo has nothing to say." Pipe it straight into an agent that reads standard input, for example … | claude -p.

What a prompt never contains

Tokens, session values, internal ids other than the repository page's own URL, scan warnings or anything a platform reported beyond the runtime version and the site and server names. Package names and advisory summaries come from lockfiles and public databases, so they are flattened to one line (a value that is not a plain name is dropped, never stitched together), advisory links are limited to GitHub advisories, OSV.dev, Packagist and NVD, and the prompt tells the agent, in its first paragraph, to treat them as data, not instructions. Each prompt stays under 8 KB: when there is more, the least severe items are left out with a line saying how many, and the full list stays on the repository page.

Last updated · View as Markdown