| name | contrib-ingest |
| description | Extract L1 contributor atoms from a GitHub subject's raw activity. Triggers after "tmem contrib raw <id>" or when the user says "ingest contributor", "profile <user>", "analyze how <user> works". This CREATES atoms from raw GitHub events — for synthesis use contrib-synthesize. |
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.
