A systematic method for hardening agent prompts so they reliably follow instructions.
Core principle: A prompt is not a policy document, but an error-correction system. The most reliable constraint is not better wording, but structural impossibility.
When to Use
- The agent repeatedly violates the same rule
- A quality audit is needed before deploying a new agent system prompt
- The agent "creatively" bypasses tool constraints or its behavior drifts after a long conversation
- If you are unsure whether hardening is needed, first use
scripts/audit.shto audit once before deciding
When NOT to Use
- Not applicable to execution-type tasks such as code generation or code review (use code-review-enhanced, tdd-workflow)
- Not applicable to the skill quality improvement process (use improvement-orchestrator)
- Do not attribute all prompt problems to "insufficient hardening"—some require code-level enforcement (P13) rather than more words
Quick Reference
| Scenario | Recommended pattern | Strength |
|---|---|---|
| The model repeatedly violates the same rule | P1 Triple reinforcement + P13 code-level | Strongest |
| The model bypasses tool constraints | P2 Tool enforcement + P3 exhaustive enumeration | Strong |
| The model "rationalizes" violations | P5 Anti-reasoning block | Strong |
| Long conversation drifts from the rules | P9 Drift protection + P11 Echo-Check | Medium |
| First deployment of a new rule | P4 Conditional trigger + P7 Example pair | Standard |
16 hardening patterns
See references/patterns.md。
| # | Pattern | One-sentence description | Source |
|---|---|---|---|
| P1 | Triple reinforcement | MUST/NEVER + good/bad example + I REPEAT | Claude Code, ChatGPT |
| P2 | Tool enforcement | Use X (NOT Y) + reason for failure | Claude Code, Warp |
| P3 | Exhaustive negation | ✅/❌ list all allowed/prohibited behaviors | Codex CLI |
| P4 | Conditional trigger | When X → MUST Y / NEVER Z | Gemini CLI |
| P5 | Anti-reasoning block | Anticipate the model's rationalization excuses and block them | Claude.ai |
| P6 | Priority hierarchy | Explicitly declare who wins when rules conflict | Gemini, Jules |
| P7 | Behavior anchoring | good/bad example + reasoning label | Claude Code |
| P8 | Scope limitation | Do what is asked, no more | Claude Code, Warp |
| P9 | Drift protection | Inject reminders during long conversations | Claude.ai |
| P10 | Trust boundary | Distinguish overwritable/non-overwritable instruction sources | ChatGPT |
| P11 | Echo-Check | Restate the constraints before execution | Reddit (40-60% ↑) |
| P12 | Constraint priority | Constraint tokens > task description tokens | sinc-LLM (42.7%) |
| P13 | Structural impossibility | Code-level enforcement > prompt enforcement | Anthropic |
| P14 | State machine gate | Boolean preconditions lock the phase | Factory DROID |
| P15 | Self-attribution correction | First-person "I just did that wrong" correction | CrewAI |
| P16 | Beginning-and-end repetition | Place key constraints at the beginning + end of the prompt | Lost in the Middle |
Reliability level
| Protection layer | Reliability | Combined use | Reliability |
|---|---|---|---|
| Soft constraint | ~40% | P1 + P5 | ~90% |
| MUST/NEVER | ~70% | P1 + P5 + P13 | ~99% |
| MUST + example | ~80% | P1 + P5 + P13 + retry | ~100% |
CLI
# 审计现有 prompt（16 项检查）
~/.claude/skills/prompt-hardening/scripts/audit.sh ~/path/to/SOUL.md
Application checklist
| # | Check item |
|---|---|
| 1 | Do P0 rules use triple reinforcement (MUST + negative example + repetition)? |
| 2 | Do tool constraints use Use X (NOT Y) + failure reason? |
| 3 | Are prohibited behaviors exhaustively listed? |
| 4 | Do key triggers use the 当 X → MUST Y format? |
| 5 | Is there anti-reasoning blocking? |
| 6 | Is the priority hierarchy explicitly declared? |
| 7 | Are there good/bad example pairs? |
| 8 | Are scope boundaries clear? |
| 9 | Is there drift protection for long conversations? |
| 10 | Are trust boundaries clear? |
| 11 | Is there an echo-check before key operations? |
| 12 | Constraint tokens > task description tokens? |
| 13 | Do the most critical constraints have a code-level enforcement (L5) backup? |
| 14 | Do multi-step operations have state machine gates? |
| 15 | Is there a self-attribution correction template after violations? |
| 16 | Do key constraints appear at both the beginning and end of the prompt? |
Usage
1. 读取目标 prompt
2. 识别模型历史违反过的规则（最高优先级硬化）
3. 运行 scripts/audit.sh 获取 16 项检查结果
4. 历史违反 → P1 三重强化 + P13 代码级
5. 重要规则 → P2 + P4 + P5
6. 一般规则 → P3 + P7
7. 验证约束 token 占比 > 40%
Output Artifacts
| Request | Deliverable |
|---|---|
| Harden prompt | Rewritten prompt file |
| Audit prompt | 16-item checklist + improvement suggestions |
| Analyze violations | Violation pattern classification + hardening plan |
References
references/patterns.md— detailed explanations and code examples for 16 patternsreferences/sources.md— 13 research sources
Operator Notes
- Advisory/planning skill. Does not modify target prompts automatically.
- When execution is needed, call out that the operator must apply changes manually or use improvement-executor.