Examples

Real-world examples showing Vibe workflows from start to finish.

Example 1: Notification Settings

A complete workflow for implementing user notification settings.

Project Context

Tech Stack:

# CLAUDE.md
## Backend
- Framework: FastAPI 0.104+
- Database: PostgreSQL 17
- Cache: Redis 7.2

## Frontend
- Framework: Flutter 3.24+
- State Management: Provider

Goal: Allow users to toggle 6 notification categories to reduce churn.

Step 1: Create SPEC

vibe spec "notification settings"

6 Questions Answered:

Q1. Why?

Current: 15% weekly user churn
Problem: Excessive push notifications (avg 20/day)
Goal: Reduce churn to <10% by giving users control
ROI: Retain 5,000 users/month = $50k MRR

Q2. Who?

Primary: All users (100k DAU)
Secondary: Support team (reduced complaints)
Scale: 500k MAU, 20% MoM growth
Platform: 95% mobile, 5% web

Q3. What?

Core Features:
1. 6-category toggles:
   - Likes (default: ON)
   - Comments (default: ON)
   - Follows (default: ON)
   - Mentions (default: ON)
   - Feed updates (default: OFF)
   - Marketing (default: OFF)

2. Bulk actions:
   - Enable all
   - Disable all

Edge Cases:
- All disabled → Show warning modal
- Toggle fails → Retry 3x, show error
- New users → Auto-apply defaults

Q4. How?

Performance:
- API: P95 < 500ms
- UI toggle: < 100ms perceived latency

Scalability:
- 100k concurrent users
- 10M settings updates/day

Security:
- Rate limiting: 100 req/min per user
- JWT authentication required
- Audit log all changes

Caching:
- Redis: User settings (1h TTL)
- Invalidate on update

Q5. When?

Development: 24 hours (3 days)
- Phase 1 (Backend): 8 hours
- Phase 2 (Frontend): 8 hours
- Phase 3 (Integration): 4 hours
- Testing: 4 hours

Launch: December 1, 2025
Priority: HIGH (blocks Q4 OKR)

Q6. With What?

Backend:
- Python 3.11, FastAPI 0.104+
- PostgreSQL 17 (existing)
- Redis 7.2 (existing)

Frontend:
- Flutter 3.24+, Dart 3.5+
- Provider (existing)
- Dio (existing)

Push:
- Firebase Cloud Messaging (existing)

Infrastructure:
- GCP Cloud Run (existing)
- No new dependencies

Output:

✅ Created: .vibe/specs/notification-settings.md

Summary:
- 6 requirements
- 24 acceptance criteria
- Priority: HIGH
- Timeline: 3 days (24 hours dev)

Step 2: Generate Plan

vibe plan "notification settings"

Generated Plan Highlights:

Architecture:

Flutter App → FastAPI → PostgreSQL
                ↓
              Redis Cache
                ↓
          FCM (for push)

Database Schema:

CREATE TABLE user_notification_settings (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    likes BOOLEAN NOT NULL DEFAULT true,
    comments BOOLEAN NOT NULL DEFAULT true,
    follows BOOLEAN NOT NULL DEFAULT true,
    mentions BOOLEAN NOT NULL DEFAULT true,
    feed_updates BOOLEAN NOT NULL DEFAULT false,
    marketing BOOLEAN NOT NULL DEFAULT false,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    CONSTRAINT unique_user_settings UNIQUE(user_id)
);

CREATE INDEX idx_user_notification_settings_user_id
ON user_notification_settings(user_id);

API Endpoints:

GET    /api/v1/users/{user_id}/notification-settings
PATCH  /api/v1/users/{user_id}/notification-settings
POST   /api/v1/users/{user_id}/notification-settings/enable-all
POST   /api/v1/users/{user_id}/notification-settings/disable-all

Cost Analysis:

Infrastructure: $0/month (existing)
Redis cache: $0/month (existing capacity)
Development: 24 hours × $100/hr = $2,400
Total: $2,400 one-time

Output:

✅ Created: .vibe/plans/notification-settings.md

Summary:
- 3 Phases: Backend → Frontend → Integration
- Timeline: 24 hours
- Cost: $0/month recurring
- Stack Reuse: 100%

Step 3: Decompose Tasks

vibe tasks "notification settings"

Generated Task Breakdown:

Phase 1: Backend (8 hours)

Task 1-1: Database Migration (1h)
Task 1-2: Pydantic Schemas (0.5h)
Task 1-3: Repository Layer (1.5h)
Task 1-4: Service Layer (2h)
Task 1-5: API Endpoints (2h)
Task 1-6: Redis Caching (1h)

Phase 2: Frontend (8 hours)

Task 2-1: Data Models (0.5h)
Task 2-2: API Client (1h)
Task 2-3: Provider Setup (1h)
Task 2-4: Settings Screen UI (3h)
Task 2-5: Toggle Components (1.5h)
Task 2-6: Error Handling (1h)

Phase 3: Integration (4 hours)

Task 3-1: E2E Testing (2h)
Task 3-2: Performance Testing (1h)
Task 3-3: Documentation (1h)

Output:

✅ Created: .vibe/tasks/notification-settings.md

Task Breakdown:
- Total: 18 tasks
- Phase 1: 6 tasks (8h)
- Phase 2: 6 tasks (8h)
- Phase 3: 3 tasks (4h)
- Critical path: 16h

Step 4: Execute Backend Tasks

vibe run --phase 1

Task 1-1: Database Migration

Agent: Database PostgreSQL Expert

-- Generated migration
CREATE TABLE user_notification_settings (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    likes BOOLEAN NOT NULL DEFAULT true,
    comments BOOLEAN NOT NULL DEFAULT true,
    follows BOOLEAN NOT NULL DEFAULT true,
    mentions BOOLEAN NOT NULL DEFAULT true,
    feed_updates BOOLEAN NOT NULL DEFAULT false,
    marketing BOOLEAN NOT NULL DEFAULT false,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    CONSTRAINT unique_user_settings UNIQUE(user_id)
);

CREATE INDEX idx_user_notification_settings_user_id
ON user_notification_settings(user_id);

Verification:

✅ Migration file created
✅ All 6 columns present
✅ Defaults match SPEC
✅ Foreign key constraint added
✅ Index created

Quality Score: 95/100
Complexity: Low (CC: 1)

Task 1-2 to 1-6: (Similar execution pattern)

Repository layer with async methods
Service layer with business logic
API endpoints with FastAPI
Redis caching with 1h TTL
Unit tests with pytest

Phase 1 Result:

✅ Phase 1 completed in 7.8 hours

Files changed: 12 files
- 1 migration
- 2 schemas
- 1 repository
- 1 service
- 1 API router
- 6 test files

Code Quality: 92/100 (A-)
Test Coverage: 95%

Step 5: Execute Frontend Tasks

vibe run --phase 2

Task 2-4: Settings Screen UI

Agent: Frontend Flutter Expert

class NotificationSettingsScreen extends StatelessWidget {
  const NotificationSettingsScreen({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Notification Settings'),
      ),
      body: Consumer<NotificationSettingsProvider>(
        builder: (context, provider, child) {
          if (provider.isLoading) {
            return const Center(child: CircularProgressIndicator());
          }

          if (provider.error != null) {
            return ErrorWidget(
              error: provider.error!,
              onRetry: provider.loadSettings,
            );
          }

          return ListView(
            children: [
              SwitchListTile(
                title: const Text('Likes'),
                subtitle: const Text('When someone likes your post'),
                value: provider.settings.likes,
                onChanged: (value) => provider.updateSetting('likes', value),
              ),
              // ... other toggles
              const SizedBox(height: 24),
              Padding(
                padding: const EdgeInsets.all(16),
                child: ElevatedButton(
                  onPressed: provider.isDirty ? provider.save : null,
                  child: const Text('Save Changes'),
                ),
              ),
            ],
          );
        },
      ),
    );
  }
}

Phase 2 Result:

✅ Phase 2 completed in 8.2 hours

Files changed: 8 files
- 2 models
- 1 API client
- 1 provider
- 1 screen
- 3 widgets

Code Quality: 90/100 (A-)
Widget Tests: 89%

Step 6: Integration & Testing

vibe run --phase 3

E2E Test Scenario:

testWidgets('User can toggle notification settings', (tester) async {
  // 1. Launch app and navigate to settings
  await tester.pumpWidget(const MyApp());
  await tester.tap(find.byIcon(Icons.settings));
  await tester.pumpAndSettle();

  // 2. Toggle likes setting
  await tester.tap(find.text('Likes'));
  await tester.pumpAndSettle();

  // 3. Save changes
  await tester.tap(find.text('Save Changes'));
  await tester.pumpAndSettle();

  // 4. Verify success message
  expect(find.text('Settings saved'), findsOneWidget);

  // 5. Reload and verify persistence
  await tester.pageBack();
  await tester.tap(find.byIcon(Icons.settings));
  await tester.pumpAndSettle();

  // 6. Verify likes is OFF
  final likesSwitch = tester.widget<Switch>(find.byType(Switch).first);
  expect(likesSwitch.value, false);
});

Performance Test:

# Load test: 1000 concurrent users
wrk -t 10 -c 1000 -d 30s http://localhost:8000/api/v1/users/123/notification-settings

Results:
- P50: 45ms
- P95: 320ms ✅ (target: <500ms)
- P99: 480ms ✅
- Throughput: 2,200 req/sec

Phase 3 Result:

✅ Phase 3 completed in 3.5 hours

- E2E tests: 8 scenarios passing
- Performance: P95 320ms (target: <500ms) ✅
- Documentation: Updated API docs and README

Step 7: Final Verification

vibe verify "notification settings"

Verification Report:

📊 Verification Report: notification-settings

Requirements: 6/6 ✅
Acceptance Criteria: 24/24 ✅

✅ REQ-001: Category Toggles (4/4)
✅ REQ-002: Default Settings (6/6)
✅ REQ-003: Bulk Actions (2/2)
✅ REQ-004: Performance (3/3)
✅ REQ-005: Security (3/3)
✅ REQ-006: Caching (6/6)

Code Quality: 91/100 (A-)
- Backend: 92/100
- Frontend: 90/100
- Complexity: Good (avg CC: 4.1)
- Test Coverage: 93%

Performance: ✅ Exceeds targets
- API P95: 320ms (target: <500ms)
- UI latency: <50ms

Security: ✅ All checks passed
- Rate limiting: Enabled
- Authentication: Required
- Audit logging: Implemented

Overall: 100% complete, ready to deploy 🚀

Report: .vibe/reports/verification-2025-11-17.md

Step 8: Deploy

# Commit changes
git add .
git commit -m "feat: Add notification settings feature"
git push

# Deploy to production
gcloud run deploy api --region us-central1
flutter build web
firebase deploy --only hosting

Summary

Total Time: 19.5 hours (vs 24h estimate) ✅ Code Quality: 91/100 (A-) ✅ Test Coverage: 93% ✅ Performance: P95 320ms (target: <500ms) ✅

Files Changed:

Backend: 12 files (584 lines added)
Frontend: 8 files (423 lines added)
Tests: 14 files (892 lines added)
Total: 34 files, 1,899 lines

Business Impact:

Expected churn reduction: 15% → 10%
5,000 users retained/month
$50k MRR saved

Example 2: User Authentication

Brief example showing OAuth integration.

SPEC Summary

Why: Improve signup conversion (40% → 60%)
Who: New users (1k signups/day)
What: Social login (Google, Apple, Facebook)
How: OAuth 2.0, JWT tokens, 24h expiry
When: 2 days (16 hours dev)
With: FastAPI + Flutter + Firebase Auth

Key Tasks

Backend: OAuth endpoints (4h)
Frontend: Login buttons (2h)
Integration: Token management (2h)

Result

Signup conversion: 40% → 58% ✅
Development time: 14h vs 16h estimate
Code quality: 89/100

Example 3: Dark Mode Toggle

Quick feature implementation example.

Workflow

vibe spec "dark mode"
vibe plan "dark mode"
vibe tasks "dark mode"
vibe run --all  # Only 6 tasks, safe to run all

Implementation Highlights

Theme provider with system detection
Persistent storage (SharedPreferences)
Smooth animation transitions
4 hours total development time

Example 4: Search Feature

Complex feature with multiple components.

Tech Stack

Backend: PostgreSQL full-text search + Elasticsearch
Frontend: React with debounced input
Cache: Redis for popular queries

Phases

Phase 1 (Backend): 12 hours
- PostgreSQL GIN indexes
- Elasticsearch integration
- Redis caching layer
Phase 2 (Frontend): 8 hours
- Search input with debounce
- Results pagination
- Filter UI
Phase 3 (Optimization): 4 hours
- Query optimization
- Cache tuning
- Performance testing

Performance Results

P95 latency: 180ms (target: <200ms) ✅
Elasticsearch queries: 40ms avg
Redis cache hit rate: 78%

Example 5: API Rate Limiting

Infrastructure improvement example.

Problem

API abuse causing server overload (CPU 85% avg)

Solution

vibe spec "api rate limiting"
vibe plan "api rate limiting"
vibe tasks "api rate limiting"
vibe run --phase 1

Implementation

Redis-based rate limiter
Per-user and per-IP limits
Custom limit tiers (free/pro/enterprise)
Rate limit headers (X-RateLimit-*)

Code Example

from fastapi import Request, HTTPException
from app.core.rate_limiter import RateLimiter

limiter = RateLimiter(redis_client)

@app.get("/api/v1/users/{user_id}")
@limiter.limit("100/minute")
async def get_user(user_id: str, request: Request):
    # Check rate limit
    if not await limiter.check(request):
        raise HTTPException(status_code=429, detail="Rate limit exceeded")

    # Normal logic
    return await user_service.get_user(user_id)

Results

Server CPU: 85% → 45% avg ✅
API abuse blocked: 2.3M requests/day
False positives: <0.1%

Tips from Examples

1. Start Small, Iterate Fast

Don't run --all for complex features. Execute phase by phase.

2. Trust the Estimates

Vibe's time estimates are accurate ±10% based on complexity analysis.

3. Leverage MCP Tools

Agents automatically use tools - no manual intervention needed.

4. Document Context

CLAUDE.md ensures agents use correct tech stack and patterns.

5. Verify Before Deploy

Always run vibe verify before merging to production.

Common Patterns

Backend API Feature

vibe spec "feature" → vibe plan "feature" → vibe tasks "feature"
→ vibe run --phase 1 (Backend)
→ vibe verify "feature"
→ Deploy

Full-Stack Feature

vibe spec "feature" → vibe plan "feature" → vibe tasks "feature"
→ vibe run --phase 1 (Backend)
→ vibe run --phase 2 (Frontend)
→ vibe run --phase 3 (Integration)
→ vibe verify "feature"
→ Deploy

Quick UI Change

vibe spec "ui change" → vibe tasks "ui change"
→ vibe run --all (if <10 simple tasks)
→ vibe verify "ui change"

Next Steps:

Best Practices - Learn optimization techniques
Troubleshooting - Solve common issues
Home - Back to main page

← Back to Agents Guide | Home | Next: Best Practices →

Examples

Examples

Table of Contents

Example 1: Notification Settings

Project Context

Step 1: Create SPEC

Step 2: Generate Plan

Step 3: Decompose Tasks

Step 4: Execute Backend Tasks

Step 5: Execute Frontend Tasks

Step 6: Integration & Testing

Step 7: Final Verification

Step 8: Deploy

Summary

Example 2: User Authentication

SPEC Summary

Key Tasks

Result

Example 3: Dark Mode Toggle

Workflow

Implementation Highlights

Example 4: Search Feature

Tech Stack

Phases

Performance Results

Example 5: API Rate Limiting

Problem

Solution

Implementation

Code Example

Results

Tips from Examples

1. Start Small, Iterate Fast

2. Trust the Estimates

3. Leverage MCP Tools

4. Document Context

5. Verify Before Deploy

Common Patterns

Backend API Feature

Full-Stack Feature

Quick UI Change

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally