Rocket Blogs
Engineering
By Dhruv Gandhi
Apr 7, 2026
You already know what you're trying to figure out. Type it. Rocket handles everything after that.
Table of contents
What is the difference between Rocket's slash commands and chat for AI code generation?
How do Rocket's 80+ slash commands handle ordering and dependencies?
Can you chain slash commands together in Rocket, and how does that work?
Why does Rocket surface slash commands in a menu instead of detecting intent through chat?
How does the Redesign engine work, and what are the 8 redesign commands?
What makes a slash command pipeline fail-safe compared to a chat instruction?
This is the engineering story behind the architectural call that defines how Build works in 1.0.
What this post covers: Why Rocket built two architecturally distinct execution systems — probabilistic chat and deterministic slash command pipelines — instead of routing everything through a single prompt-interpretation loop. It explains how 80+ commands are engineered as multi-step pipelines with hard input contracts, ordered execution, per-step validation, and output guarantees, organized into a dependency taxonomy that mirrors real production architecture.
Go to any AI. Type the same operation three different ways.
1"add stripe payments to my app"
2"integrate stripe checkout"
3"implement stripe with subscription support and webhook handling"Three different outputs. Different things present, different things missing, each time.
The model isn't broken. The architecture is. For operations with known correct outputs, routing through a prompt-interpretation loop is a structural flaw — not a model quality problem. The output quality of a known operation was depending on the prompt quality of the person asking.
That's the bug we set out to fix.
We built two separate systems inside Rocket's Build layer. Not one system with two modes. Two architecturally distinct systems:
Chat handles open-ended work. Describe what you want. The model reads your project context, interprets intent, makes architectural calls, writes code. Flexible because it reasons about your intent.
Slash Commands handle known operations. A pre-engineered pipeline runs. The model doesn't interpret anything — the command already defines every step. The pipeline executes in sequence, validates each step, and produces the same output regardless of how you phrased the request.
These are not two skins on the same engine. Chat is probabilistic by nature. Commands are deterministic by design.
The decision we debated internally: we could have hidden this. Built one interface that silently detects "they're asking for payments" and routes to a pipeline under the hood. We didn't. When you select a command, you know exactly what's about to happen. Transparency over magic.
A slash command is not a prompt shortcut. A prompt shortcut still sends text to the model. The model still interprets. The output is still probabilistic.
A slash command is a multi-step execution pipeline with hard guarantees.
Here's the structure for every command:
1. Input Contract Before anything runs, the command asks only the questions the pipeline needs exact answers to. Not inferred. Asked. The pipeline needs exact inputs to produce exact output.
2. Codebase Analysis The command reads the current state of your project: what files exist, what dependencies are installed, what would be affected. It doesn't write into a project it hasn't read.
3. Ordered Execution Steps run in a defined, non-negotiable sequence. Dependencies are real. You can't generate webhook handlers before the payment form exists. You can't configure RLS before the auth tables exist.
4. Per-Step Validation Each step is verified before the next begins. If step 3 fails, step 4 doesn't start. The pipeline halts at the exact failure point and reports the specific issue.
5. Output Contract When the command completes, the codebase is in a defined, verified state. Every time. Regardless of how you triggered it.
The 80+ commands aren't a flat list. They're organized into dependency layers that mirror real production architecture:
Foundation — Authentication, Payments. Everything else may depend on user models, auth state, or payment configuration. These go first because everything downstream references them.
Connectors — Email, Forms, CMS, Analytics, Scheduling, SMS, WhatsApp, A/B Testing, AI Chatbot. These create the data flows that Quality commands need to audit.
Quality — SEO, Accessibility, Privacy & Compliance, GEO/AEO, Conversion. These audit and improve what's already built. An SEO command run before the app exists produces garbage results.
Precision — Brand & Identity, Layout & Structure, Animations & Effects, Language/i18n. These modify visual and content properties without touching the data layer. Safe to run anytime.
Recovery — Fix Layout Issues, Fix Overflow, Fix Responsive Design, Fix Visual Hierarchy, Fix Navigation, Fix Touch Interactions. Specific diagnosis, targeted correction.
Reimagine — The Redesign family. Eight commands sharing one comprehension layer. Covered in depth below.
This isn't cosmetic organization. It's a real dependency map. Run Quality before Foundation and you get audits against an incomplete product. The order exists because the engineering constraints are real.
Because every command has a defined output contract, commands can chain. Each command trusts that the previous one left the codebase in a known state.
1/Add Supabase Authentication
2→ auth in place: login UI, middleware, RLS, migrations1/Add Stripe Payments
2→ payments gated behind auth; Stripe knows the user model1/Add Transactional Email Notifications
2→ order confirmation fires after successful payment1/Improve SEO
2→ audit runs against the complete, functional application1/Implement Privacy Compliance
2→ GDPR/CCPA covers all user data the app now collectsThe privacy command at the end doesn't need to guess what user data exists. It reads the auth configuration, the payment setup, and the email configuration the previous commands established and verified.
Chat cannot do this. An instruction doesn't have an output contract. You cannot chain instructions the way you chain commands because you cannot trust what the previous instruction actually produced. This is structural — not a model quality problem. Making the model smarter doesn't give you composability.
The Redesign family is eight commands, one comprehension layer. It's the most architecturally complex part of the system.
Every redesign command starts with structural reading of the input URL. Not a screenshot. The system parses the live DOM and builds a structural intermediate representation:
This shared comprehension layer is built once. What makes each command different is its constraint set — three questions:
| Command | What stays | What changes | Diagnosis first |
|---|---|---|---|
/Reimagine Website Design | Every word | Entire visual system | None — unconditional |
/Full Website Makeover | Brand intent | Design + copy | What content actually means |
/Mobile-First Redesign | Content, features | Layout architecture | Current breakpoint behavior |
Eight commands. Eight constraint sets. One comprehension layer.
Adding a ninth command means defining a new constraint set — not rebuilding the comprehension engine.
/Redesign from Heatmap forced me to solve something no other command required: the input data itself has two opposite interpretations.
A cold zone on a heatmap means low user attention. But why it's cold has two completely different answers:
These are opposites. Acting on the heatmap data without diagnosing which interpretation is correct will either bury your CTA or give your legal disclaimer a hero section.
The fix: cross-reference heatmap data against the structural representation. A cold zone around a primary CTA (identified by semantic role) means the CTA is important but invisible. A cold zone around a legal disclaimer means users correctly ignore it.
Without this diagnosis step, the system would optimize everything for maximum attention equally. That's the wrong goal — some things should be ignored.
/Fix Visual Hierarchy took the longest to get right because it requires the system to make a judgment that human designers make intuitively: where should the eye go first, second, and never?
I decomposed "visual hierarchy" into five measurable properties:
| Property | What it measures | Why it matters |
|---|---|---|
| Type scale ratio | Size gap between headings and body | Below 1.5×, a heading doesn't register as a heading |
| Contrast delta | Color contrast vs neighbors | Highest contrast wins attention. Equal contrast = split attention |
| Whitespace isolation | Space around element vs neighbors | More space = more prominence. Tight packing = visual noise |
| Position weight | Where in the viewport | Top-left dominates in LTR layouts. Below fold = invisible |
The command computes all five for every visible element, generates a ranking, and compares it against the intended hierarchy derived from semantic roles (primary CTA > secondary CTA > nav > body > legal).
Where they diverge: the command identifies which specific property is causing the mismatch and adjusts only that. A CTA with the right color but wrong size gets enlarged. A heading with right size but insufficient contrast gets a color shift. Nothing else changes.
That's the difference between a command and a chat response. A diagnosis, then a minimal targeted correction.
There's a second reason we surface commands explicitly rather than routing through chat detection.
Type / and you see 80+ operations organized by category. You discover capabilities you'd never think to ask for in a chat box.
/Generate GEO and AEO Report — most people don't know what GEO and AEO are. They'd never type this. But when they see it in the menu under "GEO", they get curious, click it, and learn their app can be optimized for AI search engines.
/Implement Privacy Compliance — nobody wakes up thinking "let me ask the AI to make my app GDPR compliant." But seeing it in a menu makes it obvious.
In a pure chat interface, the discovery surface is limited to what users can imagine asking for. With commands, the discovery surface is the entire capability list. The menu doesn't just execute — it educates.
Type /. A menu appears. Pick a command. Answer a couple of questions if prompted. The operation runs. Your preview updates.
The codebase analysis, the ordered execution, the per-step validation, the dependency taxonomy, the constraint engine, the heatmap cross-referencing, the hierarchy computation — all invisible. All running underneath.
The engineering complexity exists so that someone building a real product can chain authentication, payments, email, SEO, and GDPR compliance onto their application — correctly, completely, consistently — by picking items from a menu.
80 commands. Each one a pipeline. Each pipeline engineered so the user never has to be.
/Fix Visual Hierarchy command adjusts only the specific property causing the mismatch./Redesign from Heatmap| Structure |
| Element positions, visual weight |
| Why zones are hot or cold |
/Fix Conversion Issues | Design system | Conversion blockers | Root cause of drop-off |
/Fix Visual Hierarchy | Content, layout | Visual weight distribution | Intended vs actual hierarchy |
/Generate Brand-Matched Page | Nothing | Everything | Design language of reference |
/Redesign Like Competitor | Your content, brand | Visual style | Their design language |
| Size vs viewport |
| Element area as % of screen |
| A CTA at 3% is invisible. At 8%, it registers instantly |