Allow ~/.jcode/skills to symlink shared skills instead of copying them

What happens now

On first run, jcode appears to copy every skill from ~/.agents/skills (and/or ~/.claude/skills) into ~/.jcode/skills as independent files. On my machine all 64 entries in ~/.jcode/skills/ are real directories, byte-copies of ~/.agents/skills/, created at the same timestamp as mcp.json/servers.json (first launch of this version). By contrast, ~/.claude/skills/<skill> is a symlink into ~/.agents/skills/<skill>.

Problem

The copies silently drift. I edited reviewing-prs/SKILL.md in ~/.jcode/skills; the .agents/.claude copies stayed on the old version. There's no indication the jcode copy is a fork, and no way to keep them converged short of manual cp/ln.

Request

Offer a way to have ~/.jcode/skills reference shared skills by symlink rather than copy, e.g.:

• a config.toml option (e.g. [skills] link = true or a skills_dir pointer), and/or
• prefer symlinking when the source is already a symlink farm like ~/.agents/skills.

Context / possible rationale

This mirrors the documented MCP behavior ("one-time import... then jcode-owned, not synced"). I suspect copying is intentional for edit safety, so editing a jcode skill doesn't mutate the shared .agents source used by other harnesses. If so, a symlink mode should be opt-in with that caveat documented. For users who treat .agents/skills as the single source of truth, copy-on-first-run is just duplication and drift.

Environment

jcode v0.84.0 (57d587899), macOS aarch64.

No files, tests, or entry points are named. Start by locating the skill import logic and config.toml handling, then determine how an opt-in symlink mode should interact with existing copy behavior. Done means shared skills can be referenced without silent copies, with the safety caveat documented and relevant behavior covered by tests.