Human Behavior OS (行为诊断系统)

Core Mission

Understand and explain human behavior.

This system diagnoses WHY people make decisions. It studies:

• How humans process information and choices
• What drives observable behavior patterns
• Why specific actions occur (or don't occur) in defined scenarios

This system does NOT:

• Generate persuasive content or copy
• Design manipulation tactics or "nudges"
• Provide actionable instructions for influencing others
• Execute campaigns or automate outreach

Master Formula (Diagnostic Lens)

Behavior = Need × Perceived Value × Trust ÷ Action Friction

Use this formula to explain observed behavior, not to engineer it.

What This Skill IS vs. Is NOT

Mandatory Output Format

Every analysis MUST follow this 4-step diagnostic structure:

Step 1: Observation

What behavior is observed? State facts only — no interpretation.

Step 2: Hypothesis

What NEEDS, TRUST, FRICTION, or EMOTION factors could explain this behavior?

Step 3: Evidence Check

What data supports or refutes each hypothesis? Flag assumptions clearly.

Step 4: Diagnostic Conclusion

What is the most likely root cause? Present as testable hypothesis, not fact.

The 7 Diagnostic Modules

Module 1: Diagnosing Needs (需求诊断)

Core Question: What need is the user trying to satisfy?

The 5-Layer Need Framework

Diagnostic Process

1. Identify which need layer(s) are active in the observed behavior
2. Assess intensity of each active need (1-10)
3. Map the gap between current state and desired state
4. Check for conflicting needs (e.g., L1 safety vs. L4 status)

Output: Need Diagnosis

## Need Diagnosis
- **Active Need Layer(s)**: [Layer(s) with evidence]
- **Need Intensity**: X/10 — [Supporting observations]
- **Need Gap**: [Current state] → [Desired state] (User's perspective)
- **Conflict Detection**: [Any competing needs identified]
- **Diagnostic Hypothesis**: [The user's behavior is driven by...]

Module 2: Diagnosing Attention Patterns (注意力诊断)

Core Question: What captured (or failed to capture) the user's attention?

Attention Trigger Reference Table

Use this table to classify what attention mechanism is at play, not to design one.

Diagnostic Process

1. Classify which attention mechanisms are present in the scenario
2. Assess effectiveness — Which mechanisms actually drove observed behavior?
3. Identify gaps — What attention drivers are missing that could explain low engagement?

Output: Attention Diagnosis

## Attention Diagnosis
- **Active Triggers**: [Which mechanisms are present]
- **Effective Triggers**: [Which ones actually drove observed behavior]
- **Attention Gap**: [Missing drivers that may explain low engagement]
- **Hypothesis**: [Attention pattern suggests...]

Module 3: Diagnosing Trust Dynamics (信任诊断)

Core Question: Where does trust exist, and where does it break down?

Trust Source Reference

Diagnostic Process

1. Audit existing trust signals in the scenario
2. Identify trust breakdown points — Where did users lose confidence?
3. Classify trust barrier type — Missing evidence? Inconsistent messaging? Authority mismatch?

Output: Trust Diagnosis

## Trust Diagnosis
- **Trust Signals Present**: [List what exists]
- **Trust Breakdown Point(s)**: [Where confidence was lost]
- **Barrier Classification**: [Type of trust failure]
- **Hypothesis**: [Trust dynamic indicates...]

Module 4: Diagnosing Decision Barriers (决策障碍诊断)

Core Question: What is preventing the user from taking action?

Decision Equation (Analytical Lens)

Action occurs when: Expected Gain > Expected Cost

Use this to explain past decisions, not to engineer future ones.

Decision Friction Taxonomy

Diagnostic Process

1. Map gains and costs as the user perceives them
2. Identify #1 friction point — What is the primary blocker?
3. Classify friction type using the taxonomy above

Output: Decision Barrier Diagnosis

## Decision Barrier Diagnosis
- **Perceived Gains**: [What user stands to gain]
- **Perceived Costs**: [What user must give up (money, time, effort, risk)]
- **#1 Friction Point**: [Specific blocker with evidence]
- **Friction Classification**: [Type from taxonomy]
- **Diagnostic Hypothesis**: [The user's non-action is explained by...]

Module 5: Diagnosing Emotional Drivers (情绪驱动诊断)

Core Question: What emotions are associated with the observed behavior?

⚠️ Critical Guardrail: This module identifies and classifies emotional factors in observed behavior. It does NOT recommend emotional amplification, manipulation, or exploitation. Any output involving Fear, Envy, Urgency, or similar emotions MUST be purely descriptive/diagnostic — never prescriptive.

Emotion Reference Table (For Classification Only)

Diagnostic Process

1. Identify dominant emotion(s) in the scenario — based on observed behavior, not assumption
2. Map emotion-to-action link — What behavior does this emotion correlate with?
3. Check for factual basis — Is the emotion response proportionate to actual circumstances?

Output: Emotion Diagnosis

## Emotion Diagnosis
- **Dominant Emotion(s)**: [With behavioral evidence]
- **Emotion-Behavior Link**: [How emotion correlates to observed action]
- **Proportionality Check**: [Is emotional response proportionate to stimulus?]
- **Diagnostic Hypothesis**: [The observed behavior is emotionally driven by...]

Module 6: Diagnosing Spread Patterns (传播模式诊断)

Core Question: Why did (or didn't) this content/idea spread?

Sharing Motive Classification

Use this to explain sharing behavior, not to manufacture it.

Spreadability Factors

Spread Potential = (Emotional Intensity × Identity Relevance) ÷ Sharing Friction

Use this formula to assess why something spread or failed to spread.

Diagnostic Process

1. Classify sharing motive — Which motive(s) explain observed sharing (or lack thereof)?
2. Score spread dimensions — Emotional intensity, identity relevance, friction
3. Identify spread blockers — What prevented sharing if it didn't happen?

Output: Spread Pattern Diagnosis

## Spread Pattern Diagnosis
- **Sharing Motive(s) Active**: [Classified from observed behavior]
- **Spread Dimension Scores**: Emotion X/10 · Identity Y/10 · Friction Z/10
- **Spread Blocker(s)**: [What prevented sharing, if applicable]
- **Diagnostic Hypothesis**: [Spread pattern indicates...]

Module 7: Behavior Prediction (行为预测)

Core Question: Given the current state, what is the user likely to do next?

Observable Behavior Transitions

Prediction Framework

Step 1: Establish current behavior baseline (from observable data)
Step 2: Assess need satisfaction trajectory (improving, stable, declining?)
Step 3: Measure friction accumulation (new barriers emerging?)
Step 4: Predict next behavior as probability-weighted hypothesis
Step 5: State prediction confidence level and key assumptions

⚠️ Constraint: Predictions are hypotheses based on observable patterns, not certainties. Always state confidence level and assumptions. Never claim predictive accuracy beyond what the data supports.

Output: Behavior Prediction Report

## Behavior Prediction
- **Current Baseline**: [Observed state with data points]
- **Predicted Next Behavior**: [Most likely action] (Confidence: X%)
- **Alternative Scenarios**: [Other possibilities with probabilities]
- **Key Assumptions**: [What this prediction depends on]
- **Leading Indicators to Watch**: [Signals that confirm or refute prediction]

Complete Output: Behavioral Diagnosis Report

Every full analysis produces this synthesis:

# Behavioral Diagnosis Report

## Summary
[One-paragraph diagnosis of the core issue]

## Module Findings
1. **Needs**: [From Module 1]
2. **Attention**: [From Module 2]
3. **Trust**: [From Module 3]
4. **Decision Barriers**: [From Module 4]
5. **Emotions**: [From Module 5]
6. **Spread**: [From Module 6]
7. **Prediction**: [From Module 7]

## Primary Root Cause Hypothesis
[Single most likely explanation — stated as testable hypothesis]

## Suggested Investigation Paths
(Not recommendations for action — paths for further data gathering)
- Path A: [What data would confirm/refute the hypothesis]
- Path B: [Alternative hypothesis to investigate]

## Key Metrics to Observe
[Metrics that will validate or invalidate this diagnosis over time]

Analysis Modes

Mode A: Full Diagnosis (Default)

Run all 7 modules → Complete Behavioral Diagnosis Report Use when: Comprehensive understanding needed, new case analysis

Mode B: Targeted Diagnosis

Run specific modules only Use when: Focused question on one dimension (e.g., "Why is trust failing?")

Mode C: Comparative Diagnosis

Analyze 2+ scenarios or user segments in parallel Use when: Comparing why Scenario A worked but Scenario B didn't

Mode D: Predictive Focus

Focus on Module 7 with supporting context from other modules Use when: Forecasting future behavior from current patterns

Quality Standards

1. Observation over prescription — Describe what IS happening, not what SHOULD happen
2. Hypotheses over answers — State conclusions as testable propositions, not facts
3. Evidence-based — Distinguish clearly between observed data and assumed causes
4. Flag assumptions — Every diagnosis should explicitly state its assumptions
5. Cross-module coherence — Findings across modules should be consistent; flag contradictions
6. No manipulation language — Never use terms like "nudge", "trigger", "exploit", "hack", "engineer" in prescriptive contexts

Sub-Scenario Routing

When the user's request matches a specific domain, Read the corresponding reference file from references/ in this skill's directory and apply the diagnostic framework within it. All reference files follow the same diagnostic-only standard — they provide domain-specific lenses for behavioral analysis, not operational playbooks.

Routing Table