# Overflow — Project Fit Profile

Build a concise, evidence-based profile of the person running this prompt by analyzing their local AI coding-session history. The reader is deciding whether this person belongs on a particular project. The output must answer what they actually work on, which tools and frameworks they use, where their subject-matter experience lies, how they compare with adjacent practitioner types, and what the evidence does not establish.

The result is one HTML file for the user to review. Nothing is submitted automatically. The file is required when applying to Overflow's standing community, but not for event attendance. The user may later upload it at https://austin.overflowbuilders.com/apply/ and explicitly choose whether it stays private inside Overflow or is published publicly.

Before doing anything, tell the user in 4–5 plain sentences:

- You will analyze readable local AI coding-agent history and any project-session records you can access.
- Nothing leaves the machine during this analysis; you will produce one local HTML file for review.
- Client names, colleague names, personal details, credentials, and identifying project names will be removed or abstracted.
- Local retention limits the evidence window, and some tools keep only a short rolling history by default.
- The process usually takes 10–15 minutes, depending on session volume.

Then proceed without waiting for permission. Do not ask setup questions.

---

## What this profile is

This is a project-staffing document, not a recommendation letter, personality test, leaderboard entry, or résumé rewrite.

The useful question is not whether the person is "good at AI". Anyone running this prompt is likely a heavy AI-tool user. Identify what is different about this person:

- the work they repeatedly choose to do;
- the tools, languages, frameworks, platforms, and delivery practices they use;
- the depth of evidence for each;
- whether they personally implement, direct and review agents, or do both;
- their industry and subject-matter exposure;
- the project roles they resemble and do not resemble;
- the kinds of projects that fit them, need a complementary specialist, or are not supported by the evidence.

Do not infer that work shipped merely because a session exists. Session history can show sustained implementation, debugging, deployment activity, or operational ownership. It cannot reliably prove that a customer or employer released the work. Use verbs such as "worked on", "implemented", "debugged", "operated", or "directed" unless release is directly established.

## Hard rules

1. **Evidence over praise.** Every capability claim must trace to observed session evidence.
2. **No global scores.** Do not assign an overall score, percentile, rank, stars, radar chart, or 1–5 grades. Do not call the person "world-class", "exceptional", "impressive", "expert-level", "10x", "top-tier", or "highly skilled".
3. **Specificity is the product.** Prefer "frequently directs Next.js/TypeScript changes and verifies them in the browser" over "strong full-stack developer". If a sentence could describe most coding-agent users, rewrite it or remove it.
4. **Session evidence only.** Do not search for, request, infer from, or include LinkedIn, résumé, employer-history, or other external career-profile information. Do not mention LinkedIn anywhere in the finished HTML or embedded JSON.
5. **Show authorship honestly.** Distinguish direct implementation, agent-directed and reviewed work, mixed evidence, and unclear authorship. Directing agents well is a real mode of work; do not disguise it as hand-written implementation.
6. **Limits are required.** Name missing evidence, shallow evidence, retention gaps, and project types that would require a complementary specialist.
7. **Privacy is structural.** Abstract identifying information during extraction, not only during final editing.
8. **Concise output.** The finished profile should normally be 1,200–1,800 words, excluding embedded JSON. Prefer short paragraphs and dense lists. Do not repeat the same evidence in multiple sections.

---

## Step 1 — Inventory local evidence

Inspect these primary stores:

- **Claude Code:** `~/.claude/projects/*/*.jsonl`
- **Codex CLI/Desktop:** `~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl`
- **Cowork metadata on macOS:** `~/Library/Application Support/Claude/local-agent-mode-sessions/**/local_*.json`
- **Claude desktop-launched Code metadata:** `~/Library/Application Support/Claude/claude-code-sessions/**/*.json`

Claude desktop-launched Code metadata often points to a transcript already present in `~/.claude/projects`; use it for attribution but never double-count it.

Also check, best effort, for readable history from Gemini CLI, opencode, aider, Pi, Cursor CLI, and local-model runtimes such as Ollama or LM Studio. Installed software alone is not evidence of working familiarity. Record it only when sessions or project artifacts show use.

For each store, collect session count, total size, date range, distinct projects, and unknown-project count. If fewer than five usable sessions exist in total, stop and explain that there is not enough evidence yet.

## Step 2 — Distill with a script

Do not read hundreds of megabytes of raw logs into context. Write and run a small Python script that produces temporary digest files.

For every session, extract:

- tool, date, working directory/project, branch when present, file size, and user-message count;
- user messages only, excluding tool output, system reminders, injected instructions, environment blocks, and command stdout;
- enough message context to understand the requested work, corrections, decisions, and verification;
- no more than roughly 40 user messages per session, taking the first 25 and last 15 for longer sessions and truncating individual messages to roughly 700 characters.

Support both major Codex formats: newer `response_item` payloads and older top-level message records. Resolve Codex project attribution from session metadata, turn context, environment-context paths, and finally absolute paths in user messages. Revisit the parser if more than about 10% of sessions remain unknown.

Cowork metadata has lower fidelity. Use title and initial message as evidence of what the user delegates, but do not pretend it contains implementation details.

Compute combined cadence only as methodology metadata: sessions in the last 28 days, active weeks in the last 12 weeks, and most recent session. Do not treat volume as skill.

Group digests into chunks of roughly 150–250 KB, keeping projects together when practical.

## Step 3 — Extract observations

Use parallel subagents for chunks when available; otherwise process them sequentially. Give every extractor these rules:

> Read the complete digest. Never carry forward client, employer, colleague, or product names, identifying URLs, credentials, or personal matters. Paraphrase rather than quote. Describe commercial work by industry and function, such as "a healthcare intake application". Drop health, financial, legal, family, dating, and similarly private sessions from examples entirely.
>
> Return:
>
> 1. **Tools and working environment:** coding agents, automation, browsers, shells, IDEs, cloud platforms, deployment systems, databases, creative-AI tools, local models, and custom skills. Include session count, date range, and concrete use.
> 2. **Languages, frameworks, and technical practices:** include session count, date range, difficult work observed, routine work observed, and whether authorship is direct, agent-directed and reviewed, mixed, or unclear.
> 3. **Domains and subject matter:** industries, business functions, operational workflows, and regulated or specialized contexts. State whether evidence comes from repeated sessions or a small number of projects.
> 4. **How the person works with agents:** task decomposition, parallelism, recovery, verification, visual QA, testing, research, custom skills, and where they accept output without enough checking.
> 5. **Substantial work arcs:** abstract project descriptions, approximate sessions and date span, problems solved, and what can actually be established. Do not call them shipped unless the evidence proves release.
> 6. **Project-role indicators:** observations that distinguish product/full-stack implementation, consulting and business translation, ML research/engineering, automation/integration, design/front-end craft, infrastructure/operations, and other relevant roles.
> 7. **Negative and missing evidence:** technologies or responsibilities that might be expected but were absent, shallow, ambiguous, or agent-authored.
> 8. **Privacy risks:** anything the synthesizer must omit.

## Step 4 — Confirm the display name

Infer the practitioner's likely name from `git config user.name`, but do not lock it in yet. Do not search for the person online.

After session extraction is complete, ask the only question in this run:

> I've finished the session analysis. What name should I use on the profile?

Use that answer only for the display name. Make no external web requests and include no portrait, career history, employer list, profile URL, or external career context. Overflow collects LinkedIn separately when the person chooses to submit the finished file; it remains private to Overflow and is not part of this project-fit profile.

## Step 5 — Synthesize the staffing read

Synthesize the complete profile yourself. Do not delegate final judgment.

### Focus line

Write one plain, specific line, no more than 140 characters, describing the center of gravity of the observed work. It should help distinguish this person from other heavy agent users. Do not use a slogan and do not prefix it with "ships".

### Project role

Write a short paragraph describing the role the evidence most resembles. Then name one or two nearby roles it resembles less. Examples are comparison categories, not a mandatory taxonomy:

- product-oriented full-stack engineer;
- consultant/operator who translates business problems into working systems;
- ML engineer or researcher;
- automation and integration specialist;
- front-end/design engineer;
- platform or infrastructure engineer.

Base the distinction on observed work, not flattering adjectives.

### Tools and working environment

List the tools the person actually favors or uses repeatedly. Classify familiarity:

- `primary` — central to repeated work across projects;
- `frequent` — used substantively more than once;
- `occasional` — present but not enough evidence to call habitual.

An installed tool is not enough. Include one concise evidence statement for each.

### Languages, frameworks, and platforms

Classify each item:

- `very-familiar` — repeated complex use, architecture or difficult debugging across multiple sessions;
- `familiar` — routine substantive use in real project work;
- `some` — limited, exploratory, or mostly agent-authored evidence.

Most profiles should have only a few `very-familiar` items. For each item, record authorship as `direct`, `directed-reviewed`, `mixed`, or `unclear`. Retain the legacy tier mapping in the JSON for matching: `very-familiar → deep`, `familiar → working`, `some → touched`.

### Subject-matter experience

Identify domains and business functions observed in sessions. Use `substantial` or `some` depth. Do not add domains based on external career history.

### Relative profile

Compare the person with the three or four adjacent practitioner types most useful for staffing. Write 1–2 sentences per comparison. This is not a score. Say where the evidence is stronger, different, or thinner.

### Project match

Provide three short lists:

- **Good fit:** work this evidence supports assigning them.
- **Bring a specialist:** work they could plausibly lead or contribute to, but where complementary depth is prudent.
- **Not established here:** work the available history does not support claiming.

### Limits

State the date window and session count per tool, unknown-project count, lower-fidelity sources, retention limitations, ambiguous authorship, and major unobserved areas. Absence of evidence is not evidence of absence.

## Step 6 — Privacy pass

Review the draft as a hostile privacy reviewer. Remove or abstract every person other than the practitioner; private company/client and product names; emails, phones, addresses, internal URLs, repo names that identify clients, credentials, external career-profile information, and private personal topics.

## Step 7 — Render one HTML file

Write `~/Desktop/project-fit-{name-slug}.html` and open it locally.

The page must feel like a technical document made for developers, not a personal-brand landing page:

- dark background `#0e0d0b`, alternate surface `#161411`, text `#f2eee6`, secondary text `#a89f90`, hairlines `#2a2620`, accent `#ff4d00`;
- system sans for body and headings; system monospace for labels and metadata;
- constrained reading width around 760px, generous whitespace, thin rules, no decorative cards, no gradients, no progress bars, no score graphics, no testimonial language;
- responsive at 360px width with no horizontal overflow;
- no JavaScript, remote scripts, tracking, web fonts, or inline event handlers;
- make zero external requests; use no remote images, logos, or profile links.

Add this exact marked notice near the top of the visible body, after the compact Overflow header and before the person's name. Keep the start/end comments intact so Overflow can strip the notice when the profile is uploaded and served:

```html
<!-- overflow-local-only-notice:start -->
<div class="local-only-notice" style="border:1px solid #ff4d00;background:#ff4d0014;color:#f2eee6;padding:12px 14px;margin:0 0 24px;font:12px/1.6 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace">
  Local review copy. This file is unpublished. Upload it with your application at https://austin.overflowbuilders.com/apply/ to keep it private inside Overflow or publish it publicly.
</div>
<!-- overflow-local-only-notice:end -->
```

Visible sections, in this order:

1. compact Overflow header and evidence-window metadata;
2. name and focus line;
3. Project role;
4. Tools & working environment;
5. Languages, frameworks & platforms;
6. Subject-matter experience;
7. Relative profile;
8. Project match;
9. Limits & methodology.

Use short prose and restrained tables or definition lists. Do not place every section in a card. Do not repeat claims.

Include this exact machine-readable block, populated with real values:

```html
<script type="application/json" id="profile-data">
{
  "schema_version": 3,
  "prompt_version": 4,
  "name": "",
  "focus": "",
  "headline": "",
  "generated_at": "",
  "generated_by": { "agent": "claude-code|codex|other", "model": "" },
  "windows": {
    "claude": { "from": "", "to": "", "sessions": 0, "unknown_projects": 0 },
    "codex": { "from": "", "to": "", "sessions": 0, "unknown_projects": 0 },
    "cowork": { "from": "", "to": "", "sessions": 0, "unknown_projects": 0 },
    "other": [ { "tool": "", "from": "", "to": "", "sessions": 0, "unknown_projects": 0 } ]
  },
  "cadence": { "sessions_last_28d": 0, "active_weeks_last_12": 0, "last_session": "" },
  "project_role": { "best_fit": "", "less_like": [""] },
  "tools": [
    { "tag": "", "label": "", "kind": "agent|automation|platform|environment", "familiarity": "primary|frequent|occasional", "sessions": 0, "evidence": "" }
  ],
  "skills": [
    { "tag": "", "label": "", "category": "language|framework|platform|ai-ml|infra|data|practice", "familiarity": "very-familiar|familiar|some", "tier": "deep|working|touched", "authorship": "direct|directed-reviewed|mixed|unclear", "sessions": 0, "first_observed": "", "last_observed": "", "evidence": "" }
  ],
  "domains": [
    { "tag": "", "label": "", "depth": "substantial|some", "evidence_volume": "high|medium|low", "source": "sessions", "evidence": "" }
  ],
  "comparisons": [ { "role": "", "summary": "" } ],
  "project_match": { "good_fit": [""], "bring_specialist": [""], "not_established": [""] },
  "limits": [""]
}
</script>
```

Set `generated_by` truthfully. Omit empty window keys. Set both `focus` and `headline` to the same focus line for backward compatibility.

Use kebab-case tags. Prefer this vocabulary where it fits, adding a tag only when necessary: `python, typescript, javascript, go, rust, swift, sql, react, nextjs, vue, node, fastapi, django, rails, rag, agents, multi-agent, agent-orchestration, evals, fine-tuning, local-models, prompt-engineering, mcp, computer-use, voice-ai, embeddings, vector-db, llm-apps, image-gen, video-gen, creative-ai, aws, gcp, azure, cloudflare, vercel, docker, kubernetes, ci-cd, terraform, postgres, data-pipelines, etl, analytics, scraping, testing, security, api-design, integrations, automation, ai-assisted-delivery, design-systems, component-library, ui-prototyping, accessibility, visual-qa, electron, desktop-apps, mobile, ios, android, oauth`.

## Step 8 — Hand off

Delete temporary digest files, open the HTML, and tell the user:

- where the file is;
- the evidence date range and session count contributed by each tool;
- that it is a rolling local snapshot affected by retention;
- to edit or remove anything they do not want to share while keeping the `profile-data` JSON valid;
- that nothing has been uploaded;
- that they can submit it with their standing-community application at https://austin.overflowbuilders.com/apply/ when ready, where email and LinkedIn are required privately, LinkedIn stays outside the project-fit profile, and they explicitly choose private-to-Overflow or public publishing.