菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 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.
| name | doctor |
| description | 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. |
Thin wrapper around the kagura-engineer doctor CLI verb. It is the precondition
gate that the run / review skills run before doing any work — and you can
invoke it on its own to check the environment.
Announce: "Using the kagura-engineer:doctor skill to check the harness environment."
Usage: kagura-engineer:doctor — no arguments. Pass --config <path> only if repo.yaml is not in the current directory.
This skill reimplements nothing. It shells out to the installed CLI and surfaces the
result. If kagura-engineer is not on PATH, tell the user to install it
(uv tool install kagura-engineer or pip install kagura-engineer) and stop.
Discover config. The CLI reads repo.yaml from the current directory by
default. If the user named a different file, pass it through with --config.
There is no search path — repo.yaml must be in CWD or given explicitly.
Run the check (machine-readable):
kagura-engineer doctor --json
Capture stdout (a single JSON document) and the exit code.
Interpret the exit-code contract:
| Exit | overall | Meaning |
|---|---|---|
| 0 | ok / warn | Safe to proceed. warn items are advisory (e.g. missing ollama model, cloud credential unverified). |
| 1 | fail | Must stop. At least one blocking check failed. |
A missing or invalid repo.yaml is represented as a synthetic config | ||
failure alongside the config-free checks, so it exits 1 rather than 2. |
Surface the result. Print the per-check name / status / detail /
fix_hint table from the JSON. Lead with the blocking (fail) checks.
Hand off. If overall == "fail", suggest kagura-engineer:setup to repair the
environment, then re-run this skill. If overall is ok/warn, the caller may
proceed to kagura-engineer:run or kagura-engineer:review.