@goodtek/vibeops 0.4.0 → 1.0.0

package/templates/.vibeops/prompts/create-plan.md

@@ -1,33 +0,0 @@
----
-name: create-plan
-description: Build/refresh docs/project/{00,01,02,07} from current idea + existing docs.
-placeholders:
-  - PROJECT_NAME
-  - PROJECT_IDEA
----
-
-# Create Plan Prompt
-
----
-
-Project: `{{PROJECT_NAME}}`
-Updated idea / focus: `{{PROJECT_IDEA}}`
-
-Act as the planner agent defined in `.vibeops/agents/planner.md`.
-
-Existing `docs/project/*` files may already be present. If the files below exist, **read them and update only the deltas** (do not rewrite from scratch):
-
-- `docs/project/00-overview.md`
-- `docs/project/01-requirements.md`
-- `docs/project/02-mvp-scope.md`
-- `docs/project/07-backlog.md`
-
-The output format matches `start-project.md` — four fenced blocks, each starting with `<!-- file: <path> -->`.
-
-Also report:
-
-1. The list of sections you changed (by file, identified by H2 header).
-2. The TASK IDs added, removed, or reordered in the backlog.
-3. Up to three ambiguous points that need a user decision.
-
-Do not write code. Do not touch `docs/project/03-architecture.md` or `04-tech-stack.md`.

package/templates/.vibeops/prompts/generate-tasks.md

@@ -1,41 +0,0 @@
----
-name: generate-tasks
-description: Expand a backlog row into a full docs/tasks/TASK-NNN-*.md.
-placeholders:
-  - PROJECT_NAME
-  - BACKLOG_ITEM
-  - TASK_ID
-  - TASK_SLUG
----
-
-# Generate Task Prompt
-
----
-
-Project: `{{PROJECT_NAME}}`
-Backlog item: `{{BACKLOG_ITEM}}`
-Target TASK: `{{TASK_ID}}` slug `{{TASK_SLUG}}`
-
-Act as a "TASK author" (an offshoot of planner). Take the backlog item above and produce a single TASK file.
-
-Output is a single fenced markdown block. The first line is the comment `<!-- file: docs/tasks/{{TASK_ID}}-{{TASK_SLUG}}.md -->`.
-
-The file must include **all** of the sections below (keep the header even when the section is empty):
-
-- `Status` (planned)
-- `MVP Phase`
-- `Goal` (2 to 4 sentences)
-- `Background` (why we need this now)
-- `Scope` (bullets)
-- `Out of Scope` (bullets — explicit exclusions)
-- `Acceptance Criteria` (numbered, verifiable statements)
-- `Files to Inspect First`
-- `Expected Files to Change`
-- `Risks`
-- `Test Plan` (prefer runnable commands)
-- `Rollback Plan`
-- `Implementation Plan` (numbered)
-- `Result` — `(not yet)`
-- `Test Result` — `(not yet)`
-
-Read `docs/project/03-architecture.md`, `04-tech-stack.md`, `06-decisions.md` first so the TASK does not contradict them. Features outside the MVP go into Out of Scope as explicit rejections.

package/templates/.vibeops/prompts/implement-task.md

@@ -1,39 +0,0 @@
----
-name: implement-task
-description: Builder prompt — implement a single TASK end-to-end.
-placeholders:
-  - PROJECT_NAME
-  - TASK_ID
-  - TASK_PATH
-  - VIBEOPS_VERSION
----
-
-# Implement Task Prompt
-
----
-
-Project: `{{PROJECT_NAME}}` (VibeOps `{{VIBEOPS_VERSION}}`)
-TASK: `{{TASK_ID}}`  ·  file: `{{TASK_PATH}}`
-
-Act as the builder agent defined in `.vibeops/agents/builder.md`.
-Apply its Inputs / Output Format / Rules / Forbidden sections as-is.
-
-Read these first:
-
-- `AGENTS.md`
-- `.cursor/rules/00-project-governance.mdc` through `04-docs-update.mdc`
-- `docs/project/05-current-state.md`
-- `docs/project/06-decisions.md`
-- The relevant parts of `docs/project/03-architecture.md`, `04-tech-stack.md`
-- **The entire current TASK file**: `{{TASK_PATH}}`
-
-Procedure:
-
-1. Work only inside the TASK's Scope / Acceptance Criteria.
-2. **Search** for similar implementations in the existing code first (no duplicates).
-3. Show the list of files to change and the diff for each file as code blocks.
-4. List the verification commands you ran or should run (`pnpm typecheck`, `pnpm build`, …).
-5. Summarize Acceptance Criteria pass / fail in a small table.
-6. Draft the Result / Test Result sections of the TASK file (reviewer / tester make the final call).
-
-Do not touch other TASKs. No automatic merge or push.

package/templates/.vibeops/prompts/review-task.md

@@ -1,34 +0,0 @@
----
-name: review-task
-description: Reviewer prompt — diff vs Acceptance Criteria, find scope creep.
-placeholders:
-  - PROJECT_NAME
-  - TASK_ID
-  - TASK_PATH
-  - DIFF_BASE
----
-
-# Review Task Prompt
-
----
-
-Project: `{{PROJECT_NAME}}`
-TASK: `{{TASK_ID}}`  ·  file: `{{TASK_PATH}}`
-Diff base: `{{DIFF_BASE}}` (e.g. `main`)
-
-Act as the reviewer agent defined in `.vibeops/agents/reviewer.md`.
-Apply its Output Format / Rules / Forbidden sections as-is.
-
-Read:
-- The full TASK file.
-- `git diff {{DIFF_BASE}}..HEAD` (or the diff the user attached).
-- The relevant `.cursor/rules/*`.
-
-Evaluation steps:
-
-1. Score each Acceptance Criteria item with ✓ or ✗. Add a one-line reason for ✗.
-2. Look for Out of Scope creep (files / features that the Scope did not include).
-3. Split Suggestions into `must / should / nit`.
-4. Verdict: `pass` or `changes-requested`.
-
-No direct code edits. No new requirements (if needed, write one line: "Suggested next TASK: …").

package/templates/.vibeops/prompts/rollback.md

@@ -1,32 +0,0 @@
----
-name: rollback
-description: Recovery prompt — diagnose rollback options. Never destroy without --confirm.
-placeholders:
-  - PROJECT_NAME
-  - TASK_ID
-  - CURRENT_BRANCH
-  - BASE_BRANCH
-  - BASE_COMMIT
----
-
-# Rollback Prompt
-
----
-
-Project: `{{PROJECT_NAME}}`
-TASK in trouble: `{{TASK_ID}}`
-Current branch: `{{CURRENT_BRANCH}}`
-Base branch / commit: `{{BASE_BRANCH}}` / `{{BASE_COMMIT}}`
-
-Act as the recovery agent defined in `.vibeops/agents/recovery.md`.
-Apply its Output Format / Rules / Forbidden sections as-is.
-
-Diagnosis steps:
-
-1. Quote the user's "where it went wrong" sentence directly.
-2. Ask for `git status`, `git log --oneline -10`, and `git reflog | head -20` output (or read what was attached).
-3. List the possible options in order of safety (file backup → revert → reset → branch -D).
-4. Spell out what each option could lose.
-5. Pick one Recommended option and add a one-line reason.
-
-Never run commands directly. Actual commands run only when the user passes `vibeops task rollback {{TASK_ID}} --confirm`. Do not recommend `git push --force`.

package/templates/.vibeops/prompts/start-project.md

@@ -1,39 +0,0 @@
----
-name: start-project
-description: First-time onboarding prompt to bootstrap docs/project/* from a single idea.
-placeholders:
-  - PROJECT_NAME
-  - PROJECT_IDEA
----
-
-# Project Start Prompt
-
-Paste the text below directly into the Cursor chat.
-
----
-
-Project: `{{PROJECT_NAME}}`
-Idea: `{{PROJECT_IDEA}}`
-
-Act as the planner agent defined in `.vibeops/agents/planner.md`.
-Apply its Inputs / Output Format / Rules / Forbidden sections as-is.
-
-Goal: based on the idea above, fill in these four files.
-
-- `docs/project/00-overview.md`
-- `docs/project/01-requirements.md`
-- `docs/project/02-mvp-scope.md`
-- `docs/project/07-backlog.md`
-
-Output is four fenced markdown blocks. The first line of each block is a `<!-- file: <path> -->` comment.
-Do not touch any other files. Do not produce time or staffing estimates, and do not design the architecture.
-
-Required context to read first:
-- `AGENTS.md`
-- `.cursor/rules/00-project-governance.mdc`
-- `.cursor/rules/01-agent-orchestration.mdc`
-- `.vibeops/agents/planner.md`
-
-When you finish, report two things together:
-1. The next agent to invoke (usually `architect` → fill in `docs/project/{03,04}`).
-2. Up to three open questions that the user must decide.

package/templates/.vibeops/workflows/notion-sync.md

@@ -1,53 +0,0 @@
-# Workflow · Notion Sync
-
-Notion is the **human dashboard**. It is not the source of truth.
-
-## What is synced
-
-| Direction           | What                                                                  | Where                          |
-| ------------------- | --------------------------------------------------------------------- | ------------------------------ |
-| docs → Notion       | TASK ID, title, status, priority, branch, docs path, result summary    | Task DB                        |
-| docs → Notion       | Project name, current-state summary, next TASK ID                       | Project DB (single row by default) |
-| Notion → docs       | TASK status, priority (frontmatter)                                   | `docs/tasks/*.md` frontmatter  |
-
-## What is NOT synced
-
-- TASK bodies (Scope, Acceptance Criteria, Implementation Plan, …).
-- The bodies of `docs/project/00 ~ 07`.
-- Code changes / Git state.
-
-Details always live in the Git docs.
-
-## Setup
-
-```bash
-vibeops notion init
-# Prompts for NOTION_TOKEN. If `.vibeops.env` does not exist it asks before
-# creating one; if it exists, only the NOTION_TOKEN line is replaced safely.
-# Target IDs for the Projects / Tasks databases are not environment variables —
-# they are stored in `.vibeops.json` as `notion.projectsTargetId` /
-# `notion.tasksTargetId`.
-
-vibeops notion test
-# Validates API access + DB schemas (required properties: Name / TaskId /
-# Status / Priority / Branch / DocsPath / ResultSummary).
-```
-
-> The legacy `NOTION_API_KEY` / `NOTION_PROJECT_DB` / `NOTION_TASK_DB` environment variables are no longer used. VibeOps reads only `NOTION_TOKEN`.
-
-## Usage
-
-```bash
-vibeops notion sync             # push (idempotent)
-vibeops notion sync --dry-run   # preview
-
-vibeops task pull               # Notion → docs frontmatter
-vibeops task pull --dry-run     # preview
-```
-
-## Non-goals
-
-- Realtime webhooks.
-- Two-way body sync.
-- Child-block sync on Notion pages.
-- Creating new TASKs in Notion and pulling them into docs (that belongs to `vibeops task generate`).

package/templates/.vibeops/workflows/project-start.md

@@ -1,73 +0,0 @@
-# Workflow · Project Start
-
-The first hour of a new project.
-
-## 0. Prepare
-
-- Start in an empty directory.
-- The user has a one-to-two-paragraph **idea**.
-
-## 1. Bootstrap
-
-```bash
-vibeops init --name <project-name>
-git init && git add . && git commit -m "chore: bootstrap vibeops"
-```
-
-What gets created:
-- `AGENTS.md`, `.cursor/rules/*`, `docs/project/*`, `docs/tasks/`, `docs/logs/`
-- `.vibeops/agents/*`, `.vibeops/prompts/*`, `.vibeops/workflows/*`
-- `.vibeops.json`, `.vibeops.env.example`
-
-## 2. Plan
-
-```bash
-vibeops plan --idea "<one-paragraph idea>"
-```
-
-Paste the resulting prompt into Cursor. Cursor takes on the `planner` agent role and fills in four files.
-
-- `docs/project/00-overview.md`
-- `docs/project/01-requirements.md`
-- `docs/project/02-mvp-scope.md`
-- `docs/project/07-backlog.md`
-
-Next, invoke `architect` to fill in `03-architecture.md` and `04-tech-stack.md`.
-
-## 3. Backlog → TASKs
-
-For each backlog item:
-
-```bash
-vibeops task generate --from-backlog TASK-NNN
-```
-
-A `docs/tasks/TASK-NNN-*.md` file appears.
-
-## 4. First TASK
-
-```bash
-vibeops task start TASK-001
-vibeops task prompt TASK-001 --agent builder
-# paste into Cursor and let it work
-vibeops task check TASK-001
-vibeops task done TASK-001
-```
-
-Read the merge guidance, then merge and push manually.
-
-## 5. (Optional) Notion
-
-```bash
-vibeops notion init      # interactive .vibeops.env setup
-vibeops notion test      # validate API access and DB schemas
-vibeops notion sync      # push docs/tasks metadata to Notion
-```
-
-## 6. Daily
-
-```bash
-vibeops status           # check where you are in one second
-```
-
-Add one entry per decision or step to `docs/logs/YYYY-MM-DD.md` each day.

package/templates/.vibeops/workflows/rollback.md

@@ -1,45 +0,0 @@
-# Workflow · Rollback
-
-The standard "this TASK went wrong, let's undo it" flow.
-
-## 1. Diagnose first
-
-```bash
-vibeops task rollback TASK-NNN
-```
-
-The default is **guidance only**. It shows:
-
-- Current branch / dirty state.
-- Base branch / base commit / task branch as read from `.vibeops/state/tasks/TASK-NNN.json`.
-- Three possible strategies.
-
-## 2. Available strategies
-
-| Strategy          | Description                                                  | What you could lose                  |
-| ----------------- | ------------------------------------------------------------ | ------------------------------------ |
-| `branch-delete`   | Discard the task branch                                      | Every unmerged change on the branch  |
-| `reset-base`      | Hard-reset the current branch to the base commit              | Your current changes (stash first)   |
-| `revert-merge`    | If already merged, revert the merge commit                    | Adds a revert commit to history (OK) |
-
-## 3. Execute (destructive, `--confirm` required)
-
-```bash
-vibeops task rollback TASK-NNN --strategy branch-delete --confirm
-vibeops task rollback TASK-NNN --strategy reset-base --confirm
-vibeops task rollback TASK-NNN --strategy revert-merge --confirm
-```
-
-Combining `--dry-run` with `--confirm` prints the commands that would run without executing them.
-
-## 4. Things you never do
-
-- **`git push --force`**: never on shared branches. Even on your own task branch, do not run it unless the reason is unambiguous.
-- Automatic reflog cleanup.
-- Dropping stashes without explicit user consent.
-
-## 5. After rollback
-
-- Reset `docs/tasks/TASK-NNN-*.md` Status to `planned` or `blocked` and record the reason in Result.
-- Update `docs/project/05-current-state.md`.
-- Append a one-line entry to `docs/logs/YYYY-MM-DD.md`: "Rollback: TASK-NNN — reason".

package/templates/.vibeops/workflows/task-lifecycle.md

@@ -1,71 +0,0 @@
-# Workflow · Task Lifecycle
-
-A TASK from start to finish.
-
-## 0. Pick
-
-Run `vibeops status` to identify the next TASK. Typically run `in_progress` items before `planned` ones.
-
-## 1. Start
-
-```bash
-vibeops task start TASK-NNN
-```
-
-- A dirty working tree is refused unless changes are limited to governance docs (`docs/tasks/`, `docs/project/`, `docs/logs/`, `.vibeops/state/`); then `task start` warns and continues. Use `--allow-dirty` only when non-doc paths are dirty intentionally.
-- Records base branch / base commit / task branch in `.vibeops/state/tasks/TASK-NNN.json`.
-- Creates and checks out the `task/NNN-<slug>` branch.
-- Sets the TASK file's Status to `in_progress`.
-
-## 2. Prompt
-
-```bash
-vibeops task prompt TASK-NNN --agent builder
-```
-
-Paste the single markdown output directly into the Cursor chat. Cursor takes on the builder agent role.
-
-Other agents work the same way:
-- `--agent reviewer` — review the diff.
-- `--agent tester` — run the Test Plan.
-- `--agent docs` — update the three docs.
-
-## 3. Check
-
-```bash
-vibeops task check TASK-NNN
-```
-
-- Score Acceptance Criteria items with ✓ / ✗.
-- Match `Expected Files to Change` against actual changes.
-- Summarize current branch / dirty / commit count.
-
-## 4. Done
-
-```bash
-vibeops task done TASK-NNN
-```
-
-- Validates the TASK file's Status, Result, Test Result bodies.
-- Records `doneAt` in `.vibeops/state/tasks/TASK-NNN.json`.
-- Prints **merge guidance** (no automatic merge).
-
-A human merges:
-
-```bash
-git switch main
-git merge --ff-only task/NNN-<slug>
-git branch -d task/NNN-<slug>
-```
-
-## 5. (Optional) Notion sync
-
-```bash
-vibeops notion sync
-```
-
-Pushes TASK metadata (summary, status, priority, branch, docs path, result summary) to Notion.
-
-## When things go wrong: Rollback
-
-See [`rollback.md`](rollback.md).

package/templates/docs/project/00-overview.md

@@ -1,27 +0,0 @@
-# 00 — Overview
-
-> This document is the slot that `vibeops plan` (via the `planner` agent) fills in. Keep the section headers below and leave the bodies empty.
-
-## One-line definition
-
-<!-- One sentence describing what this project is — who it is for and what the tool/service does. -->
-
-## Problem to solve
-
-<!-- 3 to 5 bullets. Stay fact-based about current pain points. -->
-
-## Example usage
-
-<!-- A 6-to-10-line scenario showing how a single hypothetical user flows through the product. -->
-
-## Core roles
-
-<!-- 4 to 8 things this product "does", one per line. Each line starts with a verb. -->
-
-## Vocabulary
-
-<!-- 5 to 10 terms that mean something specific in this project. Disambiguate synonyms. -->
-
-## Non-goals (out of scope, forever)
-
-<!-- Things this project intentionally does not do. Different from "out of MVP scope" — that lives in 02-mvp-scope.md. -->

package/templates/docs/project/01-requirements.md

@@ -1,30 +0,0 @@
-# 01 — Requirements
-
-> Filled in by the `planner` agent.
-
-## Functional requirements
-
-<!--
-Numbered. Each line reads "the system does …".
-F-001. Users can ...
-F-002. The system ...
--->
-
-## Non-functional requirements
-
-<!--
-Performance / reliability / security / operations / compatibility.
-NF-001. No command may corrupt user data ...
--->
-
-## Users / stakeholders
-
-<!-- Who uses the product, who cares about it. By role. -->
-
-## Constraints
-
-<!-- Technical, schedule, budget, regulatory — anything imposed from outside. -->
-
-## Assumptions
-
-<!-- The "let's assume this is true" list. Items that would be risky if they break. -->

package/templates/docs/project/02-mvp-scope.md

@@ -1,36 +0,0 @@
-# 02 — MVP Scope
-
-> Filled in by the `planner` agent. Keep it small.
-
-## MVP in one sentence
-
-<!-- A single line: "Within two weeks, who can do what." -->
-
-## In scope
-
-<!--
-The 5 to 10 capabilities the MVP must have.
-- IN: sign-up and single sign-on
-- IN: ...
--->
-
-## Intentionally out for MVP
-
-<!--
-Things that may ship later but not in the MVP.
-- OUT: multiple workspaces
-- OUT: payment UI
-The clearer this is, the smaller the backlog gets.
--->
-
-## Definition of done
-
-<!--
-- Which scenarios run end-to-end.
-- Which data flows are preserved.
-- Which error situations are tolerated.
--->
-
-## How to validate
-
-<!-- How a real person confirms "the MVP is ready". One demo scenario. -->

package/templates/docs/project/04-tech-stack.md

@@ -1,29 +0,0 @@
-# 04 — Tech Stack
-
-> Filled in by the `architect` agent. Add a one-line "why" to each choice.
-
-## Runtime / language
-
-<!-- Node.js / Python / Go, etc. Version. The reason behind the choice. -->
-
-## Frameworks / libraries
-
-<!--
-| Area    | Choice             | Why                                            |
-| ------- | ------------------ | ---------------------------------------------- |
-| Server  | ...                | ...                                            |
-| ORM     | ...                | ...                                            |
-| Tests   | vitest             | TS-friendly, fast                              |
--->
-
-## Infrastructure
-
-<!-- Where the system runs, how it is deployed (high level). Detailed commands live in 09-deployment.md. -->
-
-## Package manager / build
-
-<!-- pnpm / npm / yarn, tsc / esbuild / vite, etc. Whether there is a single entry point. -->
-
-## Explicit non-adoptions
-
-<!-- Things we deliberately do not use, and why. -->

package/templates/docs/project/07-backlog.md

@@ -1,23 +0,0 @@
-# 07 — Backlog
-
-TASK order. Work top to bottom. Do not skip to the next item before the current TASK is done.
-
-> Slot to be filled by the `planner` agent.
-
-## MVP 1
-
-| ID       | Title                               | Status  |
-| -------- | ----------------------------------- | ------- |
-| TASK-001 | <first TASK title>                  | planned |
-
-## MVP 2 (later)
-
-<!-- Slot. -->
-
-## Later (out of MVP, but live candidates)
-
-<!-- Items to revisit after MVP. Do not turn them into TASKs right away. -->
-
-## Non-goals
-
-Follow the "Non-goals" section in `docs/project/00-overview.md`. The backlog only grows inside those bounds.

package/templates/docs/project/08-env.md

@@ -1,29 +0,0 @@
-# 08 — Environment
-
-Environment variables used by this project and what they mean.
-
-## Local development
-
-Copy `.vibeops.env.example` to `.vibeops.env` and fill in the values. Never commit `.vibeops.env` — it is listed in `.gitignore`.
-
-| Variable        | Purpose                                                          | Required        |
-| --------------- | ---------------------------------------------------------------- | --------------- |
-| `NOTION_TOKEN`  | Notion internal integration secret (the only secret VibeOps reads) | If using Notion |
-
-`NOTION_TOKEN` is the only secret VibeOps reads from the environment. Notion **Projects / Tasks DB target IDs** are not environment variables — they live in `.vibeops.json` as `notion.projectsTargetId` / `notion.tasksTargetId`, and `vibeops notion init` writes them. GitHub auth is owned by `gh auth`, so there is no need to put `GITHUB_TOKEN` here.
-
-> The legacy `NOTION_API_KEY` / `NOTION_PROJECT_DB` / `NOTION_TASK_DB` environment variables are no longer used. VibeOps ignores them if they remain in an existing `.vibeops.env`. It is safe to remove them by hand.
-
-<!--
-Add project-specific environment variables here once they exist.
-Examples: DATABASE_URL, OAUTH_CLIENT_ID, ...
--->
-
-## Staging / production
-
-<!-- Slot. -->
-
-## Secret management
-
-- `.vibeops.env` is a plain-text local file. Production secrets belong in a real secret manager.
-- No VibeOps command prints secret values to stdout in the clear (they are masked).

package/templates/docs/project/09-deployment.md

@@ -1,28 +0,0 @@
-# 09 — Deployment
-
-How the project is deployed and run.
-
-## Local run
-
-<!-- The single-command dev-server flow (e.g. `pnpm dev`). -->
-
-## Build
-
-<!-- Where build artifacts live and which command produces them. -->
-
-## Packaging / release
-
-<!--
-Steps per target environment.
-- npm publish?
-- Docker image?
-- Cloud (Vercel / Fly / AWS / GCP / ...) ?
--->
-
-## Environment separation
-
-<!-- Differences between dev / staging / prod. Same code with different env? Same image? -->
-
-## Rollback
-
-<!-- The standard rollback flow when a deployment goes wrong. -->