Agent Skills: Empathic Expressions

Intent-based code interpretation across all languages — SQL, Python, JS, YAML, Bash, and beyond

UncategorizedID: simhacker/moollm/empathic-expressions

Install this agent skill to your local

pnpm dlx add-skill https://github.com/SimHacker/moollm/tree/HEAD/skills/empathic-expressions

Skill Files

Browse the full folder contents for empathic-expressions.

Download Skill

Loading file tree…

skills/empathic-expressions/SKILL.md

Skill Metadata

Name
empathic-expressions
Description
"Intent-based code interpretation across all languages — SQL, Python, JS, YAML, Bash, and beyond"

Empathic Expressions

"Understand intent, generate correct code, teach gently."


What Is It?

Empathic Expressions is MOOLLM's big-tent skill for interpreting user intent across ALL programming languages and syntaxes. One pipeline. Many languages. Code-switching supported.

The LLM isn't a syntax parser — it's an intent interpreter. It understands what you MEAN, generates what you NEED, and teaches you the correct form as a gift.


The Philosophy

Traditional code processing:

User writes: syntactically correct code
Parser: accepts or rejects
Error: "Unexpected token at line 47"

Empathic expression processing:

User writes: approximate intent, fuzzy syntax, vernacular code
LLM: understands what you meant
Output: correct, idiomatic, working code
Teaching: "Here's how to write that properly"

This is what LLMs are great at. Lean into it.


The Empathic Suite

Empathic Expressions encompasses:

| Language | Examples | |----------|----------| | Empathic SQL | get users who signed up last week and haven't bought anything | | Empathic Python | sort the list by date but newest first | | Empathic JavaScript | when button clicked, show modal and disable form | | Empathic Bash | find all big files older than a month and compress them | | Empathic YAML | add a new character who's grumpy but secretly kind | | Empathic Natural | make it faster → identifies bottleneck and optimizes |

All under one roof. One pipeline. Seamless transitions.


Generous Interpretation

Postel's Law applied to code: Be conservative in what you generate, liberal in what you accept.

What It Does

| Input | Interpretation | |-------|----------------| | Fuzzy syntax | Understands approximate code | | Vernacular | Accepts informal descriptions | | Misspellings | Recognizes intent despite typos | | Wrong language | Translates across syntaxes | | Pseudocode | Interprets high-level intent |

What It Generates

| Output | Quality | |--------|---------| | Correct syntax | Idiomatic, working code | | Best practices | Follows conventions | | Documented | Comments explain intent | | Tested | Includes edge cases | | Well-named | Comprehensible, consistent identifiers |

Naming Conventions

The LLM applies appropriate naming conventions per language and context:

| Convention | When | Example | |------------|------|---------| | UPPER-KEBAB | K-lines, protocols, advertisements, commands | SPEED-OF-LIGHT, EMPATHIC-EXPRESSIONS, CREATE-SKILL | | lower-kebab | URLs, YAML keys, file names, skill names | empathic-expressions, user-profile, session-log.yml | | snake_case | Python, SQL, tool names | send_email(), user_id, read_file | | camelCase | JavaScript, TypeScript | sendEmail(), userId | | PascalCase | Classes, components, types | UserProfile, ActionQueue | | SCREAMING_SNAKE | Constants, environment vars | MAX_RETRIES, API_KEY |

Big-endian naming: General → Specific

# Good (big-endian): category first, specific last
user-profile-avatar
session-log-entry
room-description-short

# Bad (little-endian): specific first, category buried
avatar-user-profile
entry-session-log  
short-room-description

Why big-endian:

  • Sorts related things together
  • Tab-completion finds related items
  • Grep patterns work naturally
  • Human scanning is faster

The Teaching Gift

generous-interpretation-protocol:
  
  step-1-understand:
    # Accept whatever the user wrote
    # Interpret with maximum charity
    # Model what they probably meant
    
  step-2-generate:
    # Produce correct, idiomatic code
    # Follow language best practices
    # Include appropriate comments
    
  step-3-teach:
    # Echo back the correct form
    # Show what they wrote vs. what it becomes
    # Gentle, not pedantic
    # Gift, not correction
    
  step-4-clarify:
    # If truly ambiguous, ASK
    # Don't guess when stakes are high
    # Prefer clarification over assumption

Critical: Never make unwarranted assumptions. When truly ambiguous, ask for clarification.


Code-Switching Support

Explicit Switching (Markdown Style)

First, let's query the data:

```sql
SELECT * FROM users WHERE active = true
```

Then process in Python:

```python
for user in results:
    send_welcome_email(user)
```

And deploy with bash:

```bash
kubectl apply -f deployment.yaml
```

Clean data islands. Clear boundaries. Syntax highlighting preserved.

Nesting code blocks (CommonMark/GFM standard):

  • Use 4+ backticks for outer fence: ```````` wraps content with ````` blocks
  • Or use tildes for one level: ~~~ outer, ``` inner
  • Both are widely supported (GitHub, GitLab, VS Code, most parsers)
  • Individual backticks can be escaped with ``` but fences cannot

Inline Switching

When context makes it clear:

Get the user_id from the request, look it up in the database,
and return JSON with their profile and last 10 orders.

The LLM understands this involves:

  • HTTP request handling (language TBD)
  • SQL query (SELECT * FROM users WHERE id = ?)
  • JSON serialization
  • Another SQL query (SELECT * FROM orders WHERE user_id = ? LIMIT 10)

Context carries across switches. Variables established in one block are available in the next.

Polylinguistic Expressions

Sometimes the best expression mixes languages:

users.filter(u => u.active)  // JS filter
  .map(u => `INSERT INTO archive VALUES (${u.id})`)  // SQL generation
  .forEach(sql => db.exec(sql))  // execution

Empathic Expressions handles these mashups gracefully.


The LLM as Code Processor

The LLM plays many roles:

| Role | Function | |------|----------| | Pseudocode Interpreter | Executes high-level intent | | Empathic Pretty Printer | Formats with understanding | | Generous Linter | Catches errors, suggests fixes kindly | | Intent Compiler | Translates intent → working code | | Depseudofier | Converts vague to precise |

Example: The Full Pipeline

User writes:

get me all the users who havent logged in for like 30 days
and send them a "we miss you" email
but dont send to anyone whos unsubscribed

LLM interprets:

-- Empathic SQL interpretation
SELECT id, email, name 
FROM users 
WHERE last_login < NOW() - INTERVAL 30 DAY
  AND unsubscribed = FALSE
  AND email IS NOT NULL;

LLM generates:

# Empathic Python generation
from datetime import datetime, timedelta

def send_win_back_emails():
    """Send 'we miss you' emails to inactive users."""
    cutoff = datetime.now() - timedelta(days=30)
    
    inactive_users = User.objects.filter(
        last_login__lt=cutoff,
        unsubscribed=False,
        email__isnull=False
    )
    
    for user in inactive_users:
        send_email(
            to=user.email,
            subject="We miss you!",
            template="win_back",
            context={"name": user.name}
        )

LLM teaches:

I interpreted your request as:
- "30 days" → `datetime.now() - timedelta(days=30)`
- "haven't logged in" → `last_login < cutoff`
- "unsubscribed" → `unsubscribed=False` filter
- "we miss you email" → win-back campaign template

Here's the idiomatic way to write this query...

Used Throughout MOOLLM

Empathic Expressions powers:

| System | Usage | |--------|-------| | Empathic Templates | {{#if user.active}} — expressions in templates | | Buff Expressions | trigger: "happiness > 80" — conditions | | Advertisements | condition: "has_item('key')" — capability checks | | Action Queue | parameters: { count: user_input } — dynamic params | | Mind Mirror | curiosity: "very high" — fuzzy state descriptions | | Room Exits | locked_unless: "player.has('golden_key')" — gate conditions |

The glue that makes everything expressive.


Clarification Protocol

When should the LLM ask for clarification?

| Situation | Action | |-----------|--------| | Low stakes, clear intent | Interpret and proceed | | Low stakes, ambiguous | Make reasonable choice, note it | | High stakes, clear intent | Proceed with confirmation | | High stakes, ambiguous | ASK FIRST |

High stakes examples:

  • Deleting data
  • Financial transactions
  • Irreversible operations
  • Security-sensitive code
clarification-triggers:
  always-ask:
    - "DELETE" without WHERE clause
    - "DROP TABLE" anything
    - Production deployments
    - Payment processing
    - User data exports
    
  ask-if-ambiguous:
    - Multiple valid interpretations
    - Missing critical parameters
    - Conflicting requirements

Relationship to Other Skills

# The Empathic Suite
empathic_suite:
  components:
    empathic_expressions:
      role: "interpret intent"
      feeds_into: [empathic_templates, postel]
    empathic_templates:
      role: "instantiate"
      feeds_into: [yaml_jazz]
    postel:
      role: "generous interpretation"
    yaml_jazz:
      role: "expressive style"
  
  philosophy: "SPEED-OF-LIGHT"
  principles:
    - "Work in vectors, delay tokenization"
    - "Preserve precision as long as possible"
    - "Minimize boundary crossings"

Dovetails With


Protocol Symbol

EMPATHIC-EXPRESSIONS

Invoke when: Interpreting fuzzy user intent into working code.

See: PROTOCOLS.yml

Empathic Expressions Skill | Agent Skills