|
| 1 | +--- |
| 2 | +name: myvibe |
| 3 | +description: 'Use this skill when the user gives a one-line command to start a new project, such as "build me a kanban board", "scaffold a SaaS dashboard", "make a portfolio site", "create an inventory tracker", "vibe code", or "use myVibe". Runs a one-shot intake that collects every project decision in a single round, then plans, scaffolds, builds, tests, and ships a complete localhost-running project. Do not trigger for edits to existing projects, single-file requests, bug fixes, or pure questions — this skill is for new project creation only.' |
| 4 | +license: MIT |
| 5 | +compatibility: 'Cross-platform. Works on Windows, macOS, and Linux. No runtime dependencies beyond the toolchain the chosen stack needs.' |
| 6 | +metadata: |
| 7 | + version: "1.0" |
| 8 | + enhancements: |
| 9 | + - One-shot intake collects every decision upfront in a single round |
| 10 | + - Ralph-style feature loop with spec, failing test, implement, retry-with-budget |
| 11 | + - Binary quality gate (lint, types, tests, build all green or not done) |
| 12 | + - Localhost-first by design — deployment is explicitly out of scope |
| 13 | + - Vendor-neutral protocol that works across Copilot, Claude Code, Codex CLI, Cursor, Windsurf |
| 14 | +--- |
| 15 | + |
| 16 | +# myVibe |
| 17 | + |
| 18 | +A deterministic operating system for shipping professional software projects from a single one-line command. Vendor-neutral: the same protocol works the same way on any coding agent. |
| 19 | + |
| 20 | +## When to invoke this skill |
| 21 | + |
| 22 | +The user gives a one-line project command. Examples: |
| 23 | + |
| 24 | +- "Build me a kanban board with drag-and-drop" |
| 25 | +- "Make a SaaS billing dashboard" |
| 26 | +- "Scaffold an inventory tracker" |
| 27 | +- "Create a portfolio site with scroll animations" |
| 28 | +- "I want a meal-planner app" |
| 29 | +- "Use myVibe to build X" |
| 30 | + |
| 31 | +Do **not** invoke for: edits to existing projects, single-file requests, debugging existing code, or pure Q&A. This skill is for new project creation end-to-end. |
| 32 | + |
| 33 | +## The protocol |
| 34 | + |
| 35 | +The kit lives at `https://github.com/Mohamed201389/myVibe`. After install, the kit folder is on disk and the agent follows files in this order. |
| 36 | + |
| 37 | +### Step 1 — Intake (ONE round) |
| 38 | + |
| 39 | +1. Read `INTAKE.md` in the kit folder. |
| 40 | +2. Fill the 18-section intake form with sensible defaults derived from the user's one-line command. |
| 41 | +3. Send the filled form to the user in a single message; ask them to override any line or reply "go". |
| 42 | +4. After "go", write the final form to `INTAKE.md` at the new project root and commit it as `chore: lock project intake`. |
| 43 | +5. Do not ask further questions until the project is shipped. If something is ambiguous mid-build, pick a sensible default and note it in `CHANGELOG.md`. |
| 44 | + |
| 45 | +### Step 2 — Orchestrate |
| 46 | + |
| 47 | +Read `00-START-HERE.md` and follow Phases 2 through 7 in order. At each phase boundary, re-read the relevant per-stage file: |
| 48 | + |
| 49 | +- `01-plan.md` for planning |
| 50 | +- `03-scaffolding.md` for stack and bootstrap |
| 51 | +- `05-frontend.md` / `06-backend.md` / `07-database.md` for the foundation |
| 52 | +- `04-features.md` for each feature spec |
| 53 | +- `08-testing.md` for test strategy |
| 54 | +- `09-checkpoint.md` at every checkpoint |
| 55 | +- `10-changelog.md` for changelog discipline |
| 56 | +- `11-localhost.md` for env, ports, dev DX |
| 57 | +- `12-code-style.md` for code quality |
| 58 | +- `13-debugging.md` when something breaks |
| 59 | +- `14-quality-gates.md` before declaring done |
| 60 | + |
| 61 | +### Step 3 — Ralph-style feature loop |
| 62 | + |
| 63 | +For each feature in `PLAN.md`, run the tight inner loop from Phase 5 of `00-START-HERE.md`: spec → failing test → implement → run → on-fail debug-and-retry → on-pass checkpoint → next feature. Maximum 3 retry passes before escalating to the user. |
| 64 | + |
| 65 | +### Step 4 — Quality gate |
| 66 | + |
| 67 | +Before claiming done, every check in `14-quality-gates.md` must pass. If any fails, fix and re-run. |
| 68 | + |
| 69 | +## Rules of engagement |
| 70 | + |
| 71 | +- **Localhost-first.** No deployment, no cloud, no production paths in v1. |
| 72 | +- **Latest stable library versions.** No "for compatibility" downgrades. |
| 73 | +- **One feature at a time.** No parallel half-builds. |
| 74 | +- **No emojis** in code, commits, or terminal-facing docs. |
| 75 | +- **Read before edit.** Never modify a file you have not read in the current session. |
| 76 | +- **Specific over clever.** Prefer explicit, boring code that a junior can read at 2 a.m. |
| 77 | + |
| 78 | +## What this skill addresses |
| 79 | + |
| 80 | +Frontier models can write code well but freelance when given vague briefs: they pick random stacks, skip tests, ask interrogation questions mid-build, and stop halfway. myVibe replaces freestyle with a deterministic intake-plan-build-test-ship loop that closes those gaps without limiting model creativity inside each phase. |
| 81 | + |
| 82 | +## Compatibility |
| 83 | + |
| 84 | +The same protocol is published in three vendor-specific files so any agent that reads its own configuration picks it up automatically: |
| 85 | + |
| 86 | +- GitHub Copilot reads `.github/copilot-instructions.md` |
| 87 | +- Claude Code reads `CLAUDE.md` or `~/.claude/skills/myvibe/SKILL.md` |
| 88 | +- Codex CLI, Cursor, Windsurf, Aider read `AGENTS.md` |
| 89 | + |
| 90 | +Source repo: https://github.com/Mohamed201389/myVibe (MIT, no telemetry). |
0 commit comments