Build This Now
Build This Now
Get started

The pipeline

From idea to productResearch your marketSet up your environmentGenerate your specsBuild your features

What you get

DatabaseAuthenticationPaymentsEmailStorageCron jobsCaptchaCreditsDesign systemFrontend architectureBackend architectureAnalyticsReal-time

The AI system

OrchestrationThe agentsAgent teamsLearningPatterns

Design & brand

Generate your logoDesign your landing pageSet up your email domain

Grow your product

Add a new featureImprove a featureSettings page

Content & growth

BlogEmail sequencesSEOAI search optimization

Keep it solid

Security auditPenetration testingPerformance checkCodebase healthDrift detectionError monitoringFix production errorsAutomated monitoringSelf-healingRate limiting

Customize

CustomizeDesignBuildSecurityPerformanceBrainstorm

Reference

AdvancedStructureComponentsAll commandsTech stack

Self-healing

Your app fixes itself overnight and asks permission before merging.

The loop that closes itself

You run /security and it finds an RLS gap. You run /sentry and it catches a null reference in production. You run /performance and it flags an N+1 query. Good. But those are reports. Reports sit in a folder until you do something about them.

Inside Claude Code, type /heal. It reads every report sitting in your dev/reports/ directory, picks out the critical and high-severity findings, and fixes them. On a branch. Not on main. It will never push code to production without your say-so.

How it works

Heal creates a heal/ branch, then works through the issue queue one group at a time. A missing RLS policy goes to the database agent. A broken API procedure goes to the backend agent. A rendering bug goes to the designer. Each fix gets its own commit so you can cherry-pick or revert individual changes.

After the fixes, it runs every quality gate: type checking, linting, a full build. Then it runs your E2E test suite. Then it re-runs the original detector that found each issue to confirm the fix actually worked.

Confidence scoring

Not all fixes are equal. Heal calculates a score out of 100 based on what happened during the run. Tests passing, gates green, verified fixes, small diff: high score. Test regressions, unverified fixes, large diff: low score.

You get an email with a subject line that tells you what to do without opening it. "Heal: 3 issues fixed, safe to merge (95/100)." Or "Heal: fixes failed, do not merge (35/100)."

The branch sits there. You review the diff, check the confidence breakdown, and merge or discard.

What it won't do

Heal won't commit to main. It won't force-push. It won't auto-merge. It won't fix low-severity issues unless you explicitly ask. If it can't fix something without a workaround, it marks it as deferred and tells you why. A bad fix is worse than no fix.

If a test that passed before now fails after the fix, it doesn't try to "fix" the test. It records the regression and deducts confidence. That's your signal to look closer.

The overnight loop

Set up /monitor and heal runs on a schedule. Your detection commands fire in the morning. Heal runs in the evening, reads everything they found, and fixes what it can. You wake up to an email: here's what was broken, here's the branch that fixes it, here's the confidence score. Merge it or don't.

/heal              # fix critical + high from all reports
/heal --dry-run    # show what would be fixed, don't touch code
/heal --type sentry,security   # only process specific report types

Automated monitoring

Recurring checks that run on a schedule without you thinking about it.

Rate limiting

Production-grade rate limiting so your API doesn't get abused.

On this page

The loop that closes itselfHow it worksConfidence scoringWhat it won't doThe overnight loop