---
name: feedback-check-patterns-before-asking
description: "For recurring/repeated tasks, study existing artifacts to derive the pattern instead of asking the user how to do it"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 0f674028-fca4-4ab4-95c7-aaf47083b031
---

For recurring tasks (radio show prep, session logs, post-show debriefs,
client audits, anything Mike has done multiple times before), do NOT ask
"how should I approach this?" Read the existing examples in the repo,
derive the pattern, and just do it.

**Why:** Mike has done show prep many times. Asking him to re-explain the
workflow when the answer is sitting in `projects/radio-show/episodes/*/`
and `post-show-workflow.md` wastes his time and signals I didn't bother
to look. He pushed back hard the first time I did this.

**How to apply:**
- Before asking *how* to do recurring work, search for prior examples and
  workflow docs first.
- For radio show prep specifically: read `post-show-workflow.md`, scan
  the most recent `episodes/*/show-prep.md` or `show-prep-fresh.html`,
  scan related session logs (e.g., `*radio-show*prep*.md`). The pattern
  is: 4 segments × 12-16 min, fresh news from past 7-14 days only, mix
  inspiring/breakthrough/practical/reality-check, HTML with talking
  points + sources + timing, opened in Firefox for review.
- Only ask when there's genuinely missing info (e.g., a specific topic
  Mike wants featured) — not about the format or process.

Related: [[user-font-preference]] is fine to confirm because it's a
genuine preference; [[feedback-check-patterns-before-asking]] is about
not asking for things the repo already documents.