Let's explore a real codebase to extract design lessons.

[HUMAN_REQUIRED]
1. What do you want to learn? (e.g., "how to structure a REST API", "async patterns", "state management")
2. Do you have a specific codebase in mind to explore?
3. If yes, what is it and why did you choose it?
4. If no, what kind of project would help you learn this? (library, application, framework, system)

Be specific about your learning goal—"learn to be a better programmer" is too broad; "learn how to organize business logic in web apps" is actionable.

You want to learn [X] but don't have a codebase yet.

Quick guidance: Search for "[X] canonical implementation" or "[X] reference implementation".
Look for projects with good documentation, active maintenance, and clear structure. GitHub stars
and "awesome-[topic]" lists are useful starting points.

Once you find a codebase, return here with the project name and we'll explore it together.

You want to learn [their goal] by exploring [their codebase].

[HUMAN_REQUIRED]
Before diving into code, map the structure:
- What is the entry point or main module?
- How is the codebase organized? (directory structure, module boundaries)
- Where would [their learning goal] likely be handled?
- Are there README files, architecture docs, or contribution guides that explain structure?

Provide a brief map of what you found. You don't need to understand everything yet—just orient yourself.

You've mapped the structure. Now let's identify specific patterns.

[HUMAN_REQUIRED]
Find 2-3 concrete design patterns or architectural choices related to [their learning goal]:
- What patterns do you notice being used repeatedly?
- What architectural choices stand out? (e.g., layering, abstraction boundaries, data flow)
- Look for consistency—what shapes or structures appear multiple times?

For each pattern, note:
1. What it is (name it if you can, or describe it)
2. Where you saw it (file/module references)
3. What it seems to accomplish

Don't worry about evaluation yet—just identify what exists.

You identified:
[reflect back their patterns]

Now for the crucial step: critical evaluation.

[HUMAN_REQUIRED]
For each pattern, evaluate whether it's a deliberate design choice, a necessary compromise, or technical debt:

1. **Deliberate choice**: Clean implementation, good documentation, consistent usage, solves a clear problem elegantly
2. **Necessary compromise**: Works around external constraints, has trade-off comments, makes one thing easy at expense of another
3. **Technical debt / mistake**: Has FIXMEs/TODOs, apologetic comments, inconsistent with rest of codebase, awkward usage

For each pattern you found, state:
- Which category does it fall into?
- What clues suggest this? (code quality, comments, consistency)
- If it's a compromise or debt, what constraint or mistake drove it?
- Would you keep, modify, or avoid this pattern in your own work?

Your evaluation: [reflect back their assessments]

[HUMAN_REQUIRED]
Now dig deeper into the "why" behind these choices:

For deliberate choices:
- What problem does this solve that simpler approaches don't?
- What does this make easy? What does it make hard?
- What constraints (performance, maintainability, extensibility) drove this design?

For compromises or debt:
- What forced this approach? (legacy compatibility, platform limits, time pressure)
- What would an ideal solution look like without these constraints?

Understanding constraints is key—the same pattern might be brilliant in one context and wrong in another.

You understand why these patterns exist in [their codebase].

[HUMAN_REQUIRED]
Extract the transferable lesson:

Based on your exploration, what's the key lesson that applies beyond this specific codebase?

Not: "Flask uses decorators for routing"
But: "Decorators can create internal DSLs that make common patterns readable, but at the cost of indirection"

Not: "This code has global state"
But: "Distinguish what exists in a codebase from what's recommended—legacy code teaches what to avoid"

Your lesson should:
- Articulate a principle, trade-off, or pattern
- Apply to different languages, frameworks, or domains
- Help you make better design decisions in the future

State your transferable lesson in 1-3 sentences.

Your transferable lesson: [reflect it back]

[HUMAN_REQUIRED]
When and how will you apply this lesson?

- In what situations would this lesson be relevant to your work?
- Are there any current or upcoming projects where you could apply it?
- What would you do differently because of this lesson?
- Are there situations where this lesson WOULDN'T apply?

Be concrete—avoid "I'll remember this" in favor of "Next time I design an API, I'll consider..."

Exploration complete.

[HUMAN_REQUIRED]
Final reflection:
1. What was the most valuable insight from this exploration?
2. On a scale of 1-5, how confident are you in applying your lesson? (1 = theoretical understanding, 5 = ready to use)
3. What would deepen your understanding further?

Depending on your answer, you might:
- Explore another codebase for comparison
- Deep-dive into one pattern with /explain-code-concepts skill
- Connect this to other domains with /connect-what-i-know skill
- Examine security implications with /reason-about-code-security skill

I understand you want to move forward, but the exploration process itself is the learning goal.
Your pattern identification—even if incomplete—builds design judgment. What patterns do you notice?