Is delorenj/unfuck-my-git-state safe?
https://github.com/openclaw/skills/tree/main/skills/delorenj/unfuck-my-git-state
unfuck-my-git-state is a legitimate and well-authored git recovery skill with no evidence of prompt injection, credential theft, or exfiltration. The skill's bash scripts are read-only diagnostic tools; potentially destructive git commands appear only as agent-facing plan recommendations, not auto-executed code. Sensitive credential files were accessed during monitoring but the CLOSE_NOWRITE pattern and timing are consistent with the oathe audit infrastructure's own canary checks, not the skill itself. The primary risk is operational: an agent following the playbooks without strict backup compliance could irreversibly modify git history, making this skill appropriate for use by agents configured to require explicit confirmation before destructive operations.
Category Scores
Findings (6)
MEDIUM Bash Scripts Enable Destructive Git Operations When Agent Follows Playbooks -10 ▶
The skill includes three bash scripts and a SKILL.md that collectively instruct an agent to run git commands capable of irreversibly modifying branch history and worktree metadata. guided_repair_plan.sh outputs commands like 'git branch -f
LOW Force Operations in Playbooks Risk Irreversible Data Loss If Misapplied -18 ▶
Multiple playbooks include operations with no undo path: git branch -f (force-moves branch pointer, discarding local-only commits), direct .git/HEAD file writes (bypasses git safety checks), and git worktree prune (removes worktree metadata). While the skill consistently mandates backup-first, there is no technical enforcement preventing an agent from skipping that step or applying the fix to an unintended repository. The skill also does not include a 'confirm with user' step between the plan generation and apply phases.
LOW Credential Files Accessed During Monitoring Window -8 ▶
Files including /home/oc-exec/.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCloud application default credentials were opened and read during the monitoring period. All accesses show CLOSE_NOWRITE events (no modification). The access timestamps (1771940999 pre-clone, 1771941017 post-audit) and pattern strongly indicate oathe monitoring infrastructure canary baseline and verification checks rather than skill activity. No skill script references these file paths. Included as a finding due to the access occurring within the monitored session boundary.
INFO Monorepo Sparse Checkout Installation Pattern -5 ▶
The skill is distributed inside a monorepo (openclaw/skills) and installed via git sparse-checkout rather than from a dedicated repository. This is an increasingly common pattern for plugin ecosystems. The full clone is shallow (--depth 1), the target subdirectory is extracted, and /tmp/monorepo-clone is deleted cleanly. No residual network connections or persistent side effects from the clone process were observed.
INFO Canary Files Opened Read-Only During Monitoring — No Write or Exfiltration -5 ▶
All six honeypot credential files were opened during the monitored session. All events show CLOSE_NOWRITE, confirming no bytes were written. The access times (pre-clone and post-install) match the oathe monitoring lifecycle. No canary file content was observed in any network payload or process argument string throughout the session.
INFO Playbook Apply Step Lacks Explicit User-Confirmation Gate -5 ▶
SKILL.md's Fast Workflow instructs the agent to generate a repair plan and then 'apply the smallest matching playbook' without an intermediate user-confirmation step. The Automation Hooks section advises tool builders to require explicit confirmation before destructive commands, but this guidance is advisory rather than a binding constraint on the agent executing the skill. In practice an agent could apply a playbook without pausing for user approval.