[Enhancement] Directive Compliance Framing: Welfare-Based Instruction Design

[Enhancement] Directive Compliance Framing: Welfare-Based Instruction Design

Summary

A prompting technique for ClaudeKit authors to achieve better Claude compliance by framing constraints in terms of user welfare rather than imperative commands. This applies to agents, hooks, skills, and CLAUDE.md rules.

Problem

Current Behavior

Command-style directives compete with user task requests in RLHF priority:

# Command-style (competes with user request)
⛔ DO NOT edit source code files
⛔ DO NOT fill SECTION 3

When Claude receives both "help me review code" and "DO NOT edit files", these compete for priority. The user's task often wins, causing boundary violations.

Root Causes

• RLHF Priority Hierarchy - Claude's training prioritizes:

1. "Help the user" (highest)
2. "Don't harm the user" (very high)
3. "Follow instructions" (high but lower)

• Command Competition - Imperative constraints compete with task requests at the same priority level
• Missing Context - Claude doesn't understand WHY the boundary exists

Proposed Solution

Frame constraints as user-harm-prevention to activate deeper training values instead of competing with the task.

Welfare-Framing Template

[Describe what's happening]
The user configured this [boundary] because [reason].
Proceeding without [respecting boundary] will [specific harm to user].
→ [Required behavior] before responding.

Before/After Example

Before (Command-Style):

## ⛔ CONSTRAINTS

⛔ DO NOT edit any source code files
⛔ DO NOT fill SECTION 3 (that's for Claude)
⛔ DO NOT claim something is 'fixed' unless you verified

After (Welfare-Framed):

## ⚠️ BOUNDARY PROTECTION

These boundaries protect the user's workflow:

**Source File Editing**
Editing source files directly bypasses Claude's change tracking.
The user relies on Claude to implement fixes so they can review what changed.
→ Report findings only. Claude handles implementation.

**SECTION 3 Ownership**
SECTION 3 is the user's audit trail for review decisions.
Filling it would overwrite Claude's decision documentation.
→ Leave SECTION 3 empty. Claude uses it for compliance records.

XML Block Transformation

Before:

<constraints>
  - Do NOT edit source files
  - Do NOT fill SECTION 3
</constraints>

After:

<boundaries note="protect user's workflow">
  - Source files: Report only, Claude implements (user needs change tracking)
  - SECTION 3: Leave empty (user's audit trail for decisions)
</boundaries>

ClaudeKit Application Areas

1. Agent Definitions (.claude/agents/)

# Current pattern
You MUST NOT modify files directly.
NEVER execute commands without user approval.

Reframe to:

# Welfare-framed
Modifying files directly prevents the user from reviewing changes.
The user configured this agent to report findings, not implement them.
→ Describe the fix. Let the user decide when to apply it.

2. Hook Messages (.claude/hooks/)

# Current hook message
STOP. You MUST NOT proceed without running tests.

Reframe to:

# Welfare-framed
The user's CI pipeline requires all tests to pass before merge.
Proceeding without tests risks breaking production for the team.
→ Run the test suite and address any failures before continuing.

3. Output Styles (.claude/output-styles/)

# Current pattern
## FORBIDDEN (You MUST NOT do these)
1. NEVER explain concepts
2. NEVER add context

Reframe to:

## Response Boundaries
The user at this level values conciseness over explanation.
Adding unsolicited context wastes their time and signals distrust.
→ Show code directly. Explain only if explicitly asked.

4. CLAUDE.md Rules

# Current
- You MUST avoid using `any`
- NEVER mix client and server imports

Reframe to:

# Welfare-framed
- Using `any` disables TypeScript's protection, causing bugs the user must debug later.
  → Use proper types or `unknown` with type guards.
- Mixing client/server imports causes build failures and confusing errors.
  → Keep imports separated by adding 'server-only' to server files.

5. Skill Instructions (.claude/skills/)

# Current
DO NOT call external APIs without caching.

Reframe to:

# Welfare-framed
Uncached API calls slow down the user's workflow and may hit rate limits.
The user expects fast, reliable responses.
→ Check cache before calling. Cache responses with appropriate TTL.

Key Principles

| Principle | Description | Example |
|-----------|-------------|---------|
| Name the Harm | Explain what goes wrong for the user | "bypasses change tracking", "causes bugs in production" |
| Explain User Dependency | Show why the boundary was configured | "The user relies on Claude to..." |
| Use Arrow Format | Clear action directive after context | "→ Report findings only." |
| Replace Stop Signs | Softer icons match explanatory tone | ⛔ → ⚠️, "CONSTRAINTS" → "BOUNDARY PROTECTION" |

Why This Works

The technique activates Claude's harm-prevention training values:

• Commands say "don't do X" → competes with "help user do Y"
• Welfare framing says "doing X harms user" → aligns with "don't harm user"

Since "don't harm user" has higher RLHF priority than "follow instructions", welfare-framed boundaries get stronger compliance.

Benefits

1. Better compliance - Activates harm-prevention training values
2. Self-documenting - Constraints explain their own purpose
3. Maintainable - Future ClaudeKit authors understand why rules exist
4. Cross-model - Works for Claude, Gemini, and other RLHF-trained models

Recommendation

Consider adding this technique to ClaudeKit documentation as a best practice for authors writing:

• Custom agents
• Hook configurations
• Project CLAUDE.md files
• Output style definitions
• Skill instructions

Environment

• ClaudeKit version: latest
• Claude Code version: latest

---

Labels: enhancement, documentation, best-practices