/contrib-ingest

name: contrib-ingest
description: Internal phase — extract L1 contributor atoms from a GitHub subject's raw activity. Invoked by contrib-profile / `/contrib ingest`.
user-invocable: false

Contributor Ingest

Turn one subject's raw GitHub activity into evidence-linked L1 atoms across the 11 fixed dimensions. You do all classification — no external LLM.

Workflow

1. Fetch raw events

tmem contrib raw <subject-id>

This prints `{commits, prs, reviewCommentsGiven, reviewThreadsReceived, issues}` (bots/forks/generated files already filtered):

• `commits` — the subject's commits across ALL branches (default branch + every

PR's head branch), deduped by sha.

• `prs` — PRs the subject authored (all branches, via the search API).
• `reviewCommentsGiven` — review comments the subject WROTE on others' PRs.
• `reviewThreadsReceived` — comments on the subject's own PRs (with `is_subject`

flagging their own replies vs reviewers').

If it errors with "gh not found" or auth failure, tell the user to run `gh auth login` and stop.

2. Classify into the 11 dimensions

**Before classifying, read `references/dimensions.md`** — the per-dimension rubric with good-vs-shallow atom examples, the Ousterhout lens for `solve`, and evidence-strength criteria. Classification quality depends on it; the summary below is only the map.

For each meaningful signal, write ONE atom tagged with exactly one dimension. Never invent style — every atom needs at least one evidence link (`PR#<n>` or commit sha).

**Technical Craft**

• `idea` — how they frame problems / pick work. Source: issue bodies (repro,

expected-vs-actual, root-cause vs symptom), PR "why" sections.

• `plan` — PR decomposition & scoping. Source: PR size (additions+deletions),

commits-per-PR, whether each PR is self-contained.

• `solve` — coding/refactor patterns. Read diffs through Ousterhout's lens: deep

vs shallow modules, information leakage, strategic vs tactical, errors designed out of existence.

• `craft` — review thinking in `reviewCommentsGiven`: do they cite the why,

weigh alternatives, label severity ("Nit:", "Optional:").

**Collaboration & Influence**

• `comms` — commit message quality (subject ≤50 chars, body explains why,

imperative mood) and PR description clarity.

• `mentor` — `reviewCommentsGiven` that teach/explain vs cosmetic-trivia floods.
• `conflict` — `reviewThreadsReceived`: in their own replies (`is_subject:true`)

do they update their view, push back constructively, avoid needless blocking.

**Outcomes & Ownership**

• `scope` — cross-repo/cross-area reach, size of areas touched.
• `ownership` — test-inclusion rate, concentration on components.
• `execution` — revert rate, post-merge rework, review coverage of merged work.

3. Write each atom

tmem contrib upsert-atom --json '{"record_id":"<id>:<dim>:<hash>","subject_id":"<id>","dimension":"plan","content":"Splits features by concern; median PR ~280 LOC, ~5 commits each.","evidence":["PR#1234","PR#1240"]}'

• `record_id` must be stable (e.g. `<subject-id>:plan:<short-hash-of-claim>`) so

re-ingest upserts instead of duplicating.

• Keep `content` to one concrete, emulable observation.

4. Guardrails (do NOT violate)

• Tone/sentiment is descriptive only — never a score or ranking.
• No vanity claims (stars, streaks, total commits, raw LOC counts).
• Skip a dimension rather than fabricate a weak claim. If a subject has <50 PRs,

note which dimensions are "insufficient data" in the atom content.

5. Report

Tell the user how many atoms were written per dimension and any dimensions left empty for lack of evidence.