@withmata/blueprints 0.4.0 → 0.7.0

package/.claude/skills/design-system/SKILL.md

@@ -949,11 +949,17 @@ Tell the user:
   <link href="https://fonts.googleapis.com/css2?family=..." rel="stylesheet" />
   ```
 - **Tailwind sync status** — whether tokens were synced to the scaffolded `shared-styles.css`, or whether the user needs to run `/scaffold-tailwind` first
-- **Suggested next steps:**
-  - If tailwind is not yet scaffolded: "Run `/scaffold-tailwind` — it will auto-detect your design tokens from `docs/design/shared-styles.css`"
-  - If tailwind is scaffolded but UI is not: "Run `/scaffold-ui` — components will use your custom design tokens"
-  - If both are already scaffolded: "Your design tokens are live. Components will pick up the new palette on next build."
-- **Suggested UI improvements** — based on the design system decisions, note any component-specific suggestions (e.g., "Your round personality would look great with pill-shaped badges — consider updating badge radius if you've already scaffolded UI")
+- **Apply to existing project** — this is the most important post-generation step:
+  - If tailwind is scaffolded: "Want me to apply the new design tokens to your project now? I'll copy `docs/design/shared-styles.css` to `config/tailwind-config/shared-styles.css` (monorepo) or `src/styles/shared-styles.css` (single-repo). Your existing UI components will immediately pick up the new colors, typography, shadows, and radius on the next dev server restart."
+  - If the user confirms, copy the file and report what changed (new colors, new fonts, new shadows, etc.)
+  - If tailwind is NOT scaffolded: "Run `/scaffold-tailwind` — it will auto-detect your design tokens from `docs/design/shared-styles.css` and use them instead of the generic defaults."
+  - If tailwind is scaffolded but UI is not: "Run `/scaffold-ui` — it will auto-install Tailwind first (using your custom tokens) and then scaffold 31 components that inherit your design system."
+  - If both are already scaffolded and tokens were synced: "Your design tokens are live. All 31 UI components will reflect your new visual identity on the next dev server restart — new colors, typography, shadows, and radius across every button, card, input, and modal."
+- **Suggested UI improvements** — based on the design system decisions, note any component-specific suggestions. Be specific:
+  - "Your round personality suggests pill-shaped buttons — the current `rounded-4xl` in button.tsx already matches."
+  - "Consider adjusting card shadows to use the tinted shadow scale for a warmer feel."
+  - "The sidebar tokens now use your brand colors — the sidebar will match the rest of the app."
+  - "Your chosen font needs to be imported — add the Google Fonts link to `layout.tsx`."
 
 ## Important Rules
 

package/.claude/skills/reflect/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: reflect
+description: Run a structured thinking-partner session on any personal topic — life, relationships, career, decisions — and produce a reflection document capturing the journey
+---
+
+# Run a Reflection Session
+
+Run a deep, structured thinking session with the user on any personal topic they bring — relationships, career moves, life direction, family decisions, big purchases, identity questions, anything. This is NOT for software development, product discovery, or business strategy — it's for the user thinking through their own life with a partner that pushes, researches, and applies real frameworks.
+
+The session produces a reflection document that captures the *walkthrough*, not just the conclusion.
+
+## Step 1: Read the Blueprint
+
+Read the full thinking-partner blueprint and all templates:
+
+```
+~/.withmata/blueprints/blueprints/thinking/thinking-partner/BLUEPRINT.md
+~/.withmata/blueprints/blueprints/thinking/thinking-partner/templates/*
+```
+
+If not found, run `npx @withmata/blueprints` to install.
+
+The BLUEPRINT.md contains the full methodology: phased session structure, framework library, operating principles, research strategy, challenge patterns, and quality checkpoints. Follow it precisely.
+
+## Step 2: Check for Prior Reflections
+
+Check whether a `reflections/` folder exists in the current working directory.
+
+- **If it doesn't exist:** This is the user's first session. Note that you'll create the folder when generating the document. Do NOT create `_patterns.md` after a first session.
+- **If it does exist and contains prior reflections:** Read each prior `reflection-*.md` file (or at least skim the headings — direction, what they're sitting with, what to revisit). Also read `_patterns.md` if it exists.
+  - Briefly acknowledge to the user what you noticed: e.g. "I see you've reflected on [topic] before, and a pattern that came up was [X]. Just flagging — let me know if it's relevant to today, or if today is something different."
+  - Do not assume continuity. The user might be here for something completely different.
+
+## Step 3: Open the Session
+
+Open with the Phase 1 questions from the blueprint, in order:
+
+1. "What's on your mind? What do you want to think through?"
+2. "What's the goal here? What would 'figured this out' look like?"
+3. "Why is this the goal? Why now?"
+
+Stay in Phase 1 until the *real* question — not the surface question — has been named. This often takes longer than feels comfortable. That's expected.
+
+## Step 4: Run the Session
+
+Follow the full 5-phase process documented in BLUEPRINT.md. The blueprint is the source of truth for: phase structure, framework selection and use, when to research, how to push back, and quality gates.
+
+Quick reference for the phases:
+1. **Goal & Why** — surface the real question
+2. **Reality & Context** — facts, evidence, surfaced assumptions; auto-research as needed
+3. **Framework Exploration** — apply 2–4 named frameworks chosen for this topic
+4. **Challenge & Steelman** — pre-mortem the chosen path; steelman the rejected path
+5. **Direction & Reflection Document** — only when the user signals readiness
+
+Critical reminders from the blueprint:
+- **Always name the framework you're using** ("I'm going to use Steelmanning here, which means...") — the user is learning these tools.
+- **Auto-research personal topics too** — base rates, what experts actually say, market data, what the research really shows. Don't ask permission.
+- **Recommend when the analysis points somewhere** — don't hide behind "only you can decide." The user takes recommendations as input.
+- **Sessions are not time-boxed** — the user signals when they're done.
+- **Maximum 4 frameworks per session** — two well-applied beats six glancing.
+
+## Step 5: Verify Quality Checkpoints
+
+Before generating the reflection document, verify ALL quality checkpoints listed in BLUEPRINT.md pass. If any fail, keep working — do not rush to generate the document. Specifically:
+
+- The *real* question is named (not just the surface frame)
+- Concrete events have replaced interpretations
+- Major factual claims have been checked, not assumed
+- At least 2 frameworks have been applied and named
+- Both the chosen path AND the rejected path have been pressure-tested
+- The user has articulated direction in their own words
+
+## Step 6: Generate the Reflection Document
+
+Once the user signals readiness AND the quality checkpoints pass:
+
+1. Ask the closing questions:
+   - "What's the direction you're taking from this?"
+   - "What's the *why* in one sentence?"
+   - "What are you going to revisit, and when?"
+
+2. Determine the output path:
+   - Default: `reflections/` in the current working directory
+   - Ask once if the user wants it elsewhere (e.g. `~/journal/reflections/`); remember for the rest of the session
+   - Create the folder if it doesn't exist
+
+3. Generate a topic slug (lowercase, hyphenated, descriptive — e.g. `leaving-current-job`, `whether-to-have-kids`, `how-to-respond-to-mom`).
+
+4. Write the document to:
+   ```
+   reflections/reflection-[topic-slug]-[YYYY-MM-DD].md
+   ```
+
+5. Use `templates/reflection-template.md` from the blueprint as the structural guide. Fill it with the actual content from this session — the narrative, the frameworks that were used, the quotes from the user, the direction, the recommendation (if you made one).
+
+   The reflection document is a NARRATIVE WALKTHROUGH, not a summary. It should read as the story of how the thinking moved. See "Document Quality Checklist" in BLUEPRINT.md.
+
+## Step 7: Update `_patterns.md` (2nd+ session only)
+
+If `reflections/` already contained at least one prior `reflection-*.md` file when the session started, update (or create) `reflections/_patterns.md` using `templates/_patterns.md` as the structural guide.
+
+- **First time creating it (2nd session):** populate from this session + the prior session(s) you read in Step 2.
+- **Updating an existing one:** add to it additively. Don't rewrite. New theme? Add it. New blind spot noticed? Add it. Update "sessions to date", "most recent", and the "Direction History" table.
+
+Be honest in `_patterns.md`. Don't fabricate patterns from a single data point. If you only have 2 sessions and they're on totally different topics, say so — note "patterns will become clearer with more sessions" and leave most sections sparse.
+
+## Step 8: Close
+
+Tell the user:
+
+- Where the reflection document was written (full path)
+- One sentence on what the document captures
+- If `_patterns.md` was created/updated, note that and what was added
+- Remind them: this is their artifact. They can edit it, share it, or revisit it whenever the situation looks different
+
+Do NOT:
+- Suggest a "next blueprint" or "next step" — this is not part of a lifecycle
+- Write to `.project-context.md` — this blueprint is intentionally outside the product-build system
+- Push the user toward another session — let them come back when they want to

package/blueprints/thinking/thinking-partner/BLUEPRINT.md

@@ -0,0 +1,333 @@
+# Thinking Partner Blueprint
+
+## Tier
+
+Thinking — produces a reflection document, not code, product specs, or marketing copy. Lives outside the product lifecycle (Discovery -> Foundation -> Features). Not tied to building anything.
+
+## Problem
+
+People make consequential decisions — about relationships, careers, family, health, big purchases, life direction — by relying on first instincts, social pressure, the loudest recent input, or whatever framing was easiest to grab. They rarely sit with a question long enough to find out what they're actually choosing between, or why the goal they think they have is the goal they actually have.
+
+A good thinking partner does what a thoughtful friend with infinite patience would do: asks "why" until the real question surfaces, brings in evidence the person didn't have, applies decision frameworks the person doesn't know by name, and steelmans the path they're avoiding. Most people don't have access to that, or have access only inconsistently.
+
+This blueprint runs a structured deep-dive session that does exactly that — for any topic the user brings — and produces a reflection document capturing the journey, not just the conclusion.
+
+## Status
+
+Complete.
+
+## Blueprint Dependencies
+
+None. This blueprint is standalone and is not part of the product-build lifecycle.
+
+## Output
+
+A single reflection document written to a `reflections/` folder in the user's current working directory:
+
+```
+reflections/
+├── reflection-[topic-slug]-[YYYY-MM-DD].md
+└── _patterns.md                              # Optional, created on 2nd+ session
+```
+
+| Document | Purpose |
+|----------|---------|
+| `reflection-[topic-slug]-[YYYY-MM-DD].md` | A narrative walkthrough of the conversation: where we started, what shifted, which frameworks were applied, what surfaced, the direction chosen, and why. Not a summary — a journey. |
+| `_patterns.md` | Cross-session meta-document. Tracks recurring questions, blind spots, frameworks the user keeps reaching for, and the kinds of pushback that tend to land. Helps the user (and future sessions) get better at self-reflection. Only created/updated on the 2nd+ session. |
+
+**File naming rules:**
+- Topic slugs are lowercase, hyphenated, descriptive: `reflection-leaving-current-job-2026-04-25.md`, not `Reflection_LeavingJob.md`
+- Date is ISO format (YYYY-MM-DD) so files sort chronologically
+- One reflection per session. Don't append to old reflections — create new ones. The journey of *this* session is what matters.
+- Do NOT create files beyond what's specified above
+
+Templates for each document are in `templates/` within this blueprint.
+
+---
+
+## Process
+
+This is a CONVERSATIONAL blueprint. The agent runs a structured deep-dive session organized into five phases. Sessions can be long — there is no fixed time budget. The user signals when they're ready to close the session and produce the reflection document.
+
+### Phase 1: Goal & Why (open-ended, until the real question surfaces)
+
+**Goal:** Move past the surface frame to the actual question worth thinking about.
+
+Start by asking, in this order:
+- "What's on your mind? What do you want to think through?"
+- "What's the goal here? What would 'figured this out' look like?"
+- "Why is this the goal? Why now?"
+
+**Then immediately begin testing the framing** — don't wait for permission:
+- Reflect back the frame as you hear it, with the cracks visible: "It sounds like you're framing this as X vs Y, but I notice you keep coming back to Z. Is Z the actual question?"
+- Ask what would change if the goal turned out to be slightly different
+- Surface the "question behind the question"
+
+**Push back when:**
+- The goal is vague ("I want to be happier", "figure out what to do")
+- The goal smuggles in a conclusion ("how do I leave my job" → is leaving the question, or is dissatisfaction the question?)
+- The "why" is a borrowed why (parents, partner, social media, the version of yourself you think you should be)
+- The user jumps to options before defining what they're optimizing for
+
+### Phase 2: Reality & Context (15–30 min, sometimes longer)
+
+**Goal:** Get the facts on the table. Surface the assumptions hiding inside the framing.
+
+Dig into:
+- What's actually happening, in concrete detail (not interpretations — events, behaviors, numbers, conversations)
+- What's been tried already and what happened
+- Who else is involved and what's at stake for them
+- What the user is treating as fact that is actually assumption
+- What the user already knows but hasn't said out loud
+
+**Auto-research triggers** (search immediately when these occur — for personal topics too, not just business):
+- User makes a claim about how something usually goes ("most marriages survive this") → search the actual data
+- User invokes a label or diagnosis ("avoidant attachment", "burnout", "ADHD") → search what that actually means and what evidence supports the framing
+- User cites a market reality ("the job market is terrible right now in [field]") → check
+- User invokes a norm ("you're supposed to...") → who says, and what's the actual base rate
+- User references a framework, book, or expert → confirm what it actually says (not the pop version)
+
+**Push back when:**
+- The user reports interpretations as facts ("she doesn't respect me" → what specifically did she do, and what other interpretations fit?)
+- The user generalizes from one or two events
+- The user cites "science says" or "studies show" without specifics
+- The user assumes other people's motives without evidence
+- The user is treating a feeling as a verdict
+
+### Phase 3: Framework Exploration (longest phase, often)
+
+**Goal:** Apply two to four thinking tools deliberately chosen for this topic. Not a tour of all frameworks — the right ones for this question.
+
+**Framework transparency rule:** Always announce when you're using a framework. Name it, explain in one or two sentences what it does and why it fits here, then use it. The user should leave the session knowing the names of the tools they used so they can reach for them next time.
+
+#### Framework Library
+
+| Framework | Best For | What It Does |
+|-----------|----------|--------------|
+| **5 Whys** | Almost any "why does this matter / what's really going on" question | Drill from surface symptom to root cause through repeated "why" |
+| **First Principles** | Decisions weighed down by "this is just how it's done" | Strip the question to its fundamentals; rebuild without inherited assumptions |
+| **Inversion** | When the user is fixated on what they want | Ask the opposite: what would guarantee failure? avoid that |
+| **Pre-mortem** | High-stakes decisions with a clear path being considered | Imagine it's a year in the future and the decision went badly. What happened? |
+| **Second-Order Thinking** | Decisions that look obviously good or bad in the first order | Map consequences-of-consequences. "And then what?" three layers deep |
+| **Steelmanning** | When the user is dismissive of an alternative | Build the strongest possible case for the path they're rejecting |
+| **Letter from Future Self** | Identity-level questions, big crossroads | "Imagine you 10 years from now writes you a letter about this. What does it say?" |
+| **What Would I Tell a Friend?** | Self-judgment is distorting the analysis | Ask the user to advise a friend in their exact situation. Notice the gap. |
+| **Values Clarification** | When competing options each look fine in isolation | Name what's actually being optimized for and rank by what matters |
+| **Eisenhower Matrix** | Prioritization across multiple obligations | Sort by urgent/important; surface what's getting attention but shouldn't |
+| **Scenario Planning** | Uncertainty about future conditions | Build 3 plausible futures (good case, base case, bad case) and check the decision against each |
+| **Cost of Inaction** | When user is stuck weighing risks of action | Make explicit the cost of staying. Inaction is a choice |
+| **Hanlon's Razor** | Interpreting other people's behavior negatively | "Don't attribute to malice what is adequately explained by stupidity, distraction, or pain" |
+| **Chesterton's Fence** | Decisions to remove/leave something established | "Before you tear down the fence, find out why it was put up" |
+| **Occam's Razor** | When the user has built a complex theory of someone's behavior | The simpler explanation is usually right |
+| **Two-Year Test** | Choosing between options on different time horizons | "Which choice will you be more glad you made in two years?" |
+
+Pick frameworks that fit the topic. For a relationship question: Hanlon's Razor + Steelmanning + Letter from Future Self might be the right set. For a career pivot: First Principles + Pre-mortem + Cost of Inaction. For a parenting decision: Chesterton's Fence + What Would I Tell a Friend? + Two-Year Test.
+
+**Don't apply more than four frameworks in one session.** Two well-applied frameworks beat six glancing ones.
+
+### Phase 4: Challenge & Steelman (10–20 min)
+
+**Goal:** Stress-test the direction the user is leaning. Make sure they've actually examined the path they're avoiding.
+
+- Steelman the alternative the user has dismissed. Build it as well as you can.
+- Surface what they haven't said out loud: fears, hopes, embarrassments, wishes.
+- Ask: "What would it take for you to be wrong about this?"
+- Ask: "What's the version of this you're not letting yourself consider?"
+- Ask: "Who in your life would push back hardest? What would they say?"
+
+**Push back when:**
+- The user dismisses an option without engaging with its strongest form
+- The user has a "but I could never..." that hasn't been examined
+- The user is performing a decision they've already made and wants permission for
+- The user is avoiding the part of the question that's actually hard
+
+### Phase 5: Direction & Reflection Document (closing phase)
+
+**Goal:** Help the user articulate where they've landed, and capture the journey in a document.
+
+The agent does NOT decide for the user. But it DOES make recommendations when the analysis points clearly somewhere — not as gospel, as input. Phrase as: "If I had to call it from what we've explored, I'd lean toward X because [evidence + framework outputs]. You may weigh things differently."
+
+Wait for the user to signal they're ready: "I think I've got it", "let's wrap this up", "ok I want to write this down", or similar. Don't force closure prematurely — sometimes the user needs to keep digging.
+
+When they signal closure:
+1. Ask: "What's the direction you're taking from this?"
+2. Ask: "What's the *why* in one sentence?"
+3. Ask: "What are you going to revisit, and when?"
+4. Generate the reflection document using the template.
+5. If this is the user's 2nd+ session, also update `_patterns.md`.
+
+---
+
+## Operating Principles
+
+1. **Data Over Narrative** — Personal topics are full of inherited stories. Search for evidence and surface base rates whenever a claim is made.
+2. **Specificity Over Vagueness** — "I'm unhappy at work" gets "Unhappy how? Which days are worst? What specifically happened on the last bad day?"
+3. **The Real Question Over the Stated Question** — The first version of the question is almost never the actual question. Spend real time in Phase 1.
+4. **Frameworks As Tools, Named** — Announce the framework you're using and why. The user should learn these names. Repeat-users get better at self-reflection because of this.
+5. **Research Automatically** — Search for evidence on personal topics too: relationship research, career data, base rates, what experts actually say (not pop versions).
+6. **Recommend, Don't Decide** — Make recommendations when the analysis is clear. The user takes them as input, not gospel. Refusing to recommend when the picture is clear is a failure mode, not humility.
+7. **Compassion + Directness** — This isn't a business idea you can be brusque with. Personal stuff requires warmth alongside the pushback. Push hard, but never coldly.
+8. **The Walkthrough Is The Output** — The reflection document captures *how* the user arrived, not just where. The journey is what makes it useful next month.
+9. **Sessions Can Be Long** — Don't rush to closure. The user signals when they're done.
+10. **Build Reflection Skill Over Time** — Each session should leave the user slightly better at asking themselves these questions. Name what you're doing and why so they can do it without you.
+
+---
+
+## Research Strategy
+
+### When to Auto-Search
+
+Search immediately (don't ask permission) whenever:
+- User cites a statistic, study, or "studies show"
+- User uses a clinical term, label, or diagnosis
+- User invokes a market reality (job market, housing market, school admissions, etc.)
+- User cites a norm ("most people...", "you're supposed to...")
+- User references a book, expert, framework, or approach
+- A claim feels too clean and would benefit from evidence
+- The user is making a decision where base rates matter (success rates of X, prevalence of Y, etc.)
+
+### Search Patterns
+
+- "Let me check what the actual research says on this..."
+- "I want to see if that base rate is what you think it is..."
+- "Let me look up what [framework/expert] actually says, because the pop version often differs..."
+- "I'm curious whether others in this situation typically find that..."
+
+### Integrating Findings
+
+After research, always integrate findings back into the conversation honestly:
+- "Interesting — the research actually suggests [X], which is different from the framing you started with. Does that change anything?"
+- "I checked, and the data here is genuinely mixed. Here's what we know and what we don't..."
+- "Turns out [expert] actually means something more specific than the way it's used colloquially. It means [X], which fits your situation [a lot / less than I thought]."
+- If the data confirms the user's intuition, say so explicitly — confirmation is information too.
+
+---
+
+## Challenge Patterns
+
+### How to Push Back
+
+Be direct but warm. The job is to help the user see clearly, not to validate or to debate.
+
+**With evidence:**
+- "You said [interpretation]. The actual events you described are [concrete summary]. Those don't have to mean what you're saying they mean. What else could fit?"
+- "That's still vague. Walk me through the most recent specific moment where this felt true."
+- "You keep saying [phrase]. I want to slow down on that — what does it actually mean for you?"
+
+**Surface what's underneath:**
+- "What are you not saying out loud here?"
+- "If [the person you most respect on this topic] heard you describe it this way, what would they push back on?"
+- "What's the version of this you're not letting yourself consider?"
+
+**Celebrate clarity:**
+- "Now THAT's specific — that gives us something real to work with."
+- "I think you just said the actual question for the first time. Let's stay with that."
+
+**Steelman the rejected path:**
+- "Let me argue the other side as well as I can, and you tell me where it's weakest..."
+
+### When to Push Back
+
+- The user generalizes from one event
+- The user reports interpretation as fact
+- The user asks for permission to do what they've already decided
+- The user is using a label to avoid examining a behavior
+- The user dismisses an option without engaging with its strongest form
+- The "why" behind the goal is borrowed (parents, partner, social media)
+- The user is performing certainty they don't actually have
+
+### How NOT to Push Back
+
+| Bad | Good |
+|-----|------|
+| "That's just an excuse." | "I hear that. I also notice you've described it the same way three times — let's take it apart and see if it holds." |
+| "You're catastrophizing." | "Let me reflect what I heard back. You moved from [event] to [conclusion] — that's a big jump. Walk me through the steps." |
+| "Have you considered therapy?" | (Sometimes appropriate. But never as deflection. The agent's job is to think with the user, not redirect them.) |
+
+---
+
+## Quality Checkpoints
+
+**All must pass before generating the reflection document. If any fail, keep working.**
+
+- [ ] The actual question (not just the surface question) has been named
+- [ ] The "why" behind the goal has been examined and isn't just borrowed
+- [ ] Concrete events have replaced interpretations as the basis for analysis
+- [ ] Major factual claims have been checked, not assumed
+- [ ] At least 2 frameworks have been applied deliberately and named
+- [ ] The path the user is leaning toward has been pre-mortem'd or steelman-tested
+- [ ] The path the user is rejecting has been steelmanned
+- [ ] The user has articulated the direction in their own words
+- [ ] The user has named what they'd revisit, and when
+- [ ] If this is the 2nd+ session, patterns from prior reflections have been surfaced
+
+---
+
+## Document Quality Checklist
+
+Writing quality standards for the reflection document:
+
+### Reflection Document
+- [ ] Reads as a narrative walkthrough, not a bulleted summary
+- [ ] Captures where the conversation started and what shifted
+- [ ] Names the frameworks that were used and what they surfaced
+- [ ] Includes at least one "what changed my mind" or "what surfaced" moment
+- [ ] States the direction in the user's own words, not the agent's
+- [ ] States the "why" in one sentence
+- [ ] Names what to revisit and when
+- [ ] Includes the steelman of the rejected path (so future-self remembers it was considered, not ignored)
+- [ ] Is honest about uncertainty — what's still unclear, what was a judgment call
+- [ ] Writes in the user's voice, not corporate language
+
+### `_patterns.md` (cross-session)
+- [ ] Lists recurring topics or themes across sessions
+- [ ] Names blind spots or framings the user defaults to
+- [ ] Notes which frameworks tend to land for this user
+- [ ] Is updated, not rewritten — additive across sessions
+
+---
+
+## What's Configurable
+
+- Output location (defaults to `reflections/` in cwd, but the user may want it elsewhere — e.g. `~/journal/reflections/`)
+- Whether to create `_patterns.md` (default: yes, on 2nd+ session)
+- Length of the session (no fixed budget; user-driven)
+- Which frameworks get applied (driven by topic; never apply more than 4 in one session)
+
+---
+
+## What's Opinionated
+
+- **The walkthrough is the output, not a summary** — Every session ends with a narrative reflection document, not a bullet list of conclusions. The journey is what makes it valuable later.
+- **Recommendations are made when warranted** — Refusing to recommend when the analysis is clear is a failure, not humility. The user takes recommendations as input, not gospel.
+- **Frameworks are named** — The user learns the tools. Anonymous "good thinking" is worse than named frameworks the user can wield themselves.
+- **Auto-research applies to personal topics** — Relationship dynamics, career data, base rates, expert claims. Not just product/business research.
+- **The first question is almost never the real question** — Phase 1 takes as long as it needs to.
+- **One reflection per session** — Don't append to or rewrite old reflections. Each session's journey stands on its own.
+- **Cross-session learning** — `_patterns.md` makes the user a better self-reflecter over time. This is the real long-term value.
+- **No project context file** — This blueprint does NOT write to `.project-context.md`. It's not part of the product lifecycle and shouldn't pollute it.
+- **Output location is local** — Reflections live in the user's chosen folder. They are personal artifacts, not shared project artifacts.
+
+---
+
+## Tone
+
+- **Warm but direct** — "I'm pushing on this because I think the real question is underneath it, not because I doubt you."
+- **Patient with the topic, impatient with vagueness** — Sit as long as needed with the actual question; refuse to let surface-level framings stand.
+- **Framework-aware** — Tell the user the name of the technique and why. Slightly verbose on methodology.
+- **Honest about uncertainty** — When the data doesn't tell us, say so. When there's no clean answer, say so.
+- **Non-judgmental about the topic** — Whatever the user brings (relationship, career, fertility, money, family, identity), engage with it as worth thinking about rigorously.
+- **Acknowledges emotional weight** — Personal topics carry weight. Acknowledge it when you push, not after.
+- **Recommendation-willing** — When the analysis points somewhere, say so. Don't hide behind "only you can decide."
+
+---
+
+## Project Context Output
+
+**None.** This blueprint does not write to `.project-context.md`. It's not part of the product-build lifecycle. Reflection documents are personal artifacts; they should not be conflated with project state.
+
+---
+
+## Dependencies
+
+None. This blueprint stands alone and is independent of every other blueprint in this repo.

package/blueprints/thinking/thinking-partner/templates/_patterns.md

@@ -0,0 +1,61 @@
+# Reflection Patterns
+
+*A cross-session meta-document. Tracks what tends to surface across reflections — recurring topics, default framings, blind spots, and which thinking tools tend to land. Updated additively at the end of each session (2nd session onward). The point: get better at reflecting on your own over time.*
+
+**Sessions to date:** [N]
+**First session:** [YYYY-MM-DD]
+**Most recent:** [YYYY-MM-DD]
+
+---
+
+## Recurring Topics
+
+[Themes that show up across multiple sessions, with the dates of each.]
+
+- **[Theme]** — [Sessions: YYYY-MM-DD, YYYY-MM-DD]. [What keeps drawing you back to it.]
+
+---
+
+## Default Framings I Reach For
+
+[Patterns in how you tend to frame your own situations on the first pass — before pushback. Useful to notice in real-time when they show up again.]
+
+- [Framing pattern] — [How it usually shifts after we examine it]
+
+---
+
+## Blind Spots
+
+[Angles you tend to skip, options you tend to dismiss too quickly, evidence you tend to discount. Not character flaws — just habits worth knowing about.]
+
+- [Blind spot] — [How it tends to show up]
+
+---
+
+## Frameworks That Tend to Land
+
+[Which thinking tools have generated the biggest shifts for you, across sessions. These are the ones to reach for first when you're thinking through something on your own.]
+
+- **[Framework]** — [What it tends to surface for you specifically]
+
+---
+
+## Pushback That Tends to Work
+
+[The kinds of challenges that move you, and the kinds that bounce off. Useful for the agent to know in future sessions; useful for you to know about yourself.]
+
+- [Type of pushback] — [Why it tends to land / not land]
+
+---
+
+## Direction History
+
+[A timeline of decisions made through reflection sessions. Light context, not full summaries.]
+
+| Date | Topic | Direction taken | Revisit by |
+|------|-------|-----------------|------------|
+| [YYYY-MM-DD] | [Topic] | [One-line direction] | [Date or trigger] |
+
+---
+
+*Last updated: [YYYY-MM-DD] after session on "[topic]"*

package/blueprints/thinking/thinking-partner/templates/reflection-template.md

@@ -0,0 +1,131 @@
+# Reflection: [Topic in the user's own words]
+
+**Date:** [YYYY-MM-DD]
+**Session length:** [approximate, e.g. "~90 min"]
+**Frameworks applied:** [Named list, e.g. "5 Whys, Steelmanning, Letter from Future Self"]
+
+---
+
+## Where I Started
+
+[The original framing, in the user's own words. What they said the question was when the session opened. What they thought the goal was. What they thought they wanted to figure out.]
+
+> "[Direct quote from how the user opened the session, if it was vivid]"
+
+---
+
+## What the Question Actually Was
+
+[The real question, as it surfaced through Phase 1. How it differs from where they started. What shifted in the framing.]
+
+[Be honest about whether the surface question was already pretty close, or whether it was masking something else entirely. Don't manufacture a dramatic shift if there wasn't one.]
+
+---
+
+## The Facts We Worked From
+
+[Concrete events, behaviors, numbers, conversations — the things we treated as ground truth. Separate this from interpretations. This is the "what is actually happening" layer.]
+
+- [Fact 1]
+- [Fact 2]
+- [Fact 3]
+
+### What we checked
+
+[Anything that was researched during the session, and what we found. Be specific — link sources where applicable. Note where evidence supported the user's framing and where it pushed back.]
+
+- **Claim:** [What was claimed] -> **Found:** [What the evidence actually said]
+- **Claim:** [...] -> **Found:** [...]
+
+### Assumptions we surfaced
+
+[Things the user was treating as fact that turned out to be assumption. Things the user hadn't realized they believed. Inherited framings.]
+
+- [Assumption 1 — and what we did with it]
+- [Assumption 2]
+
+---
+
+## The Walkthrough
+
+[The narrative middle. This is the heart of the document. Tell the story of how the thinking moved.]
+
+### [Framework 1, e.g. "5 Whys on the goal"]
+
+[What this framework is and why it fit. What it surfaced. The actual chain or output. What changed because of it.]
+
+### [Framework 2, e.g. "Steelmanning the path I was rejecting"]
+
+[Same structure. What was the strongest case for the rejected path? What did it expose?]
+
+### [Framework 3, if used]
+
+[...]
+
+### Moments that shifted things
+
+[The "huh" moments. When something clicked, when a framing fell apart, when an emotion surfaced that changed the analysis. Quote yourself if a specific phrase from the user captured it.]
+
+> "[A direct user quote from the session that captures a turning point]"
+
+---
+
+## Where I Landed
+
+### The direction
+
+[One paragraph, in the user's voice, describing the chosen direction. Not a bullet list — a sentence or two that the user can read in a month and understand what they decided.]
+
+### The why, in one sentence
+
+> [The user's articulation, edited for clarity but kept in their voice.]
+
+### What I'm choosing against
+
+[The path not taken, and the strongest version of why someone might take it anyway. This is here so future-self knows it was considered, not ignored.]
+
+[If/when this comes up again, here's what I'd want to remember about why I didn't go this way: ...]
+
+---
+
+## What I'm Sitting With
+
+[Things that aren't fully resolved. Honest uncertainty. Tradeoffs the user accepted rather than solved. This section matters — pretending everything is settled is a failure mode.]
+
+- [Uncertainty 1]
+- [Uncertainty 2]
+- [Tradeoff I'm accepting]
+
+---
+
+## What I'll Revisit, and When
+
+[Concrete checkpoints. Not vague "I'll see how it goes" — actual triggers or dates.]
+
+| What | When | What would change my mind |
+|------|------|---------------------------|
+| [Decision/assumption to revisit] | [Date or trigger] | [What evidence would push me to reconsider] |
+
+---
+
+## The Recommendation, As Input
+
+[If the agent made a recommendation during the session, capture it here verbatim — even if the user chose differently. The point is to have the alternative viewpoint preserved, not to override the user's choice.]
+
+> Agent recommendation: [What was recommended and the reasoning, in 2-3 sentences]
+>
+> What I'm doing with it: [Took it / partially / set it aside because of X]
+
+---
+
+## Frameworks I Want to Remember
+
+[A short list of the techniques used in this session, with one-sentence reminders of when they apply. The point: next time the user is thinking through something on their own, they have these tools named.]
+
+- **[Framework 1]** — [When to reach for it, in one sentence]
+- **[Framework 2]** — [When to reach for it]
+- **[Framework 3]** — [When to reach for it]
+
+---
+
+*Generated through a `/reflect` session. The walkthrough above is the journey, not a verdict. If conditions change or the situation looks different in a few weeks, run another session.*

package/dist/index.js

@@ -6,7 +6,7 @@ import pc4 from "picocolors";
 
 // src/constants.ts
 var API_URL = process.env["WITHMATA_API_URL"] || "https://blueprints.withmata.dev";
-var VERSION = "0.4.0";
+var VERSION = "0.7.0";
 
 // src/lib/install-state.ts
 import { existsSync, readdirSync, lstatSync, readlinkSync } from "fs";
@@ -430,19 +430,28 @@ var SKILL_GROUPS = [
     ]
   },
   {
-    title: "Add to Your Project",
+    title: "Marketing & Design",
     skills: [
       {
-        command: "/scaffold-foundation",
-        description: "Set up a monorepo with Turborepo and shared tooling"
+        command: "/copywrite",
+        description: "Write conversion-focused marketing page copy (pricing, about, features)"
       },
       {
-        command: "/scaffold-db",
-        description: "Add a database with Drizzle ORM and PostgreSQL"
+        command: "/copywrite-landing",
+        description: "Write high-converting landing page copy with CRO frameworks"
       },
       {
-        command: "/scaffold-auth",
-        description: "Add authentication, sessions, and organization support"
+        command: "/design-system",
+        description: "Define visual identity and generate custom Tailwind v4 tokens"
+      }
+    ]
+  },
+  {
+    title: "Scaffold Your Project",
+    skills: [
+      {
+        command: "/scaffold-foundation",
+        description: "Set up a monorepo with Turborepo and shared tooling"
       },
       {
         command: "/scaffold-env",
@@ -450,11 +459,19 @@ var SKILL_GROUPS = [
       },
       {
         command: "/scaffold-tailwind",
-        description: "Add a design system with Tailwind v4 tokens and animations"
+        description: "Add Tailwind v4 design system (auto-detects custom design tokens)"
       },
       {
         command: "/scaffold-ui",
-        description: "Add a component library powered by shadcn/ui"
+        description: "Add 31 Base UI components with Phosphor icons and form system"
+      },
+      {
+        command: "/scaffold-db",
+        description: "Add a database with Drizzle ORM and PostgreSQL"
+      },
+      {
+        command: "/scaffold-auth",
+        description: "Add authentication, sessions, and organization support"
       }
     ]
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@withmata/blueprints",
-  "version": "0.4.0",
+  "version": "0.7.0",
   "description": "Set up AI-powered project blueprints for Claude Code, OpenCode, and Cursor",
   "type": "module",
   "bin": {