Say your team uses Claude Code, Codex, and Pi. Someone catches an authorization bug and adds a useful rule to their review skill: check the denied request as well as the allowed one.
Where does that rule go next?
If it stays in one person's home directory, the next teammate's AI reviewer never gets it. Copy it into three tool folders and you now have three files to keep up to date.
I prefer keeping the checklist beside the code, where a pull request can change it. Each developer can use their preferred AI tool.
I maintain skillshare, the open-source tool used below. It manages skills, MCP connections, plugins, and hooks across supported tools. Start with one local review skill, then bring in the rest of your setup as needed.
A 20-second look
Watch the original demo (MP4). The original animation includes Cursor; this walkthrough uses Pi alongside Claude Code and Codex.
Start with one useful review task
For this example, the task is reviewing authorization and public API changes. A skill is a directory containing a SKILL.md file with a name, a description of when to use it, and the instructions.
Keep the first version short. A checklist with four rules your team agrees on is easier to review than a large prompt collection nobody has read.
On macOS or Linux, install the CLI with Homebrew:
brew install skillshare
Other installation options, including Windows, are in the installation instructions.
From the root of a project that doesn't already have a skillshare config:
skillshare init -p --targets claude,codex,pi
skillshare new team-review -p --pattern none
Choose the targets your team actually uses. -p keeps this setup scoped to the project. --pattern none creates the plain template.
Replace .skillshare/skills/team-review/SKILL.md with:
---
name: team-review
description: "Review a pull request for regressions in authorization and public API behavior. Use when asked for a team code review."
---
# Team review
Read the diff and the relevant callers before reporting findings.
- For authorization changes, check both allowed and denied requests.
- For public API changes, compare request and response shapes with existing consumers.
- Report only reachable bugs. Include the file, line, and an example that triggers each one.
- State which checks you ran and which behavior remains unverified.
Keep the review read-only. Propose fixes without changing files.
The description gives the tool a reason to load the skill. The body tells it what to do once loaded. Replace the rules with checks that matter to your codebase.
Inspect it, then sync it
Run these in order, stopping if a step fails:
skillshare audit -p
skillshare sync -p --dry-run
skillshare sync -p
skillshare status -p
The audit scans the skill for suspicious content. Read the instructions yourself too, especially when you start installing third-party skills; a clean scan isn't a guarantee of safety.
The dry run previews the sync. With the default merge mode on macOS and Linux, the real sync creates per-skill symlinks into the configured target directories. The checklist stays in .skillshare/skills/team-review/.
For this setup, the target directories are .claude/skills for Claude Code, .agents/skills for Codex, and .pi/skills for Pi. Each team-review link points back to the same project skill.
Copy mode is available for environments that need regular files; run sync again after edits when using it.
Review checklist changes in the same PR
Suppose a bug fix reveals a missing check. Add that check to team-review/SKILL.md in the same pull request as the fix. A reviewer can ask whether the new instruction would actually have caught the bug.
Commit the project config, the local skill, and the generated .skillshare/.gitignore using your normal Git workflow. Keep generated target links out of version control. If you later add remote skills, include their lockfile as well. The project setup guide covers what belongs in Git.
After a teammate clones or pulls the project, this local-only example needs:
skillshare audit -p && skillshare sync -p
Once the project declares remote skills, install those before auditing and syncing:
skillshare install -p && skillshare audit -p && skillshare sync -p
Git carries the local checklist and configuration. The sync step makes them available to the configured tools on that machine.
Bring MCP, plugins, and hooks along too
The review checklist is only part of a working setup. Changing tools can also mean re-entering MCP connections, finding the right plugin package, and rebuilding hooks. Skillshare manages these resources alongside skills, with separate previews for what each tool receives.
MCP: define a connection once
Keep a server's command or URL in one definition, choose its receiving tools, and let skillshare write their native configuration formats. The MCP setup guide covers adding a connection and importing one you already use.
Claude Code, Codex, and Pi are supported. Pi uses its built-in MCP support and needs Pi 0.99.0 or later. Keep credentials out of the project repository and use environment references where appropriate. Login, OAuth, and tool approvals still happen in the receiving agent.
Plugins: keep the package together
A plugin can bundle skills, MCP connections, hooks, and supporting files. Use the plugin manager to discover a source, select compatible tools, and review the installation. Pi packages are supported too.
Choose a package built for the target tool. Skillshare doesn't turn a Claude plugin into a Pi extension. Project plugin management is supported for Claude Code and Pi; Codex plugin management uses global scope. Native project trust still applies.
Hooks: keep the tool's own behavior
Hooks can run a project check at an agent event or load a native extension. Skillshare keeps named hook definitions, previews their destinations, and writes the relevant configuration or files.
Event names and payloads remain tool-specific. For Pi, supply extension code that matches your installed Pi version; skillshare writes the extension file without translating another agent's hook runtime. Review and test that code in Pi before relying on it.
After configuring these resources, preview them separately:
skillshare sync mcp -p --dry-run
skillshare sync hooks -p --dry-run
skillshare sync plugins -p --dry-run
For the configured project resources, skillshare sync --all -p includes skills, agents, extras, MCP, and hooks. Plugins are a separate operation: skillshare sync plugins -p. Review the preview and respect the supported scope before applying either.
Check the reviewer against a known bug
Open a configured tool and ask:
Use the team-review skill to review this diff. Keep it read-only and show a concrete input for each finding.
Try it against a past authorization bug whose cause you know. Check whether the tool finds the missed denied-request case, cites the right code, and distinguishes executed tests from assumptions. Verify that the skill is available in each tool you use; restart the tool if needed after syncing.
Sharing the instructions doesn't make different models produce identical reviews. It gives your team one checklist to inspect and improve when a review misses something.
skillshare is on GitHub. If you try this, I'd like to hear which project rule you put in your first shared skill. A star helps other developers find the project if it earns a place in your workflow.
Top comments (0)