How do I install the Review In Worktree skill?

Run npx skillmds@latest add ddtcorex/review-in-worktree in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Review In Worktree safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Review In Worktree?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Review In Worktree free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Review In Worktree?

ddtcorex (@ddtcorex) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Review In Worktree by ddtcorex — Agent Skill

Name: Review In Worktree
Author: ddtcorex

Review In Worktree

Use this skill when reviewing code isolated in a Git worktree outside a Govard-managed project directory (for example Maestro merge-request review trees under /tmp), when "govard tool" cannot find the project configuration, or when asked to run Govard-managed commands against a detached review tree.

ddtcorex 8f1eb80 2.3 KB Updated Sep 17, 2026

File contents

Reviewing in Detached Worktrees

Why Govard Commands Fail Here

govard tool … resolves the project from a .govard.yml found upward from the current directory and dispatches into that project's running app container. A bare review worktree (created with git worktree add for a merge request) carries neither the config nor a running environment, so project-routed Govard commands fail by design.

Option 1 — Point at the Owning Checkout (preferred, read-only intent)

If the branch under review belongs to a Govard project that is already up (govard up ran in the real checkout), resolve the environment from there:

GOVARD_PROJECT_DIR=/path/to/real-checkout govard status

Verify with govard status before anything else. Treat this as read-only context for your review; never run mutations (migrations, cache flushes, indexers) against the owning project's database because a review asked for it.

Option 2 — Bootstrap a Throwaway Config

Only when the review must execute code and no owning environment exists:

govard init          # detects the framework, writes .govard.yml in the worktree
govard up            # brings up an isolated stack named after this directory

Clean up afterwards so review trees do not leak containers:

govard down && git worktree remove ../<worktree>

Option 3 — Static Analysis Only (most MR reviews)

Most automated reviews only need the diff, repository history, and the domain skills (magento2-code-review, magento2-linter guidance). Prefer this when the reviewer has no container rights or the MR is not meant to run.

Guardrails

Never point GOVARD_PROJECT_DIR at production or shared staging checkouts.
A worktree shares the repository with its main checkout: rebases or git worktree remove affect both — coordinate before cleaning up.
Database state is per project, not per worktree: two worktrees of one project share data through the same stack.

---name: review-in-worktreedescription: Use this skill when reviewing code isolated in a Git worktree outside a Govard-managed project directory (for example Maestro merge-request review trees under /tmp), when "govard tool" cannot find the project configuration, or when asked to run Govard-managed commands against a detached review tree.---# Reviewing in Detached Worktrees## Why Govard Commands Fail Here`govard tool …` resolves the project from a `.govard.yml` found upward fromthe current directory and dispatches into that project's running appcontainer. A bare review worktree (created with `git worktree add` for amerge request) carries neither the config nor a running environment, soproject-routed Govard commands fail by design.## Option 1 — Point at the Owning Checkout (preferred, read-only intent)If the branch under review belongs to a Govard project that is already up(`govard up` ran in the real checkout), resolve the environment from there:```bashGOVARD_PROJECT_DIR=/path/to/real-checkout govard status```Verify with `govard status` before anything else. Treat this as read-onlycontext for your review; never run mutations (migrations, cache flushes,indexers) against the owning project's database because a review asked for it.## Option 2 — Bootstrap a Throwaway ConfigOnly when the review must execute code and no owning environment exists:```bashgovard init # detects the framework, writes .govard.yml in the worktreegovard up # brings up an isolated stack named after this directory```Clean up afterwards so review trees do not leak containers:```bashgovard down && git worktree remove ../<worktree>```## Option 3 — Static Analysis Only (most MR reviews)Most automated reviews only need the diff, repository history, and the domainskills (`magento2-code-review`, `magento2-linter` guidance). Prefer thiswhen the reviewer has no container rights or the MR is not meant to run.## Guardrails- Never point `GOVARD_PROJECT_DIR` at production or shared staging checkouts.- A worktree shares the repository with its main checkout: rebases or `git worktree remove` affect both — coordinate before cleaning up.- Database state is per project, not per worktree: two worktrees of one project share data through the same stack.

Frequently asked questions