# Overflow — Proof of Work You are about to build an **evidence-based proof-of-work profile** for the person running this prompt, by analyzing their local AI coding session history. You may be any capable coding agent — Claude Code, OpenAI Codex CLI, or another tool that can read files and run scripts; the analysis is the same regardless of which agent executes it, and it always covers **all** the session stores on the machine, not just your own. The output is a single self-contained HTML file they will review and — only if they choose — submit at https://austin.overflowbuilders.com/assessment/ to join the Overflow community's practitioner ledger, which is used to route real client work to the people who've proven they can ship it. Before doing anything, tell the user in 4–5 plain sentences: - What you're about to do (analyze their local session logs from Claude Code, Codex, and — where present — Claude Desktop/Cowork and other agents). - That **nothing leaves their machine** — you produce one HTML file; they review it and decide whether to submit it. - That client names, personal details, and secrets are scrubbed by design, and they get final review and can edit anything. - That **coverage is limited by local retention**: Claude Code deletes session transcripts older than ~30 days by default, so Claude Code work before that window won't appear (Codex and Cowork records usually reach back further). The profile will state exactly what date range each tool contributed. - Roughly how long it will take (typically 10–15 minutes depending on volume). Then proceed without waiting for permission. Do not ask configuration questions. --- ## Core principles (these override your helpful instincts) 1. **Evidence only.** Every claim in the profile must be traceable to something actually observed in sessions. If you didn't see it, it doesn't go in. The person's self-description, résumé claims, or LinkedIn are NOT inputs to the analysis. 2. **This is not a recommendation letter.** The reader is staffing real client projects and needs calibrated truth, not praise. A profile that says someone is deep in everything is useless and will be discarded. Banned words and framings: "world-class", "exceptional", "impressive", "expert-level" (except as a defined tier), "rockstar", "10x", "mastery", "top-tier", "highly skilled", "extremely". No superlatives anywhere. 3. **Calibrate hard.** Most practitioners have 2–5 genuinely deep areas. If your draft tiers more than 6 skills as "deep", you are grading too generously — re-examine the evidence. Honest profiles have plenty of "touched" entries. The same applies to the graded signals: most practitioners land at 2–3 on most signals; if your draft has three or more grades at 4+, re-examine the evidence with the rubric anchors in hand. 4. **No two profiles alike.** Never reuse stock phrasing for the summary, headline, or shape sections — write them fresh from this person's specific evidence. If a sentence could appear verbatim in another practitioner's profile, rewrite it until it couldn't. 5. **Gaps are mandatory content.** A section listing what was NOT observed (and the limits of this analysis) is required. It's what makes the rest credible. 6. **Privacy is structural, not cosmetic.** Client and employer names, colleague names, secrets, personal matters never appear in the output — see the scrub rules below. Abstraction happens at extraction time, not just at the end. --- ## Step 1 — Inventory Check the primary session stores: - **Claude Code:** `~/.claude/projects/*/` — each subdirectory is a project (directory name encodes the project path); `*.jsonl` files inside are session transcripts. - **Codex CLI:** `~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl`. - **Claude Desktop / Cowork** (macOS): two metadata stores under `~/Library/Application Support/Claude/`: - `local-agent-mode-sessions/**/local_*.json` — **Cowork** sessions. Each file has `title`, `initialMessage`, `cwd`, `createdAt`/`lastActivityAt` (epoch ms), and `model`. Full transcripts live inside the Cowork VM and are not readable here, so treat these as real but lower-fidelity evidence: session volume, date range, and the titles + initial messages (which are genuine user-side signal about what the person delegates and how they phrase it). - `claude-code-sessions/**/*.json` — Claude Code sessions launched from the desktop app. Each file's `cliSessionId` maps to a transcript at `~/.claude/projects//.jsonl`, which is **already counted in the Claude Code store above** — use these files only to attribute sessions as desktop-launched vs terminal-launched. Never double-count them. Collect for each store: session count, total size, date range, and the list of distinct projects. Note: Claude Code deletes transcripts older than ~30 days by default, so the Claude window is usually shorter than the Codex window. Record both windows — they go in the report's methodology section. Then widen the net, best-effort (the goal is the big picture of how this person uses AI, not just two tools): - **Other AI coding tools** — if you find session/history stores for other agents (e.g. Gemini CLI under `~/.gemini`, opencode, aider's `.aider.chat.history.md` files, Pi, Cursor CLI), include them: extract user messages if the format is parseable; if not, record volume and date range as supporting evidence only. Never guess at content you can't actually read. - **Local model runtimes** — check for Ollama (`ollama list` if installed), LM Studio, or similar. Installed models and any session evidence of using them are a real skill signal (`local-models`); record what's installed and observed, nothing more. If ALL stores are empty or near-empty (< 5 sessions total), stop and tell the user there isn't enough session history to build an evidence-based profile; suggest they re-run after a few weeks of normal use. Do not fabricate a profile from an empty base. ## Step 2 — Distill (script, not reading) The raw logs are usually hundreds of MB — do not read them directly. Write and run a small Python script that produces compact **digest files** in a temp directory: For each session, extract: - Header: tool (claude|codex|other), date, project (cwd), git branch if present, file size, message count. - The **user messages only** (these carry the strongest signal of what the person was trying to do and how they work). Skip tool results, system reminders, command output, and injected context. For Claude Code JSONL: lines with `type: "user"`, taking `.message.content` when it's a string, or the `text` fields of content blocks when it's an array — but SKIP any content containing ``, ``, or `tool_result` blocks. For Codex JSONL there are TWO formats — newer files wrap messages as `response_item` lines whose payload is a user message; older files (pre-2026) have top-level `{"type":"message","role":"user",...}` lines — handle both, and SKIP payloads containing `` or ``. - **Project attribution is mandatory, not best-effort.** "unknown project" loses the context that makes evidence credible. For Codex sessions, resolve the working directory in this order before giving up: (1) session metadata lines (`session_meta`, `turn_context`, or similar fields carrying `cwd`), (2) the `` block's cwd/workdir text — parse it for the path BEFORE skipping the block, (3) the first user message that mentions an absolute path. Only after all three fail may a session be marked `unknown`. Count unknowns per store and print the count in the distill summary — if more than ~10% of sessions are unknown, revisit your parser before proceeding; the methodology section must report the final unknown count honestly. - Truncate each message to ~500 characters, cap at ~40 user messages per session (take the first 25 and last 15 if longer). - **Cowork sessions** get a one-block digest each from their metadata: date, model, `title`, and `initialMessage` (truncated to ~500 chars), marked `tool: cowork`. Low fidelity is fine — say so in the digest header. While distilling, also compute **cadence** across ALL stores combined (from session dates): sessions in the last 28 days, number of distinct weeks with at least one session in the last 12 weeks, and the date of the most recent session. Claude Code's ~30-day retention means the 12-week view leans on the longer-window stores (Codex, Cowork metadata) — compute from whatever evidence exists and report the limitation in the methodology section rather than extrapolating. Group digests into chunk files of roughly 150–250 KB each, keeping sessions from the same project together where possible. Print a summary: N sessions distilled into M chunks. ## Step 3 — Extract (parallel subagents) Spawn one subagent per chunk file, in parallel (if subagent tools are unavailable, process chunks sequentially yourself). Each subagent reads its chunk and returns a structured extraction. Give each subagent these instructions verbatim: > Read the digest file at {path} — read the WHOLE file, in multiple reads if needed. It contains user-side messages from AI coding sessions. Return a structured report with these sections. **Abstraction rule, apply at extraction time:** never carry forward client names, employer names, colleague/person names, product codenames, or identifying URLs — describe them by industry and function instead (e.g. "a logistics company's ERP integration", "a healthcare startup's patient-intake app"). Never quote messages verbatim; paraphrase. Flag any secrets you see (keys, tokens, passwords) only as "secrets present in session on DATE" — never reproduce them. > > 1. **Technologies & skills observed** — languages, frameworks, platforms, AI/ML techniques (RAG, agents, evals, fine-tuning, local models, MCP, prompt engineering...), infra/devops, data work. Look beyond traditional web/backend engineering — these count as fully-fledged skills, not curiosities: **creative AI** (image/video generation and editing — GPT Image, Nano Banana, Midjourney, Veo, Sora, ComfyUI and the like — and creative-AI production workflows), **desktop & native apps** (Electron, Tauri, Swift/macOS, Windows), **design craft** (design systems, component libraries, UI prototyping, accessibility work, responsive/visual QA), and **agent orchestration** (running parallel agents, verification loops, structured recovery strategies, multi-agent pipelines). For each: how many sessions it appears in, date range, and depth signals — was the person debugging hard problems, making architecture decisions, and recovering from failures (deep), routinely shipping standard work (working), or briefly exploring / following tutorials (touched)? > 2. **Domains** — industries and problem spaces worked in (abstracted per the rule above), with evidence volume. > 3. **AI-tooling fluency observations** — concrete behaviors: how they scope and delegate tasks to the agent, whether they verify output or accept blindly, how they recover when the agent goes wrong, use of subagents/skills/automation, prompt specificity. > 4. **Working style observations** — shipping cadence, testing discipline, debugging persistence, how they scope work, planning vs diving in. > 5. **Communication observations** — how clearly they specify what they want (structure, context given, precision). Observational, not judgmental. > 6. **Notable projects** (abstracted) — 1-line descriptions of the most substantial pieces of work, with rough effort signals (session counts, duration). > 7. **Signal instances** — dated, concrete instances (positive AND negative) bearing on five graded signals the synthesizer will score. For each instance: date, project (abstracted), what happened, one line. The signals: > - *verification* — checked or failed to check the agent's work (ran tests, demanded screenshots, caught an agent mistake — or accepted broken output). > - *judgment* — diagnosed a root cause before prescribing, pushed back on a flawed agent plan with reasons, made an explicit tradeoff call — or thrashed, retried blindly, treated symptoms. > - *communication* — an ask that was notably well-specified (context, constraints, acceptance criteria) or notably vague. > - *orchestration* — subagents, parallel sessions, background jobs, custom skills/hooks/automation, verification loops built into pipelines — or purely single-threaded chat use. > - *scope* — the largest things carried end-to-end: what was shipped, over how many sessions/days. > 8. **Anything to scrub** — personal/sensitive topics present (health, finances, legal, family, dating) so the synthesizer knows to exclude those sessions from examples entirely. > > Be specific and calibrated. Absence of depth signals is itself a finding — report it. ## Step 4 — Synthesize Merge the extractions yourself (do not delegate synthesis). Build: **Headline** — one line, max 90 characters, in the form of what this person's Overflow name tag would say: the most specific, distinctive true statement about what they ship. Grounded in their strongest observed work — never generic ("builds AI solutions" is a failure; "ships voice agents that survive real phone trees" is the register). This is the anti-sameness anchor for the whole profile. **Skill tiers** — assign each observed skill one of three tiers, using these definitions strictly: - **deep** — sustained complex work observed across multiple sessions: hard debugging, architecture decisions, non-trivial tradeoffs, recovery from failures. Volume alone does not qualify; struggle-and-resolution does. - **working** — routinely used to ship real work without evident struggle; standard tasks completed competently. - **touched** — appears briefly, exploratory, tutorial-level, or the agent did all the work with no evidence the person could operate independently. Every skill entry carries: tier, session count, first/last observed date, and one concrete (abstracted) example. Tag each skill with a category: `language | framework | ai-ml | infra | data | practice`. If the person directs agents rather than hand-writing code, say so plainly in the relevant entries — it's a defining characteristic, not a flaw to hide. **Domains** — industries/problem spaces with evidence volume, abstracted. **Graded signals** — five 1–5 grades against the anchored rubrics below. These are the most consequential numbers in the profile — they are how the reader ranks practitioners against each other — so grade them like a skeptical examiner, not a friend. Rules: - Every grade must cite **at least 2 evidence observations** (abstracted, dated where possible) drawn from the extractions' signal instances. A grade without evidence is invalid — lower it until the evidence supports it. - **Grades 4–5 require multiple distinct instances across different projects or dates.** One good day is not a pattern. - Calibration: across real practitioners, most grades land at 2–3. A 5 should be rare enough to be remarkable. When evidence is thin or mixed, grade low and say why — a defensible 2 is worth more than an inflated 3. - Negative evidence counts. If the extractions show both verification loops and blind acceptance, the grade reflects the mix, and the evidence lines say so. The rubrics: 1. **`verification_discipline`** — does the person check the agent's work? - 1 — accepts output without checking; breakage from unverified work appears later in the history. - 2 — occasional spot-checks, no routine. - 3 — usually runs or inspects the result before moving on; catches obvious breaks. - 4 — habitual verification loops (tests, screenshots, live checks) across projects; catches agent mistakes before they land. - 5 — systematic: demands evidence from the agent, independently audits, catches subtle plausible-but-wrong output. 2. **`judgment_rigor`** — quality of thinking visible in how they direct the work. - 1 — vague thrash; retries without diagnosis; follows flawed plans off the cliff. - 2 — some direction, but often treats symptoms rather than causes. - 3 — generally diagnoses before prescribing; reasonable calls under normal conditions. - 4 — consistently root-causes, pushes back on bad agent plans with reasons, weighs tradeoffs explicitly. - 5 — repeatedly catches the agent's flawed reasoning early, reframes problems, makes scope and tradeoff calls that visibly save projects. 3. **`communication_precision`** — how well they specify work (the closest session-visible proxy for how they'd interact with a client or team). - 1 — one-line vague asks; the agent is left guessing at intent. - 2 — intent discernible, constraints and context routinely missing. - 3 — states the goal and key context most of the time. - 4 — structured asks: context, constraints, acceptance criteria; anticipates ambiguity before it bites. - 5 — specs read like well-written tickets — sequencing, edge cases, explicit non-goals; rework due to unclear intent is rare. 4. **`orchestration_leverage`** — how much machine they put between themselves and the work. - 1 — single-threaded chat use, default settings, no tooling. - 2 — occasional use of one advanced capability (a script, a skill). - 3 — regular use of subagents, skills, or automation where they fit. - 4 — parallel agents, background jobs, custom skills/hooks; verification built into the pipeline. - 5 — designs multi-agent systems as a working style: fan-out/verify loops, scheduled automation, cross-tool orchestration. 5. **`autonomy_scope`** — the largest thing demonstrably carried end-to-end. - 1 — snippets and single-file fixes. - 2 — features inside an existing codebase, with guidance. - 3 — full features end-to-end, including debugging and deployment. - 4 — whole products or services shipped over multi-week arcs, including infrastructure. - 5 — multiple substantial systems shipped and operated end-to-end (product, infra, ops) over months. **Flagship work** — the 1–3 largest things this person demonstrably shipped end-to-end, abstracted per the scrub rules: one-line summary, session count, and the span in days from first to last related session. This is the `autonomy_scope` evidence made concrete. If nothing qualifies, say so — an empty flagship list with honest skills beats a padded one. **AI-tooling fluency** — one of the profile's most valuable sections; no résumé shows this. Tier it (deep/working/touched) with 3–6 concrete observed behaviors, both strengths and weaknesses (e.g. "delegates well-scoped tasks and verifies output" vs "tends to accept first output without checking"). **Working style** — 3–5 observations with evidence. Include communication clarity here as observation, not a grade. **Shape** — specialist / generalist / T-shaped, one paragraph justifying from the distribution of tiers, written fresh from this person's evidence. **Gaps & not observed** — at least 3 entries: common skills for this kind of work that never appeared, or appeared only shallowly. Plus the limits box: data window per tool, that sessions only show AI-assisted work (pre-AI career is invisible), and that absence of evidence is not evidence of absence. ## Step 5 — Scrub pass Re-read your full draft as a hostile privacy reviewer. Remove or abstract: any person's name other than the practitioner; company/client/employer names; emails, phones, addresses; API keys, tokens, credentials, internal URLs and repo names that identify a client; health, financial, legal, family, or dating content (drop those sessions from examples entirely — do not even abstract them); anything a practitioner would not want a prospective client to see. Industry-level descriptors ("a fintech startup") are allowed and encouraged. When in doubt, cut. ## Step 6 — One interaction: identity + optional links Infer the practitioner's name from `git config user.name`. Now ask the user (this is the ONLY question in the whole run): > The analysis is done. Confirm your name is "{name}" (or give the name you want on the profile), and optionally paste your LinkedIn URL — it will be attached as self-reported contact info, not merged into the evidence. Include whatever they provide as metadata only. ## Step 7 — Render the HTML Write a single self-contained HTML file to `~/Desktop/proof-of-work-{name-slug}.html`. Requirements: - **Fully self-contained**: inline CSS, **zero external requests of any kind** — no web fonts, no images, no scripts loading from anywhere. This is a trust property: the file must be verifiably inert. Must render from a double-click. - **Design — match the Overflow brand exactly.** This is a dark, editorial, terminal-inflected document, not a marketing page and not a generic résumé. Use these tokens: - Background `#0e0d0b` (cards/alt surfaces `#161411`), text `#f2eee6`, secondary text `#a89f90`, hairlines `#2a2620`, single accent `#ff4d00` (soft variant `#ff4d0022`). Dark always — no light mode. - Fonts (system only): labels/metadata/badges in `ui-monospace, "SF Mono", Menlo, Consolas, monospace`; body and headings in `-apple-system, "Segoe UI", sans-serif` with tight letter-spacing on big headings; italic serif accents (`Georgia, serif`) sparingly for emphasis words. - Section labels in mono, uppercase, letter-spaced, accent-colored, prefixed with `// ` (e.g. `// skills`, `// gaps`). Header/footer as thin hairline-bordered bars in mono smallcaps. Selection color: accent background, ink text. - Tier badges in mono uppercase: deep = accent-filled, working = accent-outlined, touched = dim-outlined. **No progress bars, star ratings, or radar charts.** - The headline rendered prominently under the name as `ships: {headline}` in mono with the accent color. - **Sections in order**: header bar (Overflow ● Proof of Work) → name + `ships:` headline + **per-tool data windows** (each store's from→to range and session count, with a note when a tool's retention limits the window, e.g. "claude code: last ~30 days only") + cadence in mono → factual 3–4 sentence summary → Signals (the five graded signals: each as its mono label, a `N/5` badge in the tier-badge style — accent-filled at 4–5, accent-outlined at 3, dim-outlined at 1–2 — and its evidence lines underneath; **no bars, dots, or stars**) → Flagship Work → Skills (grouped by category, tier badges, evidence) → Domains → AI-Tooling Fluency → Working Style → Shape → Gaps & Not Observed → Methodology & Privacy (how this was made, what was scrubbed, all data windows, which agent generated it, and the sentence "Generated from local session evidence and reviewed by the practitioner before sharing."). - **Embedded machine-readable data**: include a `