Profile Me

Profile Me

Build an honest portrait of the user as a person — not a resume summary, not a list of their tech stack. The default goal is personality, not credentials.

Most developers who run this skill have conversation histories dominated by coding work. That data is real but misleading as a personality source — it's what they did at the desk, not who they are. The skill must look through the work to find the person.

Inspired by Orson Scott Card's Speaker for the Dead: tell the truth about who someone is — not to flatter, not to judge, but to understand and serve.

Core principles:

• Person over practitioner. Unless a professional portrait is explicitly requested, keep

work out of it. Technical skills, frameworks, and job history are not the subject.

• Truth over comfort, kindness over cruelty. Report what the evidence shows. Frame it with

respect. Never sanitize away a real pattern, but never weaponize one either.

• Evidence-based. Every claim should trace to observable data. If it can't be evidenced,

flag it as inference and explain why.

• Short and true beats long and restated. A portrait that captures three real things is more

useful than one that pads with professional biography. If the evidence is thin on a dimension, say so and move on.

When to Use

Trigger on requests like:

• "profile me", "build my profile", "get to know me"
• "create my AI profile" or "build my context document"
• "make a system prompt about me"
• "help another AI get to know me"
• "build a working-with-me guide"
• "what do you know about me"

Not this skill: "update my resume", "write my LinkedIn bio", "describe my tech stack" — those are professional documents, use a different prompt or request the Professional Portrait explicitly.

Data Collection

Privacy Gate

Before reading ANY data, briefly tell the user what categories of data will be examined (conversation history, shell config, git config, project files, SSH config, AWS config) and ask: "Anything you'd like me to skip?"

This is a one-time check, not a per-file approval. Most users will say "go ahead" but some may exclude SSH config, AWS accounts, or specific directories. Respect exclusions completely — don't reference excluded data even indirectly.

Phase 1: Discovery

Before analyzing anything, map what data sources exist. Not all users will have all sources. Run discovery in parallel where possible.

Source 1: AI Agent Conversation History

Probe for each and read what exists. Don't assume any particular agent is installed.

| Agent | Path | Format | User message field | |-------|------|--------|-------------------| | Claude Code | ~/.claude/history.jsonl | JSONL | display | | Aider | **/.aider.chat.history.md (per-project) | Markdown | lines after #### human | | OpenCode | ~/.local/share/opencode/opencode.db | SQLite | message table, data col (JSON) | | Copilot Chat (VS Code) | ~/Library/Application Support/Code/User/globalStorage/github.copilot-chat/**/*.jsonl | JSONL | v.requests[].message | | Gemini CLI | ~/.gemini/ | metadata only | no conversation data stored locally | | Cursor | ~/Library/Application Support/Cursor/User/globalStorage/ | SQLite/JSONL | similar to VS Code | | Windsurf | ~/Library/Application Support/Windsurf/User/globalStorage/ | SQLite/JSONL | similar to VS Code | | Continue.dev | ~/.continue/ | JSON sessions | messages[].content where role=user | | ChatGPT (desktop) | ~/Library/Application Support/ChatGPT/ | SQLite | varies | | Amazon Q | ~/.aws/amazonq/ | varies | varies |

Discovery commands:

# Check which agents have data
ls ~/.claude/history.jsonl 2>/dev/null && echo "claude-code"
find ~/dev -name ".aider.chat.history.md" -maxdepth 4 2>/dev/null
ls ~/.local/share/opencode/opencode.db 2>/dev/null && echo "opencode"
ls "~/Library/Application Support/Code/User/globalStorage/github.copilot-chat/" 2>/dev/null && echo "copilot-chat"
ls ~/.continue/ 2>/dev/null && echo "continue"

Source 1b: Claude Code Environment

~/.claude/CLAUDE.md                          # Global instructions — personality, preferences, rules
~/.claude/settings.json                      # Tool preferences, model choices
~/.claude/projects/*/memory/                 # Per-project memories (feedback, user, project, reference types)
~/.claude/projects/*/memory/MEMORY.md        # Memory indexes
~/.claude/agents/                            # Custom agent definitions
~/.claude/skills/                            # Installed skills
~/.claude/bin/                               # Custom scripts and tools

Source 2: Personal Expression (prioritize these over work repos)

~/dev/me/ (or personal equivalent)          # Personal/side projects — names, themes, what they chose to build
~/.local/share/chezmoi/ or ~/dotfiles/      # Dotfiles — configuration as aesthetic choice
~/cloud/ or ~/notes/ or ~/Documents/        # Personal notes, writing, Obsidian vaults
~/.zshrc or ~/.bashrc                       # Aliases and functions — naming reveals personality
~/dev/me/*/README.md                        # Personal project READMEs (distinct from work)

Skip for personal profile: Work repositories (~/dev/ excluding personal dir), work project READMEs, CI configs, deployment files. These describe the job, not the person.

Source 3: Shell & System Configuration

~/.bashrc or ~/.zshrc                        # Shell config — aliases, functions, env vars, PATH
~/.bash_profile or ~/.zprofile               # Login shell config
~/.gitconfig                                 # Git identity, aliases, preferences
~/.ssh/config                                # Connection patterns (work vs personal hosts)
~/.aws/config                                # Cloud account structure (if applicable)

Source 4: Conversation History Analysis

Harvest user messages from every agent source found in Source 1. Each format requires different extraction:

• Claude Code (history.jsonl): jq -r 'select(.display != null and (.display | length) > 20) | .display' ~/.claude/history.jsonl
• Aider (.aider.chat.history.md): extract lines after #### human markers
• OpenCode (SQLite): sqlite3 ~/.local/share/opencode/opencode.db "SELECT data FROM message" then parse JSON for role=user
• Copilot Chat (JSONL): parse v.requests[].message from session files
• Continue.dev: parse messages arrays from session JSON files, filter role == "user"

Combine all sources into a single corpus before analysis. Deduplicate by content where the same text appears across agents. Note which agents were most active — tool diversity is itself a signal.

Extracting personality from work-heavy histories

Most developers' conversation histories are 90%+ coding requests. Don't profile the work — look for the person between the work. Specifically look for:

• Off-task moments — when they stop asking about code and say something else entirely
• Named frustrations — what they express irritation about (process? quality? ambiguity? people?)
• Humor — dry, self-deprecating, absurdist, pedantic? Look at how they frame problems
• What they name things — project names, function names, variable names, alias names reveal aesthetic sense
• How they handle being wrong — defensive, curious, matter-of-fact, amused?
• What triggers verbosity — a terse person who suddenly writes three paragraphs is showing you what matters to them
• Correction patterns — "no, that's not what I meant" style reveals communication expectations
• What they tolerate vs. what they push back on — the line between patience and impatience
• Energy signatures — excitement markers, relief ("perfect"), disappointment ("ugh"), satisfaction ("exactly")
• Delegation style — terse goals? detailed specs? thinking-out-loud as they type?

For the personal portrait, weight these signals more heavily than project counts or framework choices. A list of technologies is a LinkedIn section. The texture of how someone talks is a personality.

Extract from the combined corpus:

• Message length distribution — terse vs. verbose; and when each occurs
• Vocabulary patterns — formality level, humor frequency, domain bleed from personal interests
• Emotional signals — caps usage, punctuation patterns, frustration/excitement markers
• Typo patterns — fast and impulsive vs. careful and deliberate
• Agent preference patterns — what tasks they route to which tool (reveals mental model of AI)

Phase 2: Deep Reading

Read all discovered sources. Use subagents to parallelize across categories:

• Agent 1: Memory files and MEMORY.md indexes (feedback, user-type, and project memories — skip reference-only)
• Agent 2: Global CLAUDE.md/AGENTS.md only (not per-project — those describe work, not person)
• Agent 3: Shell/git/system configuration (aliases, functions, git identity, dotfiles aesthetic)
• Agent 4: Conversation history — personality pass (see sampling guidance below)
• Agent 5: Personal notes, Obsidian vault, personal writing, personal project READMEs
• Agent 6: Personal side projects — names, themes, what they chose to build unprompted

Conversation history sampling for personality: Sample broadly in time (beginning, middle, recent), but filter aggressively for personality signals. Skip: pure code requests, bug descriptions, "add X to Y", pasted content. Keep: opinions, frustrations, humor, naming choices, how they frame problems, off-task remarks, how they respond to errors, what they thank you for, what they push back on. Target 40-80 messages that would survive the filter "does this tell me something about who this person is?"

Analysis Framework

After collecting data, analyze across these dimensions. See references/analysis-framework.md for the full analytical rubric with questions and evidence patterns for each dimension.

Dimensions

For personal portrait (default): use dimensions 3–7 only. Dimensions 1–2 belong in the Professional Portrait.

1. Professional Identity (Professional Portrait only) — Role, seniority, domain expertise, career trajectory
2. Technical Profile (Professional Portrait only) — Languages, frameworks, infrastructure, architecture patterns
3. Communication Style — Formality, verbosity, humor, emotional expression, delegation patterns
4. Cognitive Style — How they approach problems, make decisions, handle uncertainty, what excites vs. bores them
5. Values & Priorities — What they actually optimize for (vs. what they say they do), what frustrates them, what impresses them
6. Creative & Personal — Side projects, hobbies, interests, aesthetic preferences, what they build when nobody's watching
7. Relational Patterns — How they interact with collaborators (human or AI), how they give feedback, what they expect, what they appreciate

Bias Guardrails

During analysis, actively guard against:

• Halo effect: A person's technical skill doesn't mean they're right about everything. Note

areas of strength AND areas where evidence is thin.

• Confirmation bias: Don't cherry-pick messages that support a narrative. If someone is

usually terse but occasionally writes long thoughtful messages, report both patterns.

• Flattery creep: It is tempting to write profiles that read like recommendation letters.

Resist. Report patterns as patterns. "Prefers to work fast and sometimes skips testing steps" is more useful than "moves at an impressive pace."

• Deficit framing: Don't frame neutral traits as problems. Terse communication is a style,

not a flaw. Heavy side-project activity is a pattern, not workaholism (unless there's evidence of burnout).

• Gender/identity assumptions: Use the pronouns and identity markers the person uses in

their own writing. If unclear, use their name or "they."

• Projection of values: If someone doesn't write tests, don't assume they don't value

testing — maybe they just test differently. Let evidence speak.

• Recency bias: Don't over-weight recent conversations. Someone's most active project this

month may not reflect their long-term identity.

Output Documents

Default output: Personal Portrait + System Prompt. Always produce these two unless the user says otherwise.

Offer the Working-With-Me Guide and Professional Portrait as opt-in extras — mention them briefly after presenting the defaults. Do not produce a Professional Portrait unless explicitly requested.

Store outputs in the user's preferred temp/output directory.

1. Personal Portrait (portrait-personal.md)

The "Speaker for the Dead" document. Who this person really is — not their resume, their self.

Structure:

• Opening: 2-3 sentences that capture the essence (the "if you only read this" summary)
• How they think — cognitive patterns, decision-making style, what energizes vs. drains them
• What they care about — values evidenced by behavior, not stated values; the gap between the two if it exists
• The texture — humor, aesthetic taste, naming choices, the small things that make them them
• What they make when nobody's asking — personal projects, creative output, things they chose unprompted
• Closing: The through-line — what connects all of this into a coherent person

Do not include: tech stack, job history, professional credentials, languages/frameworks. Those belong in the Professional Portrait. If a work pattern is genuinely revealing about personality (e.g., obsessive perfectionism about performance), note the personality trait, not the technical fact.

Critical writing prompts:

• Find the central tension. Every person has a defining contradiction — two forces that

coexist and drive them. The person who starts 45 projects but writes "I want stability." The person who moves fast but insists on dry-run defaults. Name it explicitly. The tension IS the person — don't resolve it, honor it.

• Identify the most revealing single data point. Across all the evidence, one fact will tell

you more about this person than any paragraph of analysis. An essay title, a shell function name, a project they keep coming back to, a correction they made. Find it and let it anchor the portrait.

• Longer messages are diagnostic. When a typically terse person writes at length, pay

attention to what triggers verbosity. It usually reveals what they're protecting or what genuinely excites them.

Tone: Warm but honest. Like a close friend who knows you well enough to be truthful. Never sycophantic, never clinical.

2. Professional Portrait (portrait-professional.md) (opt-in only)

Do not produce this by default. Only generate if the user explicitly requests it (resume help, LinkedIn, interview prep, "what's my tech stack", etc.).

The document a hiring manager, recruiter, or professional contact should read.

Structure:

• Role and positioning (current + aspirational)
• Technical depth — languages, frameworks, cloud, architecture, with evidence of depth level
• Domain expertise — industries, compliance frameworks, specialized knowledge
• Leadership signals — team building, mentoring, architectural decision-making
• Project portfolio — work AND personal, showing range and initiative
• Working style — how they operate day-to-day, what kind of team/org they thrive in

Proficiency calibration: For each technical area, assign an evidence-based depth level:

• Expert: Daily use, custom tooling, deep configuration, architectural decisions.

Evidence: high session counts, detailed CLAUDE.md, performance optimization work.

• Proficient: Regular use, comfortable across the surface area, some customization.

Evidence: moderate session counts, working configurations, shipped projects.

• Familiar: Has used it, can navigate it, reaches for it when appropriate.

Evidence: occasional sessions, follows e

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: carlkibler
• Source: carlkibler/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.