7 coding agent automations you can put to work this week

It's Tuesday morning and the same chores are back. A dependency waited all week for review, someone flagged the setup doc as outdated and none of it urgent on its own but enough together to fill the morning.

Recurring repository work often starts with a recurring reminder. Left alone, these small checks accumulate and take up time.

Hoplite automations run a prompt against a project on a schedule or through an authenticated webhook. Each trigger starts a new thread and agent run, with its own activity timeline. That makes them useful for chores whose instructions stay mostly the same between runs. The automation documentation covers configuration and run history.

The recipes below are starting prompts. Adjust their paths and checks to your repository, then run the first instance while someone is available to review it. Approval requests and missing credentials can still interrupt automated work. Keep PR auto-merge off during the trial and tell each automation to leave its PR for human review.

Start with work that has a small stopping point

1. Check one dependency update

Run weekly. Limit the first version to a named package or a small approved list.

Check whether an approved dependency has a patch update. Read its release notes, update one package and its lockfile, and run the relevant checks. Open a draft PR if they pass. If the update requires application changes or the baseline already fails, report the findings and stop.

Review the lockfile as well as the manifest. A one-line version change can pull in considerably more than one line of work.

2. Investigate one flaky test

Run after a person identifies a recurring failure, or use a webhook from your CI system when you've configured the required delivery.

Investigate the specified flaky test using the supplied failure log. Try to reproduce it with a bounded number of reruns. Report the attempts and outcomes. If you find a specific cause, propose a minimal fix. Do not delete, skip, or weaken the test to make the run pass.

Set the rerun limit explicitly. An agent with an infinite patience budget is still using a finite compute budget.

3. Check setup documentation

Run weekly against the setup guide and the repository's declared runtime and package manager.

Compare the setup documentation with the current scripts and configuration. Verify changed commands in the sandbox. Open a small docs PR for confirmed mismatches, and report commands that require unavailable services. Leave unrelated wording alone.

This works best when the repository environment can install and run the application without someone completing an interactive wizard.

4. Review stale feature flags

Run monthly against an explicit list of flags approved for investigation.

Find references to the named flags and describe the behavior each branch controls. Identify tests and any configuration outside this repository that removal would affect. Produce a removal proposal. Do not delete a flag until an owner confirms its rollout state.

A search result can't establish whether a production flag is still needed. Keep this recipe investigative until that fact is supplied.

Use external events carefully

5. Triage a Sentry error

Use a schedule for a selected project, or a webhook from a system that can send Hoplite's required bearer header.

Inspect the reported error and related events. Check for an existing fix before editing. Reproduce with sanitized data, add a regression test if possible, and open a draft PR. If reproduction fails, report the evidence and the missing information in the Hoplite thread. Do not resolve the Sentry issue automatically.

Sentry inspection and mutation have different permission boundaries. Check the integration's available capabilities before assigning actions such as comments or resolution.

6. Summarize a failed deployment

Trigger from your deployment system with the relevant sanitized log or accessible reference.

Compare the supplied failure with the deployment configuration and recent changes. Identify the first relevant failure and propose the next diagnostic step. Do not redeploy, change secrets, or alter infrastructure. Report uncertainty when the log doesn't establish a cause.

This gives an engineer something specific to inspect without turning every failed deployment into an automatic infrastructure edit.

7. Propose one maintenance cleanup

Run weekly against a team-approved category, such as an unused internal helper.

Find one small cleanup supported by repository evidence. Check dynamic references and public exports before suggesting removal. If the candidate is safe to change, prepare a draft PR and run the relevant tests. Otherwise explain why it needs an owner's decision.

Make the first run easy to inspect

Cron schedules include an IANA timezone; intervals have a minimum of one minute. Choose a cadence that matches the work and available review time. Daily dependency PRs aren't useful when the team reviews them monthly.

Keep shared procedures in repository skills or project instructions. Personal skills don't apply to automations. After the first run, inspect its timeline, pending approvals, and output before enabling a recurring schedule. Start with the docs check if you want a contained task whose result is easy to read.