kagura-engineer

Use when kagura-engineer:doctor reports a blocked or failing environment — scaffolds missing config, installs and authenticates harness prerequisites, and generates Memory Cloud MCP config by shelling out to `kagura-engineer setup`, then re-checks with doctor.

Use before any kagura-engineer run/review, or when the harness reports a blocked environment — diagnoses the local setup (git, selected brain CLI, gh, ollama, memory backend, and gh-issue-driven plugin) by shelling out to `kagura-engineer doctor` and reports what must be fixed.

Use to measure whether memory grounding actually improves PR quality — shells out to `kagura-engineer eval` with one or more issue numbers, running the SAME fixed issue set in two arms (recall ON vs OFF) and printing an A/B table. HARNESS — high cost; it runs the full loop twice per issue and mutates the repo. Confirm with the user before launching.

Use to review a git ref, branch, or PR with the local kagura-engineer reviewer — shells out to `kagura-engineer review [target]`, returning a structured verdict and findings. With `--fix` it is a HARNESS that edits files and commits; without `--fix` it is read-only.

Use to drive a single GitHub issue to a pull request with the kagura-engineer harness — shells out to `kagura-engineer run` with an issue number (guard → recall → worktree → start → implement → ship → persist). HARNESS — this mutates the repo, creates a PR, and spends model budget; confirm with the user before launching.

Use to bootstrap a fresh checkout for the kagura-engineer harness — scaffolds a commented repo.yaml template and adds it to .gitignore by shelling out to `kagura-engineer init`. Run this before setup/run/review when no repo.yaml exists yet. Idempotent and never overwrites.