npx pulse-cc install@latest

Works on Mac, Windows, and Linux.

Why I Built This

I wanted to build a complete SaaS while I sleep.

Not a toy. Not a prototype. Production-ready code that actually works when I wake up.

So I'd tell Claude to build 5 features before bed. Every morning, same story: "Done!" it says. I check — half broken. Button doesn't click. API returns 500s. Styling is a mess. The authentication "works" except it doesn't actually authenticate anyone.

Claude doesn't verify. It just says it's done and moves on.

I'm a solo developer. I don't have a QA team. I don't have code reviewers. I have Claude and 8 hours of sleep I'd like to get.

So I built PULSE.

Now I write my features, run /pulse:execute, and go to bed. PULSE handles the rest:

• Worker implements the feature
• Independent verifier checks if it actually works (fresh context, zero assumptions)
• Failed? Automatic retry with a smarter model
• Still failing? Blocks and waits for me instead of shipping broken code

I wake up to features that actually work. Not "done" — verified done.

That's the difference.

The Problem

You tell Claude to build features. It says "Done!" after each one.

You trust it. Why wouldn't you?

Then you check:

Feature 1: Login form ............... "Done!" ... button submits to nowhere
Feature 2: Dashboard ................ "Done!" ... crashes on load
Feature 3: Payment integration ...... "Done!" ... charges $0.00 every time
Feature 4: Email notifications ...... "Done!" ... sends to [email protected]
Feature 5: User settings ............ "Done!" ... saves nothing

Claude marks tasks complete the moment it writes code — not when the code works.

It's not lying. It genuinely believes it's done. But believing and being are different things.

You wanted autonomous coding. You got autonomous claiming.

The Solution

PULSE splits every feature into two independent agents that don't trust each other:

┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                             │
│   WORKER                           VERIFIER                                 │
│   "I built it"          →          "Prove it"                               │
│                                                                             │
│   • Implements feature             • Fresh context (zero knowledge)         │
│   • Writes code                    • Reads requirements only                │
│   • Creates documentation          • Tests actual functionality             │
│   • Says "done"                    • Says "actually done" or "try again"    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

The verifier has zero knowledge of what the worker did. No shared context. No assumptions. No "looks good to me."

It reads the requirements. It checks the actual code. It runs real tests.

If verification fails → automatic retry with smarter model → repeat until it actually works.

100% Native Claude Code Skills

PULSE isn't a wrapper. It's not a separate tool. Everything is a Claude Code skill.

~/.claude/skills/
├── pulse-execute/SKILL.md           # Orchestrator
├── pulse-engine-worker-sonnet/      # Worker (Sonnet)
├── pulse-engine-worker-opus/        # Worker (Opus)
├── pulse-engine-verifier-sonnet/    # Verifier (Sonnet)
├── pulse-engine-verifier-opus/      # Verifier (Opus)
├── pulse-status/                    # Status checker
├── pulse-project-init/              # Project setup
└── ... 10+ more skills

Why this matters:

No Python scripts. No Docker containers. No separate processes to manage. No API keys to configure. PULSE runs inside Claude Code using the same skill system you already have.

Forked Contexts = True Independence

Here's the magic: worker and verifier engines run in completely separate, forked contexts.

┌─────────────────────────────────────────────────────────────────────────────┐
│  YOUR MAIN CLAUDE CODE SESSION                                              │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │  /pulse:execute                                                       │  │
│  │       │                                                               │  │
│  │       ├──► FORK ──► Worker Context (isolated)                         │  │
│  │       │              • Implements feature                             │  │
│  │       │              • Writes to disk                                 │  │
│  │       │              • Context DISCARDED after                        │  │
│  │       │                                                               │  │
│  │       └──► FORK ──► Verifier Context (isolated)                       │  │
│  │                      • Fresh start, zero knowledge                    │  │
│  │                      • Reads only requirements + code                 │  │
│  │                      • Context DISCARDED after                        │  │
│  │                                                                       │  │
│  │  Main context stays CLEAN                                             │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

Your main conversation never gets polluted.

Worker does its thing → context thrown away. Verifier does its thing → context thrown away. State persists through files in .pulse/, not conversation history.

This is why PULSE can run 20 features without context rot. Each engine gets a fresh start. Your main session stays lean.

Why Forked Skills Beat In-Context Agents

| In-Context Agents | PULSE Forked Skills | |-------------------|---------------------| | Worker and verifier share context | Completely isolated contexts | | Verifier sees worker's reasoning | Verifier sees only requirements | | Context grows with each feature | Context resets each feature | | 5 features = context overflow | 50 features = still clean | | Confirmation bias built-in | Independence by architecture |

The verifier literally cannot be biased by the worker's implementation. They never meet.

Set It and Forget It

This is what autonomous coding should be:

# 1. Write your features in plain English
/pulse:execute

# 2. Go to sleep

# 3. Wake up to this:

═══════════════════════════════════════════════════════════════════════════════
  PULSE Execution Complete
═══════════════════════════════════════════════════════════════════════════════

  ┌────┬─────────────────────────────────┬────────────┬──────────────────────┐
  │ #  │ Feature                         │ Status     │ Attempts             │
  ├────┼─────────────────────────────────┼────────────┼──────────────────────┤
  │ 1  │ user-authentication             │ ✓ Verified │ 1                    │
  │ 2  │ stripe-payment-integration      │ ✓ Verified │ 3 (auto-escalated)   │
  │ 3  │ email-notification-system       │ ✓ Verified │ 1                    │
  │ 4  │ admin-dashboard                 │ ✓ Verified │ 2 (1 retry)          │
  │ 5  │ user-settings-page              │ ✓ Verified │ 1                    │
  └────┴─────────────────────────────────┴────────────┴──────────────────────┘

  Total: 5 features │ Verified: 5 │ Production Ready: YES

═══════════════════════════════════════════════════════════════════════════════

Feature 2 failed twice. PULSE automatically escalated to a smarter model, retried, and kept going until it actually worked.

You didn't lift a finger. You were asleep.

Smart Model Escalation

Start cheap. Escalate only when needed.

Attempt 1: Sonnet (fast, $0.003/1K tokens)
     │
     ↓ verification failed
     │
Attempt 2: Opus (smarter, catches edge cases)
     │
     ↓ verification failed
     │
Attempt 3: Opus (final try with learned context)
     │
     ↓ verification failed
     │
BLOCKED → You decide what to do (not broken code shipped silently)

Easy features stay cheap. Hard features get the firepower they need.

{
  "models": {
    "default": "sonnet",
    "retry": "opus",
    "retry_after_attempts": 1
  },
  "settings": {
    "max_retries_per_feature": 3
  }
}

Most features pass on first try with Sonnet. The tricky ones automatically get Opus. You save money without sacrificing quality.

How It Actually Works

1. Initialize (30 seconds)

/pulse:project-init

Creates .pulse/ folder with your project config.

2. Add Features (your way)

Quick mode — just edit .pulse/feature_updater.md:

## New Features
- Add user authentication with OAuth
- Create Stripe payment integration
- Build admin dashboard with analytics
- Implement email notification system

Research mode — full competitor analysis and planning:

/pulse:plan-and-research-saas

3. Execute (then walk away)

/pulse:execute

PULSE takes over:

For each feature:
  │
  ├── Worker implements (creates PLAN.md, writes code, SUMMARY.md)
  │
  ├── Verifier validates (fresh context, tests functionality)
  │
  ├── PASSED? → Next feature
  │
  └── FAILED? → Retry with smarter model → Loop until verified

4. Come Back to Working Code

Every feature gets:

• PLAN.md — What the worker planned to do
• SUMMARY.md — What was actually done
• VERIFICATION.md — Proof it works

.pulse/features/
├── 001-user-authentication/
│   ├── PLAN.md
│   ├── SUMMARY.md
│   └── VERIFICATION.md ← "Tested login flow: PASSED"
├── 002-stripe-integration/
│   ├── PLAN.md
│   ├── SUMMARY.md
│   └── VERIFICATION.md ← "Tested $10 charge: PASSED"

Documentation and verification built-in. Not afterthoughts.

The 5 Files That Control Everything

After /pulse:project-init, your .pulse/ folder has 5 key files. Edit these, run commands, PULSE does the rest.

1. CONFIG.json — The Brain

Controls how PULSE behaves. Edit once, forget about it.

{
  "project_name": "my-saas",
  "description": "AI-powered analytics dashboard",

  "settings": {
    "auto_commit": true,
    "max_retries_per_feature": 3,
    "skip_on_max_retries": false
  },

  "models": {
    "default": "sonnet",
    "retry": "opus",
    "retry_after_attempts": 1
  },

  "verification": {
    "project_type": "browser",
    "base_url": "http://localhost:3000",
    "start_command": "npm run dev"
  }
}

| Setting | What It Does | When to Change | |---------|--------------|----------------| | max_retries_per_feature | Attempts before blocking | Increase for complex projects | | models.default | First-try model | Set to opus if budget allows | | models.retry | Retry model | Keep as opus for hard problems | | verification.project_type | browser/api/cli/manual | Match your project type |

Note: When project_type is "browser", PULSE uses Playwright MCP to automate real browser testing — clicking buttons, submitting forms, navigating pages, and verifying UI state. This is how the verifier confirms your web app actually works.

You probably don't need to touch this after initial setup.

2. PROJECT.md — The Intelligence

This is what the worker reads before every feature. The more you fill in, the smarter PULSE gets.

# My SaaS

> AI-powered analytics dashboard for startups

## Tech Stack
- Next.js 14 (App Router)
- PostgreSQL + Prisma
- Clerk Auth
- Tailwind CSS + shadcn/ui

## Commands

| Command | When | Required |
|---------|------|----------|
| `npm run lint` | After code changes | Yes |
| `npm run build` | Before verification | Yes |
| `npm test` | After implementation | No |

## Patterns to Follow
- All API routes in `app/api/`
- Use server actions for mutations
- Zod validation on all inputs

## Gotchas
- Clerk middleware must wrap all auth routes
- Prisma client singleton in `lib/db.ts`

## Do NOT
- Use `any` type
- Skip error handling
- Commit .env files

This is your project's instruction manual for AI. The worker reads it before every feature. Better PROJECT.md = better code.

3. feature_updater.md — The Quick Input

The fastest way to add features. Write what you want, PULSE figures out the rest.

# Feature Update Request

## New Features
- Add dark mode toggle to settings page
- Create Stripe checkout flow for pro plan
- Build team invitation system with email notifications
- Add usage analytics dashboard with charts

## What's Broken
- Login button doesn't redirect after auth
- Dashboard crashes when no data exists

## What's Missing
- Password reset flow
- Mobile responsive nav

## Priority Changes
- Stripe integration is critical, move to phase 1

## Remove Features
- Remove feature 12 (no longer needed)

Run: /pulse:features-from-file

PULSE will:

1. Parse your natural language
2. Auto-assign IDs, phases, priorities
3. Update PULSE_FEATURES.json
4. Archive this file
5. Reset to empty template

You never touch JSON directly. Just write what you want.

4. plan_and_research_saas_updater.md — The Full Planning Input

For when you want PULSE to research competitors, analyze the market, and create a comprehensive plan.

# My SaaS Project

A B2B analytics platform that helps startups track user engagement.

## Tech Stack
- Framework: Next.js 14
- Database: PostgreSQL + Prisma
- Auth: Clerk
- Styling: Tailwind CSS + shadcn/ui
- Payments: Stripe

## Project References
- https://github.com/vercel/next.js/tree/canary/examples/with-stripe
- https://github.com/shadcn-ui/ui

## Web References
- https://stripe.com/docs/billing/subscriptions
- https://clerk.com/docs/nextjs/get-started

## Notes
- Must support team workspaces
- Need usage-based billing
- Real-time dashboard updates required

Run: /pulse:plan-and-research-saas

PULSE will:

1. Research competitors via web search
2. Fetch and analyze your references
3. Ask clarifying questions
4. Generate detailed PLAN.md, ACTION_ITEMS.md, and PULSE_FEATURES.json
5. Archive this file

Use this for greenfield projects or major new phases.

5. feedback_updater.md — Live Steering

Inject feedback while PULSE is running. The worker checks this before each feature.

# Feedback for PULSE Worker

## For Current Feature
Use the existing Button component from ui/button, don't create a new one

## For Specific Feature
Feature 5 (stripe-integration): Use the new Stripe Payment Element, not legacy Checkout

## General Guidance
Always add loading states to buttons
Use optimistic updates for better UX

## Stop/Change Direction
STOP working on feature 8, requirements changed - will update later

The worker reads this, applies feedback, then archives it. You can steer without interrupting.

The Workflow

┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                             │
│   1. EDIT FILES                        2. RUN COMMAND                       │
│                                                                             │
│   ┌─────────────────────────┐          ┌─────────────────────────┐          │
│   │ feature_updater.md      │    →     │ /pulse:features-from-file│          │
│   │ "Add login page"        │          │ /pulse:execute          │          │
│   └─────────────────────────┘          └─────────────────────────┘          │
│                                                  │                          │
│   ┌─────────────────────────┐                    │                          │
│   │ plan_and_research_      │    →     ┌────────▼────────┐                  │
│   │ saas_updater.md         │          │ PULSE works     │                  │
│   │ (full planning)         │          │ autonomously    │                  │
│   └─────────────────────────┘          └────────┬────────┘                  │
│                                                  │                          │
│   ┌─────────────────────────┐                    │                          │
│   │ feedback_updater.md     │    →     ┌────────▼────────┐                  │
│   │ (live steering)         │          │ 3. VERIFIED     │                  │
│   └─────────────────────────┘          │    CODE         │                  │
│                                        └─────────────────┘                  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

That's it. Edit markdown files. Run commands. Get verified code.

Why Worker + Verifier Beats Everything Else

| Traditional AI Coding | PULSE | |----------------------|-------| | Claude implements and self-reports "done" | Worker implements, Verifier independently validates | | No verification — just vibes | Checks actual code execution | | Bugs ship while you sleep | Bugs caught before marked complete | | You wake up to debug | You wake up to deploy | | "Works on my context" | Works in production | | Manual retry when things break | Automatic retry with model escalation | | Context bloats with each feature | Forked skills = fresh context every time | | Worker and verifier share memory | Complete isolation by architecture |

The verifier starts completely fresh. No knowledge of implementation. No confirmation bias. No "well I wrote it so it probably works."

It reads what the feature should do. It checks if it actually does it. It doesn't care about the worker's feelings.

Production-Ready Guarantees

PULSE doesn't ship broken code. Here's what "verified" actually means:

| Guarantee | How | |-----------|-----| | Code compiles | Build commands from PROJECT.md run successfully | | Tests pass | Test commands from PROJECT.md complete without errors | | Feature works | Verifier tests actual functionality against requirements | | No regressions | Full project validation, not just new code | | Documentation exists | PLAN.md, SUMMARY.md, VERIFICATION.md for every feature | | Audit trail | Know exactly what was done, when, and how many attempts |

If it says "verified" — it works. If it can't verify — it doesn't pretend.

Commands

| Command | What It Does | |---------|--------------| | /pulse:execute | Run all features autonomously (this is the magic) | | /pulse:status | Check progress, see what's verified | | /pulse:project-init | Initialize .pulse/ folder | | /pulse:features-from-file | Import from feature_updater.md | | /pulse:features-unblock | Handle blocked features (complete/skip/retry) | | /pulse:plan-and-research-saas | Full planning with research | | /pulse:settings | Configure models and behavior | | /pulse:help | Show all commands |

Quick Start

# Install PULSE (one command)
npx pulse-cc install@latest

# In Claude Code, initialize your project
/pulse:project-init

# Add features to .pulse/feature_updater.md
## New Features
- User authentication with OAuth
- Payment processing with Stripe
- Admin dashboard

# Run and walk away
/pulse:execute

# Come back to verified, production-ready features

The Philosophy

I don't want to manage AI. I want AI to ship features while I do other things.

But "autonomous" doesn't mean "unsupervised chaos." It means systematic, verified, production-ready output.

PULSE is opinionated:

• Verify everything — No feature is "done" until independently confirmed
• Fail loudly — If something can't be verified, block instead of pretending
• Escalate intelligently — Use cheap models first, expensive models when needed
• Document automatically — Every decision, every verification, every attempt
• Respect sleep — The whole point is you shouldn't need to babysit
• Stay native — 100% Claude Code skills, no external dependencies, no separate processes
• Isolate contexts — Forked skills keep your main conversation clean forever

If you want to vibecode and hope for the best, there are other tools.

If you want to build a SaaS while you sleep, there's PULSE.

Install

npx pulse-cc install@latest

Works on Mac, Windows, Linux. Requires Claude Code and Node.js 18+.

CLI Reference

pulse-cc install     # Install to ~/.claude/
pulse-cc update      # Update PULSE files
pulse-cc uninstall   # Remove PULSE
pulse-cc version     # Show version
pulse-cc help        # Show help

FAQ

Q: What if a feature keeps failing verification?

After max_retries_per_feature attempts (default: 3), PULSE blocks and waits. Run /pulse:features-unblock to:

• Mark complete (if you fixed manually)
• Skip (move to next feature)
• Retry (fresh attempts)

It will never mark something verified that isn't.

Q: Can I use only the expensive model?

Yes. Set both default and retry to "opus" in CONFIG.json. Verification quality is the same either way.

Q: Does it work with existing projects?

Yes. Run /pulse:project-init in any project. Fill out PROJECT.md with your build/test commands. PULSE adapts.

Q: What if I need to intervene?

Check /pulse:status anytime. Use /pulse:features-unblock for blocked features. Full control when you want it, full autonomy when you don't.

Q: Is this just fancy task management?

No. The magic is independent verification. Other tools track tasks. PULSE verifies outcomes. The worker/verifier split is why this works.

Q: Why native Claude Code skills instead of external scripts?

No dependencies. No API keys. No separate processes. PULSE runs entirely inside Claude Code using the same skill system you already have. Install once, works everywhere.

Q: How does context isolation actually work?

Worker and verifier run as forked skills — completely separate Claude contexts. The worker implements and its context is discarded. The verifier starts fresh, reads only requirements and actual code, then its context is discarded too. Your main session never bloats. State persists through .pulse/ files, not conversation history. This is why PULSE can run 50 features without context rot.

Requirements

• Claude Code CLI
• Node.js 18+
• Playwright MCP — Required for browser-based verification. PULSE uses Playwright heavily to test web applications by automating real browser interactions (clicking buttons, filling forms, checking UI state). Install via: npx @anthropic-ai/claude-code mcp add playwright -- npx @anthropic-ai/mcp-playwright
• Features you want built while you sleep

License

MIT