# 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: the runtimes that run (Runtime) with the exact version and where each came from, a runtime only CI mentions marked unknown, then what the workflows set up (CI) with the workflow files, frameworks, package managers and lockfiles, 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; - a version only CI sets up that is past end-of-life or releases behind gets its own **CI** item (`chore/upgrade-ci-node-24`) that touches the workflow setup steps only; - a Cloudflare Workers `compatibility_date` 12 months old or more gets an item that moves it to today: the wrangler file (`wrangler.toml` / `wrangler.json` / `wrangler.jsonc`) as the file to edit, "set compatibility_date to today and run the test suite", and Cloudflare's [compatibility dates](https://developers.cloudflare.com/workers/configuration/compatibility-dates/) page as the guide; - rules and a checklist the agent prints for every pull request. The target comes from [endoflife.date](https://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: ```sh curl -fsS -b "" https://repodar.dev/app/repos//prompts/upgrade.md curl -fsS -b "" https://repodar.dev/app/repos//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.