collab-proof

---
name: collab-proof
description: Use when the user wants a session retrospective or AI-contribution analysis: what Amara contributed vs. what the developer drove. Triggers on 'what did you do this session', collaboration evidence.
category: Engineering
version: 1.0.0
tools: []
---

# collab-proof

Surface AI-collaboration evidence a developer didn't consciously record — what shipped, what was actually figured out, and Amara's real contribution vs. the developer's — as a structured chat summary at the end of a work session. Three-layer pipeline: signal detection, four-frame intent scoring, then structured output.

**Use when:** the user wants a session retrospective, an AI-contribution analysis, or asks "what did you actually do this session" / collaboration evidence — often at the end of a coding session.

Ground every judgment in the actual conversation and any code/diff summary available in context — recent commits, file changes discussed, and the back-and-forth. Never fabricate.

## Layer 1 — Signal detection

Classify the session at the highest level that matches:

**HIGH** (full write-up) — a new file was created; 4+ files were modified; an explicit option comparison happened ("vs", "instead of", "chose X over Y"); design discussion ran 15+ exchanges; OR a bug was fixed **with root-cause diagnosis** in the conversation (not just "fixed X" but "the bug was caused by Y because Z").

**Bug-fixing override:** even a single-file fix classifies as HIGH if the conversation contains a root-cause explanation ("the bug was...", "this happened because..."), a diagnosis process ("I checked...", "turned out..."), or fix rationale ("chose this because... instead of X"). File count doesn't matter for bugs — a well-diagnosed single-file fix outweighs a 10-file feature with no discussion.

**MEDIUM** (one-line log only) — 1–3 files modified with no root-cause discussion, or a minor feature added with no tradeoffs discussed.

**LOW** (say nothing beyond "Routine session — nothing recorded") — no code changes (planning/discussion only), or a single trivial change with no context ("fix typo", "rename variable").

## Layer 2 — Four-frame intent scoring

Score each frame 0.0–1.0 against the conversation and any diff summary:

- **Frame A — Technical** (code churn complexity): 1.0 new module/complex logic (state machine, novel algorithm); 0.5 existing function modified or simple endpoint added; 0.1 typo/comment/plain-text edit.
- **Frame B — Uncertainty** (developer doubt signals): 1.0 code written then rolled back, explicit doubt expressed, a revert; 0.5 advice sought mid-implementation, 2+ revisions on the same area; 0.0 uninterrupted directive execution.
- **Frame C — Fork** (decision-branch presence): 1.0 two-plus alternatives explicitly compared; 0.5 a tradeoff mentioned without explicit comparison; 0.0 a single standard approach with no alternatives considered.
- **Frame D — AI contribution** (actual impact): 1.0 identified a bug/edge case the developer hadn't noticed and proposed the fix; 0.6 generated structural boilerplate/skeleton that materially accelerated execution; 0.2 reformatted or transcribed developer-directed code with no independent contribution.

**Pruning:** drop any frame scoring below 0.4 — **except** the High-Speed Execution Guard: if Frame A ≥ 0.8 AND Frame D ≥ 0.6, do not prune and do not silence the session even with B = C = 0. Classify immediately as `FEATURE_BUILDING`, signal HIGH — zero uncertainty in a fast session is a feature, not a reason to discard it.

**Intent classification** from surviving frames:

| Surviving frames | Dominant intent | Meaning |
|---|---|---|
| A high + D mid-high (B, C low) | `FEATURE_BUILDING` | High-velocity feature generation, AI scaffolding |
| B high + A/D high | `BUG_FIXING` or `STUCK` | Active debugging or unresolved looping |
| C high + A high | `REFACTORING` or `EXPLORING` | Architecture exploration, weighing alternatives |
| All frames < 0.4 | `FLOW_STATE` or LOW | Routine typing — stay silent unless Layer 1 was HIGH |

On a tie, pick the intent with the highest combined frame score, and record the runner-up — it belongs in the session narrative rather than being discarded.

Before writing the Layer 3 output, resolve the frame scores, the pruned-frame list, the chosen intent, the signal level, and a one-sentence calibration note (e.g., which exception rule fired) into a compact internal summary — this keeps the narrative grounded in the actual scores rather than vibes.

## Layer 3 — Output

**HIGH signal** — present in chat (do not write files):

A decision entry per real fork (only if Frame C confirms alternatives genuinely existed — never fabricate one): Context (what forced the choice), Decision, Alternatives considered, Reasoning (prefix "inferred:" if reconstructed), AI contribution split into Identified / Suggested / Developer-driven, Intent class, Signal score, Outcome (implemented/pending/reversed).

For `BUG_FIXING` intent, use instead: Root cause (the WHY, not just the what), Symptom, Fix, Why this fix, Alternative fixes considered, the same AI-contribution split, Outcome (fixed/workaround/deferred).

Follow with a short session narrative covering: what shipped (grounded in the actual changes discussed), what was figured out (the Frame B/C reasoning and tradeoffs a developer typically forgets), where it got hard (Frame B findings — uncertainty, reverts, stuck moments), an honest AI-contribution paragraph (Frame D synthesis, calibrated — neither overclaimed nor dismissed), and next steps inferred from what's obviously incomplete.

If the platform surfaces token/cache usage for the session, fold a one-line summary (total tokens, cache-hit rate) into the narrative; otherwise omit it — don't fabricate numbers.

**MEDIUM signal** — a single summary line: intent, MEDIUM, AI-contribution score, a short verb phrase of what shipped.

**LOW signal** — "Signal: LOW — Routine session, nothing recorded."

## Honesty rules

Never invent a decision not present in the conversation or clearly implied by the diff. Prefix reconstructed reasoning with "inferred:". Frame D must be calibrated, not overclaimed or dismissed. If every frame scores below 0.4, write nothing.

## Mid-session checkpoint

If the conversation is long-running and context may be lost before a natural session end, take a lightweight checkpoint: recompute the Layer 1 signal from what's currently visible, re-score all four frames, and note the single most important decision or finding so far in one line. When the session-end retrospective runs, merge this into the fuller Layer 3 output rather than losing it.