Skip to main content

vibe-coding

Manage the full lifecycle of a Vibe Coding project — create, refine, brainstorm, initialize, plan, implement, review, test, deploy, update, and fix issues. Use when the user wants to start a new project from a prompt, evolve its requirements, plan or write code, validate or deploy it, or apply updates and bug fixes against an existing project.

Source facts

Repository
X-School-Academy/skill-pilot
Last source activity
May 29, 2026 at 03:57
Detected SKILL.md language
English
Stars
20
Forks
13

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
15 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
vibe-coding
description
Manage the full lifecycle of a Vibe Coding project — create, refine, brainstorm, initialize, plan, implement, review, test, deploy, update, and fix issues. Use when the user wants to start a new project from a prompt, evolve its requirements, plan or write code, validate or deploy it, or apply updates and bug fixes against an existing project.
# Vibe Coding Skill Drives every stage of a Vibe Coding project. Stage details live in `references/`. This file defines layout, lifecycle rules, and stage dispatch. ## Roles Project Manager · Technical Writer · Backend Developer · DevOps Engineer · Code Reviewer · QA Engineer · Creative Strategist Apply only the roles relevant to the chosen stage. Announce actions before performing them: `As a {Role}, I will {action}.` ## Project Boundary Stay inside `workspace/vibe-coding/{project-name}/` unless the user explicitly asks otherwise. ## Project Layout ``` workspace/vibe-coding/{project-name}/ ├── README.md # overview and usage guide ├── CHANGELOG.md # change log per update/fix cycle ├── AGENTS.md # AI-agent instructions for this project ├── requirements.md # living — scope and intent ├── plan.md # living — current implementation plan ├── implementation.md # living — current implementation summary ├── deployment.md # living — deployment record ├── initialized.md # write-once — init completed mark ├── design-archive/ # timestamped snapshots, created only when needed └── (project source code) ``` `create` bootstraps the project folder, root design docs, and top-level files. It does not create `design-archive/`; archive stages create it when needed. `deploy` creates `assets/` when missing. ## File Lifecycle Rules **Living docs** (overwrite in place, always current): `requirements.md`, `plan.md`, `implementation.md`, `deployment.md`. Refresh after any stage that changes scope, plan, or code. **Top-level files** (maintain throughout lifecycle): - `README.md` — update when purpose, usage, or setup changes - `CHANGELOG.md` — append an entry each update/fix cycle - `AGENTS.md` — update when AI-agent notes change **Plan archiving** — before writing a new `plan.md`, archive the old one: ```bash timestamp=$(date +"%Y-%m-%d-%H%M") mkdir -p design-archive mv plan.md "design-archive/plan.$timestamp.md" ``` **Intermediates** — archive after consumption using `{basename}.{YYYY-MM-DD-HHMM}.md`: - `brainstorm.md`, `update.md`, `issues.md`, `reviewed.md`, `tested.md` `initialized.md` is write-once — never refresh it. ## Default Flows **New project:** `create → refine → initialize → plan → implement → test → review → deploy` **Update/fix:** `update/fix → refine → plan → implement → test → review → deploy` The `update/fix` stage only sets up the trigger doc. `plan` and `implement` then run the same as in the new project flow, but automatically read the trigger doc for context. | Stage | Purpose | |-------|---------| | create | Create project folder, `requirements.md`, and top-level stubs | | refine | Resolve ambiguities only; keep original meaning | | initialize | Init git repo for a new project | | plan | Archive old `plan.md`; write new plan | | implement | Write code; update `implementation.md` | | test | Test → fix → retest until all requirements pass | | review | Review for cleanliness/correctness; fix all issues found | | deploy | Deploy; update `deployment.md` and `README.md` | ## agent-workflow Context When invoked inside an `agent-workflow`, call the `agent-workflow` skill's **continue-workflow** action immediately after each stage completes. ## Stage Dispatch | Intent | Reference | |--------|-----------| | Start a new project | `references/create.md` | | Clarify requirements | `references/refine.md` | | Brainstorm ideas | `references/brainstorm.md` | | Apply brainstorm to requirements | `references/apply-brainstorm.md` | | Initialize new project repo | `references/initial.md` | | Create a dev plan | `references/plan.md` | | Implement from plan | `references/implement.md` | | Review for defects | `references/review.md` | | Test the implementation | `references/test.md` | | Deploy the project | `references/deploy.md` | | Apply `update.md` changes | `references/update.md` | | Fix issues from `issues.md` | `references/fix-issues.md` | If the intent matches multiple stages, ask before acting. ## Instructions 1. **Identify the project** — confirm `workspace/vibe-coding/{project-name}/`; if new, dispatch to `create`. 2. **Identify the stage** — map the request to one dispatch entry; announce role(s) and stage. 3. **Read the reference** — follow `references/{stage}.md`. 4. **Apply lifecycle rules** — archive intermediates, refresh living docs, never rewrite `initialized.md`. 5. **Report** — state what ran, which files changed, and what comes next. ## Key Principles - **Single source of truth**: living docs always reflect current state. - **Archive before overwrite**: never lose intermediate content. - **Boundary discipline**: stay in the project folder. - **One stage per turn**: run multiple stages in sequence if asked. - **Refresh after change**: always update living docs before reporting done.
View on GitHub