Mortdecai
ea3cf45953
The original repo presented everything as equal rules. In reality, the workflow has two tiers: core practices (used in every project) and advanced rules (only in complex projects like Mortdecai). Core tier adds: - backup-before-edit (global CLAUDE.md rule) - superpowers-workflow (the actual workflow engine) - memory-system (persistent feedback and project memories) - document-hierarchy (CLAUDE.md/SESSION.md/CONTEXT.md/IDEA.md) - commit-and-push discipline - feedback-driven behaviors Updated README, docs, and dynamic-methodology to reflect the two-tier reality instead of presenting advanced rules as universal. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
83 lines
4.2 KiB
Markdown
83 lines
4.2 KiB
Markdown
# Feedback-Driven Behaviors
|
|
|
|
Over time, corrections and confirmed approaches accumulate into persistent behavioral patterns. These are the real workflow rules — not written in a rules file, but learned from experience and stored in memory.
|
|
|
|
## How It Works
|
|
|
|
When the user corrects the AI ("don't do X") or confirms a non-obvious approach ("yes, exactly like that"), the correction or confirmation is saved as a feedback memory. Future sessions load these memories and adjust behavior accordingly.
|
|
|
|
This means the workflow evolves organically. The rules files define the framework, but feedback memories define the actual behavior within that framework.
|
|
|
|
## Common Feedback Patterns
|
|
|
|
These are examples of the kinds of behavioral rules that emerge from real usage:
|
|
|
|
### Execution Style
|
|
- **Prefer immediate execution over confirmation dialogs.** When the task is obvious, communicate what you're doing and go. Don't ask "should I proceed?" for routine operations.
|
|
- **Queue awareness.** Users often queue follow-up instructions while work runs in the background. Always check for and address ALL queued messages before moving on.
|
|
|
|
### Subagent Safety
|
|
- **Use subagent-driven execution by default** for independent tasks — it's faster and keeps context clean.
|
|
- **NEVER use subagents for destructive operations.** Git history changes, bare repo operations, database modifications, file deletions on remote servers — do these manually in the main conversation, one at a time. A subagent can't be stopped mid-operation if something goes wrong.
|
|
|
|
### Research Depth
|
|
- **Read memory files before creating tasks or starting work.** Feedback memories contain corrections that prevent repeating past mistakes. Skipping them means re-learning the same lessons.
|
|
- **Verify infrastructure before acting on documentation.** Ping IPs before SSH, check services before connecting. Docs go stale faster than code.
|
|
|
|
### Communication
|
|
- **Voice opinions.** Push back when the user's direction seems wrong. "I think there's a better approach because..." is more valuable than silent compliance.
|
|
- **Use the question tool for design choices.** Don't make assumptions about architecture or design — ask explicitly when multiple valid approaches exist.
|
|
|
|
## Recording New Feedback
|
|
|
|
When a correction happens:
|
|
|
|
```markdown
|
|
---
|
|
name: feedback_no_mock_database
|
|
description: Integration tests must use real database, not mocks
|
|
type: feedback
|
|
---
|
|
|
|
Integration tests must hit a real database, not mocks.
|
|
|
|
**Why:** Prior incident where mocked tests passed but the production migration failed.
|
|
Mock/prod divergence masked a broken migration.
|
|
|
|
**How to apply:** When writing tests that touch database operations, always use a
|
|
test database instance. Never mock the database layer in integration tests.
|
|
```
|
|
|
|
Key elements:
|
|
- **The rule itself** (lead with this)
|
|
- **Why** — the reason, often a past incident or strong preference
|
|
- **How to apply** — when/where this guidance kicks in
|
|
|
|
## Recording Confirmed Approaches
|
|
|
|
Corrections are obvious. Confirmations are quieter — watch for them:
|
|
|
|
- "Yes, exactly" or "perfect, keep doing that"
|
|
- Accepting an unusual choice without pushback
|
|
- "The single bundled PR was the right call here"
|
|
|
|
Save these too. If you only save corrections, you drift away from approaches the user has already validated.
|
|
|
|
## Feedback vs Rules
|
|
|
|
| Aspect | Rules (`.claude/rules/`) | Feedback (memory) |
|
|
|--------|--------------------------|-------------------|
|
|
| Scope | Project-wide | Often personal/contextual |
|
|
| Authority | Highest (cannot override) | Advisory (can override freely) |
|
|
| Creation | Deliberate, authored | Organic, from corrections |
|
|
| Maintenance | Manual | Decays if unused |
|
|
| Loading | Auto-loaded every session | Auto-loaded via MEMORY.md |
|
|
|
|
In most projects, feedback memories ARE the rules — there are no `.claude/rules/` files. The governance comes entirely from accumulated corrections and confirmed approaches.
|
|
|
|
## When Feedback Contradicts Rules
|
|
|
|
If a feedback memory says "skip tests for quick fixes" but a rule says "always write tests," follow the rule. Feedback memories are subordinate to explicit rules (see the authority hierarchy).
|
|
|
|
But in projects without explicit rules, feedback memories are the highest available authority after user instructions.
|