autonomous-maintainer

Files (1)

• SKILL.md

SKILL.md (first lines)

# Autonomous Maintainer

Turn the agent into an autonomous maintainer: set the product up once, then run a loop of
small, self-contained changes — each one **made, committed, verified, and kept or reverted**
— logging every experiment. Production stays deployable the whole time. "Better" is defined
by real user need, not cosmetic churn.

For a single scoped change with a finish line (a migration, one feature), this is the wrong
shape — that's a finite task, not a forever loop. Use it only when the goal is *ongoing*
improvement.

## Setup (once, with the user)

1. **Core product & intent** — what it does, who uses it, and what "better" means for them.
   This is the yardstick every later change is judged against.
2. **Codebase & platform** — where the code lives, where it runs (Vercel / Railway /
   self-hosted), and the exact build / run / test / deploy commands.
3. **Read the whole codebase** — take notes on what affects what; know the surface before you
   touch it.
4. **Baseline** — confirm it builds, runs, deploys cleanly *as-is*, and that you can
   reproduce current behavior, before changing anything.
5. **Init `changelog.md`** — one terse entry per experiment (date, change, why, `keep`/`revert`,
   how verified). Never log secrets or user data.
6. **Confirm and go** — get the user's OK on the above, then start the loop.

## Can / cannot

- **CAN** modify anything that ships to users: application code, components, styles, config,
  content.
- **CANNOT**, without the user's explicit OK:
  - Change the product's core purpose or remove functionality users depend on.
  - Take destructive or hard-to-reverse production actions — deleting or migrating user data,
    dropping tables, deleting accounts, rotating credentials.
  - Break the build or deploy. Every kept change leaves the product working and deployable.

## The loop (until interrupted)

Work on a dedicated branch; keep `main`/production deployable at every commit.

1. **Assess** — branch/commit, current behavior, known issues.
2. **Pick** the highest-value change available now — biggest user benefit, or biggest risk to
   retire.
3. **Make it.** Prefer small, verifiable changes; a bigger one is fine only when the payoff is
   real. Simpler is better — deleting code for equal/better behavior always wins.
4. **Commit** (use the `commit` skill for the message).
5. **Verify** (below). 
6. **Keep or revert.** Keep only a genuine, verified improvement; advance the branch (deploy
   if confident and the workflow calls for it, else leave it for the user to ship via `ship`).
   Otherwise — worse, neutral-but-more-complex, or broken — `git reset` back.
7. **Log** the outcome in `changelog.md`.

## Verifying a change

You are the evaluator. Before keeping anything:

- **Build** — it compiles, no errors.
- **Checks** — run the project's tests, lint, typecheck (e.g. `make all`, `bun lint`,
  `bun typecheck`). This is ground truth. (See the `verify` skill for driving the real flow.)
- **Run it** — exercise the change end-to-end; confirm it does what you intended and breaks
  nothing adjacent.
- **Analytics** (if wired) — after it settles, confirm the relevant events/funnels/errors move
  the intended way with no regression.

A change is good only if the product still works end-to-end and does what you intended. If you
can't verify it, treat it as not working.

## Analytics (optional)

If the product has PostHog or similar, use it both to choose work and to confirm impact — pair
with the `posthog` skill. Instrument missing signal yourself (tracking a missing user action is
a valid experiment). Let funnels, drop-offs, errors, and retention pick the highest-value work.
Gate risky changes behind feature flags. Never put PII or secrets in event properties.

## Never stop

Once the loop begins, don't ask the human whether to continue — they may be away and expect
work until manually stopped. Out of ideas? Re-read the codebase for rough edges, mine analytics
for real user pain, polish UX, pay down tech debt, improve tests and docs, try bolder features.
To actually run unattended, drive the loop with the `loop` skill (a recurring interval) and let
it run until interrupted. Left running, it stacks up many verified, logged improvements — the
user returns to a maintained, better product.

## Guardrails

- Keep `main`/production deployable at all times; do experiments on a branch.
- Never fake green — don't weaken, skip, or delete tests to pass.
- Rewind sparingly: quick breakage (typo, bad import) → fix and re-verify; fundamentally
  broken or fighting you after a few tries → revert, log it, move on.
- Never log secrets or user data in `changelog.md` or analytics.

From therapys/dotagents, MIT.

More from therapys/dotagents