/colleague-distillation

name: colleague-distillation
description: Distill a colleague into a reusable AI skill (work + persona) using tool connections — Slack, Slack AI, Jira, GHE, Bitbucket, Confluence, SharePoint, Teams, Outlook, Notion, Linear, Google Docs, and more — without manual paste. Use when the user wants a colleague skill, digital twin of a coworker, or capture of someone's technical voice from workplace systems. Requires tool_connections + 10xProductivity verified_connections (or equivalent .env).

> **10xProductivity skill:** This file is the Claude Code entry point for colleague distillation when working in this repo.

Colleague distillation (tool-backed)

Purpose

Produce a **colleague skill**: structured **work knowledge** (systems, standards, review style) plus **persona** (tone, decisions, interpersonal habits), using **APIs and search** already wired in **tool_connections** / **10xProductivity** — not hand-pasted exports.

Output layout matches the open **[colleague-skill](https://github.com/titanwings/colleague-skill)** convention so results can coexist with that generator:

• `colleagues/{slug}/work.md`
• `colleagues/{slug}/persona.md`
• `colleagues/{slug}/meta.json`
• `colleagues/{slug}/SKILL.md` (merged invocable skill)

**Optional:** Clone colleague-skill for its `prompts/work_analyzer.md`, `persona_analyzer.md`, `work_builder.md`, `persona_builder.md` if you want identical extraction templates; this skill defines *what to fetch* and *where to write*.

---

Prerequisites

1. Load the relevant 10xProductivity connection docs under **`tool_connections/`** and any allowed private recipes under **`$TENX_PRIVATE_DIR/personal/`**. 2. Load **`$TENX_PRIVATE_DIR/verified_connections.md`** — only call tools listed there (or documented in `10xProductivity/tool_connections/` / `personal/`). 3. For Jira, use the verified Jira connection documentation and recipes in this repo. 4. **Credentials:** `source` or load **`$TENX_PRIVATE_DIR/.env`** (or project `.env`) before `curl` / scripts. Never commit secrets.

---

Cursor vs Claude Code

| Environment | Where to put generated files | How this skill is loaded | |-------------|------------------------------|---------------------------| | **Cursor** | Repo root: `colleagues/{slug}/` | `.cursor/skills/colleague-distillation/SKILL.md` | | **Claude Code** | Same `colleagues/{slug}/` under the active project | `.claude/skills/colleague-distillation/SKILL.md` |

Use the **same** slug and folder layout in both; only the skill *install path* differs.

---

Slug rules

• **Slug** = unique directory name: `michael_donnelly`, `michael_donnelly_2`, … (ASCII, underscores).
• **Collisions:** Same slug **overwrites** an existing colleague folder. Disambiguate with `_2`, `_3`, or a distinct codename.
• Store display name and aliases in **`meta.json`**, not only in the slug.

---

Phase 1 — Resolve identity

Before searching, pin **who** the colleague is:

1. **Active Directory** (if configured in tool_connections): resolve **email**, **manager chain**, **department** — use for Jira/Slack account mapping when IDs are unknown. 2. **Slack**: From `verified_connections.md`, use Slack API recipes to resolve **`@handle` → user id** (`U…`) for `from:@user` / `from:U…` search syntax. 3. **Jira**: Resolve **accountId** (assignee, reporter, comment author) via Jira user search API — see `jira` skill.

Record: `slack_user_id`, `jira_account_id`, `email`, `ad_cn` (as available).

---

Phase 2 — Pull source material (priority order)

Gather **raw excerpts** (save under `colleagues/{slug}/knowledge/raw/` as `.md` or `.json` snippets) with **source + URL/ticket/channel + date** in each chunk header. Cap volume per source (e.g. last 90–180 days) unless the user asks for full history.

Tier A — Highest signal for “how they work and sound”

| Source | What to fetch | Why | |--------|----------------|-----| | **Slack** | `search.messages`: `from:user`, date range, `in:#relevant-channels`; thread URLs they participated in | Tone, decisions, pushback, on-call voice | | **Slack AI** (Slackbot DM) | Targeted questions: e.g. “Summarize how [Name] argues for design decisions in threads about [topic]” | Fast synthesis over large Slack corpus | | **Jira** | JQL: `assignee`, `reporter`, `comment ~`, component/team filters; descriptions, comments, status transitions | Work scope, prioritization, written precision | | **GHE** | PRs **authored**, **reviewed** (`/pulls`, review comments API); issues filed | Code review voice, technical standards | | **Bitbucket Server** | Same pattern as GHE when Bitbucket Server is the primary Git host | Same |

Tier B — Depth and standards

| Source | What to fetch | Why | |--------|----------------|-----| | **Confluence** | Pages **created by** or **substantially edited by** them (CQL / search); team runbooks they own | Long-form standards, architecture voice | | **Notion** | Pages they authored or commented on | Long-form async thinking, project context | | **SharePoint** | Docs and wikis they own or edited | Standards docs, team handbooks |

Tier C — Optional / role-specific

| Source | When | |--------|------| | **Google Drive** | Docs/slides they own (if verified in `verified_connections.md`) | | **PagerDuty** | Oncall/incident behavior | | **Console / IAHub** | Release/ops ownership if building an ops-heavy persona | | **Microsoft Teams / Outlook** | If verified — email/thread tone (handle consent carefully) | | **Gmail (personal recipe)** | Only if user explicitly wants email and connection is verified |

Tier D — Do not rely on for persona without extra care

• Raw **git blame** without PR context — noisy.
• **HR systems** — use only for title/team if needed, not personality inference.

---

Phase 3 — Synthesize (work vs persona)

**Work (`work.md`):** Systems, stacks, coding/review conventions, doc habits, Jira/workflow patterns, incident/release behavior — cite **patterns**, not one-off jokes.

**Persona (`per