adityaarakeri

git-hygiene

Version control discipline for agent work. Atomic commits, meaningful messages, safe operations, and zero destructive surprises. Use this whenever committing, branching, merging, rebasing, resolving conflicts, or preparing pull requests, before any git command that rewrites or discards history, and when the user says "commit this", "clean up the history", or "undo". Consult it before every force push, reset, or clean, without exception.

API & Backend Listed

plan-first

Write and confirm a short implementation plan before starting any large or risky change. Use this for tasks that touch three or more files, alter public APIs, database schemas, auth, payments, build systems, or CI, for migrations and multi-step refactors, and whenever the honest estimate is "this will take many steps". Also trigger it when the user asks "how would you approach this", says "plan", or when the request is ambiguous enough that two reasonable engineers would build different things.

AI & Automation Listed

repo-recon

Systematically map an unfamiliar codebase before changing anything in it. Use this whenever work starts in a repo, service, or module that has not been explored in the current session, when the user says things like "new codebase", "help me understand this project", "onboard me", or before any non-trivial change where the surrounding code is unknown. Also reach for it after a change failed because of a wrong assumption about project structure or conventions.

safe-refactor

Change code structure without changing behavior, in small verified steps. Use this for refactoring, renaming, extracting functions or modules, moving files, removing duplication, dependency and framework migrations, and any "clean this up" or "improve this code" request. Especially important when test coverage is thin, the codebase is unfamiliar, or the diff will exceed a couple hundred lines.

self-review

Review the complete diff as a skeptical senior reviewer before handing work back. Use this after finishing any code change and before declaring it done, before committing a substantial diff or opening a pull request, and whenever the user says "review", "check this", or "is this ready". Includes a lightweight security sweep of the changed lines. Make this the last step of every non-trivial coding task.

Testing & QA Listed

tdd-loop

Drive implementation with a strict red-green-refactor test loop. Use this when implementing a new feature, changing behavior, or fixing a bug in any codebase that has automated tests or should have them, especially when the user says "add", "implement", "build", "fix", or "make it do X". Also use it to lock a bug fix in place with a regression test before touching the production code.

verify-done

An evidence gate that must pass before claiming any task is complete. Use this at the end of every coding task, right before saying "done", "fixed", "implemented", or "should work", and whenever tempted to assume code works without running it. Applies to features, bug fixes, refactors, config changes, and one-off scripts alike. If work is being handed back to a human, this gate comes first.