Set up with your coding agent

Open your target repository in Codex, Cursor or another coding agent, then paste one prompt below. These prompts ask the agent to inspect your project and prepare a usable setup. They do not require you to choose paths or test commands before the agent has read the repository.

I want to…	Use this prompt	What it prepares
Try one maintenance task locally	Local setup	Project configuration, a task file and verified setup commands
Open maintenance PRs from GitHub Actions	GitHub Actions	A manual workflow first, with the required secrets and permissions documented
Call the engine from Python or TypeScript	Maintenance from a script	A script with configuration in code and structured result handling
Understand a failed or blocked run	Diagnose a run	An evidence-based diagnosis and the smallest relevant correction
Keep a library compatible with official APIs	Prism template	Scoped maintenance with official reference sources
Connect scanner findings to Slack or remediation PRs	Security template	The template and integration requirements; a webhook gateway is still needed

Configuration checks do not call a model. A real maintenance run uses the chosen agent account; a GitHub workflow's dry_run still generates a proposal and can incur model charges. It suppresses publication, not inference.

For CLI submission and a hosted GitHub workflow, see CLI & GitHub automation.

Local setup

Set up Repo Maintainer for one local task in this repository.
Read https://repomaintainer.com/docs/getting-started/ and the linked configuration
reference, then inspect this repository's instructions, runtime, package manager,
source paths, test commands and existing automation. Verify commands against the
current CLI; do not guess flags or assume npm, pytest or Cargo is used here.

Install or locate the native engine and identify the coding agent it will use.
Preserve an existing .maintainer.yml; otherwise initialize version 2 configuration.
Choose one small task appropriate to this project. Write task.md with the current
behavior, desired behavior and acceptance checks. Configure narrow editable paths
and the actual setup, test and lint commands. Include .maintainer-output/ in
.gitignore. Keep credentials in the environment or the user's secret store.

Run repo-maintainer check. Run the configured baseline checks when the environment
supports them; report missing tools and pre-existing failures separately. Explain
that setup/check commands can install dependencies or execute project code.
Do not make a paid inference call, commit unrelated work, apply a generated patch,
create a PR or add a schedule as part of this setup-only task.

Show the diff, required credential names (never values), exact first-run command,
where to find the result, and how to review/apply a successful patch. Explain that
runs inspect committed HEAD, so uncommitted source changes are not included.

Once setup checks pass, use the first-run walkthrough to run a task and review the result. The prompt deliberately stops before inference.

GitHub Actions

Use this after a local setup works, or when the project can only be tested in CI. GitHub Actions runs on your repository's runner; it is separate from the hosted website preview.

Prepare GitHub Actions maintenance for this repository using
https://repomaintainer.com/docs/getting-started/#weekly-cloud-maintenance and the
current reusable workflow in djsydney04/repo_maintainer.

Inspect the existing .maintainer.yml, CI workflow and repository runtime. Preserve
existing automation. Add a manual workflow_dispatch caller first, without a cron
schedule. Pin uses and maintainer_ref to the same reviewed full commit SHA and
verify the referenced workflow's input and secret names at that revision.

Configure meaningful project checks and narrow editable paths. Identify the
provider credential to store as an Actions secret without putting its value into
the workflow. Explain the permissions needed for PRs, blocker issues and any CI
dispatch, and how these differ from read-only proposal generation. If using
self-hosted runners, verify the required labels and tools.

Validate YAML/configuration and the caller's input types. Document how to run a
manual dry run and inspect its artifacts: dry_run still calls the agent but skips
publication. Do not dispatch a paid run, enable a schedule or change repository
permission settings during this preparation task.

Return the diff, required settings/secrets, expected proposal/validation/publication
stages, and the exact steps to enable recurring work after the first reviewed run.

A schedule belongs in the consuming repository, not in the SDK. Start with one focused recurring instruction; do not keep scheduling a completed feature request.

Maintenance from a script

Set up a Repo Maintainer script in this repository. Read
https://repomaintainer.com/docs/templates/ and the script template's SETUP.md.
Use Python or TypeScript according to the project's existing tooling.

Install or locate the native repo-maintainer executable and the matching SDK.
Use the documented installation source; do not assume a package is published to
PyPI or npm. Supply the complete configuration as a dictionary/object rather than
requiring a YAML file. Discover the real source paths and checks from this repo.
Keep the task separate from trusted commands and configuration.

Call check() before run(). Handle changed, unchanged and blocked outcomes, retain
artifact paths, and propagate operational errors. A blocked proposal must not be
applied or published automatically. Test result handling with an offline fixture
or mocks; clearly label that this is not a live model run.

Keep the first real run manual. Do not add a web service, scheduler, paid inference
call or publication step during setup. Show the script, installation commands,
required environment-variable names and an example invocation.

See the Python, TypeScript and result contract pages for concrete API examples.

Diagnose a run

Diagnose the latest failed or blocked Repo Maintainer run for this repository.
Read https://repomaintainer.com/docs/troubleshooting/ and inspect the available
result.json, report.json, events.jsonl and validation evidence, or the relevant
GitHub Actions run. Do not print credentials or dump the environment.

Identify the failing stage, command/error, source revision, configuration and
whether the failure existed before the proposed patch. Distinguish invalid setup,
provider/authentication errors, quota limits, interruption and failed project tests.
A configuration check passing does not prove the project tests passed.

Make the smallest supported configuration or documentation correction within this
request. Do not increase budgets, broaden editable paths, rotate credentials or
repeat paid runs merely to see whether the error disappears. Preserve the failed
run's artifacts. Finish with evidence, the fix, validation performed, and the
specific next command or user action needed. Say when the available evidence is
insufficient rather than inventing a root cause.

Reuse the documentation skill

The repository includes docs-skill for improving developer documentation and writing prompts like these. Agents that discover .agents/skills/ can use the repo copy. To install it for your Codex user from the Repo Maintainer checkout:

mkdir -p "$HOME/.codex/skills"
cp -R .agents/skills/docs-skill "$HOME/.codex/skills/"

If that destination already exists, compare it before replacing your customized copy. Invoke the skill with:

Use $docs-skill to improve this repository's setup documentation. Verify examples
against the code, add agent setup prompts, and clearly separate working features,
templates, previews and steps that still need configuration.