[Bug] Project-local skill override not loaded by runtime

Bug Description
Cowork project-local skill override not loaded by runtime

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.85
• Feedback ID: 6f238e1f-ec20-4975-b829-1f8a75e406be

Summary

Customized skills placed at the documented project-local path <project>/.claude/skills/<skill_name>/SKILL.md are not being loaded by the Cowork runtime. Instead, a read-only cached copy at /var/folders/.../claude-hostloop-plugins/<hash>/skills/<skill_name>/ is being loaded — even when the project-local copy contains substantial customizations.

This breaks the intended customization pattern for project-level skills and blocks team-specific skill iteration.

---

Environment

• Cowork mode (Claude desktop app)
• macOS
• Project folder with a .claude/skills/ directory containing a custom-edited skill
• The project's own README (at .claude/skills/README.md) documents the expected loading order: plugin → user → project, with project-level winning

---

Affected skill (specific repro case)

• Skill name: intel471-roadmap-generator
• Project-local path (editable): /Users/bhoffman/Documents/Claude/Projects/Intel 471 PM Agent/.claude/skills/intel471-roadmap-generator/
• Cached path being loaded (read-only): /var/folders/vp/3dm4yd9j695b8rx63wfdpsq00000gn/T/claude-hostloop-plugins/646ecf567032733a/skills/intel471-roadmap-generator/

The project-local SKILL.md is ~50 KB. The cached SKILL.md is ~39 KB. The ~10 KB delta is real, intentional customization (additional rules, exclusions, geometry, marker discipline updates, theme assignments) — none of which is reflected when the skill is invoked.

---

Reproduction steps

1. In a Cowork project, place a customized skill at <project>/.claude/skills/<skill_name>/SKILL.md.
2. Verify the project-local file has different content from any cached or plugin-installed version of the same skill.
3. In a fresh Cowork session opened against that project, invoke the skill (e.g., type /skill <skill_name> or trigger it via natural language).
4. Observe the Skill tool's response. It will report Base directory for this skill: /var/folders/.../claude-hostloop-plugins/<hash>/skills/<skill_name> — not the project path.
5. Compare the SKILL.md content injected into the agent's context against the project-local file on disk. They will differ.

---

Expected behavior

Per the documented loading order (and per standard Claude Code conventions), project-level skills should shadow plugin-installed and user-level skills with the same name. When invoked from within a project that has <project>/.claude/skills/<skill_name>/SKILL.md, the runtime should load that file.

---

Actual behavior

The runtime loads from the claude-hostloop-plugins cached copy. The project-local file is silently ignored.

Verification:

• File timestamps confirm the project-local file was edited recently (post-cache).
• diff between the two SKILL.md files shows substantial added content in the project-local copy (Atlas team exclusion, customfield_12101 Team field documentation, closed-beta label handling, row-dimension slice options, TLP marking rule, and more).
• None of those customizations are reflected in the agent's behavior when the skill is invoked.

Stronger evidence: project-local skill is not discovered at all

Follow-up test confirms the issue is not just shadowing — the project-local skill is invisible to the runtime:

1. Deleted the cached copy at /var/folders/.../claude-hostloop-plugins/646ecf567032733a/skills/intel471-roadmap-generator/.
2. Started a fresh Cowork session in the project (with the project-local copy still present at <project>/.claude/skills/intel471-roadmap-generator/).
3. Typed "generate roadmap" to invoke the skill.
4. Result: The runtime did NOT load the project-local copy. Instead it fell back to a generic skill from a different plugin (product-management:roadmap-update) — a skill that knows nothing about VPM, Verity471, or the customer's domain.

This proves the project-local skill at <project>/.claude/skills/<name>/ is not being registered as an available skill at all. The runtime appears to discover skills only from the claude-hostloop-plugins cache, never from the project-level path. The README's documented loading order (project > user > plugin) is not implemented.

---

Impact

• Skill iteration is impossible without re-bundling and re-installing through the plugin pipeline. For a non-developer user, that's not a viable workflow.
• The project-level customization pattern documented in Cowork's own skill README is non-functional. Users following the documentation will find their edits ignored.
• Significant time loss: hours of iteration where edits to project-local files appeared to land on disk but had no runtime effect. Users debug a non-bug for a long time before identifying the override layer as the problem.

---

Workarounds attempted (none satisfactory)

• Editing project-local files directly. Edits persist on disk but don't load at runtime.
• Writing to the plugin cache. /var/folders/.../claude-hostloop-plugins/... is mounted read-only; cannot be modified.
• Project Instructions redirect. Pasting the rules into Project Instructions works around the issue, but defeats the purpose of having a self-contained, distributable project-local skill — and forces every rule update to live in two places.

---

Asks

1. Confirm whether the project-local override at <project>/.claude/skills/ is supposed to shadow claude-hostloop-plugins cached skills with the same name. The project-level README states it should. The runtime behavior contradicts that.
2. If yes (intended to shadow): fix the discovery/load path to actually shadow.
3. If no (not intended to shadow): update the docs to reflect the actual behavior, and provide an alternative pattern for users who need to customize a skill for a single project.
4. In either case: surface the active load path more clearly in the UI so users don't have to grep the Skill tool's response to know which copy is being used.

---

Additional context

• The user's project also contains .claude/skills/README.md (written by the user) documenting the intended override order. This is what the user was relying on. Happy to share that file on request.
• Diagnostic outputs (file sizes, diff excerpts, timestamps) available on request.