Phase 1 repo resolution assumes the configured clone is clean; stale staged work in a shared cache clone blocks git pull #148

Gap

Phase 1's resolution snippet picks the configured path whenever it exists, and only the fallback scan prefers a clone with no uncommitted changes ([ -z "$(git -C "$d" status --porcelain)" ] && break, template line 161). The configured path is usually a gardener-managed cache clone shared with other sessions. On a trace-dev-loop cycle (2026-09-12) it held ~1,145 lines of staged, uncommitted work from an earlier session, on main, 45 commits behind origin/main; git checkout main && git pull printed Aborting and the tree stayed stale — the very first action of the cycle failed, which is what the snippet exists to prevent. The staged work had been superseded by a separate repo and was git stashed with a descriptive message, but the template gave no guidance, and deleting another session's work would have been the wrong call.

Every generated loop uses the same snippet against a cache path, so this belongs in create-dev-loop.md rather than in one skill.

Suggested instruction text

After cd "$REPO_ROOT" in Phase 1:

Check the tree is clean before syncing. git status --porcelain must be empty. If it is not, this is someone else's in-flight work (the configured path is a shared cache clone): do not git checkout -- . or git clean. Compare it against origin/{{DEFAULT_BRANCH}} and the recent PR list — if it has clearly landed or been superseded, git stash push -m "<why> — stashed by {{SLUG}}-dev-loop <date>" and note the stash in the cycle report; if it has not, stop and surface it to the user before touching the tree.

Origin

Filed from dmccoystephenson/trace-dev-loop#10 (label template-rule), which stays open there until the template carries this text and the skill retrofits it.

drafted by Claude on behalf of Daniel Stephenson