/contrib-profile

name: contrib-profile
description: Orchestrator for Contributor Intelligence. Trigger when the user pastes a GitHub profile/repo URL or handle and asks to profile, analyze, learn from, or study an engineer (EN/VI — "phân tích người này", "học từ người này"). Runs add→ingest→build→playbook end-to-end via the per-phase contrib skills.

Contributor Profile — A→Z orchestrator

The friendly front door to the `/contrib` feature. The user shouldn't have to know the subcommand sequence — they give you a target and an intent, and you either run the whole pipeline for them or walk them through it.

1. Figure out the target

Accept any of these and normalise to `<github_user>` + `<owner/repo>`:

• a profile URL — `https://github.com/<user>`
• a repo URL — `https://github.com/<owner>/<repo>`
• a handle — `<user>`, `<owner>/<repo>`, or an existing subject id `<user>@<repo>`

If you only have a **user** (no repo), the profile needs a repo to scope ingest. Find their most relevant repo instead of guessing:

gh api "users/<user>/repos?sort=pushed&per_page=20" --jq 'sort_by(-.stargazers_count) | .[] | select(.fork|not) | "\(.full_name)\t★\(.stargazers_count)"' | head

Pick the top owned repo where they actually **author code** — by stars/activity. Skip forks, and skip non-code repos that rank high on stars but carry no engineering signal (awesome-lists, dotfiles, docs/blog repos). If it's genuinely ambiguous (several comparable code repos, or they're mainly a reviewer), show the short list and ask which one rather than guessing.

2. Preflight

gh auth status

If `gh` is missing or unauthenticated, stop and tell the user to run `gh auth login`. Nothing downstream works without it.

3. Decide the mode

• **Do-it-all** (default when the user said "profile / analyze / learn from"):

run the whole pipeline yourself, reporting progress between phases.

• **Guide** (when the user asked "how do I use this" or wants to drive): lay out

the steps below as a checklist and run only what they ask for, one at a time.

4. Run the pipeline (do-it-all)

Execute in order. Each phase has a dedicated skill — invoke it, don't reinvent it.

1. **Declare** (idempotent — skip if already a subject):

   tmem contrib add <user> <owner/repo>

2. **Ingest** — invoke the **contrib-ingest** skill, which fetches raw activity (`tmem contrib raw <id>`) and writes 11-dimension atoms. Mention it can take a minute or two for an active engineer (per-PR calls). 3. **Consolidate** — invoke the **contrib-consolidate** skill to turn the atoms into the L3 persona. 4. **Synthesize** — invoke the **contrib-synthesize** skill to produce the learnable playbook (and exemplar quotes).

Then present, in this order:

• a 2–3 sentence summary of how this engineer works,
• the **learnable playbook** (the emulable heuristics — the payoff),
• a pointer to what's next (below).

5. Offer the next moves

After the first profile, surface the high-value follow-ups so the user knows the feature's range — pick what fits their intent, don't dump all of them:

• `tmem contrib persona <id>` — the full 11-dimension dossier with evidence.
• **You vs them** — invoke contrib-synthesize's compare against the user's

existing self-persona (`tmem persona`); no need to ingest the user from GitHub.

• **Capability model** — profile a 2nd engineer, then `tmem contrib capabilities`

to see what top engineers share (needs ≥2 built personas).

• `tmem contrib trajectory <id>` — their per-year cadence/style arc.
• `tmem contrib team add/capabilities` — group several into a team model.

6. Guardrails

• This skill only **orchestrates** — the per-phase skills own classification and

synthesis quality (and their `references/` rubrics). Don't duplicate their logic.

• Everything is evidence-linked and stored under `<global>/contributors/` — the

self-memory feature is never touched.

• Be honest about scope: cadence/style is measured, PR diff size is not.