Developer Profile

Build a comprehensive developer profile by combining git commit activity with Claude Code session data. The result paints a full picture: what you build, when you build it, how you use AI assistance, and where your focus goes.

How it works

A collection script at scripts/collect.py in the plugin root scans git repos for commit metadata and reads the Claude Code session files of every profile. It outputs a single JSON payload with two top-level sections: git and claude. It needs Python 3.9 or later and nothing outside the standard library.

• Commits: the window starts at local midnight on the --since day, and each commit is dated by its author date, so rebased commits keep their original day. A commit is counted once across clones (by hash) and once within a repository (by author email, author date and subject, which drops rebased copies). Stashes are not commits. Repositories that share a directory name are counted together.
• Profiles: ~/.claude, every ~/.claude-* directory and $CLAUDE_CONFIG_DIR, each only when it has a projects/ directory, deduplicated by physical path. --config-dir PATH (repeatable, ~ expanded) scans only the given directories instead, and warns on stderr about any without projects/. claude.profiles_scanned always lists the profiles read; when the window has no sessions it is the only claude key.
• Copied sessions: profiles often hold copies of the same session file. Copies are grouped by their path relative to projects/. The largest copy is read, plus any copy of a different size (a session resumed in another profile), and user/assistant entries are unioned by uuid, so every message counts once. Copies last modified before --since are skipped.
• Titles: a session's title is its last custom-title entry; when copies disagree, the largest copy wins.
• Local time: every date, hour, weekday and week in both sections is in the machine's local time zone, so git and Claude patterns line up.

Step 1: Collect the data

The script is <skill base dir>/../../scripts/collect.py, where the skill base directory is the one printed when this skill loads.

Run it on ~/Local/ unless the user names another directory. The script auto-detects the git author and defaults to the last 90 days, which takes about 30 seconds; give wider --since ranges a longer Bash timeout.

python3 <skill base dir>/../../scripts/collect.py ~/Local/ --format json

Override if the user asks for a different time range, author or profile. --since takes an ISO date such as 2025-01-01 (relative dates like 3 months ago are rejected):

python3 <skill base dir>/../../scripts/collect.py ~/Local/ --since 2025-01-01 --author 'Someone Else' --config-dir ~/.claude-work

Step 2: Interpret and present

The JSON output has two top-level keys: git and claude. Use both to build a unified profile. Cross-reference them — the most interesting insights come from correlating the two (e.g., "You use Claude most heavily on the repos where you commit the most fixes" or "Your Claude sessions peak at 22:00, exactly when your commit volume spikes").

Git section (git)

Summary

• Total commits, active repos, date range, commits per day
• Weekend vs weekday split — surface this if skewed
• Busiest single day — call it out with context

Streaks

• Current streak and longest streak
• If the current streak is strong, celebrate it. If it broke recently, note when.

Repo breakdown (by_repo)

• Rank by commit volume. Group into tiers: heavy focus, moderate, light touch.
• Call out repos that appeared suddenly (new projects) or went silent.

Weekly/monthly trends (by_week, by_month)

• Spot acceleration or deceleration. Which weeks were peak output?
• Correlate spikes with specific repos using by_repo_week.

Time-of-day patterns (by_hour, by_time_bucket)

• Early bird or night owl?
• Distinct work sessions (morning burst, evening push)?
• Use by_repo_hour to see if different repos get worked on at different times.

Day-of-week patterns (by_day_of_week)

• Which days are heaviest? Weekend work?
• Surprising gaps?

Commit types (by_type)

• Features vs fixes vs refactors vs chores?
• Use by_repo_type to show how work type varies by project.

Vocabulary (top_words)

• Domain themes from commit messages.

Repo context (repo_context)

Every repository with commits in the window has an entry, including a clone whose commits all count toward an earlier clone, so repo_context can name repositories that by_repo leaves out.

• branch: Current branch name — reveals active work.
• recent_subjects: Last 20 commit subjects — summarize themes in plain language.
• uncommitted: modified, added, deleted, renamed and untracked paths — hints at active WIP.

Claude section (claude)

Automated runs are sessions started through the Agent SDK that have no typed prompt: their main entries carry entrypoint sdk-py, sdk-ts or sdk-cli (the CLI run non-interactively, as with claude -p), which is how scripts and pipelines drive Claude Code. They count toward the cost keys (total_cost_usd, cost_by_model, unpriced_models and cost_by_week) and are summarised in automated_sessions. Every other key, from total_sessions to top_session_words, covers interactive sessions only.

Summary

• Total sessions, estimated cost (pay-as-you-go rates, not actual spend on flat-rate plans — note this when presenting). total_cost_usd includes automated runs; average_cost_per_session is per interactive session.
• Total turns, average turns per session. A turn is a prompt typed into a main session; tool results, meta and compact-summary entries, harness messages (task notifications, command output, CI events, interrupt markers), prompts sent to subagents and prompts a program sends through the Agent SDK (promptSource is sdk and origin.kind isn't human) don't count.
• Total tool calls, average tools per session
• Active days and sessions per active day. With only automated runs in the window, total_sessions is 0 and date_range is null.

Automated runs (automated_sessions)

• sessions counts the automated runs and cost is their share of total_cost_usd.
• When there are any, report them on one line of their own (how many runs, what they cost, their share of spend) and keep them out of the habits you describe.

Cost by model (cost_by_model, unpriced_models)

Costs use the list prices from the pricing page (PRICING_SOURCE in the script):

• Cache writes are billed at the 5-minute or 1-hour rate from the cache_creation breakdown; without a breakdown, all cache_creation_input_tokens are billed at the 5-minute rate.
• Fast mode (usage.speed is fast) uses the fast rates for Opus 5.5, Opus 5 and Opus 4.8. US-only inference (usage.inference_geo is us) costs 1.1×.
• Claude Code writes one entry per content block of an API response, and only the last one carries the final usage; earlier ones hold a running output count and no speed. So each response is priced once per message.id (the entry's uuid when there is none), from its entry with the most output tokens (the later one on a tie) across every copy read, while message counts stay per entry.
• cost_by_model maps each canonical model (such as claude-opus-5-5, with [1m] and date suffixes stripped) to USD, most expensive first.
• unpriced_models maps each model without a known price, by raw name, to its assistant-message count. Such models are never priced as another model, so a non-empty map means the total understates spend — say so.
• <synthetic> costs nothing and appears in neither.

Duration (duration)

• Median, average, and max active minutes per interactive session. Active time adds up the gaps between a session's entries, subagents included, and counts any gap longer than 15 minutes as 15, so a session left open or resumed days later only counts the time it was in use.
• total_hours: wall-clock active time across interactive sessions, so parallel sessions count once.

Data sources (data_sources)

Each session is tagged with how its data survived:

• main+subagent — both parent session file and subagent data present (recent sessions)
• main-only — only the parent session file
• subagent-only — parent was cleaned up by Claude Code's retention, only subagent data survived

A high subagent-only count for older periods (Jan–Feb 2026 and earlier) is expected — Claude Code silently cleans up older projects/*.jsonl files but leaves subagents/ subdirs alone. For periods before the subagent feature started persisting (~Jan 9, 2026), neither survives, which is why you may see gaps in Nov–Dec 2025 even though history.jsonl has entries for that range.

If the user asks about gaps in the timeline, explain this cleanup behavior. Don't pretend the gap is because they weren't using Claude — they were, the data just got purged.

Models (models)

• Which models are used and how often. Is the user an Opus user, a Sonnet user, or do they switch based on context?
• <synthetic> entries are Claude Code's internal messages (hooks, system events) — not real API calls. Note their share but don't attribute cost to them.

Tool usage (tools)

• Ranked tool counts. Which tools dominate (Bash, Read, Edit, Grep, Glob, Agent, etc.)?
• High Bash usage suggests scripting-heavy workflows; high Agent usage suggests delegation patterns; high Edit vs Write suggests iterative refinement.

Skills (skills)

• Which slash commands / skills are invoked. Shows workflow preferences.

By project (by_project)

• Sessions, cost, turns, and tool calls per project, named after the session's working directory. A session in a worktree under <repo>/.claude/worktrees/ counts toward <repo>.
• Cross-reference with git by_repo — which repos get the most AI assistance relative to their commit volume? A repo with many commits but few Claude sessions is "manual" work; one with few commits but many sessions is "AI-assisted" or exploratory.

By project hour (by_project_hour)

• Do different projects get Claude help at different times? Covers the 10 projects with the most sessions.

Hourly / daily / weekly patterns (by_hour, by_day_of_week, by_week)

• Compare with git patterns. Do Claude sessions happen at the same hours as commits, or different?
• Claude-heavy weeks vs commit-heavy weeks — do they correlate or alternate?

Cost trends (cost_by_week)

• Spending trajectory. Increasing, stable, or decreasing?
• Correlate spikes with specific projects or high-commit weeks. Automated runs are in these totals but not in by_project.

Session vocabulary (top_session_words)

• What themes emerge from session titles? Domain terms, action words.
• Compare with git commit vocabulary — are the same themes present, or does Claude get used for different work than what gets committed?

Presentation guidelines

Lead with 3-5 bold headline insights. The best insights cross-reference git and Claude data:

• "You spent $X on Claude this month, mostly on [project] — which is also your highest-commit repo"
• "Your Claude sessions peak at 1am but your commits peak at 10pm — you research late, commit earlier"
• "You use Opus for [project] but Sonnet for [project] — the complex backend gets the big model"
• "[Project] has 3x more Claude sessions per commit than any other repo — heavy AI assistance there"

Spend figures include automated runs, while session, project and timing figures are interactive only, so when a headline pairs spend with sessions or projects, say how much of the spend was automated.

After the headlines, present two detailed sections (Git Activity, Claude Usage) with tables and plain language analysis. Then a combined "Cross-reference" section that ties the two together.

If the user asks for CSV output, run the script with --format csv instead — this outputs the git repo-weekly grid only, one row per ISO week such as 2026-W53.

Keep it concrete. Reference specific repos, weeks, numbers, and dollar amounts. Avoid filler.