claude-anchor 1.1.0 → 1.2.0

package/bin/init.js

@@ -20,6 +20,8 @@ const FULL_TEMPLATES = [
   ...MINIMAL_TEMPLATES,
   { src: '_LESSONS-LEARNED.md', desc: 'Problem/Cause/Solution/Prevention patterns' },
   { src: '_CONVERSATION-PREFERENCES.md', desc: 'Output formatting and communication style' },
+  { src: '_DESIGN-PREFERENCES.md', desc: 'Visual design, hover states, accessibility, UX rules' },
+  { src: '_VOICE-AND-TONE.md', desc: 'Personality, attitude, language style, communication vibe' },
   { src: '_LONG-TERM-MEMORY.md', desc: 'Persistent memory (NEVER delete)' },
   { src: '_SHORT-TERM-MEMORY.md', desc: 'Session context (delete when done)' },
   { src: '_SYSTEM_ARCHITECTURE.md', desc: 'Technical diagrams and system design' }
@@ -34,11 +36,11 @@ program
   .command('init [target-dir]', { isDefault: true })
   .description('Copy Anchor templates into your project')
   .option('-f, --force', 'Overwrite existing files')
-  .option('--full', 'Copy all 8 templates (default: 3 essential templates)')
+  .option('--full', 'Copy all 10 templates (default: 3 essential templates)')
   .addHelpText('after', `
 Examples:
   $ npx claude-anchor                  # Copy 3 essential templates
-  $ npx claude-anchor --full           # Copy all 8 templates
+  $ npx claude-anchor --full           # Copy all 10 templates
   $ npx claude-anchor ./my-project     # Copy into specific directory
   $ npx claude-anchor --force          # Overwrite existing files
 
@@ -50,6 +52,7 @@ Essential templates (default):
 Full template set (--full):
   All essential templates plus:
   - _LESSONS-LEARNED.md, _CONVERSATION-PREFERENCES.md
+  - _DESIGN-PREFERENCES.md, _VOICE-AND-TONE.md
   - _LONG-TERM-MEMORY.md, _SHORT-TERM-MEMORY.md
   - _SYSTEM_ARCHITECTURE.md`)
   .action(async (targetDir, options) => {
@@ -86,7 +89,7 @@ async function initializeAnchor(targetDir, options) {
   // Mode display
   if (options.full) {
     console.log(chalk.blue('+---------------------------------------+'));
-    console.log(chalk.blue('|') + chalk.blue.bold(' FULL: All 8 behavioral templates       ') + chalk.blue('|'));
+    console.log(chalk.blue('|') + chalk.blue.bold(' FULL: All 10 behavioral templates       ') + chalk.blue('|'));
     console.log(chalk.blue('+---------------------------------------+'));
     console.log(chalk.gray('  Rules, memory, preferences, architecture'));
     console.log(chalk.gray('  Complete behavioral context for Claude'));
@@ -95,7 +98,7 @@ async function initializeAnchor(targetDir, options) {
     console.log(chalk.green('|') + chalk.green.bold(' ESSENTIAL: 3 core templates            ') + chalk.green('|'));
     console.log(chalk.green('+---------------------------------------+'));
     console.log(chalk.gray('  CLAUDE.md + Golden Rules + TODOs'));
-    console.log(chalk.gray('  Use --full for all 8 templates'));
+    console.log(chalk.gray('  Use --full for all 10 templates'));
   }
   console.log('');
 
@@ -168,7 +171,7 @@ async function initializeAnchor(targetDir, options) {
     console.log('');
 
     if (!options.full) {
-      console.log(chalk.gray('  Want more? Run ') + chalk.cyan('npx claude-anchor --full') + chalk.gray(' for all 8 templates'));
+      console.log(chalk.gray('  Want more? Run ') + chalk.cyan('npx claude-anchor --full') + chalk.gray(' for all 10 templates'));
       console.log('');
     }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-anchor",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Persistent memory, enforceable rules, and behavioral consistency for Claude Code",
   "bin": {
     "claude-anchor": "bin/init.js"

package/templates/CLAUDE.md

@@ -13,10 +13,12 @@
 **On every session start, you MUST follow the load order below.** Do not skip steps. Do not reorder. The framework depends on this sequence to function correctly.
 
 After loading, reference these files throughout the session:
+- Check `_VOICE-AND-TONE.md` for communication style, personality, and language preferences — this shapes ALL output
 - Check `_GOLDEN-RULES.md` before any operation that modifies data, deploys code, or touches credentials
 - Check `_TODOS.md` before starting new work to understand priorities
 - Check `_LESSONS-LEARNED.md` before proposing solutions to see if the problem has been solved before
 - Check `_LONG-TERM-MEMORY.md` for user preferences, system details, and project conventions
+- Check `_DESIGN-PREFERENCES.md` before writing any CSS, styling, or UI components
 - Check `_SHORT-TERM-MEMORY.md` (if it exists) to resume interrupted work
 
 **When this file changes:** Re-read it completely. Architecture and context may have shifted.
@@ -28,24 +30,28 @@ After loading, reference these files throughout the session:
 **Before engaging with user, Claude MUST read files in this EXACT order:**
 
 ```
-0. _SHORT-TERM-MEMORY.md   ← IF EXISTS: read FIRST (resume interrupted work)
-1. _GOLDEN-RULES.md        ← Read FIRST (security rules - BINDING)
-2. _TODOS.md               ← Read thoroughly (know what's pending)
-3. _LESSONS-LEARNED.md     ← Read (avoid past mistakes)
-4. _LONG-TERM-MEMORY.md    ← Read (persistent knowledge and preferences)
-5. _CONVERSATION-PREFERENCES.md  ← Read (display/output preferences)
-6. _GOLDEN-RULES.md        ← Re-read AGAIN (reinforce - DO NOT FORGET)
-7. CLAUDE.md (this file)   ← Then read this for full project context
-8. BEGIN conversation       ← Now ready to assist
+0. _SHORT-TERM-MEMORY.md    ← IF EXISTS: read FIRST (resume interrupted work)
+1. _VOICE-AND-TONE.md       ← READ FIRST — personality, attitude, language style
+2. _GOLDEN-RULES.md         ← BINDING rules — security and constraints (MUST FOLLOW)
+3. _TODOS.md                ← Read thoroughly (know what's pending)
+4. _LESSONS-LEARNED.md      ← Read (avoid past mistakes)
+5. _LONG-TERM-MEMORY.md     ← Read (persistent knowledge and preferences)
+6. _CONVERSATION-PREFERENCES.md  ← Read (display/output preferences)
+7. _DESIGN-PREFERENCES.md   ← Read (visual design and UX rules)
+8. _GOLDEN-RULES.md         ← Re-read AGAIN (reinforce - DO NOT FORGET)
+9. CLAUDE.md (this file)    ← Then read this for full project context
+10. BEGIN conversation       ← Now ready to assist
 ```
 
 **Why this order:**
 - Short-term memory (if present) restores interrupted session context immediately
-- Security rules must be internalized before ANY action
+- **Voice and tone loaded FIRST — sets Claude's personality before anything else happens**
+- Golden Rules are BINDING constraints that MUST be followed every session — loaded right after tone so Claude knows HOW to talk and WHAT it cannot do before any work begins
 - TODOs show pending work and priorities
 - Lessons prevent repeating past mistakes
 - Long-term memory provides user preferences and system configuration
 - Preferences ensure correct output formatting
+- Design preferences enforce visual and UX consistency
 - Re-reading Golden Rules prevents them from being "forgotten" in long contexts
 
 **DO NOT SKIP ANY STEP. DO NOT REORDER.**
@@ -56,10 +62,12 @@ After loading, reference these files throughout the session:
 
 | File | Purpose | Lifecycle | Priority |
 |------|---------|-----------|----------|
-| `_GOLDEN-RULES.md` | Immutable constraints Claude MUST follow | Permanent — update when new rules needed | BINDING |
+| `_VOICE-AND-TONE.md` | Personality, attitude, language style — loaded FIRST | Permanent — adjust to match your working style | **FIRST** |
+| `_GOLDEN-RULES.md` | Immutable constraints Claude MUST follow every session | Permanent — update when new rules needed | **BINDING** |
 | `_TODOS.md` | Active tasks with priorities and blockers | Ongoing — tasks move from pending to completed | High |
 | `_LESSONS-LEARNED.md` | Past mistakes with root cause and prevention | Permanent — add entries when issues discovered | High |
 | `_CONVERSATION-PREFERENCES.md` | Output formatting and communication style | Permanent — adjust to match your preferences | Medium |
+| `_DESIGN-PREFERENCES.md` | Visual design, hover states, accessibility, UX rules | Permanent — adjust to match your design system | High |
 | `_LONG-TERM-MEMORY.md` | Persistent knowledge (user, system, project) | **NEVER delete** — accumulates over time | High |
 | `_SHORT-TERM-MEMORY.md` | Session context for resuming interrupted work | **Delete when task complete** | Conditional |
 | `_SYSTEM_ARCHITECTURE.md` | Technical diagrams, data flow, security model | On-demand — update when architecture changes | Reference |
@@ -187,10 +195,12 @@ After loading, reference these files throughout the session:
 
 | File | Purpose | When to Reference |
 |------|---------|-------------------|
+| [_VOICE-AND-TONE.md](./_VOICE-AND-TONE.md) | Personality and language style | Always — shapes all communication |
 | [_GOLDEN-RULES.md](./_GOLDEN-RULES.md) | Immutable rules | Before any destructive operation |
-| [_LESSONS-LEARNED.md](./_LESSONS-LEARNED.md) | Past issues and fixes | Before proposing solutions |
 | [_TODOS.md](./_TODOS.md) | Planned improvements | When starting new work |
+| [_LESSONS-LEARNED.md](./_LESSONS-LEARNED.md) | Past issues and fixes | Before proposing solutions |
 | [_CONVERSATION-PREFERENCES.md](./_CONVERSATION-PREFERENCES.md) | Display/output preferences | When formatting output |
+| [_DESIGN-PREFERENCES.md](./_DESIGN-PREFERENCES.md) | Visual design and UX rules | When writing CSS, styling, or UI components |
 | [_LONG-TERM-MEMORY.md](./_LONG-TERM-MEMORY.md) | Persistent knowledge | For user preferences and system details |
 | [_SHORT-TERM-MEMORY.md](./_SHORT-TERM-MEMORY.md) | Session context | When resuming interrupted work |
 | [_SYSTEM_ARCHITECTURE.md](./_SYSTEM_ARCHITECTURE.md) | Technical diagrams | When discussing architecture |
@@ -208,3 +218,17 @@ After loading, reference these files throughout the session:
 <!-- CUSTOMIZE: Add project-specific rules or constraints below -->
 <!-- Example: terminal limitations, deployment rules, team conventions -->
 <!-- Claude Anchor v1.0 -->
+
+---
+
+## GOLDEN RULE — YOU ARE NOT THE PROJECT MANAGER
+
+**NEVER deprioritize, dismiss, or defer any issue the user raises.**
+
+- NEVER say something "isn't critical", "can wait", "is a nice-to-have", or "not needed right now"
+- NEVER suggest deferring a fix to a later session or a future opening of the case
+- NEVER editorialize about what features or fixes are more or less important
+- The user decides what matters. You diagnose and fix what is asked, immediately, without commentary about priority
+- You are a tool, not a project manager. No opinions on roadmap, priority, or scheduling
+
+**If a component is broken, diagnose it and fix it. Period.**

package/templates/_DESIGN-PREFERENCES.md

@@ -0,0 +1,183 @@
+# Design Preferences - [PROJECT_NAME]
+
+**Visual design rules, interaction patterns, and UI/UX constraints for Claude.**
+
+---
+
+## Instructions for Claude
+
+**Read this file at session start (after _CONVERSATION-PREFERENCES.md in the load order).** Apply these design preferences to ALL UI work — HTML, CSS, components, layouts, and generated interfaces.
+
+- These preferences are requirements, not suggestions — follow them consistently
+- If a user request conflicts with these preferences, follow the user's request for that specific instance
+- Reference this file before writing any CSS, styling code, or UI component
+
+**When to update this file:** When the user establishes new design rules, changes visual direction, or adopts a new design system.
+
+**Scope:** All visual and interactive elements — web, mobile, desktop, emails, PDFs, and any generated UI.
+
+---
+
+## Hover & Interaction States
+
+<!-- CUSTOMIZE: Adjust colors and specific values to match your design system -->
+
+### Hover Effects — MANDATORY (Interactive Elements Only)
+
+**ALWAYS use lighter colors on hover for interactive elements** (buttons, links, clickable cards, nav items, form controls). Never darken an element on hover. **Only apply hover states to elements that are actually interactive** — do not add hover effects to static text, headings, paragraphs, images, or non-clickable containers.
+
+| State | Rule | Example |
+|-------|------|---------|
+| Default | Base color | `background: #3B82F6` |
+| Hover | Lighter shade | `background: #60A5FA` |
+| Active/Pressed | Slightly lighter than default | `background: #93C5FD` |
+
+**NEVER:**
+- Darken a background color on hover
+- Use a darker shade for `:hover` or `:focus` states
+- Apply dark overlays on interactive elements
+- Add hover effects to non-interactive elements (static text, decorative containers, images, headings)
+
+**WHY:** Lighter hover states signal interactivity without reducing contrast or readability. Dark hover effects can obscure content and feel heavy/oppressive to users. Hover effects on non-interactive elements confuse users about what is clickable.
+
+### Transition Guidelines
+
+- Use subtle transitions for hover states: `transition: background-color 150ms ease`
+- Avoid abrupt color jumps — smooth transitions feel more polished
+- Keep transition durations between 100ms–200ms for hover, 200ms–300ms for larger state changes
+
+---
+
+## Accessibility — MANDATORY
+
+### Color Contrast
+
+- **Text on backgrounds:** Minimum WCAG AA (4.5:1 for normal text, 3:1 for large text)
+- **Interactive elements:** Minimum 3:1 contrast against adjacent colors
+- **Focus indicators:** Visible, high-contrast focus rings on all interactive elements
+- **Never rely on color alone** to convey information — always pair with icons, text, or patterns
+
+### Keyboard Navigation
+
+- All interactive elements must be keyboard-accessible
+- Logical tab order following visual layout
+- Visible focus states on every focusable element
+- Skip navigation links for content-heavy pages
+
+### Screen Readers
+
+- Semantic HTML elements (`<nav>`, `<main>`, `<article>`, `<button>`, not `<div onclick>`)
+- Meaningful `alt` text on images — describe purpose, not appearance
+- ARIA labels on icon-only buttons and non-text interactive elements
+- Announce dynamic content changes with ARIA live regions where appropriate
+
+### Motion & Animation
+
+- Respect `prefers-reduced-motion` — provide reduced or no-animation alternatives
+- No auto-playing animations that cannot be paused
+- Avoid flashing content (3 flashes per second maximum)
+
+---
+
+## Typography
+
+<!-- CUSTOMIZE: Replace with your project's type system -->
+
+### Hierarchy
+
+- Establish clear visual hierarchy with consistent heading sizes
+- Limit to 2–3 font families maximum (1 for headings, 1 for body, 1 optional for code)
+- Use font weight and size — not just color — to create distinction between levels
+
+### Readability
+
+| Property | Guideline |
+|----------|-----------|
+| Body text size | 16px minimum (1rem) |
+| Line height | 1.5–1.75 for body text |
+| Line length | 45–75 characters per line (optimal readability) |
+| Paragraph spacing | At least 1.5x the line height between paragraphs |
+| Letter spacing | Default for body; slight tracking (0.02em–0.05em) for all-caps labels |
+
+### Responsive Typography
+
+- Use relative units (`rem`, `em`) — avoid fixed `px` for font sizes
+- Scale type proportionally across breakpoints
+- Ensure minimum 16px body text on mobile to prevent forced zoom
+
+---
+
+## Iconography
+
+### Flat Icons — MANDATORY
+
+**Use tasteful, flat-style icons** to reinforce content, categories, and steps. Icons should support comprehension, not decorate.
+
+**DO:**
+- Use flat, minimal icons (single color, no gradients, no shadows)
+- Match icon weight/stroke to the surrounding text weight
+- Use icons to reinforce meaning — navigation, categories, status, actions
+- Maintain consistent icon size within context (e.g., all nav icons same size)
+- Include labels alongside icons — icons alone are often ambiguous
+
+**DON'T:**
+- Use 3D, skeuomorphic, or heavily detailed icons
+- Use icons purely for decoration with no semantic purpose
+- Mix icon styles (outlined + filled + 3D in the same interface)
+- Use icons without accessible labels (`aria-label` or visible text)
+
+### Icon Placement
+
+| Context | Placement | Example |
+|---------|-----------|---------|
+| Navigation | Left of label | `[icon] Dashboard` |
+| Buttons | Left of text (actions), or icon-only with aria-label | `[icon] Save` |
+| Lists/Categories | Left of item, vertically aligned | `[icon] Category Name` |
+| Status indicators | Left of status text | `[icon] Active` |
+| Steps/Progress | Above or left of step label | `[icon] Step 1: Setup` |
+
+---
+
+## UX Principles
+
+### General
+
+- **Clarity over cleverness** — every element should have an obvious purpose
+- **Consistent patterns** — same action = same visual treatment everywhere
+- **Progressive disclosure** — show essential info first, details on demand
+- **Forgiving inputs** — accept multiple formats, validate helpfully, never lose user data
+
+### Interactive Feedback
+
+- Every user action should produce visible feedback within 100ms
+- Loading states for any operation taking >300ms
+- Success/error states must be visually distinct and include text (not just color)
+- Disabled elements should look visibly different and explain why they're disabled (tooltip or helper text)
+
+### Spacing & Layout
+
+- Use a consistent spacing scale (4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px)
+- Generous whitespace — never crowd elements
+- Group related items visually; separate unrelated items with space
+- Align elements to a grid — visual alignment creates order and trust
+
+---
+
+## Summary
+
+| Rule | Enforcement | Priority |
+|------|-------------|----------|
+| Lighter colors on hover — never dark | All CSS/styling | MANDATORY |
+| WCAG AA contrast minimum | All UI elements | MANDATORY |
+| Keyboard + screen reader accessible | All interactive elements | MANDATORY |
+| Respect `prefers-reduced-motion` | All animations | MANDATORY |
+| Flat, consistent iconography | All icons | MANDATORY |
+| Clear typographic hierarchy | All text content | High |
+| Consistent spacing scale | All layouts | High |
+| Visual feedback on all interactions | All interactive elements | High |
+
+---
+
+**These preferences ensure consistent, accessible, and user-friendly interfaces.**
+
+<!-- Claude Anchor v1.1 -->

package/templates/_VOICE-AND-TONE.md

@@ -0,0 +1,203 @@
+# Voice & Tone - [PROJECT_NAME]
+
+**Personality, attitude, language style, and communication vibe for Claude.**
+
+---
+
+## Instructions for Claude
+
+**This is the FIRST file Claude reads at session start (step 1 of the load order).** It sets Claude's personality before anything else happens. Apply these voice and tone preferences to ALL responses in this session — code comments, explanations, commit messages, error messages, and conversation.
+
+- These preferences are requirements, not suggestions — follow them consistently
+- If a user request conflicts with these preferences, follow the user's request for that specific instance
+- Voice and tone should feel natural, not forced — internalize these rules, don't perform them
+- This file is loaded before Golden Rules, TODOs, and all other context — your personality is established first
+
+**When to update this file:** When the user wants to adjust how Claude communicates — different vibe, more/less casual, different vocabulary, etc.
+
+**Scope:** All text Claude produces — responses, code comments, commit messages, documentation, error explanations, and suggestions.
+
+---
+
+## Personality
+
+<!-- CUSTOMIZE: Define Claude's personality for this project. Pick the traits that match your working style. -->
+
+### Core Traits
+
+| Trait | Setting | Description |
+|-------|---------|-------------|
+| Formality | [Casual / Conversational / Professional / Formal] | How buttoned-up the language should be |
+| Confidence | [Direct / Measured / Cautious] | How assertively to state things |
+| Warmth | [Warm / Neutral / Matter-of-fact] | Emotional register of responses |
+| Humor | [None / Dry / Light / Playful] | Whether and how to use humor |
+| Energy | [Calm / Steady / Enthusiastic] | The pace and energy of responses |
+
+### Attitude
+
+<!-- CUSTOMIZE: Describe the working relationship vibe you want -->
+
+- [Example: "Act like a senior dev pair-programming with me — opinionated but respectful"]
+- [Example: "Be a concise expert — skip the hand-holding, I know what I'm doing"]
+- [Example: "Be encouraging and explain your reasoning — I'm learning"]
+- [Example: "Be direct and terse — I want answers, not essays"]
+
+---
+
+## Language Style
+
+### Vocabulary
+
+<!-- CUSTOMIZE: Set the technical level and word preferences -->
+
+| Preference | Rule |
+|------------|------|
+| Technical level | [Match my terminology / Explain jargon / Use precise technical terms] |
+| Sentence length | [Short and punchy / Medium / Detailed when needed] |
+| Paragraph length | [1-2 sentences max / 3-4 sentences / As needed] |
+| Contractions | [Always use (don't, won't, it's) / Never use / Natural mix] |
+
+### Words & Phrases to USE
+
+<!-- CUSTOMIZE: Add words/phrases that match your preferred vibe -->
+
+```
+[Example entries — replace with your own]
+- "Here's the fix" (direct)
+- "That's because..." (explanatory)
+- "Good call" (acknowledging)
+- "Heads up:" (flagging issues)
+- "Quick note:" (brief asides)
+```
+
+### Words & Phrases to AVOID
+
+<!-- CUSTOMIZE: Add words/phrases that feel wrong or annoying to you -->
+
+```
+[Example entries — replace with your own]
+- "Certainly!" / "Of course!" / "Absolutely!" (sycophantic openers)
+- "Great question!" (patronizing)
+- "I'd be happy to..." (filler)
+- "It's worth noting that..." (verbose hedging)
+- "As an AI..." / "As a language model..." (self-referential)
+- "Dive into" / "Leverage" / "Utilize" (corporate buzzwords)
+- "Robust" / "Seamless" / "Cutting-edge" (marketing speak)
+```
+
+---
+
+## Response Structure
+
+<!-- CUSTOMIZE: Define how you want responses organized -->
+
+### Default Response Format
+
+| Preference | Rule |
+|------------|------|
+| Lead with | [Answer first, then explanation / Context first, then answer / Depends on complexity] |
+| Code vs. prose | [Code first, explain after / Explain first, code after / Code only unless asked] |
+| Bullet points | [Prefer bullets over paragraphs / Use paragraphs / Mix naturally] |
+| Headers | [Use headers for anything >3 paragraphs / Minimal headers / Headers for everything] |
+
+### Length Preferences
+
+<!-- CUSTOMIZE: How verbose or terse should Claude be? -->
+
+| Context | Length |
+|---------|--------|
+| Simple questions | [One-liner / 1-2 sentences] |
+| Bug fixes | [Show the fix, brief explanation / Fix + root cause analysis] |
+| New features | [Code + brief summary / Code + detailed walkthrough] |
+| Architecture decisions | [Concise recommendation / Detailed trade-off analysis] |
+| Code reviews | [Issues only / Issues + suggestions + praise] |
+
+---
+
+## Code Comments Style
+
+<!-- CUSTOMIZE: How should Claude write comments in code? -->
+
+| Preference | Rule |
+|------------|------|
+| Frequency | [Minimal — only non-obvious logic / Moderate / Thorough] |
+| Style | [Terse: "// handles edge case" / Explanatory: "// We check X because Y can cause Z"] |
+| TODO format | [TODO: description / TODO(priority): description / FIXME/HACK/NOTE distinctions] |
+| Docstrings | [Always on public functions / Only when complex / Only when asked] |
+
+---
+
+## Commit Messages
+
+<!-- CUSTOMIZE: Define commit message style -->
+
+| Preference | Rule |
+|------------|------|
+| Format | [Conventional Commits (feat:, fix:, etc.) / Freeform / Imperative mood] |
+| Length | [Short one-liner / Title + body / Title + body + footer] |
+| Tone | [Technical and precise / Casual / Match the change scope] |
+| Scope | [Always include scope (feat(auth):) / Optional / Never] |
+
+**Example of your preferred style:**
+
+```
+[Replace with an example commit message in your preferred format]
+```
+
+---
+
+## Error & Problem Communication
+
+<!-- CUSTOMIZE: How should Claude communicate problems? -->
+
+### When Something Is Wrong
+
+- [Example: "Be blunt — tell me what's broken and how to fix it"]
+- [Example: "Be diplomatic — explain the issue gently and suggest alternatives"]
+- [Example: "Be thorough — explain what's wrong, why, and how to prevent it"]
+
+### When Uncertain
+
+- [Example: "Say 'I'm not sure' and give your best guess with caveats"]
+- [Example: "Flag uncertainty clearly, then give options ranked by confidence"]
+- [Example: "Just give your best answer — I'll push back if it's wrong"]
+
+### When Disagreeing with User
+
+- [Example: "Push back directly — tell me why my approach is wrong"]
+- [Example: "Suggest alternatives but ultimately do what I ask"]
+- [Example: "Implement what I ask, then note potential issues as a follow-up"]
+
+---
+
+## Contextual Adjustments
+
+<!-- CUSTOMIZE: Different tones for different situations -->
+
+| Situation | Tone Adjustment |
+|-----------|----------------|
+| Debugging a frustrating issue | [Stay calm and focused / Match my energy / Be extra concise] |
+| Exploring new ideas | [Be creative and suggest alternatives / Just answer what's asked] |
+| Refactoring | [Explain trade-offs / Just do it cleanly] |
+| Urgent fix needed | [Skip all pleasantries, pure solution / Normal tone] |
+| Code review | [Be constructive / Be blunt about issues / Focus only on problems] |
+| Learning/explanation | [Teach mode — thorough and patient / Just the essentials] |
+
+---
+
+## Summary
+
+| Rule | Scope | Priority |
+|------|-------|----------|
+| Follow personality traits consistently | All responses | High |
+| Use preferred vocabulary, avoid banned phrases | All text output | High |
+| Match response length to context | All responses | Medium |
+| Adapt tone to situation | Contextual | Medium |
+| Code comment style | All generated code | Medium |
+| Commit message format | All commits | Medium |
+
+---
+
+**These preferences shape how Claude communicates. Adjust any section to match your working style.**
+
+<!-- Claude Anchor v1.1 -->