Moai Core Ask User Questions

Enterprise Interactive Survey Orchestrator

Skill Metadata

🚀 What It Does (Enterprise Context)

Purpose: Empower Alfred sub-agents to actively conduct enterprise-grade surveys for requirement clarification, architectural decisions, and complex decision automation.

Leverages Claude Code's native AskUserQuestion tool to collect explicit, structured user input that transforms vague requests into precise specifications with guaranteed UX quality across all models.

Enterprise Capabilities:

• ✅ Single-select & multi-select option types (independent or dependent)
• ✅ 1-4 questions per survey (cognitive load optimization)
• ✅ 2-4 options per question with trade-off analysis
• ✅ Automatic "Other" option for custom input validation
• ✅ Conditional branching based on user answers
• ✅ Error recovery and retry logic
• ✅ Integration across all Alfred commands (Plan/Run/Sync)
• ✅ Multi-language support (user's configured language)
• ✅ Accessibility-first TUI design
• ✅ Reduces ambiguity → single interaction vs 3-5 iterations

🎯 When to Use (Decision Framework)

✅ MANDATORY ASK when user intent is ambiguous:

1. Vague noun phrases: "Add dashboard", "Refactor auth", "Improve performance"

   • Missing concrete specification or scope

2. Missing scope definition: No specification of WHERE, WHO, WHAT, HOW, WHEN

   • Could affect 5+ files or multiple modules

3. Multiple valid paths: ≥2 reasonable implementation approaches

   • Different trade-offs (speed vs quality, simple vs comprehensive)

4. Trade-off decisions: Performance vs reliability, cost vs features

   • No single objectively best answer

5. Risky operations: Destructive actions (delete, migrate, reset)

   • Explicit informed consent required

6. Architectural decisions: Technology selection, API design, database choice

   • Long-term impact requires clarification

❌ DON'T ask when:

• User explicitly specified exact requirements
• Decision is automatic (no choices, pure routing)
• Single obvious path exists (no alternatives)
• Quick yes/no confirmation only (keep it brief)
• Information already provided in conversation

🎨 Design Principles (Enterprise Standards)

Core Principle: Certainty Over Guessing

Golden Rule: When in doubt, ask the user instead of assuming.

Why:

• ✅ User sees exactly what you'll do → no surprises
• ✅ Single interaction vs 3-5 rounds of back-and-forth
• ✅ Fast → execute with certainty
• ✅ Reduces "vibe coding" frustration
• ✅ Builds trust through transparency

Pattern:

Ambiguous request detected
         ↓
Call AskUserQuestion({questions: [...]})
         ↓
User selects from clear options
         ↓
Proceed with confirmed specifications

🏗️ Architecture: 3-Level Progressive Disclosure

Level 1: Quick Start (Minimal Invocation)

Single-Select Pattern:

const answer = await AskUserQuestion({
  questions: [
    {
      question: "How should we implement this?",
      header: "Approach",          // max 12 chars
      multiSelect: false,
      options: [
        {
          label: "Option 1",       // 1-5 words
          description: "What it does and why you'd pick it."
        },
        {
          label: "Option 2",
          description: "Alternative with different trade-offs."
        }
      ]
    }
  ]
});

// Returns: { "Approach": "Option 1" }

Multi-Select Pattern (independent features):

const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which features should we enable?",
      header: "Features",
      multiSelect: true,
      options: [
        { label: "Feature A", description: "..." },
        { label: "Feature B", description: "..." },
        { label: "Feature C", description: "..." }
      ]
    }
  ]
});

// Returns: { "Features": ["Feature A", "Feature C"] }

Level 2: Enterprise Patterns

Batch Questions (related decisions):

const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which database technology?",
      header: "Database",
      options: [
        { label: "PostgreSQL", description: "Relational, ACID, mature" },
        { label: "MongoDB", description: "Document, flexible schema" }
      ]
    },
    {
      question: "Cache strategy?",
      header: "Caching",
      options: [
        { label: "Redis", description: "In-memory, fast" },
        { label: "Memcached", description: "Distributed cache" }
      ]
    }
  ]
});

Conditional Flow (dependent decisions):

let questions = [
  {
    question: "What type of deployment?",
    header: "Deployment Type",
    options: [
      { label: "Docker", description: "Containerized" },
      { label: "Kubernetes", description: "Orchestrated" },
      { label: "Serverless", description: "Functions-as-a-Service" }
    ]
  }
];

const initialAnswer = await AskUserQuestion({ questions });

// Follow-up based on initial choice
if (initialAnswer["Deployment Type"] === "Kubernetes") {
  const kubeAnswer = await AskUserQuestion({
    questions: [
      {
        question: "Which cluster provider?",
        header: "K8s Provider",
        options: [
          { label: "AWS EKS", description: "Amazon Elastic Kubernetes" },
          { label: "GCP GKE", description: "Google Kubernetes Engine" },
          { label: "Self-Managed", description: "On-premises cluster" }
        ]
      }
    ]
  });
}

Level 3: Advanced (Error Handling & Validation)

Custom Input Validation ("Other" option):

const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which framework?",
      header: "Framework",
      options: [
        { label: "React", description: "UI library" },
        { label: "Vue", description: "Progressive framework" },
        { label: "Other", description: "Custom framework or library" }
      ]
    }
  ]
});

// Validate custom input
if (answer["Framework"] === "Other" || 
    !VALID_FRAMEWORKS.includes(answer["Framework"])) {
  const customAnswer = validateCustomInput(answer["Framework"]);
  if (!customAnswer) {
    // Re-ask with guidance
    return retryWithGuidance();
  }
}

Error Recovery:

try {
  const answer = await AskUserQuestion({...});
} catch (error) {
  if (error.type === "UserCancelled") {
    // User pressed ESC - use default or abort
    return fallbackToDefault();
  } else if (error.type === "InvalidInput") {
    // Validate and retry
    return retryWithValidation();
  }
}

Risky Operation Confirmation:

const answer = await AskUserQuestion({
  questions: [
    {
      question: "This will DELETE 15 branches and merge to main. Continue?",
      header: "Destructive Op",
      options: [
        {
          label: "Proceed",
          description: "Delete branches (CANNOT BE UNDONE)"
        },
        {
          label: "Dry Run",
          description: "Show what would be deleted"
        },
        {
          label: "Cancel",
          description: "Abort entire process"
        }
      ]
    }
  ]
});

if (answer["Destructive Op"] === "Proceed") {
  // Require additional final confirmation
  const final = await AskUserQuestion({
    questions: [
      {
        question: "Type DELETE to confirm irreversible action:",
        header: "Final Confirmation"
      }
    ]
  });
  
  if (final["Final Confirmation"] === "DELETE") {
    executeDeletion();
  }
}

📋 Key Constraints (TUI Optimization)

🔄 Integration with Alfred Sub-agents

🎓 Top 10 Usage Patterns

Pattern 1: Feature Type Clarification

Trigger: "Add dashboard feature" without specifics
Question: "Which dashboard type: Analytics, Admin, or Profile?"
Outcome: Narrowed scope → faster implementation

Pattern 2: Implementation Approach Selection

Trigger: Multiple valid tech choices
Question: "JWT tokens, session-based, or OAuth?"
Outcome: Locked architecture → deterministic development

Pattern 3: Risky Operation Confirmation

Trigger: Destructive action (delete, migrate, reset)
Question: "This will delete X. Proceed?" with retry confirmation
Outcome: Explicit consent + audit trail

Pattern 4: Multi-Feature Selection

Trigger: "Which features to enable?"
Question: Multi-select of independent features
Outcome: Precise feature set → no scope creep

Pattern 5: Sequential Conditional Decisions

Trigger: Dependent choices (Q2 depends on Q1)
Question: First survey → follow-up based on answer
Outcome: Progressive narrowing → precise specification

Pattern 6: Technology Stack Selection

Trigger: "Build with what stack?"
Question: Database, cache, queue, API type
Outcome: Full stack locked → team alignment

Pattern 7: Performance vs Reliability

Trigger: Trade-off between conflicting goals
Question: "Optimize for speed, reliability, or cost?"
Outcome: Explicit requirements → informed trade-offs

Pattern 8: Custom Input Handling

Trigger: "Other" option selected
Question: "Please describe..." with validation
Outcome: Unexpected inputs handled gracefully

Pattern 9: Experience Level Calibration

Trigger: Unclear target audience
Question: "Beginner, intermediate, or advanced?"
Outcome: Content adapted to expertise level

Pattern 10: Approval Workflow

Trigger: Major decision needs consensus
Question: Multi-team approval with options
Outcome: Documented decision with stakeholder buy-in

✅ Best Practices Summary

DO's

• Be specific: "Which database type?" not "What should we use?"
• Provide context: Include file names, scope, or impact
• Order logically: General → Specific; safest option first
• Flag risks: Use "NOT RECOMMENDED" or "CAUTION:" prefixes
• Explain trade-offs: Mention time, resources, complexity, performance
• Limit options: 2-4 per question (not 5+ for decision paralysis)
• Validate custom input: Check "Other" responses for validity
• Batch related Q's: Keep related decisions together (max 4 questions)

DON'Ts

• Overuse questions: Only ask when genuinely ambiguous
• Too many options: 5+ options cause decision paralysis
• Vague labels: "Option A", "Use tokens", "Option 2"
• Skip descriptions: User needs rationale for informed choice
• Hide trade-offs: Always mention implications and costs
• Ask for obvious: Single clear path = no question needed
• Recursive surveys: Avoid asking the same question twice
• Ignore language: Always match user's configured conversation_language

🔗 Related Skills

• moai-core-personas (Communication styles by user level)
• moai-core-spec-authoring (SPEC clarity & structure)
• moai-foundation-specs (SPEC format & requirements)
• moai-core-language-detection (Conversation language handling)

📚 Quick Reference Card

Token Budget Optimization

• Average per survey: 500-800 tokens
• Typical workflow: 1-2 surveys per task (1,000-1,600 tokens total)
• Benefit: Eliminates 3-5 clarification rounds (3,000-5,000 tokens saved)
• ROI: Net savings of 1,400-3,500 tokens per interaction

For detailed API specifications: reference.md
For real-world examples: examples.md
Last Updated: 2025-11-18
Status: Production Ready (Enterprise )