T09 · Insecure Skill Coding Practices
- Location
SKILL.md:89- Finding
Contradictory cleanup instructions may unexpectedly remove a pull-request worktree
- Content
View full analysis
# Create PR gh pr create --title "" --body "$(cat <<'EOF' ## Summary <2-3 bullets of what changed> ## Test Plan - [ ] <verification steps> EOF )" ``` Then: Cleanup worktree (Step 5) ``` The cleanup step explicitly includes Option 2: ```markdown ### Step 5: Cleanup Worktree **For Options 1, 2, 4:** Check if in worktree: ```bash git worktree list | grep $(git branch --show-current) ``` If yes: ```bash git worktree remove <worktree-path> ``` **For Option 3:** Keep worktree. ``` This conflicts with the later safety guidance: ```markdown **Automatic worktree cleanup** - **Problem:** Remove worktree when might need it (Option 2, 3) - **Fix:** Only cleanup for Options 1 and 4 ``` ### Technical Analysis The workflow gives mutually incompatible instructions for Option 2. The executable procedure directs the agent to perform Step 5 after pushing the branch and creating a pull request, while Step 5 explicitly includes Option 2 among the cases requiring worktree removal. However, the quick-reference and common-mistakes guidance state that a pull-request worktree must be preserved. An agent following the procedural instructions sequentially may treat the earlier operational steps as authoritative and execute `git worktree remove <worktree-path>`. This is an unsafe coding and configuration defect because a user selecting “Push and Create PR” did not select local worktree deletion. The check is also fragile because: ```bash git worktree list | grep $(git branch --show-current) ``` uses unquoted command substitution and matches unstructured human-readable output. Branch names containing pattern characters, spaces, ...[truncated 1697 chars]- Remediation
View remediation
. No local branch or worktree cleanup was performed. ``` 3. Require explicit confirmation immediately before any worktree removal, even when cleanup follows a previously selected workflow option. 4. Resolve and validate the exact worktree path using structured Git output rather than matching `git worktree list` with `grep`. For example, parse `git worktree list --porcelain` and verify that the selected path and branch correspond exactly. 5. Quote all shell-expanded values and use end-of-options delimiters where supported: ```bash git worktree remove -- "$worktree_path" ``` 6. Before removal, verify that: - the path is a registered linked worktree; - it corresponds to the intended feature branch; - it is not the current or base worktree; - it contains no uncommitted or untracked work; - the user has confirmed the exact displayed path. 7. Add workflow tests or review checks covering all four options so that Option 2 is guaranteed to preserve both its branch and worktree. ]]>
