wegho-agentes 4.0.1 → 6.0.0

package/skills/blockrun/SKILL.md

@@ -0,0 +1,292 @@
+---
+name: blockrun
+description: Use when user needs capabilities Claude lacks (image generation, real-time X/Twitter data) or explicitly requests external models ("blockrun", "use grok", "use gpt", "dall-e", "deepseek")
+allowed-tools: Read, Bash(python:*), Bash(python3:*), Bash(pip:*), Bash(source:*)
+---
+
+# BlockRun
+
+**BlockRun works with Claude Code and Google Antigravity.**
+
+You can't generate images. You have no real-time X/Twitter access. BlockRun gives you these capabilities.
+
+## Philosophy
+
+You have a wallet. When you need a capability you lack, you pay for it autonomously.
+
+| You Need | You Call | Pricing |
+|----------|----------|---------|
+| Image generation | DALL-E | $0.04/image |
+| Real-time X data | Grok + Live Search | $0.025/source |
+| Second opinion | GPT-5.2 | $1.75/M input, $14/M output |
+| Cheaper processing | DeepSeek | $0.14/M input, $0.28/M output |
+
+**How it works:** BlockRun uses x402 micropayments to route your requests to OpenAI, xAI, Google, and other providers. No API keys needed - your wallet pays per token.
+
+## Budget Control (Optional)
+
+If the user specifies a budget (e.g., "use at most $1"), track spending and stop when budget is reached:
+
+```python
+from blockrun_llm import setup_agent_wallet
+
+client = setup_agent_wallet()
+budget = 1.0  # User's budget
+
+# Before each call, check if within budget
+spending = client.get_spending()
+if spending['total_usd'] >= budget:
+    print(f"Budget reached: ${spending['total_usd']:.4f} spent")
+    # Stop making calls
+else:
+    response = client.chat("openai/gpt-5.2", "Hello!")
+
+# At the end, report spending
+spending = client.get_spending()
+print(f"💰 Total spent: ${spending['total_usd']:.4f} across {spending['calls']} calls")
+```
+
+## When to Use
+
+| Trigger | Your Action |
+|---------|-------------|
+| User explicitly requests ("blockrun second opinion with GPT on...", "use grok to check...", "generate image with dall-e") | Execute via BlockRun |
+| User needs something you can't do (images, live X data) | Suggest BlockRun, wait for confirmation |
+| You can handle the task fine | Do it yourself, don't mention BlockRun |
+
+## Example User Prompts
+
+Users will say things like:
+
+| User Says | What You Do |
+|-----------|-------------|
+| "blockrun generate an image of a sunset" | Call DALL-E via ImageClient |
+| "use grok to check what's trending on X" | Call Grok with `search=True` |
+| "blockrun GPT review this code" | Call GPT-5.2 via LLMClient |
+| "what's the latest news about AI agents?" | Suggest Grok (you lack real-time data) |
+| "generate a logo for my startup" | Suggest DALL-E (you can't generate images) |
+| "blockrun check my balance" | Show wallet balance via `get_balance()` |
+| "blockrun deepseek summarize this file" | Call DeepSeek for cost savings |
+
+## Wallet & Balance
+
+Use `setup_agent_wallet()` to auto-create a wallet and get a client. This shows the QR code and welcome message on first use.
+
+**Initialize client (always start with this):**
+```python
+from blockrun_llm import setup_agent_wallet
+
+client = setup_agent_wallet()  # Auto-creates wallet, shows QR if new
+```
+
+**Check balance (when user asks "show balance", "check wallet", etc.):**
+```python
+balance = client.get_balance()  # On-chain USDC balance
+print(f"Balance: ${balance:.2f} USDC")
+print(f"Wallet: {client.get_wallet_address()}")
+```
+
+**Show QR code for funding:**
+```python
+from blockrun_llm import generate_wallet_qr_ascii, get_wallet_address
+
+# ASCII QR for terminal display
+print(generate_wallet_qr_ascii(get_wallet_address()))
+```
+
+## SDK Usage
+
+**Prerequisite:** Install the SDK with `pip install blockrun-llm`
+
+### Basic Chat
+```python
+from blockrun_llm import setup_agent_wallet
+
+client = setup_agent_wallet()  # Auto-creates wallet if needed
+response = client.chat("openai/gpt-5.2", "What is 2+2?")
+print(response)
+
+# Check spending
+spending = client.get_spending()
+print(f"Spent ${spending['total_usd']:.4f}")
+```
+
+### Real-time X/Twitter Search (xAI Live Search)
+
+**IMPORTANT:** For real-time X/Twitter data, you MUST enable Live Search with `search=True` or `search_parameters`.
+
+```python
+from blockrun_llm import setup_agent_wallet
+
+client = setup_agent_wallet()
+
+# Simple: Enable live search with search=True
+response = client.chat(
+    "xai/grok-3",
+    "What are the latest posts from @blockrunai on X?",
+    search=True  # Enables real-time X/Twitter search
+)
+print(response)
+```
+
+### Advanced X Search with Filters
+
+```python
+from blockrun_llm import setup_agent_wallet
+
+client = setup_agent_wallet()
+
+response = client.chat(
+    "xai/grok-3",
+    "Analyze @blockrunai's recent content and engagement",
+    search_parameters={
+        "mode": "on",
+        "sources": [
+            {
+                "type": "x",
+                "included_x_handles": ["blockrunai"],
+                "post_favorite_count": 5
+            }
+        ],
+        "max_search_results": 20,
+        "return_citations": True
+    }
+)
+print(response)
+```
+
+### Image Generation
+```python
+from blockrun_llm import ImageClient
+
+client = ImageClient()
+result = client.generate("A cute cat wearing a space helmet")
+print(result.data[0].url)
+```
+
+## xAI Live Search Reference
+
+Live Search is xAI's real-time data API. Cost: **$0.025 per source** (default 10 sources = ~$0.26).
+
+To reduce costs, set `max_search_results` to a lower value:
+```python
+# Only use 5 sources (~$0.13)
+response = client.chat("xai/grok-3", "What's trending?",
+    search_parameters={"mode": "on", "max_search_results": 5})
+```
+
+### Search Parameters
+
+| Parameter | Type | Default | Description |
+|-----------|------|---------|-------------|
+| `mode` | string | "auto" | "off", "auto", or "on" |
+| `sources` | array | web,news,x | Data sources to query |
+| `return_citations` | bool | true | Include source URLs |
+| `from_date` | string | - | Start date (YYYY-MM-DD) |
+| `to_date` | string | - | End date (YYYY-MM-DD) |
+| `max_search_results` | int | 10 | Max sources to return (customize to control cost) |
+
+### Source Types
+
+**X/Twitter Source:**
+```python
+{
+    "type": "x",
+    "included_x_handles": ["handle1", "handle2"],  # Max 10
+    "excluded_x_handles": ["spam_account"],        # Max 10
+    "post_favorite_count": 100,  # Min likes threshold
+    "post_view_count": 1000      # Min views threshold
+}
+```
+
+**Web Source:**
+```python
+{
+    "type": "web",
+    "country": "US",  # ISO alpha-2 code
+    "allowed_websites": ["example.com"],  # Max 5
+    "safe_search": True
+}
+```
+
+**News Source:**
+```python
+{
+    "type": "news",
+    "country": "US",
+    "excluded_websites": ["tabloid.com"]  # Max 5
+}
+```
+
+## Available Models
+
+| Model | Best For | Pricing |
+|-------|----------|---------|
+| `openai/gpt-5.2` | Second opinions, code review, general | $1.75/M in, $14/M out |
+| `openai/gpt-5-mini` | Cost-optimized reasoning | $0.30/M in, $1.20/M out |
+| `openai/o4-mini` | Latest efficient reasoning | $1.10/M in, $4.40/M out |
+| `openai/o3` | Advanced reasoning, complex problems | $10/M in, $40/M out |
+| `xai/grok-3` | Real-time X/Twitter data | $3/M + $0.025/source |
+| `deepseek/deepseek-chat` | Simple tasks, bulk processing | $0.14/M in, $0.28/M out |
+| `google/gemini-2.5-flash` | Very long documents, fast | $0.15/M in, $0.60/M out |
+| `openai/dall-e-3` | Photorealistic images | $0.04/image |
+| `google/nano-banana` | Fast, artistic images | $0.01/image |
+
+*M = million tokens. Actual cost depends on your prompt and response length.*
+
+## Cost Reference
+
+All LLM costs are per million tokens (M = 1,000,000 tokens).
+
+| Model | Input | Output |
+|-------|-------|--------|
+| GPT-5.2 | $1.75/M | $14.00/M |
+| GPT-5-mini | $0.30/M | $1.20/M |
+| Grok-3 (no search) | $3.00/M | $15.00/M |
+| DeepSeek | $0.14/M | $0.28/M |
+
+| Fixed Cost Actions | |
+|-------|--------|
+| Grok Live Search | $0.025/source (default 10 = $0.25) |
+| DALL-E image | $0.04/image |
+| Nano Banana image | $0.01/image |
+
+**Typical costs:** A 500-word prompt (~750 tokens) to GPT-5.2 costs ~$0.001 input. A 1000-word response (~1500 tokens) costs ~$0.02 output.
+
+## Setup & Funding
+
+**Wallet location:** `$HOME/.blockrun/.session` (e.g., `/Users/username/.blockrun/.session`)
+
+**First-time setup:**
+1. Wallet auto-creates when `setup_agent_wallet()` is called
+2. Check wallet and balance:
+```python
+from blockrun_llm import setup_agent_wallet
+client = setup_agent_wallet()
+print(f"Wallet: {client.get_wallet_address()}")
+print(f"Balance: ${client.get_balance():.2f} USDC")
+```
+3. Fund wallet with $1-5 USDC on Base network
+
+**Show QR code for funding (ASCII for terminal):**
+```python
+from blockrun_llm import generate_wallet_qr_ascii, get_wallet_address
+print(generate_wallet_qr_ascii(get_wallet_address()))
+```
+
+## Troubleshooting
+
+**"Grok says it has no real-time access"**
+→ You forgot to enable Live Search. Add `search=True`:
+```python
+response = client.chat("xai/grok-3", "What's trending?", search=True)
+```
+
+**Module not found**
+→ Install the SDK: `pip install blockrun-llm`
+
+## Updates
+
+```bash
+pip install --upgrade blockrun-llm
+```

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: brainstorming
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
+
+## The Process
+
+**Understanding the idea:**
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Break it into sections of 200-300 words
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Implementation (if continuing):**
+- Ask: "Ready to set up for implementation?"
+- Use superpowers:using-git-worktrees to create isolated workspace
+- Use superpowers:writing-plans to create detailed implementation plan
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design in sections, validate each
+- **Be flexible** - Go back and clarify when something doesn't make sense

package/skills/brainstorming/dynamic-questioning.md

@@ -0,0 +1,350 @@
+# Dynamic Question Generation
+
+> **PRINCIPLE:** Questions are not about gathering data—they are about **revealing architectural consequences**.
+>
+> Every question must connect to a concrete implementation decision that affects cost, complexity, or timeline.
+
+---
+
+## 🧠 Core Principles
+
+### 1. Questions Reveal Consequences
+
+A good question is not "What color do you want?" but:
+
+```markdown
+❌ BAD: "What authentication method?"
+✅ GOOD: "Should users sign up with email/password or social login?
+
+   Impact:
+   - Email/Pass → Need password reset, hashing, 2FA infrastructure
+   - Social → OAuth providers, user profile mapping, less control
+
+   Trade-off: Security vs. Development time vs. User friction"
+```
+
+### 2. Context Before Content
+
+First understand **where** this request fits:
+
+| Context | Question Focus |
+|---------|----------------|
+| **Greenfield** (new project) | Foundation decisions: stack, hosting, scale |
+| **Feature Addition** | Integration points, existing patterns, breaking changes |
+| **Refactor** | Why refactor? Performance? Maintainability? What's broken? |
+| **Debug** | Symptoms → Root cause → Reproduction path |
+
+### 3. Minimum Viable Questions
+
+**PRINCIPLE:** Each question must eliminate a fork in the implementation road.
+
+```
+Before Question:
+├── Path A: Do X (5 min)
+├── Path B: Do Y (15 min)
+└── Path C: Do Z (1 hour)
+
+After Question:
+└── Path Confirmed: Do X (5 min)
+```
+
+If a question doesn't reduce implementation paths → **DELETE IT**.
+
+### 4. Questions Generate Data, Not Assumptions
+
+```markdown
+❌ ASSUMPTION: "User probably wants Stripe for payments"
+✅ QUESTION: "Which payment provider fits your needs?
+
+   Stripe → Best documentation, 2.9% + $0.30, US-centric
+   LemonSqueezy → Merchant of Record, 5% + $0.50, global taxes
+   Paddle → Complex pricing, handles EU VAT, enterprise focus"
+```
+
+---
+
+## 📋 Question Generation Algorithm
+
+```
+INPUT: User request + Context (greenfield/feature/refactor/debug)
+│
+├── STEP 1: Parse Request
+│   ├── Extract domain (ecommerce, auth, realtime, cms, etc.)
+│   ├── Extract features (explicit and implied)
+│   └── Extract scale indicators (users, data volume, frequency)
+│
+├── STEP 2: Identify Decision Points
+│   ├── What MUST be decided before coding? (blocking)
+│   ├── What COULD be decided later? (deferable)
+│   └── What has ARCHITECTURAL impact? (high-leverage)
+│
+├── STEP 3: Generate Questions (Priority Order)
+│   ├── P0: Blocking decisions (cannot proceed without answer)
+│   ├── P1: High-leverage (affects >30% of implementation)
+│   ├── P2: Medium-leverage (affects specific features)
+│   └── P3: Nice-to-have (edge cases, optimization)
+│
+└── STEP 4: Format Each Question
+    ├── What: Clear question
+    ├── Why: Impact on implementation
+    ├── Options: Trade-offs (not just A vs B)
+    └── Default: What happens if user doesn't answer
+```
+
+---
+
+## 🎯 Domain-Specific Question Banks
+
+### E-Commerce
+
+| Question | Why It Matters | Trade-offs |
+|----------|----------------|------------|
+| **Single or Multi-vendor?** | Multi-vendor → Commission logic, vendor dashboards, split payments | +Revenue, -Complexity |
+| **Inventory Tracking?** | Needs stock tables, reservation logic, low-stock alerts | +Accuracy, -Development time |
+| **Digital or Physical Products?** | Digital → Download links, no shipping | Physical → Shipping APIs, tracking |
+| **Subscription or One-time?** | Subscription → Recurring billing, dunning, proration | +Revenue, -Complexity |
+
+### Authentication
+
+| Question | Why It Matters | Trade-offs |
+|----------|----------------|------------|
+| **Social Login Needed?** | OAuth providers vs. password reset infrastructure | +UX, -Control |
+| **Role-Based Permissions?** | RBAC tables, policy enforcement, admin UI | +Security, -Development time |
+| **2FA Required?** | TOTP/SMI infrastructure, backup codes, recovery flow | +Security, -UX friction |
+| **Email Verification?** | Verification tokens, email service, resend logic | +Security, -Sign-up friction |
+
+### Real-time
+
+| Question | Why It Matters | Trade-offs |
+|----------|----------------|------------|
+| **WebSocket or Polling?** | WS → Server scaling, connection management | Polling → Simpler, higher latency |
+| **Expected Concurrent Users?** | <100 → Single server, >1000 → Redis pub/sub, >10k → specialized infra | +Scale, -Complexity |
+| **Message Persistence?** | History tables, storage costs, pagination | +UX, -Storage |
+| **Ephemeral or Durable?** | Ephemeral → In-memory, Durable → Database write before emit | +Reliability, -Latency |
+
+### Content/CMS
+
+| Question | Why It Matters | Trade-offs |
+|----------|----------------|------------|
+| **Rich Text or Markdown?** | Rich Text → Sanitization, XSS risks | Markdown → Simple, no WYSIWYG |
+| **Draft/Publish Workflow?** | Status field, scheduled jobs, versioning | +Control, -Complexity |
+| **Media Handling?** | Upload endpoints, storage, optimization | +Features, -Development time |
+| **Multi-language?** | i18n tables, translation UI, fallback logic | +Reach, -Complexity |
+
+---
+
+## 📐 Dynamic Question Template
+
+```markdown
+Based on your request for [DOMAIN] [FEATURE]:
+
+## 🔴 CRITICAL (Blocking Decisions)
+
+### 1. **[DECISION POINT]**
+
+**Question:** [Clear, specific question]
+
+**Why This Matters:**
+- [Explain architectural consequence]
+- [Affects: cost / complexity / timeline / scale]
+
+**Options:**
+| Option | Pros | Cons | Best For |
+|--------|------|------|----------|
+| A | [Advantage] | [Disadvantage] | [Use case] |
+| B | [Advantage] | [Disadvantage] | [Use case] |
+
+**If Not Specified:** [Default choice + rationale]
+
+---
+
+## 🟡 HIGH-LEVERAGE (Affects Implementation)
+
+### 2. **[DECISION POINT]**
+[Same format]
+
+---
+
+## 🟢 NICE-TO-HAVE (Edge Cases)
+
+### 3. **[DECISION POINT]**
+[Same format]
+```
+
+---
+
+## 🔄 Iterative Questioning
+
+### First Pass (3-5 Questions)
+Focus on **blocking decisions**. Don't proceed without answers.
+
+### Second Pass (After Initial Implementation)
+As patterns emerge, ask:
+- "This feature implies [X]. Should we handle [edge case] now or defer?"
+- "We're using [Pattern A]. Should [Feature B] follow the same pattern?"
+
+### Third Pass (Optimization)
+When functionality works:
+- "Performance bottleneck at [X]. Optimize now or acceptable for now?"
+- "Refactor [Y] for maintainability or ship as-is?"
+
+---
+
+## 🎭 Example: Full Question Generation
+
+```
+USER REQUEST: "Build an Instagram clone"
+
+STEP 1: Parse
+├── Domain: Social Media
+├── Features: Photo sharing, engagement (likes/comments), user profiles
+├── Implied: Feed, following, authentication
+└── Scale: Potentially high (social apps go viral)
+
+STEP 2: Decision Points
+├── Blocking: Storage strategy, authentication method, feed type
+├── High-leverage: Real-time notifications, data model complexity
+└── Deferable: Analytics, advanced search, reels/video
+
+STEP 3: Generate Questions (Priority)
+
+P0 (Blocking):
+1. Storage Strategy → Affects architecture, cost, speed
+2. Feed Algorithm → Affects database queries, complexity
+3. Auth Method → Affects dev time, UX, security
+
+P1 (High-leverage):
+4. Real-time Notifications → WebSocket vs polling
+5. Media Processing → Client-side vs server-side optimization
+
+P2 (Deferable):
+6. Story/Reels → Major feature creep, defer to v2
+7. DM/Chat → Separate subsystem, defer to v2
+
+STEP 4: Format Output
+```
+
+---
+
+## 📊 Generated Output (Example)
+
+```
+Based on your Instagram clone request:
+
+## 🔴 CRITICAL DECISIONS (Cannot Proceed Without Answers)
+
+### 1. **Photo Storage Strategy**
+
+**Question:** Where will user photos be stored and served?
+
+**Why This Matters:**
+- Affects: Monthly hosting costs, page load speed, CDN complexity
+- High-volume social apps: 1000 users × 10 photos × 2MB = 20GB storage
+
+**Options:**
+| Option | Cost | Speed | Complexity | Best For |
+|--------|------|-------|------------|----------|
+| **Cloudinary** | $89/mo (25GB) | Fast (CDN) | Low | MVP, rapid launch |
+| **AWS S3 + CloudFront** | $0.023/GB | Fast (CDN) | Medium | Production, cost-optimized |
+| **Supabase Storage** | Free tier 1GB | Medium | Low | Small scale, simple |
+| **Local Storage** | Server cost | Slow | Low | Development only |
+
+**If Not Specified:** Cloudinary (balanced for MVP)
+
+---
+
+### 2. **Feed Algorithm Choice**
+
+**Question:** How should the main feed work?
+
+**Why This Matters:**
+- Affects: Database query complexity, caching strategy, development time
+- Algorithmic feeds require ML infrastructure, ranking signals
+
+**Options:**
+| Option | Complexity | Database Impact | Best For |
+|--------|------------|-----------------|----------|
+| **Chronological** | Low | Simple query | Early stage, transparency |
+| **Follow-Only** | Medium | JOIN with pagination | Most social apps |
+| **Algorithmic** | High | Pre-computed feed tables | Instagram competitor |
+
+**If Not Specified:** Follow-Only (balanced for social app)
+
+---
+
+### 3. **Authentication Approach**
+
+**Question:** How do users sign up and login?
+
+**Why This Matters:**
+- Affects: Development time (2-5 hours), security posture, UX friction
+
+**Options:**
+| Option | Dev Time | Security | UX | Best For |
+|--------|----------|----------|-----|----------|
+| **Email/Password** | 4-5 hrs | High (if 2FA) | Medium | Full control needed |
+| **Social Only** | 1-2 hrs | Provider-dependent | Smooth | B2C, rapid launch |
+| **Magic Link** | 2-3 hrs | Medium | Very smooth | Security-focused |
+| **Clerk/Auth0** | 1 hr | High | Smooth | Fastest to market |
+
+**If Not Specified:** Clerk (fastest for MVP)
+
+---
+
+## 🟡 HIGH-LEVERAGE (Affects Architecture)
+
+### 4. **Real-time Notifications**
+
+**Question:** Do users need instant notifications for likes/comments?
+
+**Why This Matters:**
+- WebSocket adds infrastructure complexity (Redis pub/sub for scaling)
+- Polling is simpler but higher latency
+
+**Options:**
+| Option | Complexity | Scale Cost | Best For |
+|--------|------------|------------|----------|
+| **WebSocket + Redis** | High | $10+/mo | >1000 concurrent users |
+| **Polling (30s)** | Low | DB queries | <1000 users |
+| **No Real-time** | None | None | MVP, validate first |
+
+**If Not Specified:** Polling for MVP (defer WebSocket until validated)
+
+---
+
+## 🟢 NICE-TO-HAVE (Defer to v2)
+
+### 5. **Video/Reels Support**
+- Major complexity (video processing, streaming infrastructure)
+- Recommendation: Launch with photos only, add video after validation
+
+### 6. **Direct Messaging**
+- Separate subsystem (chat infrastructure different from feed)
+- Recommendation: Use Pusher/Stream for real-time or defer entirely
+
+---
+
+## 📋 Summary
+
+| Decision | Recommendation | If Changed |
+|----------|----------------|------------|
+| Storage | Cloudinary | +3 hrs setup |
+| Feed | Follow-only | +2 hrs query optimization |
+| Auth | Clerk | -3 hrs dev time |
+| Real-time | Polling | +5 hrs WebSocket setup |
+| Video | Defer to v2 | N/A |
+| DM | Defer to v2 | N/A |
+
+**Total Estimated MVP Time:** 15-20 hours with recommendations above
+```
+
+---
+
+## 🎯 Principles Recap
+
+1. **Every question = Architectural decision** → Not data gathering
+2. **Show trade-offs** → User understands consequences
+3. **Prioritize blocking decisions** → Cannot proceed without
+4. **Provide defaults** → If user doesn't answer, we proceed anyway
+5. **Domain-aware** → Ecommerce questions ≠ Auth questions ≠ Real-time questions
+6. **Iterative** → More questions as patterns emerge during implementation