Use this when you want to mine your accumulated feedback -- mistakes made, corrections received, validated approaches -- and turn them into actionable patterns. This is the "mistakes file" concept: instead of repeating the same errors, systematically review what you've learned about how to work and surface the patterns worth embedding into your practice.
Related skills: Draws from entries logged via
/engagement-journal(specificallylesson-learnedentries). Complements/engagement-retrowhich captures lessons per engagement -- this works across engagements and sessions. Feeds into/pattern-harvesterfor broader cross-engagement pattern mining.
Process
Step 1: Gather feedback sources
Collect feedback from all available sources. If any source yields no files, note the gap and proceed with what's available.
- Memory feedback files -- read any
feedback_*.mdfiles in the memory directory. These capture real-time corrections and validated approaches. - Engagement journals -- scan
journals/for all entry types. Explicit feedback surfaces inlesson-learned,reframe-moment, anddecision-madeentries, but also extract implicit feedback frompattern-observed,outcome-achieved, andinsight-capturedentries -- these often contain lessons embedded in narrative rather than labeled as corrections. - Language ledgers -- scan
journals/for anylanguage-*.mdfiles. Client language preferences, framing shifts, and power phrases reveal working-style feedback that's easy to miss. - Retro outputs -- check
journals/and skill output directories for engagement retro files that captured "What Was Hard" or "What I'd Do Differently" sections. - User input -- ask: "Any recent mistakes, corrections, or 'I wish I'd done it differently' moments you want to add?"
Step 2: Extract and categorize
For each feedback item, extract:
- What happened -- the mistake, correction, or validated approach (one sentence)
- Category --
process|communication|technical|scoping|client-management|tool-usage|estimation|stakeholder-dynamics - Direction --
avoid(don't do this) |repeat(keep doing this) |adjust(do this but differently) - Frequency -- how many times has this come up? (once, recurring, chronic)
- Context -- when does this apply? (specific engagement type, tool, situation)
Note: Most journal entries won't be labeled as "feedback." Look for feedback embedded in outcomes ("this worked because..."), patterns ("this keeps happening..."), decisions ("we chose X over Y because..."), and especially in blockers and risks. A stalled handoff or an access issue recurring across engagements is feedback about process, even if nobody called it that.
Step 3: Find patterns
Group the items and look for:
- Recurring mistakes -- same error appearing 3+ times = systemic issue, not a one-off
- Contradictions -- feedback that conflicts (e.g., "be more detailed" vs "keep it brief") -- these usually indicate context-dependent rules, not actual contradictions. Name the context.
- Validated approaches -- things that worked well and were confirmed. These are easy to lose because success is quieter than failure.
- Clusters -- multiple items pointing to the same root cause
Step 4: Produce the audit
## Feedback Audit -- {{date}}
### Sources reviewed
- {{number}} feedback memories
- {{number}} journal entries
- {{number}} language ledger entries
- {{number}} retro outputs
- {{number}} user-provided items
### Top Patterns
**Pattern 1: {{Name}}** ({{category}}, recurring {{N}} times)
- What keeps happening: {{description}}
- Root cause: {{why this keeps recurring}}
- Rule: {{the working rule to follow going forward}}
- Applies when: {{context where this rule kicks in}}
**Pattern 2: {{Name}}** ...
### Validated Approaches (Keep Doing These)
- {{approach}} -- confirmed in {{context}}. Why it works: {{reason}}.
### One-Off Lessons (Not Yet Patterns)
- {{lesson}} -- happened once in {{context}}. Watch for recurrence.
### Contradictions to Resolve
- {{feedback A}} vs {{feedback B}} -- likely context-dependent: {{proposed resolution}}
### Recommended Actions
- [ ] Save Pattern 1 as a feedback memory for session injection
- [ ] Update {{specific file}} to reflect Pattern 2
- [ ] Discuss contradiction {{N}} with user to resolve
Step 5: Act on findings
For each top pattern, offer to:
- Save as a feedback memory so it gets loaded into future sessions
- Update a skill or knowledge file if the pattern affects a specific skill's process
- Add to CLAUDE.md if it's a repo-wide convention worth documenting
Ask the user which actions to take. Don't batch-save everything -- let them choose what's worth embedding.
Example Output
Input
- Feedback sources available: 3 feedback memory files (
feedback_client-comms.md,feedback_deck-structure.md,feedback_scoping.md), 14 journal entries across 4 engagements (Meridian Logistics, Hartwell Capital, Foxgrove Retail, Dunmore Health), 1 language ledger (language-hartwell.md), 2 retro outputs - User-provided additions: "I keep sending first drafts of exec summaries before I've stress-tested the 'so what' -- got called out on it twice last month. Also, the Dunmore kickoff went really well and I want to remember why."
- Audit focus: Across the last 90 days, all engagement types
- User context: Independent strategy consultant, primarily C-suite deliverables and organizational diagnostics
Output (abbreviated)
Feedback Audit — June 2025
Sources Reviewed
- 3 feedback memory files
- 14 journal entries (4 engagements)
- 1 language ledger (Hartwell Capital)
- 2 retro outputs (Meridian post-engagement, Foxgrove mid-point)
- 2 user-provided items
Top Patterns
Pattern 1: Premature Exec Summary Dispatch (communication, recurring 4 times)
- What keeps happening: First-draft exec summaries go to clients or sponsors before the "so what" has been stress-tested against the actual audience's decision context. The finding is accurate but the implication lands flat or requires a follow-up reframe.
- Root cause: Draft completion gets treated as readiness signal. The logic chain (finding → implication → decision relevance) isn't explicitly checked before sending.
- Rule: Before sending any exec summary, run the three-question check: What does this person need to decide? Does my summary answer that directly? What would make them push back?
- Applies when: Any deliverable going to VP-level or above, especially in first-touch or mid-engagement moments.
Pattern 2: Scope Anchor Set Too Late (scoping, recurring 3 times)
- What keeps happening: Scope boundaries get defined during or after the first working session rather than before it. Meridian and Foxgrove both had work-back conversations that cost 1–2 weeks of re-alignment.
- Root cause: Eagerness to get into the content. The diagnostic work feels more valuable than the framing conversation, so the framing gets deferred.
- Rule: No working session before a written scope anchor — even a one-paragraph email confirming "here's what we're solving for and what we're not" counts.
- Applies when: All new engagements and any engagement entering a new phase.
Pattern 3: Hartwell Jargon Mismatch (communication / client-management, recurring 3 times)
- What keeps happening: Language ledger shows three moments where standard consulting framing ("workstream," "operating model," "north star") was flagged or visibly landed poorly. The Hartwell team uses operational language, not strategic abstraction.
- Root cause: Default vocabulary isn't being adjusted at engagement start — the ledger exists but isn't being referenced before client-facing drafts.
- Rule: Pull the language ledger before drafting anything for a returning client. Flag 3–5 terms to avoid and 3–5 preferred substitutes.
- Applies when: Any deliverable for a client with an existing language ledger on file.
Validated Approaches (Keep Doing These)
- Dunmore kickoff structure — opened with a 10-minute "what success looks like in 90 days" exercise before any discovery questions. Client reported it set the right tone immediately. Why it works: anchors the relationship in outcomes before process, and gives the consultant a decision filter for everything that follows.
- Meridian risk register as a communication tool — presenting the risk register mid-engagement (not just at close) prompted the client to surface a political constraint they'd been withholding. Why it works: makes it safe to share bad news when you're already naming risks together.
One-Off Lessons (Not Yet Patterns)
- Foxgrove retro flagged that a workshop with mixed seniority (IC to SVP) needed a pre-session norm-setting moment that wasn't planned for. Flattening worked eventually but cost 20 minutes. Watch for recurrence in mixed-room formats.
- Hartwell language ledger noted that the CFO responds better to written pre-reads than live framing — caught once, not yet confirmed as a rule.
Contradictions to Resolve
- "Be more concise in written updates" (Meridian retro) vs "We needed more context in the recommendations" (Foxgrove mid-point check-in) — likely context-dependent: concision rule applies to status updates and check-in emails; fuller context applies to recommendation memos where the reader must act without you in the room. Proposed resolution: document two templates — one for updates, one for action-driving recommendations.
Recommended Actions
- Save Pattern 1 (exec summary check) as a feedback memory for session injection — high recurrence, easy to operationalize
- Add Pattern 2 (scope anchor) to the scoping skill process as a hard gate before Step 1
- Update
feedback_client-comms.mdto formalize the Hartwell language ledger pull as a pre-draft step - Save Dunmore kickoff structure as a validated approach memory — at risk of being lost since success is quieter than failure
- Discuss the concision contradiction to confirm the two-template resolution before documenting
Which of these do you want to act on now?