executing-plans assumes every plan produces code changes in a git-tracked project

• I searched existing issues and this has not been proposed before

Searched open and closed issues and PRs for "worktree", "non-code plan", "no git repository", "google doc", "document deliverable plan mode". Related but distinct: #2241 (same two skills, also about the "plans assume application code" gap — but #2241's fix adds an Infrastructure-and-operations subsection for plans that still act on a target system with something to roll back; this report is about the case one level further out, where there is no target system or repository at all).

What problem does this solve?

executing-plans Step 1 unconditionally says "Ensure an isolated workspace: use superpowers:using-git-worktrees to create one or verify the existing one," and Step 3 unconditionally requires invoking finishing-a-development-branch after task completion. Both assume the plan being executed produces code changes on a branch.

Claude Code's own Plan Mode (EnterPlanMode/ExitPlanMode) is generic — it produces an approved plan file for any kind of task, not only code implementation. I hit this executing a plan whose entire deliverable was a document (a proposal populated into a Google Doc via browser automation, plus a markdown handoff doc) in a working directory that was not a git repository at all — no repo, no branch, nothing to worktree and nothing to merge or finish.

Following the skill literally there means fabricating a git repo/worktree purely to satisfy the skill, which is unrequested scope the user never asked for. The skill has no entry-condition check for "does this plan even touch a git-tracked project," so it's silently inapplicable to every non-code planning session, and an agent instructed to always use an applicable skill has no clean way to notice that it doesn't apply, short of reasoning it out mid-execution.

Proposed solution

Add an explicit entry-condition check at the top of Step 1: "Does this plan produce code changes in a git-tracked project?" If no, skip the using-git-worktrees step and skip the Step 3 finishing-a-development-branch hand-off entirely, replacing "Complete Development" with a plain completion report. The per-task execute/verify loop in Step 2 is already deliverable-agnostic and needs no change — this is a single early branch, not a rewrite.

What alternatives did you consider?

A separate "executing non-code plans" skill — rejected as premature; nothing about Step 2 needs to differ, only the git-specific bookends in Steps 1 and 3. Leaving it to the executing agent's judgment — rejected; that's the current state, and it means every non-code plan either gets a fabricated git repo or an agent quietly improvising past a "required sub-skill."

Is this appropriate for core Superpowers?

Yes. Any skill that keys its steps off "there is a plan file to execute" needs an explicit check for what kind of deliverable the plan describes before applying steps (git worktree, branch, PR, deploy, etc.) specific to one deliverable type. This isn't specific to my domain or a third-party tool — it applies to anyone who uses Plan Mode for something other than a code change.

Environment (required)

Field	Value
Superpowers version	6.3.0 (b36e0829c6d0), claude-plugins-official marketplace
Harness (Claude Code, Cursor, etc.)	Claude Code
Harness version	2.1.269
Your model + version	Claude Sonnet 5 (claude-sonnet-5)
All plugins installed	superpowers

Context

Captured in a personal skill-observation log during a real session and re-verified against both main and dev at time of filing (identical on both) — the local pinned copy matches upstream HEAD, so this isn't a local-drift artifact. Filed as an issue rather than a PR because a skill-behavior change here needs the eval evidence this repo's contributing guide asks for, which I haven't run; happy to open a PR instead if a maintainer prefers that path for a change this small.