# Overflow — AI Work Assessment Build a concise, evidence-based profile of the person running this prompt from configurable, clearly separated source layers: 1. their local AI coding-session history; 2. longitudinal technical activity available through their authenticated GitHub account; 3. optional LinkedIn career history, only when the person explicitly opts in. A configured copy of this prompt may begin with a `Source choices for this run` block. When present, it is authoritative: inspect only sources marked `include`; do not inspect, request, or mention sources marked `omit`; and never treat a user's omission as evidence of missing ability. `claude` covers Claude Code, Cowork, and desktop-launched Claude sessions. `other_local` covers best-effort readable history from Cursor, Gemini CLI, Pi, opencode, aider, and local-model runtimes. If no source-choice block is present, use every available technical source and ask whether to include LinkedIn as described below. The reader is deciding what kind of AI practitioner this person demonstrably is and where they belong in a community or on a particular project. The output must answer what they actually work on, whether their evidence centers on prototypes, production shipping, operating live systems, or changing mature systems, which technical surfaces and AI practices recur, what the source-specific captured activity can honestly show, how they frame and steer agent work, where their subject-matter experience lies, and what the evidence does not establish. The result is one HTML file for the user to review. Nothing is submitted automatically. This is the v6/schema-v8 contract. The local review file contains the complete work profile except the anonymous cohort-comparison section. Do not request, reconstruct, embed, estimate, or display any Overflow cohort distribution, placement, percentile, comparison count, or curve before submission. Include the exact marked post-submission callout specified below in place of that section. The report may contain the exact marked, user-triggered upload panel specified below; it sends nothing until the user completes the form, consents, and clicks the final upload button. After a successful upload, Overflow retains only the normalized structured profile payload, discards the surrounding HTML/CSS/JavaScript and applicant-supplied cohort data, removes LinkedIn career context, and calculates the comparison from the stored submission. Overflow renders a consistent report from that data. The user explicitly chooses whether the stored technical profile stays private inside Overflow or is published publicly. The finished file must begin with Overflow's standard site header: the outlined orange square `O`, the text `Overflow / Austin`, and a compact `Visit Overflow ↗` link. Both the brand and navigation link must point to the absolute URL `https://austin.overflowbuilders.com/`, open only when the user clicks, and work from a local `file://` page. Match the public site's dark palette, orange accent, restrained uppercase mono navigation, and editorial display type. Do not invent a separate assessment brand or put `Experience profile` in the wordmark. Before doing anything, tell the user in 4–7 plain sentences, mentioning only sources selected for this run: - You will analyze readable local AI coding-agent history and any project-session records you can access. - You will use their already-authenticated GitHub account to gather contribution metadata and long-term technical activity; you will not publish, modify, clone, star, follow, or write anything on GitHub. - LinkedIn career history is optional. If included, you will open it in an authenticated browser, verify that the person can see the page, and use it only as separately labeled career context. - Source analysis and report generation happen locally. GitHub and, if selected, LinkedIn receive normal authenticated read requests. The profile stays on the person's computer unless they manually upload it to Overflow; cohort placement is not calculated or shown before that upload. - Client names, colleague names, personal details, credentials, and identifying project names will be removed or abstracted. - Local retention limits the session-evidence window, GitHub visibility depends on account and organization access, and LinkedIn is self-reported career context rather than proof of implementation. - The process usually takes 15–25 minutes, depending on session volume and source coverage. Only when no configured source-choice block is present, ask exactly one source-choice question before proceeding: > Include LinkedIn career history? **Recommended, but optional.** Reply `yes — ` to include it, or `no` to build the profile from local sessions and GitHub only. If the user answers yes without a URL, ask only for the URL. When a configured source-choice block includes LinkedIn but no URL is supplied, ask only for the URL. When it omits LinkedIn, do not ask about or open LinkedIn. Honor every configured include/omit choice without asking the user to reconsider it. Do not ask other setup questions unless an included GitHub or LinkedIn source reaches a genuine user-owned sign-in, SSO, MFA, or account-identity boundary. --- ## What this profile is This is an evidence-based AI work profile and 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; - whether their evidence shows exploration, working prototypes, live delivery, ongoing operation, or mature-system change; - the system contexts and technical surfaces in which that work occurs; - a limited stack of rule-derived badges, each backed by normalized work arcs; - 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 overall scores or pre-submission placement.** Do not assign an overall score, percentile, rank, radar chart, or 1–5 grade. The only stars allowed are the badge-specific 1–3 proof stars defined below; they measure evidence strength, never talent, seniority, or relative rank. Never total or average badge stars. Do not place any metric on a distribution or estimate where the person might fall. The source-specific GitHub activity characterization is allowed only when it follows the explicit standard below and says that it is not a seniority or expertise score. 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. **Source boundaries are hard boundaries.** Local sessions support claims about recent working behavior and implementation evidence. GitHub supports longitudinal technical activity and collaboration evidence. LinkedIn supports career chronology and stated role context only. Never present LinkedIn claims as implementation proof, and never let LinkedIn affect skill tiers or project-fit scoring. 5. **Volume is not quality.** Commit counts, contribution days, repository counts, session counts, followers, stars, endorsements, and network size are descriptive metadata, not measures of skill or seniority. 6. **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. 7. **Provenance is visible.** Every substantive section and machine-readable claim must identify whether it comes from `sessions`, `github`, `linkedin`, or a cautious synthesis of named sources. 8. **Limits are required.** Name missing evidence, shallow evidence, retention gaps, source-access gaps, and project types that would require a complementary specialist. 9. **Privacy is structural.** Abstract identifying client and private-project information during extraction, not only during final editing. Never store or display access tokens, private repository URLs, connection lists, email addresses, or collaborator names. 10. **Concise output.** Keep the visible profile between 700 and 1,100 words, excluding embedded JSON and form labels. Prefer short findings, labels, and visual comparisons. Do not repeat evidence across sections. 11. **Write for the profile owner.** Address the reader as `you`. Keep implementation and assessment language out of the visible page. Never show prompt or schema versions, contract names, characterization versions, API terminology, source-policy labels, `directional`, `coverage`, `compatible profiles`, `optional enrichment`, `not assessed`, or internal field names. Translate anything useful into plain language and omit the rest. 12. **Normalize before characterizing.** Do not jump from raw sessions to person-level labels. First group evidence into substantial work arcs, then classify each arc across the controlled axes below. 13. **One value per axis.** Every work arc gets exactly one delivery state, system context, primary work surface, change type, and responsibility level. Use `unknown` where allowed rather than blending categories or guessing. A secondary work surface may be recorded but never replaces the required primary surface. 14. **Badges are derived conclusions.** Do not choose badges because they sound plausible. Apply the explicit qualification rules to the normalized work arcs. Tool installation, job titles, employer prestige, session volume, GitHub volume, and self-description never earn a badge by themselves. 15. **Complete badge evidence map.** Badges are non-exclusive and describe different dimensions. Evaluate every controlled badge exactly once. Show earned and observed badges with their proof, and show every unawarded badge in a quieter gray map with the reason and evidence needed to move it forward. Do not hide a qualifying badge merely to satisfy a display cap. 16. **Interaction analysis is behavioral, not psychological.** Describe observable task framing, context provision, correction, exploration, feedback, and orchestration. Do not infer intelligence, mental health, motives, personality disorders, or hidden emotions. Do not expose or reconstruct hidden chain-of-thought, private reasoning tokens, or system/developer messages; use only visible conversational behavior and outcome evidence. 17. **Activity is a timeline, not a virtue.** Show cadence, concurrency, context pressure, tool/platform use, and model choice over time when the logs support them. Separate interactive work from scheduled automation and background workers. Never equate more sessions, more concurrent work, a newer model, or more tokens with better performance. 18. **One community-facing profile.** Build one canonical evidence profile for the broader Overflow community. Do not add an internal staffing lens, employer-specific interpretation, audience toggle, or alternate scoring view. --- ## Step 1 — Inventory local evidence Inspect only the local source families marked `include`. If Codex, Claude, or other local agents are omitted, skip their paths completely and record the omission as a user choice rather than a coverage failure. 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 — Collect authenticated GitHub context If GitHub is marked `omit`, skip this step completely, make no GitHub request, and set its source status to `declined` rather than `unavailable`. Use GitHub only through the person's existing authenticated `gh` session. Begin with `gh auth status` and `gh api user`. Never print, read, copy, summarize, or persist the token. Make no GitHub mutations. If GitHub is not authenticated, ask the user to complete `gh auth login` and tell you when it is ready. If they decline, continue with GitHub marked `unavailable`; do not silently substitute public scraping. When `gh api user` succeeds, treat that authenticated account as the account the person chose to analyze and set `account_verified: true`. Record the login as provenance, but do not create or display an identity-confidence score or warning. Use the GitHub GraphQL or REST API and a local script to collect and aggregate. Keep GitHub's different counting surfaces separate; they answer different questions and must never be merged under a label such as `total commits`. Collect these two commit measures independently: - **Indexed authored commits:** authenticated commit-search `total_count` for `author:`, plus bounded annual counts. Label it exactly `indexed authored commits`. Record `incomplete_results`, the query date, and the authenticated login. This is the broadest account-level count available here, but it is still not an absolute lifetime census. - **Contribution-graph qualifying commits:** yearly `contributionsCollection.totalCommitContributions`. Label it exactly `contribution-graph qualifying commits`. GitHub applies profile-contribution eligibility rules, so this is a subset and must never be presented as the person's complete commit history. Also collect broad authenticated search totals for authored pull requests, authored issues, and reviewed pull requests when available. Run separate bounded queries for the trailing 12 months to populate `commits_last_12`, `authored_pull_requests_last_12`, and `reviewed_pull_requests_last_12`. Use the exact generation date minus 12 months as the boundary and record it in methodology. Do not substitute contribution-graph PR/review/issue counts for these broader totals without the same explicit `contribution-graph qualifying` label. Then collect and aggregate: - account creation date and contribution years; - earliest and latest observed contribution dates; - annual indexed-authored commit counts and, separately, annual contribution-graph qualifying counts; - broad lifetime-visible and trailing-12-month counts for indexed authored commits, authored pull requests, and reviewed pull requests, with their query definitions; - active days, active months by year, total observed active months, active years, longest visible continuity, and recent activity; - accessible repository metadata needed to summarize public/private coverage, repository age, maintenance span, archived/fork status, and primary languages, when available without cloning; - repeated evidence of creating, maintaining, reviewing, or collaborating on software over time; - repeat work in the same repository across months or years, release/tag activity, merged pull requests, reviews, and issue participation when visible. Omit unavailable signals from the visible profile. Query each contribution year separately when the API requires bounded windows. Aggregate repository information locally and immediately discard private repository names, URLs, organization names, collaborator identities, commit messages, issue text, and PR text. Do not clone repositories merely for this assessment. Inspect code only when the repository is already present locally and the local-session analysis independently makes it relevant. Before drawing any experience conclusion, run a definition audit. Compare annual indexed-authored commits with annual contribution-graph qualifying commits across the same date windows. If the counts differ materially, explain why and prohibit the graph count from driving the activity characterization. A search `total_count` may describe volume, but search enumeration is capped and cannot establish a complete repository census; do not infer distinct-repository totals from a truncated result set. Record coverage honestly: authenticated account, collection date, accessible repository count, whether private contribution counts were available, search completeness, any organization/SSO gaps, and the possibility of missing work from unlinked commit emails, other Git hosts, deleted repositories, or inaccessible organizations. Account creation is not the start of a career; describe only "observed GitHub activity since …". Never use stars, followers, contribution volume, lines changed, or repository count as a skill score. GitHub may strengthen claims about longevity, continuity, maintenance, collaboration, and technology exposure, but session or code evidence is still required for implementation-depth claims. ### GitHub Activity Characterization v3 Characterize the observable activity without turning GitHub into a seniority score or withholding a useful conclusion because an optional signal is unavailable. Contribution-graph qualifying counts cannot drive the characterization; use consistently defined indexed-authored activity. Use this standard internally and store it in JSON. Do not show the standard's name, version, rung names, or unavailable optional signals in the visible profile. Show only the useful conclusion and the facts supporting it. Consider these dimensions separately: - **Continuity:** active calendar years, recent annual activity, and month-level continuity when it can be collected reliably; - **Activity context:** indexed authored commits and authored pull requests, explicitly labeled as volume rather than complexity or quality; - **Collaboration:** authored pull requests, reviews, and issue participation; - **Optional stewardship signal:** repeat work, releases, review responsibility, or long-lived maintenance when visible. If unavailable, omit it from the visible profile and do not lower the characterization. Use the highest supported descriptive label: 1. **Visible activity** — at least one indexed authored event. 2. **Repeated activity** — indexed authored activity in at least 2 calendar years, including recent activity. 3. **Sustained recent activity** — indexed authored activity in at least 3 calendar years including the current or immediately preceding year, plus visible authored pull-request, review, or issue activity. `Stewardship observed` is an optional additional signal, not a fourth rung and not a prerequisite. Never translate this label into professional years, seniority, job level, implementation depth, or an overall profile score. The person running the prompt is the profile owner. A successful authenticated `gh api user` result is sufficient attribution for this assessment; display-name differences are not a scoring dimension and require no warning. Store characterization version 3 in JSON and mark older characterizations stale when the policy changes. ## Step 3 — Collect optional LinkedIn career context If LinkedIn is marked `omit`, skip this step completely and set LinkedIn mode to `declined`. Do not mention its absence as a deficiency. Set LinkedIn mode to one of `included`, `declined`, or `unavailable`. If the user opted in, open the supplied LinkedIn URL in the available authenticated browser. Do not use unauthenticated scraping, search-engine snippets, or a different person's browser profile. Confirm that the page is visible and that its displayed identity matches the practitioner. If LinkedIn requires login, SSO, MFA, or a passkey, ask the user to complete that step in the same browser and continue only when they say it is ready. If access still fails, mark LinkedIn `unavailable` and continue; do not infer the missing history. Read only the practitioner's own profile sections needed for career context: - headline and About summary; - experience roles, organizations, date ranges, industries, and stated responsibilities; - education, certifications, and clearly stated professional specialties when relevant; - broad career transitions, overlapping roles, leadership scope, and total observable chronology. Do not inspect posts, comments, reactions, recommendations, endorsements, connections, followers, contact details, or other people's profiles. Do not click external links. Treat LinkedIn as self-reported. It may explain chronology, industry exposure, or role framing, but it cannot establish implementation quality or override contradictory session/GitHub evidence. Because the user explicitly opted in, public employer names and role titles may appear in the local review copy when they materially clarify the chronology. Still remove client names, colleague names, contact information, and sensitive personal details. Title the section `Career history` and say `From LinkedIn` once. Keep it visually separate from observed proof. Wrap every visible LinkedIn-derived element outside the main career section—including any source card or limit note—in its own `` / `` pair so upload removes it cleanly. If the user declined LinkedIn, do not open LinkedIn and do not mention missing LinkedIn as a deficiency. State only that career context was not included by choice. ## Step 4 — Distill local sessions 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. Also produce a separate metadata-only agent-operations ledger. This ledger must never contain command text, tool arguments, file contents, URLs, credentials, tool output, or resource identifiers. Record only: - tool/function name, broad category, source harness, session identifier, and timestamp; - explicit reusable-skill, command, MCP, hook, automation, agent-template, or eval-harness use when it can be identified safely; - permission mode metadata, whether the mode appears environment-inherited, user-selected, or unclear, and explicit mode-change events; - requests for elevated access and their broad purpose (`deployment`, `network`, `filesystem`, `process`, `account`, or `other`), plus approved or denied outcome only when the log states it unambiguously; - denominators needed for honest interpretation: sessions scanned, sessions with usable tool metadata, observed tool calls, and sessions with usable permission metadata. Extend that ledger with a privacy-safe activity timeline: - one coverage window per source harness, including first and last readable event, coverage days, whether retention appears limited, and known limitations. A log's first readable date is never evidence that the person first adopted the tool on that date; - monthly interactive-session counts, scheduled/background-run counts, tool-category counts, and model-session counts by source; - model names only when explicitly present in session metadata. Normalize aliases cautiously, retain `unknown`, and never infer a model from dates or product branding; - context-pressure events such as explicit context-length/token-limit failures, compaction events, and recoveries. Store category and counts only—never the surrounding prompt, error text, or reasoning content; - interactive concurrency from 15-minute activity buckets. A session is active in a bucket only when an observable user, assistant, or tool event occurs in that bucket; do not treat the entire first-to-last session span as continuously active; - active days, median interactive sessions per active day, average concurrent sessions across active buckets, 95th-percentile concurrency, peak concurrency, and days with two or more interactive sessions; - scheduled automations, subagents, and background workers in separate fields. They may describe orchestration but must not inflate interactive multitasking. Coverage comparability is mandatory. Mark the timeline `comparable` only when the same source has at least three complete months of materially consistent readable coverage. Mark it `partial` when a useful same-source comparison exists but is shorter or incomplete, and `not-comparable` when totals mainly reflect different retention windows or sources entering and leaving the readable data. Claude-family local history is commonly retention-limited to roughly the last 30 days; detect the actual window and disclose it rather than assuming older activity did not exist. For a Claude-only user with a retention-limited window, label the section `Activity in the captured window`, not `Activity and evolution`, and do not claim a long-term trend. For interaction analysis, retain a bounded digest of visible user messages and visible conversational assistant responses needed to understand framing, clarification, correction, feedback, and resolution. Exclude assistant analysis/reasoning records, hidden chain-of-thought, system/developer instructions, injected context, and tool output. Never attempt to reconstruct private reasoning from logs. Codex and Claude-family harnesses encode permissions differently. Preserve source-specific counts and vocabulary; never merge them into one permission score. An approval policy supplied by the host environment is not evidence that the user personally chose it. An installed skill, MCP, or tool is not evidence of use. 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, sessions per observed week, and most recent session. Do not treat volume as skill. Do not benchmark distinct project counts yet: worktrees, monorepos, deleted paths, and temporary directories make that definition too unstable. Group digests into chunks of roughly 150–250 KB, keeping projects together when practical. ## Step 5 — Extract local-session 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 active-session count, date range, concrete use, and metadata-only observed-call count where reliable. Separate explicitly used reusable assets from merely installed assets. > 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:** identify functional expertise separately from industry exposure. For each recurring domain, extract the operating problems, actors and workflows, data or business objects, recurring constraints, decisions the person appears equipped to make, transfer patterns across projects, session/date coverage, and whether the evidence is repeated or narrow. Examples of useful functional domains include revenue operations, delivery operations, evidence and reporting systems, content production, and AI operating models. Do not stop at a broad label such as `business operations`. > 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:** identify coherent units of work that produced or materially changed an outcome. For each candidate, return an abstract project label, approximate sessions and date span, source observations, counterevidence, and raw evidence for delivery state, system context, primary work surface, change type, responsibility, review/governance, and confidence. Do not choose badges and do not call work shipped unless the evidence proves release or live use. > 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. > 9. **Agent operating metadata:** summarize tool-category mix, reusable skills/MCPs/commands/hooks/automations actually used, permission-mode coverage by harness, explicit permission-mode changes, and scoped escalation requests. Return raw counts with denominators and limitations. Do not interpret frequent elevated access as inherently good or bad. > 10. **Activity coverage and evolution:** summarize source-specific retention windows first, then interactive versus scheduled activity, concurrency using the 15-minute-bucket definition, tool/platform and model mix by month, explicit context-pressure events, and recoveries. State whether the months are comparable. Never treat the start of a retained window as tool-adoption evidence. Volume is descriptive, not a capability judgment. > 11. **Observable interaction dynamics:** return evidence for task framing, context provision, direction versus exploration, correction quality, feedback/confirmation style, and how the person changes approach after failure. Use visible conversation only. Identify both recurring patterns and counterexamples; do not label intelligence, hidden sentiment, or personality pathology. ## Step 5A — Normalize work arcs before characterizing the person Merge overlapping observations into three to eight substantial work arcs. A work arc may span many sessions or repositories, but it must describe one coherent outcome. Tiny edits, setup-only sessions, generic questions, and repeated attempts at the same task are not separate arcs. Classify every arc on the following independent axes. Choose exactly one value per axis; use `unknown` only where it is explicitly allowed. Do not collapse the axes into an overall maturity judgment. ### Delivery state - `exploration` — research, analysis, experiments, or throwaway trials without a stable working artifact; - `working-prototype` — a usable demonstration or local/hosted prototype, without evidence of production adoption; - `live-use` — merged, deployed, released, or used in a real operating workflow; - `ongoing-operation` — repeated maintenance, monitoring, incident response, iteration, or ownership after live use. ### System context - `greenfield` — a new system or capability created from a mostly blank starting point; - `early-system` — an existing prototype or young codebase still taking shape; - `established-system` — an existing shared codebase or workflow with meaningful conventions and dependencies; - `mature-constrained` — a long-lived or high-consequence system with compatibility, governance, migration, reliability, security, or organizational constraints; - `unknown` — the history does not establish the context. ### Primary work surface - `product-operations` — requirements, business process, service design, decision support, or operating-model work; - `experience-interface` — interaction design, visual systems, front-end experience, content, or accessibility; - `application-software` — application behavior, APIs, services, and product logic; - `data-models` — schemas, analytics, pipelines, ML, retrieval, evaluation data, and data quality; - `workflow-integration` — automations, agents, connectors, orchestration, and cross-system workflows; - `platform-infrastructure` — deployment, environments, security, observability, performance, and reliability foundations. An arc may include one `secondary_surface` from the same vocabulary, or an empty string. The primary surface is the one that best explains the central judgment and effort, not every technology touched. ### Change type Choose one: `new-capability`, `integration`, `experience-improvement`, `architecture-refactor`, `migration`, `reliability-performance`, `incident-recovery`, `analysis-decision-support`, or `operational-automation`. ### Responsibility - `directed-task` — carried out a narrowly prescribed task; - `scoped-contributor` — made a bounded contribution within someone else's system or workstream; - `workstream-owner` — framed and drove a substantial outcome while coordinating dependencies; - `system-owner` — repeatedly made consequential decisions across a system's lifecycle. Set `reviewer_governor` to true only when the person repeatedly reviews, approves, sets standards, or protects system quality beyond their own implementation. Assign `confidence` as `high`, `medium`, or `low` based on source quality, repeated observations, and counterevidence. ## Step 5B — Derive an Operator Engineer badge profile Badges are evidence-backed descriptors, not a forced personality type. Organize them around the three parts of an ideal Operator Engineer: **Technical chops**, **Business know-how**, and **Good judgment**. A person may earn multiple badges, but each badge must be supported by its own qualifying evidence test. Apply the same rules to every person and never infer a badge from a job title, employer, preferred model, installed tool, token volume, session count, or GitHub activity alone. Use only the controlled badges below. Do not create synonyms, hybrid labels, seniority levels, or role titles. ### Technical chops — how the person builds - `prototyper` — repeatedly turns ambiguous ideas into functional artifacts that can be tried by a real user. Requires at least two `working-prototype` or stronger arcs. Production is neither required nor implied; - `frontend-crafter` — repeatedly demonstrates visual, interaction, responsive, accessibility, or design-system judgment on `experience-interface` work. Merely using React, CSS, a hosted builder, or an image model is insufficient; - `production-shipper` — repeatedly gets substantive changes into live use through observable merge, release, deployment, migration, or operating handoff evidence. A polished prototype, local app, staging URL, or plan is insufficient; - `systems-architect` — repeatedly makes explicit technical boundary, data-model, dependency, integration, migration, reliability, or component-ownership decisions that survive into implementation. General systems language without consequential design decisions is insufficient; - `context-engineer` — repeatedly structures, retrieves, refreshes, compresses, or hands off durable context through skills, memory, runbooks, retrieval, or deliberate context resets. Long prompts or large context windows alone are insufficient; - `agent-orchestrator` — repeatedly decomposes work across agents or parallel tool paths, scopes ownership, integrates results, and verifies the combined outcome. Spawning agents without synthesis or control is insufficient. ### Business know-how — what the person understands and translates - `workflow-architect` — repeatedly maps a real business workflow—including actors, decisions, exceptions, controls, and data movement—into a scalable operating system or automation. Generic automation without demonstrated process understanding is insufficient; - `value-translator` — repeatedly connects business goals, economics, KPIs, customer needs, or operating constraints to technical scope and prioritization. Requirements transcription without an observable tradeoff or outcome link is insufficient; - `clear-communicator` — repeatedly gives agents and collaborators a usable outcome, relevant context, material constraints, and a concrete definition of done; when correcting course, identifies what is wrong and what should change. Requires evidence across at least three substantive tasks and must consider visible clarification burden, avoidable rework, constraint stability, and decision closure. Politeness, confidence, verbosity, grammar, native-language fluency, long prompts, or an agreeable agent response are insufficient; - `adoption-operator` — repeatedly designs the handoff, training, governance, review cadence, change management, or operating loop that gets a system used after delivery. A one-time demo or documentation-only handoff is insufficient. Render evidence-backed industry and functional `domain_stamps` beneath Business know-how as specific domain badges—for example, `Professional-services finance ★★★`—but do not duplicate them as generic controlled badges. Career-only context remains labeled `Context only` and receives no proof stars. ### Good judgment — how the person decides, verifies, and stewards - `verification-first` — repeatedly uses an independent check before accepting output: automated tests, visual QA, source comparison, numeric reconciliation, production checks, or a second-agent audit. Self-report that something works is insufficient; - `tradeoff-navigator` — repeatedly makes an explicit, evidence-backed choice among competing approaches using constraints such as value, cost, latency, risk, maintainability, reversibility, or time. Preference without alternatives or consequences is insufficient; - `recovery-operator` — detects a real failure, diagnoses it, constrains the retry or rollback, restores a safe state, and changes the approach. Routine iteration or a successful first attempt is insufficient; - `systems-steward` — improves a live or established system over time through monitoring, maintenance, refactoring, reliability work, governance, or careful change. Shipping the initial release alone is insufficient. These boundaries are mandatory: - `prototyper` proves fast functional learning; `production-shipper` proves live delivery. Neither is a lower or higher level of the other; - `frontend-crafter` proves experience/interface judgment; it may coexist with either delivery badge; - `systems-architect` proves technical structure; `workflow-architect` proves business-process structure. Do not award both from the same generic architecture language; - `production-shipper` stops at getting the change live; `systems-steward` requires separate post-launch or established-system evidence; - `context-engineer` manages information supplied to agents; `agent-orchestrator` manages work distributed across agents. Tool presence alone earns neither. Badge proof is rule-based: - **1 star · observed** — exactly one concrete badge-specific episode, or several observations inside one narrow arc, with a direct citation and no claim of repeatability. This maps to `status: emerging`; - **2 stars · established** — badge-specific proof from at least two distinct qualifying work arcs, or one sustained arc containing at least three independent observations over at least 30 days, with at least one direct outcome and no unresolved material contradiction. This maps to `status: earned`; - **3 stars · demonstrated** — portable, independently repeated proof: at least three badge-specific qualifying arcs across at least two distinct systems or organizations and at least 90 elapsed days; at least two arcs must be `high` confidence; at least two must contain direct outcome, operation, review, or recovery evidence appropriate to the badge. Do not count multiple descriptions of the same decision, release, incident, or workflow as independent arcs. There is no two-arc shortcut. This maps to `status: earned`; - omit a badge when there is only generic language, tool presence, activity volume, or inference from absence; - production, stewardship, architecture, recovery, and adoption badges require direct evidence of those conditions. A polished prototype is not production evidence; - begin from zero badges. Never fill a pillar for balance, award a badge because it sounds directionally true, or treat missing counterevidence as positive evidence; - evaluate all 14 controlled badges independently. Retain every badge that clears the 1-star threshold in its pillar array and retain every remaining controlled badge under `badge_audit.not_awarded`. The union must contain each controlled tag exactly once; - the report may visually feature the three strongest earned badges, but visual emphasis must not change, suppress, or inflate the underlying rating. Badge labels are secondary to their cited evidence; - one evidence sentence may support only one controlled badge. One work arc may support multiple badges only when each badge cites a different observable decision, behavior, or outcome from that arc; - for every controlled badge, calculate and retain `proof_basis.arc_count`, `proof_basis.system_count`, `proof_basis.span_days`, `proof_basis.direct_outcome_count`, and `proof_basis.independent_observation_count`. Counts must be badge-specific, not copied from the overall profile; - for every 1- or 2-star badge, write a concrete `next_star_evidence` statement describing what additional independent proof would satisfy the next threshold. Do not write a generic encouragement; - for every badge that was not awarded, state the badge-specific reason and the missing evidence. Never use a display cap as the reason; - set `badge_audit.candidate_count` to `14`; set `awarded_count` to the number of controlled badges retained at one to three stars; and make `not_awarded` contain the remaining controlled tags so the arithmetic reconciles exactly; Stars measure the strength, breadth, and independence of the observed proof for that specific badge. They do not mean beginner/intermediate/expert, cannot be compared across badge families, and must never be summed into a person score. Show the legend `★ Observed · ★★ Established · ★★★ Demonstrated` once near the badge stack with the note `Stars show proof strength, not skill level.` For each retained controlled badge, record its Operator Engineer pillar, `proof_stars`, status, confidence, supporting `arc_ids`, one-sentence evidence statement, structured `proof_basis`, and `next_star_evidence` when below three stars. Derive status from proof stars exactly as specified above. When the same observation is offered for two badges, require the evaluator to state what independent decision or outcome supports each; otherwise keep only the more specific badge. ### Visible communication diagnostics The `clear-communicator` badge and interaction profile may use only visible user messages and visible conversational agent responses. Never read, request, reconstruct, summarize, or score hidden chain-of-thought, encrypted reasoning, system/developer instructions, or private agent annotations. Those records are provider-specific, may be unavailable, and are not a valid standardized signal. For at least three substantive tasks, examine: - **brief completeness** — whether the person supplies a usable outcome, necessary context, material constraints, and definition of done, either initially or through efficient progressive disclosure; - **clarification burden** — whether the visible agent repeatedly asks avoidable questions, restates conflicting interpretations, or cannot form a stable plan. Do not count necessary questions caused by genuinely missing external information; - **correction specificity** — whether feedback names the mismatch, preserves still-valid constraints, and gives a usable next direction instead of only saying the result is wrong; - **constraint stability** — whether tactics change because new evidence emerged or because the original objective was unclear. Informed adaptation is positive evidence; unexplained reversals are counterevidence; - **decision closure** — whether exploration ends in a clear choice, acceptance test, or next action; - **attribution caution** — an agent can misunderstand a clear request. Attribute confusion to communication only when the visible exchange supports that causal link, and retain counterexamples. Do not create a niceness, sentiment, intelligence, IQ, sophistication, grammar, or personality score. Tone may be described neutrally only when it materially changes collaboration. The report may say that visible communication is clear, ambiguous, direct, exploratory, stable, or correction-heavy; it may not claim the person is smart or not smart. ## Step 6 — Confirm the display name Infer the practitioner's likely name from `git config user.name` and the confirmed GitHub/LinkedIn identities, but do not lock it in yet. After source extraction is complete, ask: > I've finished the session analysis. What name should I use on the profile? Use that answer for the display name. Never use a GitHub or LinkedIn display name to override the user's answer. Do not include a portrait, contact details, profile URL, or social links in the finished file. ## Step 7 — 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". ### Badge stack Apply the work-arc rules from Steps 5A and 5B before writing the narrative. Present the badges as a complete evidence map grouped by Technical chops, Business know-how, and Good judgment. A pillar may have no earned badges; do not award filler badges for visual balance. Place specific functional and industry domain badges inside Business know-how, visually distinct from the controlled badges. Give each observed or earned badge a plain-language label, one to three proof stars, one short evidence marker, and either a structured `Why ★★★` proof-basis line or a concrete `Next star` line. Do not show confidence as a percentage or turn the map into a person score. Use filled stars only—`★`, `★★`, or `★★★`—and accompany them with an accessible text label such as `3 proof stars`. Show 1-star `emerging` badges in a visually quieter `Patterns still forming` row. Never present an emerging badge as a deficiency. Then show every unawarded badge as a compact gray card with its definition, `Why not`, and `Next proof`. Do not hide a badge because it is visually inconvenient. Badge terms are navigational lenses into evidence, not the report's main claim and not a substitute for work arcs, coverage, outcomes, or comparative activity. ### Work-arc evidence Select the three to five strongest normalized arcs that explain the badges. For each, show the abstract label, date span, and friendly labels for delivery state, system context, primary surface, change type, and responsibility, followed by one concise evidence statement. Mention uncertainty directly when confidence is low. Do not expose private project, repository, client, employer, or colleague names. ### Activity coverage and evolution Show a compact, descriptive timeline of captured activity. Only answer how the person's observable AI work changed when comparable same-source coverage supports that conclusion. - Lead with one coverage band per source: exact readable date range, captured session count, coverage days, and `Full available`, `Retention-limited`, or `Unknown retention`. - If source windows differ, do not present combined monthly bars as though they were one continuous population. Split the chart by source or visibly mark which sources contribute to each month and state that raw totals are not directly comparable. - Separate interactive sessions from scheduled automations and background/subagent runs. - Show monthly interactive activity, model mix, and two to four tool/platform categories whose use materially changed over time. - Show `Typical interactive load`, `95th-percentile concurrent load`, and `Peak concurrent load` using the 15-minute-bucket method. State the number of covered active days and never call this a multitasking score. - Show explicit context-pressure events and recoveries only when observable. Distinguish context-length failures from ordinary compaction and disclose incomplete error logging. - Write an evolution sentence only when `trend_status` is `supported`. When it is `partial` or `not-supported`, write a coverage sentence explaining what the captured window can and cannot show. - Never say a person adopted, switched to, moved from, or broadened into a tool merely because that source's readable history begins later. In particular, absence of pre-window Claude data is not evidence of no earlier Claude use. - Never imply that a newer model, more concurrency, more tool calls, token-limit failures, or scheduled volume is inherently superior. ### Observable interaction profile Characterize five independent interaction dimensions using visible conversational evidence: - **Task framing** — outcome, constraints, and acceptance criteria supplied up front versus discovered interactively; - **Context strategy** — front-loaded context, progressive disclosure, explicit source retrieval, refreshes, and handoffs; - **Direction and exploration** — prescriptive execution, collaborative exploration, or deliberate switching between them; - **Correction and recovery** — specificity of corrections, diagnosis, state restoration, retry constraints, and approach changes; - **Feedback and confirmation** — how the person acknowledges uncertainty, requests evidence, confirms consequential actions, and closes loops. For each dimension provide a neutral pattern label, one to three `proof_stars` using the same proof-strength meaning as badges, one concrete evidence sentence, and one limitation or counterexample when material. Stars show strength of evidence for the pattern, not whether the interaction style is good. Do not create an interaction-personality score, sophistication score, niceness score, or sentiment score. ### Project role Write a short paragraph describing the role created by the intersection of the work arcs and badges. 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. ### Working-style fingerprint Give the practitioner four compact, evidence-backed reads that are genuinely useful to another developer or project lead: - **Build / review / operate shape:** where their observed sessions concentrate, using categorical wording rather than a composite score; - **Agent collaboration pattern:** how they decompose work, direct tools or subagents, correct output, and retain judgment; - **Verification discipline:** which forms of tests, browser QA, production checks, or evidence review recur, plus any visible gap; - **Maintenance orientation:** whether the evidence shows one-off creation, iterative refinement, debugging, recovery, or long-lived stewardship. Each read gets one short finding and one concrete evidence marker. Do not reward raw activity. A high session or commit count cannot substitute for verification, ownership, or difficult judgment. Add a small `Evidence that would improve this profile` disclosure with two or three specific evidence types that would materially change a staffing conclusion. ### Agent toolkit and permission practice Make the person's operating environment visible without turning tool volume into a score. Show three compact surfaces: 1. **Tool mix** — group observed calls into `shell`, `filesystem`, `code-edit`, `browser-computer-use`, `search-research`, `version-control`, `deploy-infra`, `data-database`, `mcp-connectors`, and `subagents`. Classify each as `habitual`, `recurring`, or `situational` using active sessions, date coverage, and substantive use—not installed availability or raw call count alone. 2. **Reusable operating layer** — list skills, custom commands, MCP integrations, hooks, recurring automations, agent templates, and eval harnesses that were demonstrably `used`, `adapted`, or `created`. Distinguish a reusable asset from the general technical skills already listed elsewhere. 3. **Permission practice** — show source-specific metadata coverage, permission-mode distribution, explicit mode changes, and elevated requests by broad purpose. Include denominators. Then write one neutral finding about scope and guardrails, such as whether elevated actions are narrowly tied to deployment or system work, whether human confirmation gates recur, or whether the evidence is too incomplete to characterize. Permission interpretation rules: - never create a permission score or rank; - never reward frequent elevation, unrestricted modes, or bypass settings as evidence of expertise; - never penalize a restrictive environment or frequent prompts, which may be host policy rather than user choice; - distinguish environment-inherited modes from user-selected changes whenever the log supports it; - report approved and denied counts only when outcomes are explicit; otherwise use `unknown` rather than inferring; - do not expose command text, arguments, paths, target resources, URLs, account names, or credentials; - do not compare raw counts across harnesses with different logging and approval models; - state when permission metadata is unavailable or incomplete. ### Sources and limits Show one compact source strip for local sessions, GitHub, and LinkedIn. A fourth line may say `Cohort comparison — added by Overflow after submission`, but it must contain no data or placement. Put up to three useful limits in a collapsed `
` section. ### Quantified GitHub evidence When GitHub is included, show one headline conclusion, one annual activity graphic, and no more than three supporting facts. Do not show a weighted sum, score, gauge, ladder, version label, definition-audit label, confirmed-identity label, or unavailable enrichment. Explain any material counting discrepancy once. Do not repeat the annual numbers in a second timeline. ### Career history from LinkedIn Include this section only when LinkedIn mode is `included`. Render the career arc as responsive CSS rows or lanes with dates outside the label area; do not use a dense SVG timeline. Show role, organization, dates, and a short domain label. Use one sentence to explain the overall arc and one sentence at most to state where it aligns with or extends observed proof. Clearly label it self-reported. Do not use this section to change skill tiers. If `subject_matter.career_context_exposure` is present in the JSON, also include one `` / `` marker pair in the HTML so the uploader can verify and remove that local-only context safely; the marked block may contain only a non-visible HTML comment when no career-context row is shown outside the career section. ### Post-submission cohort comparison Do not fetch, calculate, estimate, embed, or display the cohort comparison in the local review file. Immediately after `Work profile` and before `Delivery evidence`, include exactly one compact callout wrapped in these exact comments: ```html
02 / After submission

Your cohort comparison appears after you submit.

Review the complete staffing report now. Overflow adds the anonymous distribution section to the stored report only after a successful upload.

``` Style the callout so it belongs to the report, but do not add a chart silhouette, marker, axis, sample curve, peer count, threshold, percentile, rank, or example placement. Do not add cohort data to the machine-readable JSON. Overflow replaces this marked callout in the stored report after submission. ### 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 and identify its source. GitHub repository metadata may establish long-term exposure or maintenance, but only local sessions or inspected local code can establish implementation depth. ### 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 Make subject matter a first-class staffing surface, not a single mixed list. Separate `Industry context` from `Functional expertise`. Industry context says where the work occurred; functional expertise says what operating problems the person can repeatedly reason about. Start with one sentence naming the person's strongest transferable subject-matter pattern. Then render a compact `Domain focus` chart and `Subject-matter atlas` with three to six functional domains observed in sessions and a quieter industry-context row when supported. For every domain stamp, classify depth as `Exposure`, `Repeated`, or `Deep`. `Exposure` means one concrete but narrow arc, `Repeated` means support across at least two arcs, and `Deep` means sustained ownership, difficult judgment, or repeated work under meaningful constraints. LinkedIn may supply local-only industry exposure, but only observed work can establish repeated or deep functional expertise. For each visible functional domain show its plain name, depth, one short description of the work, and a few concrete operating objects such as pipeline stages, project allocations, evidence records, publishing assets, or model choices. Keep detailed constraints, staffing implications, dates, and counts in the existing `domains` JSON for project matching. Do not repeat Project Fit inside each domain. The Domain focus chart is not an expertise score. For each industry and function show `proof_stars`, supporting work-arc count, and the share of classified work arcs that contain that stamp. Because one arc may support more than one domain, shares need not sum to 100%. Use direct labels and state the classified-arc denominator. Career-only LinkedIn exposure may appear locally as `Context only` with no proof stars, and must be removed on upload with the other LinkedIn context. Below the domains, show one plain-language sentence explaining what carries across them. Do not add a LinkedIn industry strip here; the career section already provides that context. ### 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. - **Outside the current evidence:** work the available history does not support claiming. ### Community framing Write one short community-facing introduction that emphasizes distinctive proof, contribution shape, collaboration patterns, useful domain context, and what other members could learn from or build with this person. Do not turn community membership into a competitive gate. Do not create an internal Runpoint interpretation, staffing-mode copy, or audience switch. ### Limits State the date window and session count per tool, unknown-project count, lower-fidelity sources, GitHub access/authentication/SSO limitations, LinkedIn inclusion state, retention limitations, ambiguous authorship, and major unobserved areas. Absence of evidence is not evidence of absence. ## Step 8 — Privacy pass Review the draft as a hostile privacy reviewer. Remove or abstract every person other than the practitioner; private client and product names; emails, phones, addresses, internal URLs, private repository and organization names, credentials, connection data, and private personal topics. When LinkedIn was included by choice, retain only the public career facts needed for the chronology and remove the LinkedIn URL itself. ## Step 9 — Render one HTML file Write `~/Desktop/project-fit-{name-slug}.html` and open it locally. The page must feel like an industrial-editorial experience atlas: a visual staffing instrument, not a resume, personal-brand landing page, or long-form technical report. A reader should understand the person's shape in under 30 seconds and choose where to inspect evidence next. - dark background `#0e0d0b`, alternate surface `#161411`, text `#f2eee6`, secondary text `#a89f90`, hairlines `#2a2620`, accent `#ff4d00`; - use a distinctive locally available condensed or grotesk face for display type, a restrained sans for body copy, and system monospace for labels and metadata; never make a remote font request; - use a constrained width around 1080px, asymmetric editorial composition, decisive type scale, thin rules, and one memorable visual motif that expresses the person's experience shape; - lead with the plain delivery characterization and concrete proof, not a wall of labels. Render observed and earned badges as compact visual credentials with family, exact label, semantic glyph, 1–3 proof stars, evidence, and calibration basis. Render unawarded badges in a quieter gray map with the reason and next proof. The visual hierarchy must make `Prototyper` meaningfully different from `Production shipper`, and must not imply that one is a lower level of the other; - use a small number of purposeful surfaces rather than a repetitive card grid. No gradients, glassmorphism, gauges, radar charts, progress bars, global scores, testimonial language, or generic dashboard KPI tiles; - keep the visible reading path terse: no paragraph longer than two sentences; no section with more than roughly 80 words before an optional `
` disclosure; prefer labels, short findings, timelines, matrices, and comparison strips over prose; - responsive at 360px width with no horizontal overflow; - no remote scripts, tracking, web fonts, inline event handlers, or automatic external requests. Use no remote images, logos, or profile links; - use inline SVG only where a true data graphic earns its space. Prefer CSS grid/flex rows for career and history timelines so labels can reflow. For SVG charts, use direct labels, no legends, no top/right borders, minimal or no gridlines, one orange highlight, and a text alternative or `aria-label`; - never position prose labels inside a chart's mark area. Put finding/value labels above the chart and fixed-domain endpoint labels in a dedicated row below it. At narrow widths, stack those labels or switch to a vertical layout rather than shrinking them into collisions; - add restrained CSS-only motion to establish hierarchy, with `prefers-reduced-motion` support. CSS hover/focus states and `
` are allowed; - include one tasteful CSS-only easter egg in the Overflow mark or footer that does not hide necessary information; - every visual must remain legible at 320px, 360px, 768px, and 1440px, in print, and without color as the sole differentiator. Perform visual QA at desktop and 360px before handoff, checking text collisions, clipping, overflow, and chart-label separation. 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
Private preview. Nothing has been uploaded. Review this page before sharing it.
``` Visible sections, in this order: 1. compact Overflow site header with the outlined orange square `O`, `Overflow / Austin`, an absolute `Visit Overflow ↗` link, the generation date, and `Private preview`; never show prompt or schema versions; 2. name, focus line, and one short community-facing introduction. Do not include an audience or staffing toggle; 3. **Operator Engineer evidence map** — observed and earned badges grouped by Technical chops, Business know-how, and Good judgment; specific domain badges nested under Business know-how; badge-specific proof stars and calibration basis; the one-time legend; every unawarded badge in a gray `Why not / Next proof` map; and the short staffing read. Pillars are independent and badges are not levels on one ladder; 4. **After submission** — place the exact marked cohort callout immediately after Work profile and before Delivery evidence. It may say that the anonymous distribution section will appear after a successful upload, but it must contain no sample or personal placement data; 5. **Delivery evidence** — three to five normalized work arcs, presented as compact evidence rows rather than project case studies; 6. **Activity coverage** — source-specific retention windows first, then comparable interactive-versus-scheduled activity, model/tool observations, concurrency, and context pressure. Call it evolution only when the required same-source coverage supports a trend. Descriptive, never a score; 7. **Interaction profile** — the five observable interaction dimensions with pattern labels, proof stars, evidence, and material counterexamples; 8. **How you work** — a compact build/review/operate, agent-collaboration, verification, and maintenance fingerprint. Fold the strongest skills and practices into this section instead of adding another matrix; 9. **Agent toolkit** — tool mix, reusable operating layer, and source-separated permission practice. Prefer a compact matrix or ledger; show denominators and a neutral guardrail finding rather than a score; 10. **Domain focus & subject-matter atlas** — proof-strength/arc-coverage chart, functional expertise, separate industry context, operating problems, concrete operating objects, and one plain-language sentence about what carries across domains. Collapse each domain row to two columns at tablet width and one content column at phone width; never allow operating-object labels to create horizontal page scroll; 11. **GitHub activity** when included — one conclusion, one annual visual, and at most three supporting facts. Never show internal characterization labels, unavailable stewardship, or confirmed identity; 12. **Career history**, when LinkedIn is included — responsive chronology rows. Wrap the entire visible section in `` and `` comments; 13. **Project fit** — lens emphasis, good fit, bring a specialist, outside the current evidence, and the `Evidence that would improve this profile` disclosure; 14. **Keep or share this profile** — the exact marked direct-upload panel. It must remain local-only and send nothing before an explicit user click; 15. compact **Sources & limits** disclosure. Fold adjacent-role comparisons into Work profile or Project fit rather than giving them a full prose section. Keep lower-confidence tools, fine-grained language chronology, source limitations, calculation notes, versions, policy names, API details, and generation mechanics inside JSON or omit them. Do not repeat claims. Add the following direct-upload control near the end of the body. Keep the marker comments, element IDs, endpoint, field names, consent behavior, and no-request-before-submit behavior exact. You may style the marked section and its child elements to match the report, but do not change its functionality. This entire block is removed from stored and public reports after upload. ```html
Keep or share

Add this reviewed profile to Overflow.

Only the structured profile payload embedded in this file is sent—never the surrounding HTML, CSS, JavaScript, raw sessions, prompts, repositories, or credentials. Overflow renders the stored report from that normalized payload. You choose whether it stays private or appears in the community.

Visibility

``` The upload form is the only code in the local report allowed to make an external request, and only inside its explicit submit handler. Do not prefill email or LinkedIn, do not write form values into the profile JSON or DOM attributes, and do not send analytics from the local file. Include this exact machine-readable block, populated with real values: ```html ``` 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 10 — Hand off Delete temporary digest files, open the HTML, and tell the user: - where the file is; - the local-session and GitHub date ranges; - whether LinkedIn was included; - that nothing was uploaded; - to review the page before sharing it. Keep this handoff to four short sentences. Do not mention prompt versions, schema versions, API contracts, internal policy names, characterization labels, coverage fields, or unavailable optional signals.