- 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.
Voir sur GitHub