@minhduydev/mdpi 0.3.0

package/dist/template/.pi/skills/incremental-implementation/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: incremental-implementation
+description: Use when implementing features or fixes to enforce thin vertical slices with verify-after-each — prevents large, untested changes by requiring working code at every step
+---
+
+# Incremental Implementation
+
+> **Replaces** big-bang implementations where everything is built at once and tested at the end — enforces thin vertical slices with verification after each step
+
+## When to Use
+
+- Implementing any feature that touches more than 2 files
+- Working from a plan or spec with multiple tasks
+- Building something where partial progress should be demonstrable
+
+## When NOT to Use
+
+- One-line fixes or trivial changes
+- Pure refactors with no behavior change (use code-simplification instead)
+- Exploratory prototyping where you need to experiment freely
+
+## Common Rationalizations
+
+| Rationalization                                   | Rebuttal                                                                                                            |
+| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| "I'll build everything first and test at the end" | End-to-end testing after 500 lines of changes makes failures impossible to isolate                                  |
+| "This feature can't be split into slices"         | Every feature can be sliced — you're confusing "the UI needs all parts" with "the code must be written all at once" |
+| "Committing partial work creates noise"           | Partial working commits are rollback points. One giant commit is a rollback cliff                                   |
+| "It's faster to write it all at once"             | It feels faster until the first bug takes 2 hours to locate in a 400-line diff                                      |
+| "The slices are too small to be meaningful"       | If a slice compiles, passes tests, and moves toward the goal, it's meaningful                                       |
+| "I need to see the whole picture first"           | Read the plan first, then implement slice by slice. Understanding ≠ building all at once                            |
+
+## Overview
+
+Large implementations fail because errors compound. When you write 500 lines before running anything, each line can introduce a bug that interacts with bugs from other lines. Thin vertical slices keep the error surface small.
+
+**Core principle:** Working code at every step. Never be more than one slice away from a green build.
+
+## The Cycle
+
+```
+FOR each slice:
+  1. IMPLEMENT — Write the minimal code for this slice (1-3 files max)
+  2. VERIFY — Run typecheck + lint + relevant tests
+  3. COMMIT — Create a checkpoint with descriptive message
+  4. NEXT — Move to the next slice
+
+IF verify fails:
+  Fix within the current slice before moving on
+  Do NOT proceed to the next slice with broken code
+```
+
+## Slicing Strategies
+
+### Vertical Slice (Preferred)
+
+Each slice delivers one thin path through the full stack:
+
+```
+Slice 1: API endpoint returns hardcoded data → test passes
+Slice 2: API endpoint reads from database → test passes
+Slice 3: UI calls API and renders data → test passes
+Slice 4: Add validation and error handling → test passes
+```
+
+### Contract-First
+
+Define interfaces first, then implement behind them:
+
+```
+Slice 1: Define types/interfaces → compiles
+Slice 2: Implement with stubs → tests pass (with mocked data)
+Slice 3: Replace stubs with real implementation → tests pass
+```
+
+### Risk-First
+
+Implement the hardest or most uncertain part first:
+
+```
+Slice 1: The tricky algorithm or integration → tests pass
+Slice 2: The straightforward plumbing → tests pass
+Slice 3: The UI/presentation layer → tests pass
+```
+
+## Implementation Rules
+
+### 1. Simplicity First
+
+Default to the simplest viable solution for each slice.
+
+```
+[ ] "Let me add a factory pattern for extensibility"
+[x] "Direct function call works. Refactor to pattern IF a second use case appears"
+```
+
+### 2. Scope Discipline
+
+Each slice does ONE thing. If you notice something else that needs fixing:
+
+```
+NOTICED BUT NOT TOUCHING: [description of unrelated improvement]
+```
+
+Log it and continue with the current slice.
+
+### 3. One Compilable Step at a Time
+
+Never leave the codebase in a state where typecheck fails between slices.
+
+```
+[ ] Add 5 function signatures, then implement all 5
+[x] Add and implement function 1, verify, then function 2
+```
+
+### 4. Keep Tests Green
+
+If existing tests break from your change, fix them in the same slice — not in a "fix tests" slice later.
+
+### 5. Feature Flags for Incomplete Features
+
+If a slice can't be hidden behind existing abstractions:
+
+```typescript
+// Temporary gate — remove when feature is complete
+if (process.env.ENABLE_NEW_FEATURE) {
+  // new code path
+} else {
+  // existing behavior
+}
+```
+
+### 6. Rollback-Friendly
+
+Each committed slice should be independently revertable without breaking the build.
+
+## Slice Size Guide
+
+| Slice Size    | Signal                                     |
+| ------------- | ------------------------------------------ |
+| 1-30 lines    | Ideal — easy to review and verify          |
+| 30-100 lines  | Acceptable — still isolatable              |
+| 100-200 lines | Too large — find a split point             |
+| 200+ lines    | Stop. You're doing big-bang implementation |
+
+## Red Flags — STOP
+
+If you catch yourself:
+
+- Writing more than 100 lines without running verification
+- Saying "I'll test this after I finish the next part"
+- Having 3+ files with uncommitted changes
+- Building a complex abstraction before the simple version works
+- Skipping verification because "this slice is trivial"
+
+**STOP.** Verify what you have. Commit if it passes. Then continue.
+
+## Verification
+
+After each slice:
+
+```bash
+# Minimum verification (must pass)
+npm run typecheck   # or equivalent
+npm run lint        # or equivalent
+
+# If slice changes behavior
+npm test            # relevant test files
+```
+
+After all slices complete:
+
+```bash
+# Full verification
+npm run typecheck && npm run lint && npm test
+```
+
+## Integration with Other Skills
+
+- **test-driven-development** — Write the test for each slice FIRST (RED), then implement (GREEN)
+- **verification-before-completion** — Run full gates after the final slice
+- **code-simplification** — Refactor AFTER all slices pass, not during implementation
+- **systematic-debugging** — If a slice fails verification, debug systematically instead of guessing
+
+## See Also
+
+- **planning-and-task-breakdown** — Creates the plan that this skill executes slice-by-slice
+- **subagent-driven-development** — Orchestrates parallel execution of independent slices via subagents
+- `behavioral-kernel` skill
+- `verification-before-completion` skill

package/dist/template/.pi/skills/industrial-brutalist-ui/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: industrial-brutalist-ui
+description: Use INSTEAD OF design-taste-frontend when user requests brutalist, military-terminal, or raw mechanical aesthetics. Swiss typographic print meets utilitarian color. For data-heavy dashboards or editorial sites needing declassified-blueprint energy.
+---
+
+## When to Use
+
+- When the user requests brutalist, military-terminal, or raw mechanical aesthetics
+- For data-heavy dashboards or editorial sites needing declassified-blueprint energy
+- Instead of design-taste-frontend when utilitarian aesthetics are requested
+
+## When NOT to Use
+
+- For consumer-facing marketing or e-commerce sites
+- When clean, minimalist, or luxury aesthetics are requested
+- For accessibility-critical applications where brutalist patterns may reduce readability
+
+
+# SKILL: Industrial Brutalism & Tactical Telemetry UI
+
+## 1. Skill Meta
+**Name:** Industrial Brutalism & Tactical Telemetry Interface Engineering
+**Description:** Advanced proficiency in architecting web interfaces that synthesize mid-century Swiss Typographic design, industrial manufacturing manuals, and retro-futuristic aerospace/military terminal interfaces. This discipline requires absolute mastery over rigid modular grids, extreme typographic scale contrast, purely utilitarian color palettes, and the programmatic simulation of analog degradation (halftones, CRT scanlines, bitmap dithering). The objective is to construct digital environments that project raw functionality, mechanical precision, and high data density, deliberately discarding conventional consumer UI patterns.
+
+## 2. Visual Archetypes
+The design system operates by merging two distinct but highly compatible visual paradigms. **Pick ONE per project and commit to it. Do not alternate or mix both modes within the same interface.**
+
+### 2.1 Swiss Industrial Print
+Derived from 1960s corporate identity systems and heavy machinery blueprints.
+*   **Characteristics:** High-contrast light modes (newsprint/off-white substrates). Reliance on monolithic, heavy sans-serif typography. Unforgiving structural grids outlined by visible dividing lines. Aggressive, asymmetric use of negative space punctuated by oversized, viewport-bleeding numerals or letterforms. Heavy use of primary red as an alert/accent color.
+
+### 2.2 Tactical Telemetry & CRT Terminal
+Derived from classified military databases, legacy mainframes, and aerospace Heads-Up Displays (HUDs).
+*   **Characteristics:** Dark mode exclusivity. High-density tabular data presentation. Absolute dominance of monospaced typography. Integration of technical framing devices (ASCII brackets, crosshairs). Application of simulated hardware limitations (phosphor glow, scanlines, low bit-depth rendering).
+
+## 3. Typographic Architecture
+Typography is the primary structural and decorative infrastructure. Imagery is secondary. The system demands extreme variance in scale, weight, and spacing.
+
+### 3.1 Macro-Typography (Structural Headers)
+*   **Classification:** Neo-Grotesque / Heavy Sans-Serif.
+*   **Optimal Web Fonts:** Neue Haas Grotesk (Black), Inter (Extra Bold/Black), Archivo Black, Roboto Flex (Heavy), Monument Extended.
+*   **Implementation Parameters:**
+    *   **Scale:** Deployed at massive scales using fluid typography (e.g., `clamp(4rem, 10vw, 15rem)`).
+    *   **Tracking (Letter-spacing):** Extremely tight, often negative (`-0.03em` to `-0.06em`), forcing glyphs to form solid architectural blocks.
+    *   **Leading (Line-height):** Highly compressed (`0.85` to `0.95`).
+    *   **Casing:** Exclusively uppercase for structural impact.
+
+### 3.2 Micro-Typography (Data & Telemetry)
+*   **Classification:** Monospace / Technical Sans.
+*   **Optimal Web Fonts:** JetBrains Mono, IBM Plex Mono, Space Mono, VT323, Courier Prime.
+*   **Implementation Parameters:**
+    *   **Scale:** Fixed and small (`10px` to `14px` / `0.7rem` to `0.875rem`).
+    *   **Tracking:** Generous (`0.05em` to `0.1em`) to simulate mechanical typewriter spacing or terminal matrices.
+    *   **Leading:** Standard to tight (`1.2` to `1.4`).
+    *   **Casing:** Exclusively uppercase. Used for all metadata, navigation, unit IDs, and coordinates.
+
+### 3.3 Textural Contrast (Artistic Disruption)
+*   **Classification:** High-Contrast Serif.
+*   **Optimal Web Fonts:** Playfair Display, EB Garamond, Times New Roman.
+*   **Implementation Parameters:** Used exceedingly sparingly. Must be subjected to heavy post-processing (halftone filters, 1-bit dithering) to degrade vector perfection and create textural juxtaposition against the clean sans-serifs.
+
+## 4. Color System
+The color architecture is uncompromising. Gradients, soft drop shadows, and modern translucency are strictly prohibited. Colors simulate physical media or primitive emissive displays.
+
+**CRITICAL: Choose ONE substrate palette per project and use it consistently. Never mix light and dark substrates within the same interface.**
+
+### If Swiss Industrial Print (Light):
+*   **Background:** `#F4F4F0` or `#EAE8E3` (Matte, unbleached documentation paper).
+*   **Foreground:** `#050505` to `#111111` (Carbon Ink).
+*   **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). This is the ONLY accent color. Used for strike-throughs, thick structural dividing lines, or vital data highlights.
+
+### If Tactical Telemetry (Dark):
+*   **Background:** `#0A0A0A` or `#121212` (Deactivated CRT. Avoid pure `#000000`).
+*   **Foreground:** `#EAEAEA` (White phosphor). This is the primary text color.
+*   **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). Same red, same rules.
+*   **Terminal Green (`#4AF626`):** Optional. Use ONLY for a single specific UI element (e.g., one status indicator or one data readout) — never as a general text color. If it doesn't serve a clear purpose, omit it entirely.
+
+## 5. Layout and Spatial Engineering
+The layout must appear mathematically engineered. It rejects conventional web padding in favor of visible compartmentalization.
+
+*   **The Blueprint Grid:** Strict adherence to CSS Grid architectures. Elements do not float; they are anchored precisely to grid tracks and intersections.
+*   **Visible Compartmentalization:** Extensive utilization of solid borders (`1px` or `2px solid`) to delineate distinct zones of information. Horizontal rules (`<hr>`) frequently span the entire container width to segregate operational units.
+*   **Bimodal Density:** Layouts oscillate between extreme data density (tightly packed monospace metadata clustered together) and vast expanses of calculated negative space framing macro-typography.
+*   **Geometry:** Absolute rejection of `border-radius`. All corners must be exactly 90 degrees to enforce mechanical rigidity.
+
+## 6. UI Components and Symbology
+Standard web UI conventions are replaced with utilitarian, industrial graphic elements.
+
+*   **Syntax Decoration:** Utilization of ASCII characters to frame data points.
+    *   *Framing:* `[ DELIVERY SYSTEMS ]`, `< RE-IND >`
+    *   *Directional:* `>>>`, `///`, `\\\\`
+*   **Industrial Markers:** Prominent integration of registration (`®`), copyright (`©`), and trademark (`™`) symbols functioning as structural geometric elements rather than legal text.
+*   **Technical Assets:** Integration of crosshairs (`+`) at grid intersections, repeating vertical lines (barcodes), thick horizontal warning stripes, and randomized string data (e.g., `REV 2.6`, `UNIT / D-01`) to simulate active mechanical processes.
+
+## 7. Textural and Post-Processing Effects
+To prevent the design from appearing purely digital, simulated analog degradation is engineered into the frontend via CSS and SVG filters.
+
+*   **Halftone and 1-Bit Dithering:** Transforming continuous-tone images or large serif typography into dot-matrix patterns. Achieved via pre-processing or CSS `mix-blend-mode: multiply` overlays combined with SVG radial dot patterns.
+*   **CRT Scanlines:** For terminal interfaces, applying a `repeating-linear-gradient` to the background to simulate horizontal electron beam sweeps (e.g., `repeating-linear-gradient(0deg, transparent, transparent 2px, rgba(0,0,0,0.1) 2px, rgba(0,0,0,0.1) 4px)`).
+*   **Mechanical Noise:** A global, low-opacity SVG static/noise filter applied to the DOM root to introduce a unified physical grain across both dark and light modes.
+
+## 8. Web Engineering Directives
+1.  **Grid Determinism:** Utilize `display: grid; gap: 1px;` with contrasting parent/child background colors to generate mathematically perfect, razor-thin dividing lines without complex border declarations.
+2.  **Semantic Rigidity:** Construct the DOM using precise semantic tags (`<data>`, `<samp>`, `<kbd>`, `<output>`, `<dl>`) to accurately reflect the technical nature of the telemetry.
+3.  **Typography Clamping:** Implement CSS `clamp()` functions exclusively for macro-typography to ensure massive text scales aggressively while maintaining structural integrity across viewports.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Brutalism is just raw HTML" | Brutalism is intentional rawness, not accidental. Every rough edge is a design choice. |
+| "Brutalism doesn't need polish" | Brutalist polish is different — it's about consistency of the raw aesthetic, not smoothness. |
+| "This style works for any data" | Brutalism excels with data-heavy interfaces. It fails on emotional/brand content. |
+
+## Red Flags
+
+- Raw default styles without intentional choices
+- Legibility sacrificed for aesthetic
+- Monospace used where readability matters for long-form text
+- No responsive behavior (brutalism should still work on mobile)
+- Console/terminal aesthetic without real functionality behind it
+
+## Verification
+
+After applying industrial-brutalist design:
+
+- [ ] Raw aesthetic is intentional, not accidental default
+- [ ] Text is readable at all viewport sizes
+- [ ] Interactive elements are clearly distinguishable
+- [ ] Terminal/console elements have real function, not just decoration
+- [ ] The design communicates "declassified blueprint" energy, not "broken CSS"

package/dist/template/.pi/skills/interview-me/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: interview-me
+description: "Extracts what the user actually wants through one-question-at-a-time interview until ~95% confidence. Use when the ask is underspecified ('build me X' without who/why/success), user invokes 'interview me' / 'grill me' / 'are we sure?', or when catching yourself silently filling ambiguous requirements before any plan, spec, or code exists. Risk: Low."
+---
+
+# 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-development` 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")
+- Requirements are already captured in a spec — start from the spec instead
+- 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:
+GUESS:
+```
+
+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:
+- User:
+- Why now:
+- Success:
+- Constraint:
+- Out of scope:
+
+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 building a dashboard, making assumptions about who, what metrics, what success]
+```
+
+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 — discovered the actual ask isn't "a dashboard" but "a list"]
+```
+
+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-development`**: downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to `spec-driven-development` to write it down.
+- **`planning-and-task-breakdown`**: two hops downstream of this skill (after the spec).
+- **`brainstorming`**: parallel. Both are pre-code exploration. `interview-me` extracts intent; `brainstorming` generates options once intent is clear.
+- **`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.
+- **`source-driven-development`**: orthogonal. Interview-me clarifies what the user wants; SDD verifies framework facts. 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-development`) was framed in terms of the confirmed intent, not the original underspecified ask