Add PreToolUse:Edit guard for skills whose installed mirror differs from their git-tracked source

[DrumRobot]

Problem

Some Claude Code skills are installed locally as a mirror/cache copy (e.g. via a plugin marketplace), while the actual git-tracked source for that same skill lives in a separate repository. When an edit targets the local mirror copy directly, the edit tool succeeds silently — there is no error, no warning, and the file appears to be a normal tracked file. The change is invisible to git in that location and gets lost (or must be manually re-discovered and re-applied to the tracked source repository) unless the author happens to notice the mismatch before committing.

This has already happened at least once: a skill markdown file was edited directly in its local mirror location, and the mismatch (untracked orphan copy vs. the real tracked source in a different repository) was only discovered later, during preparation to commit — requiring the change to be reworked and ported into the actual source repository.

The general risk pattern: local skill-cache/mirror directory (read-only artifact from installation) vs. git-tracked source repository (the real place to make changes) — a project may already document this distinction in general project guidance, but documentation alone does not prevent the mistake from recurring, because nothing checks at edit-time which of the two locations is being edited.

Scope

1. Add a PreToolUse:Edit guard hook (in skills/hook-kit/resources/) that fires when the edit target path matches a known local skill-mirror directory pattern.
2. On match, the hook should check whether a git-tracked source for the same skill file exists in a separate, designated source repository (project-specific path/URL), and:
   • If a tracked source exists elsewhere, warn (not necessarily block) that the edit target may be an untracked mirror copy, and suggest verifying / editing the tracked source instead.
   • Keep the warning non-blocking by default, since some mirror-copy edits may be intentional (e.g. local experimentation) — full blocking behavior should be a configurable/opt-in escalation, not the initial default.
3. Add a fixture/self-test covering: (a) edit targeting the mirror path with a tracked source present elsewhere → warning fires, (b) edit targeting a path with no separate tracked source → no warning (normal skill authored directly in this repo).

Verification

Feature	Procedure	Expected Result
Mirror-edit warning fires	Simulate a PreToolUse:Edit payload targeting a known mirror-directory pattern for a skill that has a separate tracked source repo configured	Hook emits a warning reminding the author to check the tracked source before proceeding
No false positive on normal skill edits	Simulate an edit targeting a skill file that is authored directly in this repository (no separate mirror/source split)	Hook does not fire / allows silently
Non-blocking default	Confirm the guard's exit behavior is advisory (does not deny the tool call) unless explicitly configured to block	Edit proceeds after the warning is shown
Existing hook fixtures	Run the hook-kit self-test suite	All existing tests still pass