steroid-vibe-capture

Files (1)

• SKILL.md

SKILL.md (first lines)

# Steroid Vibe Capture

This skill captures a non-technical user's intent and translates it into a structured vibe profile.

## When To Use

Activate when the user says words like "build", "create", "design", or "make" in the context of generating a new feature or project. Do not wait for explicit skill invocation.

## Instructions

### 1. Adaptive Communication (v5.5.0)

Read the user's initial prompt and detect their technical level:

- **Non-technical signals**: words like "vibe", "feel", "clean", "like Apple", colors, aesthetics
- **Technical signals**: words like "Next.js", "API", "database", "deploy", "TypeScript", framework names

Adapt your language accordingly:
- **Non-technical user**: Never mention databases, frameworks, deployment, or APIs. Speak in terms of aesthetics, flows, and features.
- **Technical user**: You may discuss architecture, stack preferences, and deployment — they expect it.

### 2. Pre-Vibe Discussion (v5.5.0)

Do NOT immediately lock the vibe. Have a brief conversation first:

**For non-technical users**, ask up to 2 questions about:
- Visual style or aesthetic inspiration (e.g., "Should it feel like Apple Health or more like Notion?")
- Core user flow (e.g., "What's the main thing someone does when they open it?")

**For technical users**, ask up to 3 questions about:
- Architecture constraints (e.g., "Any specific framework or stack requirements?")
- Scale and deployment (e.g., "MVP or production-grade? Where will this be hosted?")
- Integration points (e.g., "Any existing APIs, databases, or services to connect to?")

**For ALL users**, determine:
- **Greenfield or Brownfield?** — Is this a new project from scratch, or are we adding to an existing codebase? If the working directory already has a `package.json`, `requirements.txt`, or similar, assume Brownfield unless told otherwise.
- **GitHub?** — If the user hasn't mentioned where to save the code, ask one friendly question: *"Do you have a GitHub repository for this, or should I just save it locally for now?"*

ONLY after the user confirms (or if the prompt was detailed enough to skip questions), proceed to lock the vibe.

If the prompt is rich and detailed enough to answer everything, ask zero questions.

### 2b. Prompt Quality Check (v5.1.0)

After capturing the initial vibe, assess completeness. If ANY of these are unclear from the user's prompt, fill in sensible defaults and document them in vibe.md:

| Question | Why It Matters | Default If Missing |
|----------|---------------|--------------------|
| Who is this for? | Determines UI complexity, accessibility needs | "General audience" |
| What's the ONE thing it must do well? | Focuses the spec, prevents scope creep | First feature mentioned |
| Any tech preferences? | Prevents wrong framework choice | "No preference — AI decides" |
| Any existing services to integrate? | Surfaces auth, API, DB needs early | "None — standalone app" |
| What's the scale? MVP or full product? | Sets scope boundaries | "MVP — launch fast" |

Add a `## Assumptions` section to vibe.md listing any defaults used:
```markdown
## Assumptions (filled by AI — user did not specify)
- Target audience: General public
- Scale: MVP
- Tech preference: None
```

This guides non-technical users without requiring them to understand development.

### 2c. Remote Repo Check (v5.3.0)

If the user's prompt doesn't mention GitHub, version control, or saving to the cloud, add to the Assumptions section:

```markdown
- Remote repository: None specified — code saved locally only
```

If the user mentions GitHub or provides a repo URL, note it:
```markdown
- Remote repository: https://github.com/user/repo
```

This determines whether CI/CD and deployment steps are generated later in the pipeline.

### 3. Anti-Summarization Directive

NEVER summarize the user's intent with "..." or leave fields blank. NEVER use placeholder text like "[to be determined]". Extract a full, cohesive vision from even the vaguest prompt. If unsure, make a reasonable creative decision and document it.

NEVER summarize existing code. If instructed to reproduce or fork a file, reproduce it line-by-line. Writing "...rest of the code here..." is a critical failure.

**Constraint Preservation (v5.5.0):** If the user's prompt contains specific directives (e.g., "do NOT use a database", "must use Framer Motion", "the hero text must say exactly..."), these MUST be captured in the `Hard Constraints & Directives` field. Dropping user constraints to make the vibe profile shorter is a critical failure.

### 4. Feature Slug Extraction

Extract a short, URL-safe slug from the user's prompt for the feature folder name.

Examples:
- "Build me a habit tracker" → `habit-tracker`
- "Create a minimal to-do app like Notion" → `todo-app`
- "Design a dashboard for my crypto portfolio" → `crypto-dashboard`

### 5. Physical Folder Creation

Once the slug is determined, begin the feature using the higher-level steroid-run entrypoint:

```
node steroid-run.cjs start <slug>
```

This is NOT optional. The command validates the slug format, creates `.memory/changes/<slug>/`, and bootstraps the first scan receipts. If the name is invalid, the command will block you with an error.

### 5b. Prompt Intelligence Receipt (v6.2.0)

If you are intentionally using the lower-level flow instead of `start`, immediately after `init-feature`, persist the normalized prompt interpretation:

```bash
node steroid-run.cjs normalize-prompt "<original user prompt>" --feature <slug> --write
```

This writes `.memory/changes/<slug>/prompt.json` and `.memory/changes/<slug>/prompt.md`. Treat `prompt.json` as the machine-readable source of truth and `prompt.md` as the readable handoff brief for:
- primary and secondary intents
- ambiguity and complexity
- continuation state
- assumptions and non-goals

From nzkbuild/steroid-workflow, MIT.

More from nzkbuild/steroid-workflow