back
loading skill details...
spread skills across a team using share and fork primitives. when to share (after the skill has proven value), how to share (team-only vs public), how to fork (clone-and-customize without losing the base), and how to track adoption via skill-roi. trigger when the user wants to roll out a skill to their team or asks "how do i let my teammates use this".
---
description: spread skills across a team using share and fork primitives. when to share, how to share, how to fork, how to track adoption. trigger when the user wants to roll out a skill to their team or asks "how do i let my teammates use this".
---
# team skill sharing playbook
the full loop for getting a useful skill from "i made it" to "the whole team uses it daily". covers when to share, which mode to share in, how teammates fork-and-customize without breaking the base, and how to track whether the share actually drove usage.
## intent
a skill that only one person uses captures 1% of its potential value. the skill graph compounds when multiple people invoke the same skill and the usage data flows back to improve ranking. sharing is the multiplier. but sharing too early (before the skill has proven value) creates noise that drowns out the real signal.
## inputs
- a skill you have saved and used at least 5 times yourself
- a clear sense of which teammates would benefit
- the team's communication channel (slack, email, etc) for the rollout
## procedure
### step 1, qualify the skill is ready to share
a skill is ready to share when:
- you have used it at least 5 times yourself
- it has stable trigger phrases (you have not edited them in the last week)
- the output is something you would forward to a teammate as-is
- it does not encode anything specific to your account (your personal email, your one customer's name, your private gist url)
if any of those are not true, iterate first. share a half-baked skill once and your team will not install the second one you share.
### step 2, generate the share link
```
/implexa:share-this
```
pick the mode:
- **team-only**: link is gated to same email domain. only @yourcompany.com addresses can install. right default for internal team rollouts.
- **public**: anyone with the link can install. right for slack, twitter, linkedin distribution. once public, you cannot retract installs already made.
### step 3, send the link with context
do not just paste the link. say what the skill does, who it is for, and one example of when to invoke it:
> sharing the "weekly status email" skill for the eng managers channel. it pulls this-week's commits, formats yesterday/today/blockers, drops it in your draft folder. invoke before friday standup. one-click install: <link>
context is the difference between 2 installs and 12 installs.
### step 4, track installs and adoption
```
/implexa:skill-roi
```
after a few days, check the skill's roi dashboard:
- unique users (how many teammates installed)
- invocations (how often it is run)
- attributed outcomes (deals closed, placements, etc - if the skill is GTM)
if installs are flat after 5 days, the share message was wrong. resend with a different framing or a concrete example.
### step 5, encourage fork-and-customize
teammates with adjacent-but-not-identical workflows should fork, not request edits to the original:
```
/implexa:fork <skill-slug>
```
the fork creates a new org skill they own, lineage-tracked back to your original. they can edit freely without affecting your version. the dashboard shows the fork tree so you can see who built on what.
forks beat edit-requests because:
- your original keeps working for everyone who installed it
- the forker can iterate without coordinating with you
- if their fork ranks higher, the dashboard surfaces that and the team naturally migrates
### step 6, retire your version if a fork wins
if someone forks your skill and their version is clearly better (higher score, more usage, more attributed outcomes), do not defend the original. install their fork yourself and archive yours. the skill graph rewards quality, not authorship.
## decision points
- **the skill encodes your personal credentials or one customer's data**: do not share. fork into a sanitized template version first.
- **the skill is highly specific to your role (one sales rep's exact workflow)**: share with team-only, narrow the audience in the message ("for the smb segment ae team"). do not blast it to everyone.
- **the skill is broadly useful beyond your team**: share publicly, post on linkedin or in the implexa community. public shares contribute to the cross-vendor index and drive inbound to your org's other skills.
- **a teammate asks for an edit that contradicts your use case**: tell them to fork. do not edit shared skills based on one person's preference.
## output contract
a shared skill with:
- a sent share link with framing context
- tracked installs over 7-14 days
- a fork tree showing any customizations
- clear attribution back to you as the original author (lineage)
## outcome signal
success means: 3+ teammates installed within 7 days AND at least 50% of installs ran the skill at least once in the first 14 days. if installs are high but runs are zero, the framing message overpromised. if installs are low, the message was weak or the audience was wrong.
## notes
- share once a skill is proven, not as you build it. sharing too early teaches your team to ignore the next share.
- fork is the right mechanic for customization, not edit-requests. the lineage tracking is a feature, not a bug.
- skill-roi is what makes the share loop visible. without it you are guessing whether sharing worked.
don't have the plugin yet? install it then click "run inline in claude" again.
added explicit edge cases (auth failures, rate limits, zero invocations, network timeouts), clarified decision logic with if-else branches, documented implexa platform inputs and permissions, expanded procedure steps with input-output contracts, and refined voice to match implexa standards.
the full loop for getting a useful skill from "i made it" to "the whole team uses it daily". covers when to share, which mode to share in, how teammates fork-and-customize without breaking the base, and how to track whether the share actually drove usage.
a skill that only one person uses captures 1% of its potential value. the skill graph compounds when multiple people invoke the same skill and the usage data flows back to improve ranking. sharing is the multiplier. but sharing too early (before the skill has proven value) creates noise that drowns out the real signal. use this skill when you have built something that works, your teammates would benefit, and you want to roll it out systematically with feedback loops.
validate that a skill is ready to share. a skill is ready when:
if any of those are not true, iterate first. share a half-baked skill once and your team will not install the second one you share.
input: skill slug, your use history, trigger phrase stability. output: decision to share or iterate further.
run the share command in your implexa workspace:
/implexa:share-this
pick the mode based on intended audience:
note: team-only shares can be upgraded to public later. public shares cannot be made team-only again.
input: skill slug, mode choice (team-only or public). output: shareable link, mode confirmation, lineage metadata.
do not just paste the link. say what the skill does, who it is for, and one example of when to invoke it. example framing:
sharing the "weekly status email" skill for the eng managers channel. it pulls this-week's commits, formats yesterday/today/blockers, drops it in your draft folder. invoke before friday standup. one-click install:
context is the difference between 2 installs and 12 installs. include: the skill's use case, the intended audience, a concrete trigger moment, and the install link.
input: share link, audience list, example scenario. output: message sent via slack, email, or team channel with framing and link.
after the share message goes out, check the skill's roi dashboard:
/implexa:skill-roi <skill-slug>
monitor these metrics:
input: skill slug, time window (7-14 days post-share). output: roi dashboard with install, invocation, outcome, and fork metrics.
if installs are flat after 5 days, the share message was wrong. resend with a different framing, a different audience segment, or a more concrete example.
edge case: if your team uses implexa but adoption dashboards are disabled, ask your workspace admin to enable skill-roi tracking. without it you are guessing whether sharing worked.
teammates with adjacent-but-not-identical workflows should fork, not request edits to the original. when a teammate asks for a variant, point them here:
/implexa:fork <skill-slug>
the fork creates a new org skill they own, lineage-tracked back to your original. they can edit freely without affecting your version. the dashboard shows the fork tree so you can see who built on what.
forks beat edit-requests because:
input: skill slug, teammate who wants to customize. output: forked skill (new slug), lineage link to original, edit permissions to forker.
if someone forks your skill and their version is clearly better (higher score, more usage, more attributed outcomes), do not defend the original. install their fork yourself and archive yours. the skill graph rewards quality, not authorship.
input: comparison of original and fork metrics (invocations, outcomes, rating). output: decision to archive original, install announcement of the winning fork.
the skill encodes your personal credentials or one customer's data: do not share. fork into a sanitized template version first. strip out api keys, oauth tokens, customer names, account ids, and personal email addresses. then share the sanitized version.
the skill is highly specific to your role (one sales rep's exact workflow): share with team-only, narrow the audience in the message ("for the smb segment ae team"). do not blast it to everyone. consider forking a generic version first.
the skill is broadly useful beyond your team: share publicly, post on linkedin or in the implexa community. public shares contribute to the cross-vendor index and drive inbound to your org's other skills.
a teammate asks for an edit that contradicts your use case: tell them to fork. do not edit shared skills based on one person's preference. edit your version only if the change benefits the majority of users.
share link is not generating or authentication fails: check that your workspace has share permissions enabled and that you have not exceeded rate limits (implexa enforces 100 shares per day per workspace). if this persists, contact your workspace admin.
skill-roi dashboard shows zero invocations after 5 days despite installs: the install message overpromised or was too vague. resend with a more specific use case and a concrete trigger phrase. if still zero, the skill may not solve a real problem. ask installers for feedback.
network timeout or api error during fork: retry the fork command after 30 seconds. if the error persists, check your workspace connection and implexa service status. your original skill remains unaffected.
a successfully shared skill delivers:
data location: all metrics visible in the skill-roi dashboard under the skill slug. fork tree visible in the skill details page. lineage links included in every install confirmation.
success means: 3+ teammates installed within 7 days AND at least 50% of installs ran the skill at least once in the first 14 days. if installs are high but runs are zero, the framing message overpromised. if installs are low, the message was weak or the audience was wrong. if forks outnumber installs of the original, the original design had gaps but the idea was sound; celebrate the fork wins and retire gracefully.
secondary signals: attributed outcomes (deals closed, cycle-time improved, etc.) for gtm and ops skills. fork adoption (teams building on your work) signals that the base skill solved a real problem. comments and feedback in the roi dashboard guide the next iteration.
credits: originally written by implexa. refined to clarify edge cases, decision logic, external connections, and voice consistency.