skills/wsf-reapply-patches/SKILL.md
Reapply local modifications after a WSF update
npx skillsauth add sampx/agent-tools wsf-reapply-patchesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Critical invariant: Every file in wsf-local-patches/ was backed up because the installer's hash comparison detected it was modified. The workflow must NEVER conclude "no custom content" for any backed-up file — that is a logical contradiction. When in doubt, classify as CONFLICT requiring user review, not SKIP.
</purpose>
Check for local patches directory:
expand_home() {
case "$1" in
"~/"*) printf '%s/%s\n' "$HOME" "${1#~/}" ;;
*) printf '%s\n' "$1" ;;
esac
}
PATCHES_DIR=""
# Env overrides first — covers custom config directories used with --config-dir
if [ -n "$KILO_CONFIG_DIR" ]; then
candidate="$(expand_home "$KILO_CONFIG_DIR")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
elif [ -n "$KILO_CONFIG" ]; then
candidate="$(dirname "$(expand_home "$KILO_CONFIG")")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
elif [ -n "$XDG_CONFIG_HOME" ]; then
candidate="$(expand_home "$XDG_CONFIG_HOME")/kilo/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
fi
if [ -z "$PATCHES_DIR" ] && [ -n "$OPENCODE_CONFIG_DIR" ]; then
candidate="$(expand_home "$OPENCODE_CONFIG_DIR")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
elif [ -z "$PATCHES_DIR" ] && [ -n "$OPENCODE_CONFIG" ]; then
candidate="$(dirname "$(expand_home "$OPENCODE_CONFIG")")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
elif [ -z "$PATCHES_DIR" ] && [ -n "$XDG_CONFIG_HOME" ]; then
candidate="$(expand_home "$XDG_CONFIG_HOME")/opencode/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
fi
if [ -z "$PATCHES_DIR" ] && [ -n "$GEMINI_CONFIG_DIR" ]; then
candidate="$(expand_home "$GEMINI_CONFIG_DIR")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
fi
if [ -z "$PATCHES_DIR" ] && [ -n "$CODEX_HOME" ]; then
candidate="$(expand_home "$CODEX_HOME")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
fi
if [ -z "$PATCHES_DIR" ] && [ -n "$CLAUDE_CONFIG_DIR" ]; then
candidate="$(expand_home "$CLAUDE_CONFIG_DIR")/wsf-local-patches"
if [ -d "$candidate" ]; then
PATCHES_DIR="$candidate"
fi
fi
# Global install — detect runtime config directory defaults
if [ -z "$PATCHES_DIR" ]; then
if [ -d "$HOME/.config/kilo/wsf-local-patches" ]; then
PATCHES_DIR="$HOME/.config/kilo/wsf-local-patches"
elif [ -d "$HOME/.config/opencode/wsf-local-patches" ]; then
PATCHES_DIR="$HOME/.config/opencode/wsf-local-patches"
elif [ -d "$HOME/.opencode/wsf-local-patches" ]; then
PATCHES_DIR="$HOME/.opencode/wsf-local-patches"
elif [ -d "$HOME/.gemini/wsf-local-patches" ]; then
PATCHES_DIR="$HOME/.gemini/wsf-local-patches"
elif [ -d "$HOME/.codex/wsf-local-patches" ]; then
PATCHES_DIR="$HOME/.codex/wsf-local-patches"
else
PATCHES_DIR="/Users/sam/coding/wopal/wopal-workspace/.wopal/wsf-local-patches"
fi
fi
# Local install fallback — check all runtime directories
if [ ! -d "$PATCHES_DIR" ]; then
for dir in .config/kilo .kilo .config/opencode .opencode .gemini .codex .claude; do
if [ -d "./$dir/wsf-local-patches" ]; then
PATCHES_DIR="./$dir/wsf-local-patches"
break
fi
done
fi
Read backup-meta.json from the patches directory.
If no patches found:
No local patches found. Nothing to reapply.
Local patches are automatically saved during WSF reinstallation
after modifying any WSF workflow, command, or agent files.
Exit.
The quality of the merge depends on having a pristine baseline — the original unmodified version of each file from the pre-update WSF release. This enables three-way comparison:
wsf-local-patches/)Check for baseline sources in priority order:
If the config directory is a git repository:
CONFIG_DIR=$(dirname "$PATCHES_DIR")
if git -C "$CONFIG_DIR" rev-parse --git-dir >/dev/null 2>&1; then
HAS_GIT=true
fi
When HAS_GIT=true, use git log to find the commit where WSF was originally installed (before user edits). For each file, the pristine baseline can be extracted with:
git -C "$CONFIG_DIR" log --diff-filter=A --format="%H" -- "{file_path}"
This gives the commit that first added the file (the install commit). Extract the pristine version:
git -C "$CONFIG_DIR" show {install_commit}:{file_path}
Check if a wsf-pristine/ directory exists alongside wsf-local-patches/:
PRISTINE_DIR="$CONFIG_DIR/wsf-pristine"
If it exists, the installer saved pristine copies at install time. Use these as the baseline.
If neither git history nor pristine snapshots are available, fall back to two-way comparison — but with strengthened heuristics (see Step 3).
## Local Patches to Reapply
**Backed up from:** v{from_version}
**Current version:** {read VERSION file}
**Files modified:** {count}
**Merge strategy:** {three-way (git) | three-way (pristine) | two-way (enhanced)}
| # | File | Status |
|---|------|--------|
| 1 | {file_path} | Pending |
| 2 | {file_path} | Pending |
For each file in backup-meta.json:
wsf-local-patches/)wsf-pristine/)Compare the three versions to isolate changes:
Merge rules:
When no pristine baseline is available, use these strengthened heuristics:
CRITICAL RULE: Every file in this backup directory was explicitly detected as modified by the installer's SHA-256 hash comparison. "No custom content" is never a valid conclusion.
For each file: a. Read both versions completely b. Identify ALL differences, then classify each as:
/Users/xxx/.claude/ → /Users/sam/coding/wopal/wopal-workspace/.wopal/), variable additions (${WSF_WS}, ${AGENT_SKILLS_*}), error handling additions (|| true)c. If ANY differences remain after filtering out mechanical drift → those are user customizations. Merge them. d. If ALL differences appear to be mechanical drift → still flag as CONFLICT. The installer's hash check already proved this file was modified. Ask the user: "This file appears to only have path/variable differences. Were there intentional customizations?" Do NOT silently skip.
When the config directory is a git repo but the pristine install commit can't be found, use commit history to identify user changes:
# Find non-update commits that touched this file
git -C "$CONFIG_DIR" log --oneline --no-merges -- "{file_path}" | grep -v "WSF update\|wsf-install"
Each matching commit represents an intentional user modification. Use the commit messages and diffs to understand what was changed and why.
After writing each merged file, verify that user modifications survived the merge:
Line-count check: Count lines in the backup and the merged result. If the merged result has fewer lines than the backup minus the expected upstream removals, flag for review.
Hunk presence check: For each user-added section identified during diff analysis, search the merged output for at least the first significant line (non-blank, non-comment) of each addition. Missing signature lines indicate a dropped hunk.
Report warnings inline (do not block):
⚠ Potential dropped content in {file_path}:
- Missing hunk near line {N}: "{first_line_preview}..." ({line_count} lines)
- Backup available: {patches_dir}/{file_path}
Track verification status — add to per-file report: Merged (verified) vs Merged (⚠ {N} hunks may be missing)
Report status per file:
Merged — user modifications applied cleanly (show summary of what was preserved)Conflict — user reviewed and chose resolutionIncorporated — user's modification was already adopted upstream (only valid when pristine baseline confirms this)Never report Skipped — no custom content. If a file is in the backup, it has custom content.
Ask user:
wsf-local-patches/wsf-local-patches/ directory## Patches Reapplied
| # | File | Result | User Changes Preserved |
|---|------|--------|----------------------|
| 1 | {file_path} | Merged | Added step X, modified section Y |
| 2 | {file_path} | Incorporated | Already in upstream v{version} |
| 3 | {file_path} | Conflict resolved | User chose: keep custom section |
{count} file(s) updated. Your local modifications are active again.
</process>
<success_criteria>
tools
Configure ellamaka, a fork of OpenCode with wopal-space mode. MUST use for any task about ellamaka config, agent frontmatter, permission rules, model/provider selection, formatter settings, config loading order, or why config changes are ignored. Trigger on requests about ellamaka or opencode config files, agent permission overrides, restricting subagents, custom/plugin tool permissions (e.g. wopal_task_*), disabling tools, configuring providers or models, formatter setup, config precedence or layering, or debugging settings that do not take effect. Use this skill even when the user says "opencode" if the actual runtime, config path, or behavior is ellamaka. Prefer this skill whenever the answer depends on the difference between ellamaka and upstream opencode, including wopal-space config loading, plugin tool permissions, or agent frontmatter precedence.
development
Plan quality verification for dev-flow. Goal-backward analysis ensures plans WILL achieve their stated goal before execution burns context. ⚠️ MUST use when: (1) Reviewing Plan quality before approve (2) Wopal completes Plan writing and needs quality gate (3) User asks to "check plan", "verify plan", "review plan" (4) Plan enters planning status and needs pre-execution validation 🔴 Trigger automatically when Plan is ready for review, even if user doesn't explicitly say "review". Agent: rook (read-only verification subagent) Mode: verification, not execution
development
Review implementation results for goal achievement and code quality. Supports both Plan-backed review and planless diff review. ⚠️ MUST use when: (1) Wopal delegates rook to review fae implementation output, (2) Prompt contains "review_type: implementation", (3) Prompt contains changed code file list or Plan path + implementation scope, (4) Any code review request from Wopal. 🔴 Trigger even when user does not explicitly mention "review" if the task involves verifying implementation results. This skill is rook-exclusive (only rook agent can load it).
tools
Foundation rules for how Wopal collaborates with sub-agents such as fae and rook. ⚠️ MUST load before ANY delegation — covers delegation tool APIs, task lifecycle, notifications, status handling, and recovery. 🔴 Trigger: "delegate", "let fae implement", "fae task", "rook review", "check task status", "cancel task", "abort task", "agent collaboration", "委派", "让 fae 执行", "fae 任务", "rook 审查", "检查状态", or any intent to hand work to a sub-agent. 🔴 Never delegate without loading this skill first. Skipping it is serious negligence. Note: this skill does not include workflow-specific prompt templates such as dev-flow templates. Those belong to the corresponding workflow skills.