@runecraft/grimoire 1.0.0

package/skills/git-worktree/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: git-worktree
+description: >
+  Use git worktrees for parallel feature branches without stashing or cloning.
+  Creates isolated working directories from a single local clone.
+  EN triggers: /worktree, git worktree, parallel branches, multiple features, isolate work.
+  PT triggers: /worktree, branches paralelas, trabalho isolado, múltiplas features.
+  Do NOT use for: simple single-branch work, fixing merge conflicts, or repos where disk space is extremely constrained.
+license: CC-BY-4.0
+---
+
+# git-worktree
+
+Use git worktrees to work on multiple branches simultaneously from a single local clone — no stashing, no cloning, no context-switching friction. Each worktree is an independent working directory on its own branch, sharing the same `.git` repository.
+
+```
+DECIDE BRANCH → ADD WORKTREE → WORK INDEPENDENTLY → MERGE → CLEAN UP
+```
+
+---
+
+## Overview
+
+A git worktree is an additional working directory attached to the same local repository. Instead of cloning the repo again or stashing unfinished work to switch branches, you create a worktree — a separate directory that checks out a different branch — and work there independently.
+
+Each worktree shares the same object database (`.git`), so commits made in one worktree are immediately visible to all others. There is no duplication of git history, only a sparse checkout of the working tree for each branch.
+
+**Benefits:**
+- No stashing — keep your current branch exactly as-is while starting something else
+- No re-cloning — disk cost per worktree is only the checked-out files, not the full history
+- True parallelism — run tests, builds, and edits in different branches side by side
+- Hotfix safety — ship a critical fix from a clean `main` checkout while your feature branch sits untouched
+
+---
+
+## When to Use
+
+| Scenario | Why worktrees help |
+|----------|-------------------|
+| Parallel epics or features | Each epic gets its own directory; no branch-switching or stashing |
+| Hotfix while on a feature branch | Checkout `main` in a new worktree, fix, push, and return to your feature — nothing stashed |
+| Reviewing or testing another branch | Checkout a PR branch in a worktree, build and test without touching your current work |
+| CI isolation | Run a long build or test suite in one worktree while continuing development in another |
+| Comparing branches | Have two branches checked out side by side for diffing or manual verification |
+
+**Do not use when:**
+- You're working on a single branch — standard git workflow is simpler
+- You need to fix merge conflicts — worktrees don't help with conflict resolution
+- Disk space is extremely constrained — each worktree costs the checkout size of that branch
+
+---
+
+## Process
+
+### Step 1: Create a Worktree
+
+From your main repository directory, use `git worktree add`:
+
+```bash
+# Create a worktree from the current HEAD (starts on same commit)
+git worktree add ../path-to-worktree
+
+# Create a worktree on an existing branch
+git worktree add ../path-to-worktree existing-branch
+
+# Create a worktree with a new branch
+git worktree add -b new-branch-name ../path-to-worktree base-branch
+```
+
+**Convention:** Place worktrees as siblings to your main repo directory (e.g., `../project-hotfix`, `../project-epic-2`). Avoid nesting worktrees inside other worktrees.
+
+### Step 2: List Worktrees
+
+```bash
+git worktree list
+```
+
+Output shows the path, HEAD commit, and branch for every worktree. The main worktree is marked with `[main]` or `[bare]`.
+
+### Step 3: Work Independently
+
+Navigate to the new directory and work as usual:
+
+```bash
+cd ../path-to-worktree
+# Edit, stage, commit, push — all commands work the same
+git add .
+git commit -m "feat(epic-2): start new feature"
+git push origin new-branch-name
+```
+
+The main worktree is unaffected. You can run builds, tests, or linters in each worktree independently.
+
+### Step 4: Clean Up
+
+When the branch is merged or no longer needed:
+
+```bash
+# Remove the worktree and its directory
+git worktree remove ../path-to-worktree
+
+# Prune stale worktree references (if a worktree directory was deleted manually)
+git worktree prune
+```
+
+`git worktree remove` fails if the branch has unmerged changes — this is a safety check. Force with `--force` only if you're certain.
+
+---
+
+## Safety Rules
+
+- **Never nest worktrees.** A worktree must not be created inside another worktree's directory. Nesting corrupts the relationship between `.git` files.
+- **One worktree per branch.** Git refuses to check out the same branch in two worktrees simultaneously. If you need a second checkout of the same branch, create a new branch from it.
+- **Shared `.git` means shared state.** Commits, fetches, and branch updates in one worktree are visible in all others. If you delete a branch in worktree A, it's gone everywhere.
+- **Clean up stale worktrees.** If you delete a worktree directory manually (without `git worktree remove`), run `git worktree prune` to remove the stale reference.
+- **Prune periodically.** After merging branches, run `git worktree prune` to keep the worktree list clean.
+- **Bare repositories.** Worktrees also work from bare repos, but the commands differ. This skill focuses on standard (non-bare) use.
+
+---
+
+## Common Patterns
+
+### Parallel Epics
+
+Start multiple epics from `main`, each in its own directory:
+
+```bash
+git worktree add -b epic-payments ../epic-payments main
+git worktree add -b epic-notifications ../epic-notifications main
+git worktree add -b epic-search ../epic-search main
+```
+
+Work on each independently. When one is ready, push and open a PR. The others continue unaffected.
+
+### Hotfix from Main
+
+You're deep in a feature branch with uncommitted changes. A critical bug needs an immediate fix on `main`:
+
+```bash
+# Create hotfix worktree from main — your feature branch stays untouched
+git worktree add -b hotfix/critical-bug ../hotfix main
+
+# Navigate, fix, commit, push
+cd ../hotfix
+# ... make the fix ...
+git add .
+git commit -m "fix(billing): prevent double charge on retry"
+git push origin hotfix/critical-bug
+
+# Return to your feature — nothing was stashed, nothing was interrupted
+cd ../project
+```
+
+### Review a PR Locally
+
+Checkout and test a PR branch without disrupting your work:
+
+```bash
+git worktree add ../review-pr-billing main
+cd ../review-pr-billing
+git fetch origin pull/42/head:pr-42
+git checkout pr-42
+# Build, test, review — your main working directory is untouched
+```
+
+### CI / Long-Running Tasks
+
+Run a full test suite or build in an isolated worktree while you keep coding:
+
+```bash
+git worktree add ../ci-build main
+cd ../ci-build
+bun test  # runs while you continue editing in the main directory
+```
+
+---
+
+## Merge Strategy
+
+After worktrees finish their work:
+
+1. **Merge in dependency order.** If epic-1 depends on epic-2, merge epic-2 first.
+2. **Resolve conflicts in the main worktree.** Conflicts must be resolved before the branch can be merged. Standard merging applies — worktrees don't change this.
+3. **Push and open PRs** from each worktree as usual.
+4. **Clean up** after merge:
+
+```bash
+# After the branch is merged on the remote
+git branch -d branch-name       # delete local branch (from any worktree)
+git worktree remove ../path     # remove the worktree directory
+```
+
+5. **Prune periodically** to remove stale worktree references:
+
+```bash
+git worktree prune
+```
+
+---
+
+## Verification
+
+After setting up a worktree:
+
+- [ ] `git worktree list` shows the new worktree with the correct branch and path
+- [ ] Navigating to the worktree directory shows the expected branch's files
+- [ ] `cd` into the worktree and run `git status` — clean state on the target branch
+- [ ] Commits made in the worktree appear in `git log` from the main directory
+- [ ] The main worktree is unaffected — your original work is exactly as you left it
+- [ ] After merging, the branch is deleted and `git worktree remove` cleans up the directory
+- [ ] `git worktree prune` confirms no stale references remain
+
+---
+
+## See Also
+
+- [Git Worktree Documentation](https://git-scm.com/docs/git-worktree)
+- [Git Worktree Tutorial (Atlassian)](https://www.atlassian.com/git/tutorials/git-worktree)
+- `git-worktree` man page: `man git-worktree` or `git worktree --help`
+- For learning patterns from your project's git history, see the `git-commit-learning` spell

package/skills/idea-refine/README.md

@@ -0,0 +1,13 @@
+# idea-refine
+
+Refine raw ideas through structured divergent and convergent thinking.
+
+| Field | Value |
+|-------|-------|
+| Version | 1.0.0 |
+| Trigger | `/ideate`, "refine this idea", "stress-test my plan" |
+| PT trigger | "refinar ideia", "expandir opções", "validar premissas" |
+
+**Do not use for** vague ideas that need `/interview-me` first to extract intent, or for requirements already sharp enough for `/spec-driven`.
+
+See [SKILL.md](SKILL.md) for the full process.

package/skills/idea-refine/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: idea-refine
+description: >
+  Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking.
+  Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan,
+  or when you want to expand options before converging on one.
+  EN triggers: /ideate, "refine this idea", "stress-test my plan", brainstorm, expand options.
+  PT triggers: refinar ideia, expandir opções, brainstorm, validar premissas.
+  Do NOT use for: vague ideas that need /interview-me first to extract intent, or for
+  requirements that are already sharp enough for /spec-driven.
+license: CC-BY-4.0
+---
+
+# Idea Refine
+
+Refines raw ideas into sharp, actionable concepts worth building through structured divergent and convergent thinking.
+
+## How It Works
+
+1.  **Understand & Expand (Divergent):** Restate the idea, ask sharpening questions, and generate variations.
+2.  **Evaluate & Converge:** Cluster ideas, stress-test them, and surface hidden assumptions.
+3.  **Sharpen & Ship:** Produce a concrete markdown one-pager moving work forward.
+
+## Usage
+
+This skill is primarily an interactive dialogue. Invoke it with an idea, and the agent will guide you through the process.
+
+```bash
+# Optional: Initialize the ideas directory
+bash skills/idea-refine/scripts/idea-refine.sh
+```
+
+**Trigger Phrases:**
+- "Help me refine this idea"
+- "Ideate on [concept]"
+- "Stress-test my plan"
+
+## Output
+
+The final output is a markdown one-pager saved to `docs/ideas/[idea-name].md` (after user confirmation), containing:
+- Problem Statement
+- Recommended Direction
+- Key Assumptions
+- MVP Scope
+- Not Doing list
+
+## Detailed Instructions
+
+You are an ideation partner. Your job is to help refine raw ideas into sharp, actionable concepts worth building.
+
+### Philosophy
+
+- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.
+- Start with the user experience, work backwards to technology.
+- Say no to 1,000 things. Focus beats breadth.
+- Challenge every assumption. "How it's usually done" is not a reason.
+- Show people the future — don't just give them better horses.
+- The parts you can't see should be as beautiful as the parts you can.
+
+### Process
+
+When the user invokes this skill with an idea (`$ARGUMENTS`), guide them through three phases. Adapt your approach based on what they say — this is a conversation, not a template.
+
+#### Phase 1: Understand & Expand (Divergent)
+
+**Goal:** Take the raw idea and open it up.
+
+1. **Restate the idea** as a crisp "How Might We" problem statement. This forces clarity on what's actually being solved.
+
+2. **Ask 3-5 sharpening questions** — no more. Focus on:
+   - Who is this for, specifically?
+   - What does success look like?
+   - What are the real constraints (time, tech, resources)?
+   - What's been tried before?
+   - Why now?
+
+   Use the `AskUserQuestion` tool to gather this input. Do NOT proceed until you understand who this is for and what success looks like.
+
+3. **Generate 5-8 idea variations** using these lenses:
+   - **Inversion:** "What if we did the opposite?"
+   - **Constraint removal:** "What if budget/time/tech weren't factors?"
+   - **Audience shift:** "What if this were for [different user]?"
+   - **Combination:** "What if we merged this with [adjacent idea]?"
+   - **Simplification:** "What's the version that's 10x simpler?"
+   - **10x version:** "What would this look like at massive scale?"
+   - **Expert lens:** "What would [domain] experts find obvious that outsiders wouldn't?"
+
+   Push beyond what the user initially asked for. Create products people don't know they need yet.
+
+**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for relevant context — existing architecture, patterns, constraints, prior art. Ground your variations in what actually exists. Reference specific files and patterns when relevant.
+
+Read `frameworks.md` in this skill directory for additional ideation frameworks you can draw from. Use them selectively — pick the lens that fits the idea, don't run every framework mechanically.
+
+#### Phase 2: Evaluate & Converge
+
+After the user reacts to Phase 1 (indicates which ideas resonate, pushes back, adds context), shift to convergent mode:
+
+1. **Cluster** the ideas that resonated into 2-3 distinct directions. Each direction should feel meaningfully different, not just variations on a theme.
+
+2. **Stress-test** each direction against three criteria:
+   - **User value:** Who benefits and how much? Is this a painkiller or a vitamin?
+   - **Feasibility:** What's the technical and resource cost? What's the hardest part?
+   - **Differentiation:** What makes this genuinely different? Would someone switch from their current solution?
+
+   Read `refinement-criteria.md` in this skill directory for the full evaluation rubric.
+
+3. **Surface hidden assumptions.** For each direction, explicitly name:
+   - What you're betting is true (but haven't validated)
+   - What could kill this idea
+   - What you're choosing to ignore (and why that's okay for now)
+
+   This is where most ideation fails. Don't skip it.
+
+**Be honest, not supportive.** If an idea is weak, say so with kindness. A good ideation partner is not a yes-machine. Push back on complexity, question real value, and point out when the emperor has no clothes.
+
+#### Phase 3: Sharpen & Ship
+
+Produce a concrete artifact — a markdown one-pager that moves work forward:
+
+```markdown
+# [Idea Name]
+
+## Problem Statement
+[One-sentence "How Might We" framing]
+
+## Recommended Direction
+[The chosen direction and why — 2-3 paragraphs max]
+
+## Key Assumptions to Validate
+- [ ] [Assumption 1 — how to test it]
+- [ ] [Assumption 2 — how to test it]
+- [ ] [Assumption 3 — how to test it]
+
+## MVP Scope
+[The minimum version that tests the core assumption. What's in, what's out.]
+
+## Not Doing (and Why)
+- [Thing 1] — [reason]
+- [Thing 2] — [reason]
+- [Thing 3] — [reason]
+
+## Open Questions
+- [Question that needs answering before building]
+```
+
+**The "Not Doing" list is arguably the most valuable part.** Focus is about saying no to good ideas. Make the trade-offs explicit.
+
+Ask the user if they'd like to save this to `docs/ideas/[idea-name].md` (or a location of their choosing). Only save if they confirm.
+
+### Anti-patterns to Avoid
+
+- **Don't generate 20+ ideas.** Quality over quantity. 5-8 well-considered variations beat 20 shallow ones.
+- **Don't be a yes-machine.** Push back on weak ideas with specificity and kindness.
+- **Don't skip "who is this for."** Every good idea starts with a person and their problem.
+- **Don't produce a plan without surfacing assumptions.** Untested assumptions are the #1 killer of good ideas.
+- **Don't over-engineer the process.** Three phases, each doing one thing well. Resist adding steps.
+- **Don't just list ideas — tell a story.** Each variation should have a reason it exists, not just be a bullet point.
+- **Don't ignore the codebase.** If you're in a project, the existing architecture is a constraint and an opportunity. Use it.
+
+### Tone
+
+Direct, thoughtful, slightly provocative. You're a sharp thinking partner, not a facilitator reading from a script. Channel the energy of "that's interesting, but what if..." -- always pushing one step further without being exhausting.
+
+Read `examples.md` in this skill directory for examples of what great ideation sessions look like.
+
+## Red Flags
+
+- Generating 20+ shallow variations instead of 5-8 considered ones
+- Skipping the "who is this for" question
+- No assumptions surfaced before committing to a direction
+- Yes-machining weak ideas instead of pushing back with specificity
+- Producing a plan without a "Not Doing" list
+- Ignoring existing codebase constraints when ideating inside a project
+- Jumping straight to Phase 3 output without running Phases 1 and 2
+
+## Verification
+
+After completing an ideation session:
+
+- [ ] A clear "How Might We" problem statement exists
+- [ ] The target user and success criteria are defined
+- [ ] Multiple directions were explored, not just the first idea
+- [ ] Hidden assumptions are explicitly listed with validation strategies
+- [ ] A "Not Doing" list makes trade-offs explicit
+- [ ] The output is a concrete artifact (markdown one-pager), not just conversation
+- [ ] The user confirmed the final direction before any implementation work

package/skills/interview-me/README.md

@@ -0,0 +1,13 @@
+# interview-me
+
+One-question-at-a-time interview until ~95% confidence about the user's underlying intent.
+
+| Field | Value |
+|-------|-------|
+| Version | 1.0.0 |
+| Trigger | `/interview`, "interview me", "grill me", "are we sure?" |
+| PT trigger | `/entrevista`, "me entrevista", "tenho certeza?" |
+
+**Do not use for** well-specified asks (route to `/spec-driven` instead), or after the spec is written (use `/doubt-driven-development` to stress-test a finished plan).
+
+See [SKILL.md](SKILL.md) for the full process.

package/skills/interview-me/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: interview-me
+description: >
+  Extracts what the user actually wants through one-question-at-a-time interview until ~95% confidence
+  about the underlying intent. Use when an ask is underspecified, when the user explicitly invokes it,
+  or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
+  EN triggers: /interview, "interview me", "grill me", "are we sure?", "stress-test my thinking".
+  PT triggers: /entrevista, "me entrevista", "tenho certeza?", questiona minhas premissas.
+  Do NOT use for: well-specified asks (route to /spec-driven instead), or after the spec is written
+  (use /doubt-driven-development to stress-test a finished plan).
+license: CC-BY-4.0
+---
+
+# Interview Me
+
+## Overview
+
+What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit.
+
+The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.
+
+This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `idea-refine` generates variations from an idea, `spec-driven` writes the requirements down, `doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
+
+## When to Use
+
+Apply this skill when:
+
+- The ask is missing at least one of: **who** the user is, **why** they want it, what **success** looks like, what the binding **constraint** is
+- The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing
+- You're tempted to start with assumptions you haven't surfaced
+- The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed)
+- The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"
+
+**When NOT to use:**
+
+- The ask is unambiguous and self-contained ("rename this variable", "fix this typo")
+- The user has explicitly asked for speed over verification
+- Pure information requests ("how does X work?", "what does this code do?")
+- Mechanical operations (renames, formats, file moves)
+- You already have ≥95% confidence; re-read the stop condition below before assuming you don't
+
+## Loading Constraints
+
+This skill needs a live, responsive user. **Do not invoke in non-interactive contexts** like CI pipelines, scheduled runs, `/loop`, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.
+
+## The Process
+
+### Step 1: Hypothesize, with a confidence number
+
+Before asking anything, write down your current best read of what the user wants in **one sentence**, plus an honest confidence number (0–100%):
+
+```
+HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
+CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like
+```
+
+The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend.
+
+When confidence is below ~70%, append a brief reason on the same line — what's still unresolved or missing. This tells the user exactly what the interview needs to surface, and prevents the number from being a vague signal.
+
+### Step 2: Ask one question at a time, each with a guess attached
+
+Format:
+
+```
+Q: <one focused question>
+GUESS: <your hypothesis for the answer, with the reasoning that produced it>
+```
+
+Wait for the user to react before asking the next question.
+
+**Why one at a time, not a batch:**
+
+- The user can't react to your hypotheses if you bury them in a list
+- Batches encourage skim-reading and surface answers
+- The third question often depends on the answer to the first; asking them all at once locks in the wrong framing
+- The user's energy for thinking carefully is finite; spend it one question at a time
+
+**Why attach a guess:**
+
+- The user reacts faster to a wrong guess than they generate an answer from scratch
+- It commits you to a hypothesis you can be visibly wrong about, which keeps you honest
+- It surfaces *your* assumptions, which is what the interview is meant to expose
+
+The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
+
+### Step 3: Listen for "want vs. should want"
+
+The most dangerous answers are the ones where the user says what a thoughtful answer *sounds like* rather than what they actually want. Watch for:
+
+- Answers that pattern-match best-practice talk ("I want it to be scalable", "clean architecture") without specifics
+- Answers that defer to convention ("the way most apps do it", "the standard approach")
+- Phrases like "I should probably…", "I think I'm supposed to…", "good engineering practice says…"
+- Buzzwords as goals — when "modern", "scalable", "robust" are the answer instead of a specific outcome
+
+When you hear these, the question to ask is:
+
+> *"If you didn't have to justify this to anyone, what would you actually want?"*
+
+That single question often does more work than the previous five.
+
+### Step 4: Restate intent in the user's own words
+
+When your confidence is high, write back what you now think the user wants. Keep it tight (5–8 lines), use their language where possible, and structure it so the user can confirm or correct line by line:
+
+```
+Here's what I now think you want:
+
+- Outcome:      <one line>
+- User:         <one line — who benefits>
+- Why now:      <one line — what changed>
+- Success:      <one line — how we know it worked>
+- Constraint:   <one line — the binding limit>
+- Out of scope: <one line — what we're explicitly not doing>
+
+Yes / no / refine?
+```
+
+Including "Out of scope" is non-negotiable. Half of misalignment is silent disagreement about what is *not* being built.
+
+### Step 5: Confirm — explicit yes, not "whatever you think"
+
+The gate is an explicit "yes." The following are **not** yes:
+
+- "Whatever you think is best." → The user is delegating, which means they don't have 95% confidence either. Re-ask with two concrete options framed as a choice.
+- "Sounds good." → Ambiguous. Ask: "Anything you'd refine?" Silence isn't confirmation.
+- "Sure, let's go." → Often a polite exit, not an endorsement. Same follow-up.
+- Silence followed by "okay let's start." → The user has given up on the interview, not converged. Stop and ask whether you've missed something.
+
+If they correct you, fold the correction in and restate. Loop until you get an explicit yes.
+
+### The 95% Confidence Stop
+
+You're done when you can answer yes to this:
+
+> *Can I predict the user's reaction to the next three questions I would ask?*
+
+If yes, you have shared understanding. Stop interviewing and produce the restate. If no, you're not done; ask the next question.
+
+This is a checkable test, not a vibe. It also has a floor: if you've gone several rounds and still can't predict, that's information about the ask, not a reason to keep grinding. Stop and tell the user: "I've asked X questions and I still can't predict your reactions. Something foundational is missing. Want to step back?"
+
+## Output
+
+The output of this skill is a **confirmed statement of intent**: the restate from Step 4, with an explicit yes from Step 5. That's the deliverable. Specs, plans, and task lists are downstream; they consume the intent this skill produces.
+
+If the user wants the intent to persist (a multi-session project, a handoff to another collaborator), offer to save it to `docs/intent/[topic].md`. Only save if they confirm.
+
+## Example
+
+A short before-and-after.
+
+**Without `interview-me`:**
+
+```
+User:  build me a dashboard for our metrics
+Agent: <starts proposing chart libraries and layouts>
+```
+
+The agent has assumed: who it's for, what metrics, what "for our team" means, what success looks like. None of these are stated. Every assumption is a place the user can later say "that's not what I meant."
+
+**With `interview-me`:**
+
+```
+User: build me a dashboard for our metrics
+
+Agent:
+HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" came to mind because that's the conventional answer.
+CONFIDENCE: ~30% — missing: who it's for, what "metrics" are, and what success looks like
+
+Q:     When you say "how are we doing?", who's asking — you alone, the engineering team in standup, or up the chain (e.g., your manager, an exec, a board)?
+GUESS: engineering team in standup, because "we" usually scopes that way and standups are where this question gets asked. If it's for execs the metrics and the framing change a lot.
+
+User: It's actually for me. I keep losing track of which experiments are running and what their early signal looks like.
+
+Agent:
+Updated read: not a team dashboard at all. It's a personal experiment tracker. Confidence: ~60% — still missing: what "early signal" means and what done looks like.
+
+Q:     Is the gap that you don't know which experiments exist, or that you can't see their results in one place?
+GUESS: the second one. You have a list of experiments somewhere, but their results live in five different tools, and reconciling them by hand is what you're tired of.
+
+User: First one actually. I literally don't have a list. They're spread across different docs.
+
+Agent: <continues>
+```
+
+Two questions in, the agent has discovered the actual ask isn't "a dashboard." It's "a list." Different artifact, different scope, different work. The dashboard would have been wrong.
+
+## Interaction with Other Skills
+
+- **`idea-refine`**: downstream. If the confirmed intent is "I want X but I don't know how to scope it," hand off to `idea-refine` to generate variations against the now-explicit intent.
+- **`spec-driven`**: downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to `spec-driven` to write it down.
+- **`spec-driven` tasks phase**: two hops downstream of this skill (after the spec).
+- **`doubt-driven-development`**: opposite end of the timeline. Interview-me is pre-decision intent extraction; doubt-driven is post-decision artifact review. Both catch divergence, but at different moments.
+- **Framework-fact verification**: orthogonal. Interview-me clarifies what the user wants; verifying facts about frameworks against official docs is separate work. They don't compete.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The ask is clear enough" | If you can't write the user's desired outcome in one sentence right now, the ask isn't clear. Run Step 1 before deciding. |
+| "Asking too many questions wastes their time" | Time wasted by 4–6 targeted questions is small. Time wasted by building the wrong thing is enormous, and the user is the one bearing that cost. |
+| "I'll figure it out as I build" | Switching costs after code exists are 10x what they are now. Discovery during implementation is rework. |
+| "They said 'whatever you think,' so I should just decide" | "Whatever you think" is delegation, not decision. Re-ask with two concrete options as a choice. |
+| "I should give them several options to pick from" | Options work when the user knows what they want and is choosing between trade-offs. They don't know what they want yet. Listing options widens the search; asking narrows it. |
+| "If I attach my guess, I'm leading them" | Leading is the point. Reacting is faster than generating from scratch. The risk is sycophancy, not leading; mitigate by being visibly willing to be wrong. |
+| "We've talked enough, I get it" | Test it: can you predict their reaction to the next three questions? If not, you don't get it yet. |
+| "The user said yes, we're done" | If the yes followed a vague restate or an open-ended "sounds good," the yes is hollow. Restate concretely and re-confirm. |
+
+## Red Flags
+
+- Three or more questions in a single message: that's batching, not interviewing
+- A question without your hypothesis attached: that's surveying, not committing
+- Accepting "whatever you think is best" as a terminal answer
+- Producing a spec, plan, or task list before the user has explicitly confirmed your restate
+- Questions framed as "what would be best practice?" instead of "what do you actually want?"
+- The user gives a sophistication-signaling answer ("scalable", "clean", "modern") and you accept it without probing whether it's what they actually want
+- Three or more rounds without your confidence visibly rising: you're asking the wrong questions, step back and reframe
+- A confidence number below ~70% with no reason attached: the user can't help close the gap if they don't know what's missing
+- Saving the intent doc before the user has confirmed (the doc itself implies a yes the user didn't give)
+- Skipping the "Out of scope" line in the restate (silent disagreement about non-goals is half of misalignment)
+
+## Verification
+
+After applying interview-me:
+
+- [ ] An explicit hypothesis with a confidence number was stated in the first turn
+- [ ] Every confidence number below ~70% was accompanied by a one-line reason (what's still unresolved or missing)
+- [ ] Questions were asked one at a time, each with the agent's guess attached
+- [ ] At least one "what would you actually want if you didn't have to justify it?" probe ran when the user gave a sophistication-signaling or convention-signaling answer
+- [ ] A concrete restate (Outcome / User / Why now / Success / Constraint / Out of scope) was written back to the user
+- [ ] The user confirmed the restate with an explicit yes (not "whatever you think," not "sounds good," not silence)
+- [ ] At the stop point, the agent could predict reactions to the next three questions it would ask
+- [ ] Any handoff to a downstream skill (`idea-refine`, `spec-driven`) was framed in terms of the confirmed intent, not the original underspecified ask