# Researchforge Doctor

> Check that ResearchForge's dependencies (git, Python, optionally Docker) are available and explain any failures. Use when setup fails, before starting a project, or when the user asks whether their machine is ready.

- Skill: `forger-labs-hq/researchforge-doctor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add forger-labs-hq/researchforge-doctor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/forger-labs-hq/researchforge-doctor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: forger-labs-hq (https://skillmd.com/u/forger-labs-hq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/forger-labs-hq/researchforge-doctor

---


# Diagnose the ResearchForge environment

```bash
researchforge doctor --json
```

Each entry has `name`, `ok`, `required`, `detail`, and an optional `hint`.

- All required checks pass → say the environment is ready and continue.
- A required check fails → explain the failure in plain language, show the
  `hint`, and stop: later commands will refuse to run. Do not try to work
  around a failed required check.
- An optional check fails (e.g. Docker) → note the limitation: experiments
  fall back to `.venv` mode, which is dependency isolation, not a security
  sandbox — only trusted repositories should be run there.

If skills seem out of date or missing, `researchforge claude status --json`
reports the installed/modified/missing state of each skill and
`researchforge claude install` refreshes unmodified ones.

## Rules

- The Python engine is the boundary: never work around a validation error, a
  protected path, or an approval gate — fix the artifact or ask the user.
- Approvals belong to the user: never pass `--yes` or type a confirmation
  unless the user explicitly approved that step in this conversation.
- Ground every summary in stored data: quote only numbers returned by
  `--json` output or files under `.researchforge/` — never invent metrics.