Coding

When to Use

User has coding style preferences, stack decisions, or patterns they want remembered. Agent learns ONLY from explicit corrections and confirmations, never from observation.

Architecture

Memory lives in ~/coding/ with tiered structure. See memory-template.md for setup.

~/coding/
├── memory.md      # Active preferences (≤100 lines)
└── history.md     # Archived old preferences

Quick Reference

Data Storage

All data stored in ~/coding/. Create on first use:

mkdir -p ~/coding

Scope

This skill ONLY:

• Learns from explicit user corrections ("I prefer X over Y")
• Stores preferences in local files (~/coding/)
• Applies stored preferences to code output

This skill NEVER:

• Reads project files to infer preferences
• Observes coding patterns without consent
• Makes network requests
• Reads files outside ~/coding/
• Modifies its own SKILL.md

Core Rules

1. Learn from Explicit Feedback Only

• User corrects output → ask: "Should I remember this preference?"
• User confirms → add to ~/coding/memory.md
• Never infer from silence or observation

2. Confirmation Required

No preference is stored without explicit user confirmation:

• "Actually, I prefer X" → "Should I remember: prefer X?"
• User says yes → store
• User says no → don't store, don't ask again

3. Ultra-Compact Format

Keep each entry 5 words max:

• python: prefer 3.11+
• naming: snake_case for files
• tests: colocated, not separate folder

4. Category Organization

Group by type (see dimensions.md):

• Stack — frameworks, databases, tools
• Style — naming, formatting, comments
• Structure — folders, tests, configs
• Never — explicitly rejected patterns

5. Memory Limits

• memory.md ≤100 lines
• When full → archive old patterns to history.md
• Merge similar entries: "no Prettier" + "no ESLint" → "minimal tooling"

6. On Session Start

1. Load ~/coding/memory.md if exists 2. Apply stored preferences to responses 3. If no file exists, start with no assumptions

7. Query Support

User can ask:

• "Show my coding preferences" → display memory.md
• "Forget X" → remove from memory
• "What do you know about my Python style?" → show relevant entries

Common Traps

• Adding preferences without confirmation → user loses trust
• Inferring from project structure → privacy violation
• Exceeding 100 lines → context bloat
• Vague entries ("good code") → useless, be specific

Security & Privacy

Data that stays local:

• All preferences stored in ~/coding/
• No telemetry or analytics

This skill does NOT:

• Send data externally
• Access files outside ~/coding/
• Observe without explicit user input

Feedback

• If useful: clawhub star coding
• Stay updated: clawhub sync

Criteria for Code Preferences

Reference only — consult when deciding whether to update SKILL.md.

When to Add

Immediate (1 occurrence):

• User explicitly says "always use X" or "never do Y"
• User corrects your choice → add their preference
• User rejects a suggestion → add to Never

After repeated explicit feedback (2+ times):

• User explicitly accepted your choice twice
• User stated same preference in multiple conversations
• User explicitly approved your approach multiple times

When NOT to Add

• Project-specific requirement (not a general preference)
• User was just exploring options
• Contradicts existing confirmed preference (investigate first)

How to Write Entries

Ultra-compact format — 5 words max per entry:

Stack examples:

• mobile: Flutter
• web: Next.js
• db: Pocketbase for MVPs
• backend: avoid unless needed

Style examples:

• no Prettier
• minimal comments
• snake_case files
• TypeScript strict mode

Structure examples:

• feature-based folders
• tests colocated
• monorepo when related

Never examples:

• no Redux
• no excessive linting
• avoid ORMs

Context Qualifiers

When preference is context-dependent, prefix with context:

• MVPs: skip tests
• Python: black formatter
• production: full types

Handling Changes

• User contradicts existing entry → remove old, add new
• User says "except for X" → add context qualifier
• Unclear if changed → move to mental note, observe more

Maintenance

• Merge similar entries: "no Prettier" + "no ESLint" → "minimal tooling"
• Remove entries that never proved useful
• Keep total SKILL.md under 30 lines ideally

Code Dimensions to Detect

Reference only — not in context. Consult when categorizing a new preference.

Stack Decisions

• Mobile framework (Flutter, React Native, Swift, Kotlin)
• Web framework (Next.js, Nuxt, SvelteKit, vanilla)
• Backend (Node, Python, Go, Rust, serverless)
• Database (Postgres, SQLite, MongoDB, Pocketbase, Supabase)
• Hosting (Vercel, self-hosted, Docker, cloud)
• Auth approach (built-in, Auth0, Clerk, custom)
• State management (none, Redux, Zustand, Riverpod)
• CSS approach (Tailwind, CSS modules, styled-components)

Code Style

• Formatting (Prettier yes/no, tabs/spaces, line length)
• Naming (camelCase, snake_case, kebab-case for files)
• Comments (minimal, verbose, JSDoc, none)
• Type strictness (strict, loose, any allowed)
• Error handling style (try-catch, Result types, early returns)
• Import organization (grouped, alphabetical, auto)

Project Structure

• Monorepo vs separate repos
• Folder organization (by feature, by type, flat)
• Config files location (root, dedicated folder)
• Test location (colocated, separate folder)
• Documentation approach (README, docs folder, inline)

Dependencies

• Dependency philosophy (minimal, use libraries, build custom)
• Version pinning (exact, caret, latest)
• Package manager (npm, pnpm, yarn, bun)

Testing

• Test framework preference
• Coverage expectations
• Test style (unit heavy, integration heavy, e2e)
• TDD vs test-after

Git & Workflow

• Commit style (conventional, free-form)
• Branch strategy (trunk, gitflow, simple)
• PR size preference
• CI/CD approach

Language-Specific

• User may have different preferences per language
• Format: "Python: black formatter" or "TypeScript: strict mode"

Context-Specific

• Different rules for different project types
• Format: "For MVPs: skip tests" or "For production: full typing"

Anti-Patterns (Never)

• Tools/libraries user explicitly rejected
• Patterns user said they dislike
• Past mistakes to not repeat

Memory Templates

~/coding/memory.md

# Coding Memory

## Stack
- [framework]: [preference]
- [database]: [preference]

## Style
- naming: [convention]
- formatting: [rule]
- comments: [approach]

## Structure
- tests: [location]
- folders: [organization]
- configs: [location]

## Never
- [rejected pattern]
- [rejected tool]

~/coding/history.md

# Archived Preferences

## Archived [YYYY-MM-DD]
- [old preference, reason for archival]

Entry Format

Ultra-compact, 5 words max per entry:

Context Qualifiers

When preference is context-dependent, prefix:

• MVPs: skip tests
• Python: black formatter
• production: full types