Existing agent · project rules · human decisions

From a maintenance
problem to a checked fix.

Routine maintenance takes more than a review comment. Let your agent investigate, repair, test and finish the work your project delegates. Keep the few decisions that need a person clear, with the patch and evidence attached.

Use the tools you already have Your agent, test runner and repository service enforce access. The starter prepares policy and explains gaps; it installs no unattended runner.

Start with one repair

Give your agent this request

Read https://chores.knlp.io/self-maintenance.html and its linked starter.
Inspect this repository's contributor instructions, tests and existing automation.
Prepare an integration that uses those conventions. Identify maintenance classes,
required evidence and actions already authorized. Propose rules for publishing,
merging and human handoffs. Take one small task as far as existing authority permits.
Preserve the patch and evidence if blocked. Show the remaining policy decisions
with a recommendation for each. Do not acquire credentials, spend, or broaden scope
merely to finish.

Keep the skill and linked files together. Inspect and pin the starter before adoption. Reuse a supported subscription login or company-approved model service where its account and data rules permit the intended work. An expired login or exhausted quota pauses the task; it does not select a new account.

Choose the completion point

Delegate actions, not a blanket autonomy switch

Prepare changes

Investigate, repair and run approved tests. Finish with a reviewed patch; the human controls publication and merge.

Publish for review

Also submit through the project's normal PR or patch-series channel, and respond to findings. The human controls merge.

Merge eligible maintenance

Also merge declared classes after current checks and required reviews pass, then check the merged result. Reserve exceptions and public behavior choices for a maintainer.

Keep decisions scoped

Edit, test, publish, branch update, merge and revert are separate permissions. Apply an accepted standing rule without asking again. One patch approval does not create a permanent rule.

Read policy from a trusted baseline outside the candidate's control. Mixed changes inherit all applicable tests and the most restrictive rights. Protected paths and unknown effects need their recorded review process. A small file or a documentation path is not proof of harmless behavior.

Carry the useful work forward

Investigate → repair → test → review → publish → merge → verify

Use a reproducible failure or a precise acceptance condition. Make a focused repair, review every commit and the complete diff, and retain failed attempts. Fold later repairs into their owning unmerged commits where appropriate. Separate a verified upstream bug fix; do not invent a Fixes: hash.

Before an external action, check the current candidate, target, policy, required evidence and native protections. A changed head or target can invalidate earlier results. A native merge queue or atomic expected-input check must close the freshness race; a read followed by a blind write does not.

Record the actual merged revision and required follow-up checks. A queued merge is not complete, and a failing post-merge check leaves work open. Stop related automatic merges and follow the explicit incident/revert rule. Reconcile an uncertain publication or merge before retrying it.

Test the changed behavior

Choose assertions before hardware

Generic profileRoutine checksAdditional evidence when affected
Portable systems libraryBuild, unit, sanitizer and ABI checksNamed transport, device or firmware behavior
Kernel integrationUserspace checks and supported configurationsDisposable guest with the required load, verifier, attach, event and cleanup paths
Compiler or build toolClean/incremental builds, dependencies, deterministic output and cache invalidationRequired platforms/toolchains and controlled performance comparisons
Storage workload toolParser/job tests and new task-owned filesSupported emulated features or allocated disposable-device tests

ABI means the binary interface seen by compiled consumers. QEMU is a machine emulator. Accept emulation only where the test policy says it answers the question. Physical performance, real GPU behavior and device-specific effects need their own evidence and resource grants. A worktree is not a sandbox.

Record passed, failed, skipped, unavailable, inconclusive, cancelled and trusted-rule exclusions separately. Missing required coverage blocks merge. Optional coverage remains visible. Never replace a missing hardware test with an unrelated green mock or choose an arbitrary disk.

Generic test profiles →

Hand over the decision, not the investigation

Make the next human action small and clear

A documentation repair can complete under an approved rule. A device change can keep its passing unit tests while an operator receives the exact missing test and prerequisites. A behavior ambiguity needs a recommended option, alternatives and the maintainer's decision. Keep those cases distinct.

Include completed work, revision, the blocked decision, recommendation, evidence, route and deadline. Routine reviews can be batched; suspected corruption or unauthorized activity uses the immediate incident channel. No response leaves the action waiting. Independent authorized work may continue.

One worker first

Validate the integration before making it routine

The offline helpers inventory local conventions, validate versioned documents and explain action gates using an explicit clock. Their output always says authority_verified: false. They cannot authenticate JSON claims, acquire permissions, execute tests or merge a branch.

A disposable local Git integration exercises expected-input reference transactions and receipt recovery with controlled test producers. Production merge needs a separately qualified native adapter. No real-project pilot, provider integration or production containment is claimed here.

Try a complete repair plus denied, stale, missing-coverage and interrupted cases. Compare completed fixes, maintainer effort, false findings and cost with your existing agent-and-CI workflow. Add scheduling or more workers only when they solve an observed problem.