team skill sharing playbook

SKILL.md

---
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.