warpdotdev Reply Learning
Extract durable patterns from feedback and examples, then codify them into the draft-brand-reply skill. The goal is always mental models and concepts, never reactive rules tied to a single situation.
When this triggers
- You receive feedback on a draft reply ("this is too brand-y", "you're hallucinating", "this isn't right")
- You're asked to review examples of past replies or triage decisions
- You're asked to look at reaction data or community engagement patterns
- You're explicitly asked to improve the reply skill
Process
1. Identify what went wrong (or right)
Start from the specific feedback or example. What happened? Be concrete:
- "I fabricated a known issue to sound helpful"
- "I conceded the competitor's framing of as heavy"
- "The tone sounded like a community manager, not a builder"
2. Ask: why?
The specific failure is a symptom. Find the underlying cause:
- Fabricating context → tendency to fill knowledge gaps with plausible filler
- Conceding framing → not confident enough in 's positioning
- Brand-y tone → optimizing for "sounding helpful" instead of actually being helpful
3. Zoom out to the pattern
Check: would this principle apply to situations beyond the one that triggered it? If it only applies to one narrow case, it's too specific. If it applies broadly, it's a pattern worth codifying.
Good pattern: "If you don't know, say less, not more" — applies to bug reports, feature questions, roadmap inquiries, anything where you might be tempted to fill a gap.
Too specific: "Don't say 'we're tracking this' on bug reports" — this is just one manifestation of the broader principle.
Test: Can you think of 3+ different situations where this principle would change behavior? If yes, it's a pattern. If not, it's a rule.
4. Check against existing principles
Read .agents/skills/draft-brand-reply/SKILL.md before adding anything. Often the right move is to sharpen an existing principle rather than add a new one. The skill should stay lean — every line needs to justify its context window cost.
Ask:
- Does an existing principle already cover this? → Sharpen its wording
- Does an existing principle contradict what you've learned? → Edit or remove it
- Is something in the skill actively leading to worse replies? → Delete it
- Is this a genuinely new dimension not yet covered? → Add it in the right section
- Is this a specific topic that keeps coming up? → Add to Topic-specific notes (but only if the pattern itself isn't general enough to live in Principles)
Adding, editing, and deleting are equally valid. A wrong principle does more damage than a missing one, but a missing one still leaves a gap. Match the action to what you've learned.
5. Write it as a principle, not a rule
Principles describe how to think. Rules describe what to do. Prefer principles.
Principle: "Own 's frame — don't let someone else's comparison define what is." → This changes thinking across all comparison scenarios.
Rule: "When someone compares to , lead with 's AI features." → This only helps in one situation and might be wrong in the next.
6. Place it correctly in the skill
- Attitude — how to think and feel about the interaction (confidence, empathy, honesty)
- Behavior — how to act on those attitudes (be precise, say less, find hooks)
- Hard constraints — bright lines that should never be crossed
- Topic-specific notes — only for genuinely recurring topics with non-obvious correct answers (e.g., subscription redirect)
Most learnings belong in Attitude or Behavior.
7. Edit and commit
Update .agents/skills/draft-brand-reply/SKILL.md with the change. Keep it tight — if the skill is getting long, look for principles that overlap and can be merged.
Learning from bulk data
When reviewing reaction data, triage patterns, or engagement analytics:
- Look for what the data says the team actually does vs. what the skill currently says to do. Mismatches are the highest-value finds.
- Quantify but don't over-index — percentages change, but the underlying reasoning usually doesn't. Codify the reasoning, not the numbers.
- Look for surprising skips and surprising replies — the edge cases reveal judgment calls that the skill might not yet capture.
- Check for consistent patterns across team members — if everyone makes the same call, it's probably a principle worth writing down. If they disagree, it's a judgment call that may not need codifying.
Anti-patterns
- Adding a rule for every mistake — the skill should have fewer, sharper principles, not an ever-growing list of don'ts.
- Codifying preferences as principles — if it's a stylistic choice that could reasonably go either way, it's not a principle.
- Keeping stale patterns — if a principle no longer matches how the team actually behaves, update or remove it.
- Over-engineering the skill — the draft-brand-reply skill should stay under ~200 lines. If it's growing past that, consolidate.