some of the agent installs aren't working like cursor. can we update the repo to follow the smae skills install as this one /Users/alisha/Projects/cc-skills-golang

Layout now matches cc-skills-golang:

• skills/{explain,search,session-handoff}/SKILL.md at repo root (git-tracked rename, history preserved)
• .claude-plugin/plugin.json + .claude-plugin/marketplace.json (source now ./)
• .cursor-plugin/plugin.json with "skills": "./skills/"
• .codex-plugin/plugin.json at root with "skills": "./skills/"
• .opencode/plugins/entire.js resolves to ../../skills
• .agents/plugins/marketplace.json source ./
• GEMINI.md imports from ./skills/session-handoff/SKILL.md
• plugins/ directory removed
• README.md install section rewritten with per-agent collapsible sections (Claude Code, Cursor, Gemini, OpenCode, Codex, Copilot)

The git clone ... ~/.cursor/skills/entire flow for Cursor will now work because skills live at the conventional top-level skills/ path. Want me to commit and push, or test a specific agent install first?

Committed as 41369d3 on alisha/refactor.

One heads-up: gemini-extension.json still has "contextFileName": "GEMINI.md" but GEMINI.md was deleted — Gemini CLI may warn or fail to load context. Want me to drop that field, or restore the file?

Three general strategies — pick based on agent:

A) Symlink from local workdir (fastest, no push needed)

Skip install flows entirely; point each agent's auto-discovery dir at your working copy:

Edit files → agent picks up changes immediately. Remove the symlink when done.

B) Install from the branch on a remote (tests the real install path)

Push first:

Then per-agent:

C) Install from a local clone (offline, tests install mechanics)

What I'd actually do

1. Push alisha/refactor (cheap, isolated from main).
2. Symlink for Cursor/Codex/Copilot — that's where the bug was, and symlinks give you the tightest iteration loop.
3. Branch-ref install for Claude Code / Gemini / OpenCode — those go through package-manager-ish flows, so you want to exercise the real code path at least once.

Want me to run any of these? (I'd push the branch but leave the actual installs for you to trigger interactively.)

Short answer: no, not strictly required — but bumping is cheap insurance and I'd do it.

Why it's probably fine without a bump

The plugin name (entire) is unchanged and all manifests are internally consistent. On update:

• Marketplace/package installs (Claude Code, Gemini, OpenCode) re-read the manifest and get the new skills path — nothing pinned to the old layout.
• Git-clone installs (Cursor, Codex, Copilot) pull the commit; .cursor-plugin/plugin.json now points at ./skills/, so auto-discovery lands in the right place.

There's no user state tied to plugins/entire/skills/ that would silently break.

Why I'd still bump

It's a structural change, and 0.x convention treats minor bumps as "may break things." Bumping to 0.2.0:

• Signals "something moved" in changelogs / npm outdated / gemini extensions update output.
• Lets anyone who pinned to v0.1.0 (e.g. the OpenCode pin example in .opencode/INSTALL.md uses #v0.1.0) opt in deliberately.
• Makes rollback obvious if it does break someone.

Version lives in 5 files to keep in sync:

• .claude-plugin/plugin.json
• .claude-plugin/marketplace.json (plugin entry)
• .cursor-plugin/plugin.json
• .codex-plugin/plugin.json
• gemini-extension.json

The actual breaking risk you should fix regardless

GEMINI.md was deleted but gemini-extension.json still has "contextFileName": "GEMINI.md". Gemini users running gemini extensions update entire will hit a missing-file error. That's a real break — version bump won't save them.

Want me to bump to 0.2.0 across all 5 manifests and drop the stale contextFileName field?

Committed as 6210dec. All 6 version fields now at 0.2.0, and the stale contextFileName is gone.