Vibe Coder

Expert vibe-coding workflow for building apps, tools, and scripts from scratch based on plain-English descriptions. Use when a user asks to build something —...

Security Scan

The skill is an instruction-only

Purpose & Capability

Name/description (building apps from plain-English specs) aligns with the SKILL.md instructions. The skill does not request unrelated binaries, credentials, or config paths.

Instruction Scope

Runtime instructions are limited to a six-phase human-centered coding workflow (clarifying questions, planning, iterative build, error handling, delivery). They don't instruct the agent to read system files, access secrets, or transmit data to external endpoints.

Install Mechanism

No install spec and no code files present. Nothing will be written to disk or downloaded by the skill itself during install.

Credentials

The skill declares no required environment variables, credentials, or config paths; the instructions do not reference any undeclared secrets.

Persistence & Privilege

always is false and there is no request to modify other skills or system-wide settings. Autonomous invocation remains the platform default but is not elevated by this skill.

Assessment

This is an instruction-only skill that tells the agent how to run a structured, interactive build workflow — it does not itself install code or ask for credentials. Before you run or execute any code the agent generates: review the produced files, inspect dependencies (package.json, Pipfile, etc.), check for hard-coded secrets, and run the code in a sandboxed environment. If you want the agent to integrate with an existing repo or run commands on your machine, explicitly provide the repository or a safe execution plan; do not assume the skill will by itself access external systems. Overall the skill appears coherent and safe, but generated code can still contain insecure patterns or unsafe dependencies, so treat outputs as untrusted until reviewed and tested.

Build anything from a plain-English description. Six phases. No silent failures.

Phase 1 — Understand the Brief

Before writing a single line of code:

• Restate the core idea back to the user in 2-3 sentences
• Confirm: core features, tech stack (propose one if not specified), UI/UX expectations
• Ask any clarifying questions needed — but batch them, don't ask one at a time
• Do not proceed to Phase 2 until the user confirms understanding

Questions to consider:

• What platform? (web, CLI, desktop, mobile, API)
• Any existing codebase to integrate with, or greenfield?
• Key constraints? (language, dependencies, hosting, runtime)
• Who's the user? (just them, a team, public)

Phase 2 — Plan the Build

Break into exactly 5 phases:

1. Structure — project scaffold, file layout, dependencies
2. Functionality — core logic, data flow, business rules
3. UI Polish — interface, UX, error states, edge cases
4. Testing — happy path, edge cases, error scenarios
5. Final Review — cleanup, docs, delivery packaging

Present the plan with bullet points under each phase. Get explicit approval before starting Phase 3.

Phase 3 — Build Phase by Phase

For each phase:

1. Announce what you're about to build before writing code
2. Write clean, commented code
3. Explain each major section in plain English (1-2 sentences max per section)
4. After each phase, ask: "Does this look right? Anything to change before I move on?"
5. Incorporate feedback before proceeding

Never skip a phase. Never start the next phase without confirmation.

Phase 4 — Error Handling

If you hit a bug or blocker:

• Describe the problem in plain English (no jargon dumps)
• Propose exactly two fixes with trade-offs
• Ask which to try
• Never get stuck silently — if you don't know the fix, say so and propose a research step

Phase 5 — Iterate

After each phase, active feedback loop:

• "Here's what was built. Here's what's next."
• Incorporate changes immediately — don't defer
• If scope expands mid-build, flag it explicitly: "This adds scope. Want to include it or keep to the original plan?"

Phase 6 — Final Delivery

Deliver:

1. Working product — all files, runnable as described
2. Build summary — what was built, key decisions made, anything deferred
3. Usage instructions — how to run it, configure it, and extend it

Format the summary as:

## What Was Built
[2-3 sentences]

## Key Decisions
- [decision + rationale]

## How to Run
[commands]

## Known Limitations / Next Steps
- [if any]

General Rules

• Plain English first, code second — always explain before or alongside
• Never present code without context
• Short explanations beat long ones — if a section needs a paragraph, the code is probably too complex
• If uncertain about user intent, ask — don't assume and build the wrong thing
• Prefer working simple over impressive broken