Getting started with MoonShift

MoonShift works directly from your GitHub issues. Each issue is the agent's entire brief — it reads the title and description and implements exactly what's written, nothing more. The quality of the pull request depends almost entirely on the quality of the issue.

Treat every issue like a short spec. State what you want, where it lives, and how you'll know it's done:

• Goal — what should change and why.
• Scope — the files, components, or areas involved (if you know them).
• Acceptance criteria — what "done" looks like.
• Constraints — styles, libraries, or patterns to follow or avoid.

In Model engine settings, pick the brain that does the coding:

• Claude (cloud) — the most reliable for complex, multi-file work. Best results, but it bills per token.
• Local model (LM Studio) — runs on your own machine for free. Great for smaller, well-scoped issues.

You can switch engines anytime — many people use a local model for routine cleanups and save Claude for the gnarly, multi-file features.

Open Scheduler settings and tell MoonShift how often to work:

• Interval — how often it checks for open issues (default every 30 minutes).
• Active window — optionally restrict runs to certain hours.
• Issues per cycle — how many issues to tackle each run.
• Build command — optional; MoonShift can run your build (e.g. npm run build) and only open a PR if it passes.

Flip on Run automatically and MoonShift handles the rest in the background — picking up new open issues on its own. You can also hit Run now anytime to kick off a cycle immediately.

Every fix lands on its own branch as a pull request on GitHub, attributed to your account, with a summary of what changed. Review it like any PR — read the diff, let your CI run, then request changes or merge.

• Good PR? Merge it like normal.
• Not quite right? Close it, or use Rerun in the dashboard to have MoonShift try the issue again.
• Track everything in the dashboard: tokens, cost, and runtime per issue, with a direct link to each PR.