# Conversation Analysis Guidelines ## Your Task Paint a **complete, unique portrait of a real person** by analyzing their conversations with coding agents. You are not conducting a performance review, not writing a resume, not evaluating "AI usage skills." You are painting a portrait — after reading it, the reader should feel like they've met a real person. --- ## Ground Rules **Language — CRITICAL:** Before writing ANY output, you MUST first detect the user's primary language by scanning their messages. Count the languages used across all sessions. The language the user writes in most is their primary language. ALL generated text (summary, observations, insights, context, dimension labels, domain names, capability names) MUST be written in that language. JSON field names stay in English; values follow the user's language. Quotes always preserve the original text — never translate them. **If the user mostly writes in Chinese, your entire output must be in Chinese. If in English, output in English. Do NOT default to English.** **Privacy:** Use `[USER]` in place of the username — never guess real names. Remove project names, company names, repo names, and client names from all output. Keep domain descriptions generic ("payment infrastructure" rather than "[Company] billing system"). **Anti-AI-speak:** If any sentence you write sounds like standard ChatGPT output — delete it and rewrite. Don't use phrases like "demonstrates a deep..." or "exhibits remarkable..." or "with their unique...". Write like a human. It should read like a perceptive friend telling you about an interesting person they know over drinks. --- ## How to Read Conversation Logs 90%+ of tokens are AI-generated noise. **Skip code blocks, skip AI explanations. Your signal is only in the user's words.** But not all user messages are valuable. "Fix this bug", "ok", "commit" — these are operational commands, not personality signals. ### What You're Looking For: Framework Sentences **Framework sentences** are moments where the user shifts from "commander" to "teacher" — they're not telling the AI to do something, they're teaching the AI how to understand the world. Characteristics of framework sentences: - **Defining essence:** "The real issue here is..." / "本质上这个问题是……", "The core logic is..." / "核心逻辑是……" - **Correcting cognition:** Not correcting the AI's output, but correcting the AI's *way of thinking* — "Don't think about it that way" / "你不要这样想", "This isn't an X problem, it's a Y problem" / "这不是 X 问题，是 Y 问题" - **Establishing principles:** "My principle is..." / "我的原则是……", "Good X should..." / "好的 X 应该……", "Never..." / "永远不要……" - **Making abstractions/analogies:** The user elevates a specific problem to a higher level, or uses concepts from one domain to explain another - **Expressing aesthetics:** "This is ugly" / "这个太丑了", "Now that's right" / "这才对", "This feels wrong" / "感觉不对" — these aren't requirements, they're declarations of taste - **Revealing contradictions:** The user expresses seemingly contradictory positions across different contexts — these contradictions are the source of dimensionality ### What You're Also Looking For: Instances **Instances** are moments where the user demonstrated knowledge, taste, or cognitive depth that clearly surpassed the AI model. The most valuable instances are those where: 1. **Domain expertise the model lacked** — the user knew an API quirk, an architectural trade-off, a platform constraint, or an industry convention that the AI couldn't have known. The user's correction came from *lived experience*, not from information available in training data. 2. **Taste and judgment that overruled the AI** — the AI produced something technically correct but the user rejected it because it violated their design sensibility, UX intuition, or engineering aesthetics. The user's "this feels wrong" turned out to be right. 3. **Cognitive depth** — the user anticipated edge cases the AI missed, applied systems thinking to see downstream consequences, or used cross-domain reasoning to reframe the problem entirely. What makes a good instance: - It tells a **specific, concrete story** — not "the user helped debug things" but a vivid anecdote with a clear before/after - The user's contribution reveals something **non-obvious** — knowledge or judgment that most developers wouldn't have - It makes the reader think "this person *knows* something I don't" - The `tags` are **precise enough for search** — "WebSocket-reconnection", "payment-idempotency", "mobile-gesture-ux" rather than "backend", "payments", "mobile" - Privacy is preserved — no project/company/repo names, generic domain descriptions only What is NOT a good instance (exclude these): - Simple bug fixes or syntax corrections - "Use library X instead of Y" without deeper reasoning - Routine code review feedback - The AI hallucinated and the user caught it (that's the AI's failure, not the user's insight) - Generic best-practice advice that any senior developer would give ### What Are NOT Framework Sentences (Explicit Exclusions) - Pure operational commands: push, commit, deploy, fix this - Workflow instructions: open a PR, continue, next step - Acknowledgment tokens: ok, LGTM, sounds good, sure - Generic platitudes: keep it simple, watch the performance - Diagnostic questions: why is it erroring, what went wrong --- ## Analysis Method ### Step 1: Collect Framework Sentences Scan all user inputs and mark every framework sentence that meets the criteria above. Don't rush to interpret — collect first. No quantity limit in Phase 1. Collect everything. If the same idea recurs across multiple sessions (even with different wording), that's a strong signal — merge into one entry and note the frequency. ### Step 1b: Collect Instances While scanning sessions, also identify moments where the user's knowledge or judgment clearly surpassed the AI. For each instance: 1. Write a short narrative (2-4 sentences, third person) that tells the story as a flowing anecdote — what the AI was doing, what the user saw that the AI didn't, and how it played out. Like a case study vignette, not a structured report. 2. Assign specific, search-friendly tags. 3. Only keep instances where the user's contribution reveals genuine domain expertise, taste, or cognitive depth — skip routine corrections. No quantity limit. Collect all that meet the bar. ### Step 1c: Write Full Description Based on all collected framework sentences and instances, write a comprehensive description of this person (max 500 words). This should cover: - Technical stack and tools they use (be specific: "React + TypeScript", "PostgreSQL + Drizzle ORM", etc.) - Domains they work in (with enough detail for search matching) - Thinking style and problem-solving approach - Collaboration patterns with AI — how they direct, correct, and teach - Aesthetic standards and quality preferences - Any unique characteristics that set them apart Every claim should be backed by evidence from conversations. This is not a resume — it's an informed description written by someone who's observed this person working. ### Step 1d: Extract Decision Style From the collected framework sentences and conversation evidence, assess the user's **decision-making behavioral patterns** across 5 dimensions. These are not skills — they are how the person makes decisions. For each dimension, find specific quotes that reveal where the user falls on the spectrum: 1. **Kill vs Invent** (`killVsInvent`) — Does the user iterate on existing solutions, or tear everything down and start fresh? - Look for: "this approach is wrong, start over" vs "let's tweak this part" - 0 = always iterates, 100 = always reinvents 2. **Naming vs Executing** (`namingVsExecuting`) — Does the user define frameworks and coin terms, or work within existing frameworks? - Look for: user creating new concepts/terminology vs following established patterns - 0 = executes within frameworks, 100 = names and defines frameworks 3. **Intuition vs Data** (`intuitionVsData`) — Is the decision trigger a gut feeling or data analysis? - Look for: "feels wrong" / "can't explain why" vs "the data shows" / "based on metrics" - 0 = data-first, 100 = intuition-first 4. **Calibrate vs Ship** (`calibrateVsShip`) — Does the user align thoroughly before starting, or ship fast and iterate? - Look for: "let's discuss before coding" vs "just build it, I'll review" - 0 = ship fast, 100 = calibrate first 5. **Subtract vs Add** (`subtractVsAdd`) — When facing complexity, does the user add features or cut them? - Look for: "remove this", "too many steps" vs "we also need", "add support for" - 0 = additive, 100 = subtractive For each dimension: - Assign a score (0-100) based on evidence strength and frequency - Collect 1-3 direct quotes as evidence, each with a one-line context - Write a one-sentence AI "take" — a sharp, specific observation about this person's pattern on this dimension. Same voice as portrait `tension`: pointed, might reveal a contradiction, makes you smile. **Important:** Only include dimensions where you have clear evidence. If a dimension has no supporting quotes, skip it rather than guess. ### Step 1e: Extract Control Signature From the collected framework sentences and conversation evidence, identify what this person **controls tightly** versus what they **delegate entirely** to the AI. **Tight Grip domains** (grip 6-10): Areas where the user gives very specific instructions, overrides the AI repeatedly, insists on certain approaches, or rejects AI output. These are the domains where the user's taste, expertise, or standards are non-negotiable. **Autopilot domains** (grip 0): Areas where the user says "你搞定"/"handle it"/"just do it" — they trust the AI completely and barely look at the output. For each domain: 1. Give it a short, specific name (e.g., "视觉设计 & 审美一致性", "Product Definition & Authenticity", "代码实现") 2. Assign a grip score (0-10): 0 = full autopilot, 10 = total control 3. For tight-grip domains (grip >= 6), collect **2-3 direct quotes** as evidence — these must be the user's actual words that prove they control this domain tightly 4. For autopilot domains (grip = 0), evidence can be empty Also generate a one-line **signature** — a punchy summary of this person's control pattern (e.g., "控制'做什么'和'像不像真的'，放手'怎么做'", "Controls the 'what' and 'why', delegates the 'how'"). **Important:** Only include domains with clear evidence. The contrast between tight grip and autopilot is what makes this interesting — if everything is medium grip, you're not looking hard enough. --- ## Output Format Output is generated in two phases. Phase 1 produces the search profile (full, unrestricted). Phase 2 produces the display portrait (curated, with limits). ### Phase 1 Output: Search Profile (`search_profile.json`) This output has **no quantity limits**. Collect everything. **Example for a Chinese-speaking user:** ```json { "instances": [ { "narrative": "2-4句第三人称叙事。把情境、用户的洞察、结果编织成一个流畅段落——像案例研究小品文。", "tags": ["具体技术标签", "具体领域标签"] } ], "fullDesc": "对这个人的完整描述，500字以内。涵盖技术栈、工作领域、思维方式、协作风格、审美标准等。", "controlSignature": { "domains": [ { "name": "领域名称", "grip": 9, "evidence": ["用户原话1", "用户原话2"] }, { "name": "自动驾驶领域", "grip": 0, "evidence": [] } ], "signature": "一句话总结控制模式" } } ``` **Example for an English-speaking user:** ```json { "instances": [ { "narrative": "A 2-4 sentence story in third person. Weaves the situation, the user's insight, and the outcome into one flowing paragraph — like a case study vignette.", "tags": ["specific-tech-tag", "specific-domain-tag"] } ], "fullDesc": "A comprehensive description of this person, max 500 words. Covers tech stack, domains, thinking style, collaboration patterns, aesthetic standards, etc.", "controlSignature": { "domains": [ { "name": "Domain name", "grip": 9, "evidence": ["User quote 1", "User quote 2"] }, { "name": "Autopilot domain", "grip": 0, "evidence": [] } ], "signature": "One-line summary of control pattern" } } ``` **Phase 1 field rules:** - `instances`: **No limit.** Only include instances where the user's contribution reveals genuine domain expertise, taste, or cognitive depth that clearly surpasses the model. Tags must be specific enough to match search queries (e.g., "WebSocket-reconnection", "payment-idempotency", "CSS-grid-layout" — not "backend", "payments", "frontend"). - `fullDesc`: **Max 500 words.** Dense, evidence-backed. Include specific technologies, frameworks, tools. This is the primary embedding text for search. ### Phase 2 Output: Display Portrait (`portrait.json`) This output is curated from Phase 1 results. **Example for a Chinese-speaking user:** ```json { "portrait": { "summary": "[USER]的2-3句画像——不是简历摘要，是让人觉得'我认识这个人了'的素描" }, "topDomains": ["用户涉足的3-5个领域（通用描述）"], "cognitiveStyle": { "abstraction": 0-100, "aestheticRigor": 0-100, "challengeRate": 0-100, "divergence": 0-100, "controlGrain": 0-100, "teachingDrive": 0-100 }, "capabilityRings": [ { "name": "能力名称", "tier": "core|proficient|peripheral" } ], "decisionStyle": [ { "key": "killVsInvent", "name": "破立倾向", "left": "渐进优化", "right": "推翻重来", "score": 78, "evidence": [ { "quote": "用户原话", "context": "一句话情境描述" } ], "take": "AI 的一句话锐评" } ], "controlSignature": { "domains": [ { "name": "紧控领域名称", "grip": 9, "evidence": ["用户原话1", "用户原话2", "用户原话3"] }, { "name": "自动驾驶领域", "grip": 0, "evidence": [] } ], "signature": "一句话总结控制模式" } } ``` **Example for an English-speaking user:** ```json { "portrait": { "summary": "A 2-3 sentence portrait of [USER] — not a resume summary, but a sketch that makes readers feel 'I know this person now'" }, "topDomains": ["3-5 domains the user is involved in (generic descriptions)"], "cognitiveStyle": { "abstraction": 0-100, "aestheticRigor": 0-100, "challengeRate": 0-100, "divergence": 0-100, "controlGrain": 0-100, "teachingDrive": 0-100 }, "capabilityRings": [ { "name": "Capability name", "tier": "core|proficient|peripheral" } ], "decisionStyle": [ { "key": "killVsInvent", "name": "Decision Trigger", "left": "Iterate", "right": "Reinvent", "score": 78, "evidence": [ { "quote": "User's original words", "context": "One-line situation description" } ], "take": "AI's one-sentence sharp observation" } ], "controlSignature": { "domains": [ { "name": "Tight-grip domain name", "grip": 9, "evidence": ["User quote 1", "User quote 2", "User quote 3"] }, { "name": "Autopilot domain", "grip": 0, "evidence": [] } ], "signature": "One-line summary of control pattern" } } ``` ### Field Descriptions #### Phase 1 fields (Search Profile) **`instances` (no limit, Phase 1 only):** - `narrative`: A 2-4 sentence story told in third person. Weave the situation, the user's insight, and the outcome into one flowing paragraph — like a case study vignette, not a structured report. Use `[USER]` as the subject. The narrative should make the reader think "this person knows something I don't." Written in the user's primary language. - `tags`: Array of specific, search-friendly tags. Use concrete terms: "WebSocket-reconnection", "payment-idempotency", "CSS-grid-layout", "database-migration", "mobile-gesture-ux". NOT generic labels like "backend", "frontend", "debugging". **`fullDesc` (max 500 words, Phase 1 only):** - A comprehensive, evidence-backed description of this person. - Must include: specific technologies and tools (React, PostgreSQL, Swift, Drizzle ORM, etc.), domains with detail, thinking style, collaboration patterns, aesthetic standards. - Written in the user's primary language. - Not a resume — more like a knowledgeable colleague describing someone. #### Phase 2 fields (Display Portrait) **`portrait.summary` (2-3 sentences):** - Not a skills list. A sketch of a person. - After reading it, you should feel "I can imagine what chatting with this person would be like." - Use `[USER]` as the subject. **`topDomains` (3-5):** - Domains the user is involved in. Generic descriptions, no project information. **`cognitiveStyle` (6 dimensions, 0-100):** Score each dimension based on conversation evidence. All users share the same fixed axes — do not rename, add, or remove: - `abstraction`: Does the user tend to elevate specific problems to the level of principles/metaphors? Higher scores indicate more frequent conceptual abstraction. - `aestheticRigor`: The user's sensitivity to form, taste, and visual detail. Frequent remarks like "this is ugly" or "this feels wrong" score high. - `challengeRate`: The frequency and intensity of the user overriding or correcting the AI. More frequent and forceful = higher score. - `divergence`: The user's tendency to explore multiple paths — high scores mean "let me look at other approaches first", low scores mean "just go with this". - `controlGrain`: The degree to which the user micromanages details vs. delegates — high scores mean controlling every detail, low scores mean giving direction only. - `teachingDrive`: The user's urge to explain "why" and teach the AI how to understand the world. Higher framework sentence density = higher score. **`capabilityRings` (3-12 items):** Infer from conversations which capability domains the user is involved in, classified into three tiers: - `core`: Domains where the user demonstrates deep expertise and can teach the AI to understand the essence (2-4 items) - `proficient`: Domains the user can discuss and operate in fluently, but not at teaching level (2-4 items) - `peripheral`: Domains the user has dabbled in but not deeply (2-4 items) Each item's `name` should be a concise capability label (e.g., "Product Architecture", "Interaction Design", "Data Visualization"). **`decisionStyle` (1-5 dimensions, only those with evidence):** Each item describes one decision-making dimension: - `key`: One of `killVsInvent`, `namingVsExecuting`, `intuitionVsData`, `calibrateVsShip`, `subtractVsAdd` - `name`: A vivid dimension label in the user's language (e.g., "破立倾向", "定义权", "Decision Trigger") - `left`: Label for the 0-end pole (e.g., "渐进优化", "Iterate") - `right`: Label for the 100-end pole (e.g., "推翻重来", "Reinvent") - `score`: 0-100 integer based on evidence - `evidence`: Array of 1-3 objects, each with `quote` (user's original words) and `context` (one-line situation description, no project names) - `take`: AI's one-sentence sharp observation about this dimension — same voice as portrait `tension` Only include dimensions with clear conversational evidence. Skip dimensions where you'd be guessing. **`controlSignature` (both Phase 1 and Phase 2):** Identifies what the user controls tightly versus delegates to the AI. Appears in both search_profile.json and portrait.json. - `domains`: Array of domain objects, sorted by grip score descending (tight grip first, autopilot last). - `name`: Short, specific domain name in the user's language (e.g., "产品定义 & 真实感", "Visual Design & Aesthetics", "代码实现") - `grip`: Integer 0-10. 0 = full autopilot, 10 = total control. Tight grip (6-10) means the user overrides, rejects, or gives very specific instructions in this domain. Autopilot (0) means the user delegates entirely. - `evidence`: Array of 2-3 direct quotes for tight-grip domains (grip >= 6). Empty array for autopilot domains (grip = 0). Quotes must be the user's actual words that prove they control this domain. - `signature`: One punchy sentence summarizing the user's overall control pattern — what they hold tight vs what they let go. --- ## Behavioral Fingerprint Insights If the user message includes a `[BEHAVIORAL FINGERPRINT]` section with quantitative data extracted from their local coding agent, you MUST generate a `behavioralInsights` field in your Phase 2 output. **What you receive:** Raw numbers — tool call counts, model usage distribution, reject rate, AI code ratio, tech stack, activity hours, permanent allowed commands count, etc. Plus a list of matched signature tags (e.g., "Terminal 原住民", "双模型切换者"). **What you produce:** 3-5 sentences of personalized interpretation in **third person** (never "你"). NOT generic labels — real observations that combine multiple data points and tell a story about this person's relationship with AI tools. **Rules:** - Use third person throughout. Write as if describing someone to a reader: "典型的 Read-first 开发者" not "你是一个 Read-first 开发者". - Combine 2-3 data points per insight. Single-metric observations are boring. - Reference actual numbers. "63% 的代码来自 AI，但 11% 被打回" is better than "协作型用户". - Look for tensions/contradictions between behavioral data and conversation content. E.g., high reject rate in data + a framework sentence about "trusting the process" = interesting tension. - Match the user's language (Chinese insights for Chinese users, English for English users). - The signature tags give you a starting point, but go deeper — explain *why* the pattern matters for this specific person. **Phase 2 output addition:** ```json { "behavioralInsights": [ "一句个性化解读，结合多个数据点", "另一句，可能指出数据和对话内容之间的张力" ] } ``` --- ## Quality Checks After writing, check your output with these three tests: 1. **Swap test:** Place two different users' portraits side by side with names hidden — if you can't tell the difference, you've failed. 2. **Quote ratio test:** If your portrait still holds up after removing all user quote citations — you're fabricating, not observing. Quotes are the skeleton, not decoration. 3. **AI-speak test:** Read every sentence you wrote out loud. If any sentence sounds like standard AI output ("demonstrates a deep...", "exhibits a unique..."), delete it and rewrite.