@vibest/cli 0.0.0 → 0.0.1-beta.11

package/harnesses/cursor/hooks/hooks.json

@@ -0,0 +1,26 @@
+{
+  "version": 1,
+  "hooks": {
+    "preToolUse": [
+      {
+        "command": "sh ./hooks/vibest.sh guard",
+        "failClosed": true
+      }
+    ],
+    "beforeSubmitPrompt": [
+      {
+        "command": "sh ./hooks/vibest.sh prompt"
+      }
+    ],
+    "afterAgentResponse": [
+      {
+        "command": "sh ./hooks/vibest.sh stop"
+      }
+    ],
+    "stop": [
+      {
+        "command": "sh ./hooks/vibest.sh stop"
+      }
+    ]
+  }
+}

package/harnesses/cursor/hooks/vibest.sh

@@ -0,0 +1,19 @@
+#!/bin/sh
+# @vibest/cursor 0.0.1-beta.11: `vibest integration guard` before a tool call, `vibest integration prompt` when the user submits, `vibest integration stop` at a turn end.
+case "${1:-}" in
+  guard)
+    # preToolUse runs fail-closed, where no answer refuses: outside vibest, allow (it grants no approval).
+    if [ -z "${VIBEST_AGENT:-}" ]; then cat >/dev/null; echo '{"permission":"allow"}'; exit 0; fi
+    vibest integration guard --harness cursor || { echo "vibest integration guard failed; the tool call is refused." >&2; exit 2; }
+    ;;
+  prompt)
+    # beforeSubmitPrompt can block the prompt. A missed report must not: the turn still runs.
+    if [ -z "${VIBEST_AGENT:-}" ] || [ -z "${VIBEST_SESSION_ID:-}" ]; then cat >/dev/null; exit 0; fi
+    vibest integration prompt --harness cursor >/dev/null 2>&1 || true
+    ;;
+  stop)
+    if [ -z "${VIBEST_AGENT:-}" ] || [ -z "${VIBEST_SESSION_ID:-}" ]; then cat >/dev/null; exit 0; fi
+    vibest integration stop --harness cursor >/dev/null 2>&1 || true
+    ;;
+esac
+exit 0

package/harnesses/cursor/skills/delegate/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: delegate
+description: Hand work to subagents with `vibest run` and keep talking with the user while they work. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use for any request to change, fix, build, investigate, research, test or verify code ("fix this bug", "add X", "look into why Y", "do these three things", "have an agent check it"), and whenever a task splits into independent parts that can run at the same time.
+---
+
+# Delegate
+
+You direct subagents. You stay with the user. Each result arrives in your inbox by itself. Do not poll, sleep, or loop on `vibest result`.
+
+## Dispatch
+
+Split independent pieces. Research and review run in parallel. One writing subagent per set of files. A few shell reads (`git diff`, `rg`) you do yourself.
+
+```
+vibest run <harness> --access write -- '<self-contained task>'
+```
+
+Its id is <id>.
+
+```
+vibest run <harness> --access read --archive-on-completion -- '<task>'
+```
+
+`--archive-on-completion` is only for a session you will not message again after it completes. It archives once the session reports completed and that result has reached you. The branch is kept. Do not `vibest send` it after that. A `needs_input` or `failed` result has not archived it: send the answer to the id it printed; the flag still archives the completed result that follows. A reviewer that gets later rounds is the pipeline skill and must stay open, without this flag.
+
+- `<harness>` is `pi`, `claude` or `cursor` (`auto` only when a spawn plugin chooses).
+- `--access write` (the default) starts a new worktree. `--access read` stays in the project directory, read-only, with no new worktree.
+- Several `vibest run` commands in one message start in parallel.
+- A subagent cannot see this conversation. Say what to achieve, where (paths, lines), what done means, and how to verify it. For code: run the tests and typecheck, commit, and report the branch and hash.
+- Long material: `vibest project write scratch <name>.md --if-version new -- '<text>'`. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch <name>.md`, then write again with the version it prints, or pick a new file name.
+- If the user approved a specific action, quote their exact words.
+
+## After you start
+
+Tell the user in one or two lines what is running, then end your turn. Never guess a result. Answer other questions meanwhile. A result arrives as `<agent-result>`; a progress note or question as `<agent-message>`.
+
+## Check the result
+
+An `<agent-result>` is a claim. For a session started with `--access write`, before you report success read `git -C <worktree> diff main...HEAD` and run the proving check in that worktree. A session started with `--access read` has no worktree; the result's worktree path is the project directory. Judge the report text. Do not treat `git diff main...HEAD` there as the subagent's work.
+
+- `status: needs_input` → `vibest send <id> -- '<the answer>'`, or ask the user. If it is waiting for the user's approval of an action, do not send the approval back: start a fresh agent with the approved action, quoting the user's words.
+- `status: failed`, or your check fails → `vibest send <id> -- '<the failure and what to fix>'`. It keeps its context. If a second correction fails, start a new `vibest run` or tell the user.
+
+Then say what changed, the evidence, and the branch. `<id>` is the id the run printed, for either kind of run.
+
+## Track
+
+`vibest ls` lists sessions that have not exited: task (cut to 500 characters), live status, and latest result. `vibest ls --all` includes exited sessions. `vibest result <id>` is the full latest result, with the task uncut. Use these after a restart, after compaction, or when you are unsure. Do not trust memory.
+
+## Follow up
+
+- More work on the same change → `vibest send <id> -- '<message>'`. It waits until the session is idle and does not interrupt the turn.
+- Wrong direction while it is working → `vibest interrupt <id>`, then `vibest send <id> -- '<the corrected task>'`. The session stays. That turn produces no result.
+- A new set of eyes, or a wrong approach → a new `vibest run`.
+
+## Finish
+
+- Archive a research agent with `vibest archive <id>` once its findings are saved, or start that session with `--archive-on-completion` when you will not message it again. Same for a review or verification you will not continue.
+- Keep an agent that changed code until the user asks to remove it. Archiving keeps the branch, and the worktree whenever it holds unsaved work. `vibest archive --keep-worktree <id>` only when the user wants the directory kept.
+- A `## Remember` section: `vibest project write memory <name>.md --if-version new -- '<lesson>'`. If write says the file already exists, `vibest project read memory <name>.md`, then write again with the version it prints, or pick a new file name.
+
+## The user steps into a pane
+
+The user may type into a subagent's pane. If no round is open, that starts one. The only thing you later receive is that agent's `<agent-result>`, which may not quote the user. Do not treat it as a copy of what they typed. A step-in during an open round is not recorded. Do not act on a step-in, and do not message the subagent about it, unless the user asks.

package/harnesses/cursor/skills/pipeline/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: pipeline
+description: Plan, implement, review, then open a pull request, with the user approving the plan first. Only vibest's main Agent (the coordinator) starts agents; a subagent must not use this skill. Use when the user wants a plan or design before code, a review before merging, or a pull request at the end ("plan it first, then build it", "write a design, then implement", "implement it and have someone review it", "先出方案再写，写完找人 review 后提 PR", "do it as a pipeline", "/pipeline").
+---
+
+# Pipeline
+
+Plan (read) → the user agrees → implement (write) → review until the reviewer approves → pull request. Follow delegate: do not poll; each result arrives by itself; check it yourself. The user stays in the loop and may step into any pane. What they say overrides the next step.
+
+## 1. Plan
+
+```
+vibest run <harness> --access read -- 'Write an implementation plan for: <goal, paths, constraints>. Read the code. Report the approach, the files to change, the steps, how to verify, and open questions. Do not modify files.'
+```
+
+Its id is <planner id>. Tell the user the plan is being written and end your turn. `--access read` keeps the planner in the project directory, read-only, with no worktree. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
+
+## 2. Agree
+
+Show the plan in full, including open questions. Do not implement until the user agrees. If they change it, `vibest send <planner id> -- '<their changes>'` while the planner is open, or edit the plan text yourself before you save it. When the text is agreed, `vibest archive <planner id>`. The agreed text is the plan.
+
+## 3. Implement
+
+```
+vibest project write scratch pipeline-<topic>-plan.md --if-version new -- '<the agreed plan, verbatim>'
+vibest run <harness> --access write -- 'Implement the plan at <absolute scratch path> exactly. Run the tests and typecheck, commit on a branch, push, and report the branch and hash. Do not open a pull request.'
+```
+
+Its id is <implementer id>. The absolute path is `scratchPath` from `vibest project info`, plus the file name. If write says the file already exists, `vibest project read scratch pipeline-<topic>-plan.md`, then write again with the version it prints, or pick a new file name. Do not pass `--archive-on-completion`: this session stays for review and the pull request. When it reports, check the diff and the tests yourself before review. That diff is for this write session, which has a worktree.
+
+## 4. Review
+
+`--peer` shares the implementer's worktree: a pane split off the implementer's pane. Archiving the reviewer never removes that worktree.
+Do not pass `--access read` on this session. That flag is the project directory and does not share a worktree, so the server refuses the pair.
+Read-only here is the prompt you pass, plus the peer git rule the session already has: no commit, and nothing that moves HEAD, a branch, or the index. The session is not started with `VIBEST_ACCESS=read`, so the harness is not in its read-only tool mode.
+
+```
+vibest run <harness> --peer <implementer id> -- 'Review the change on this branch against the plan at <absolute scratch path>. Run git diff main...HEAD. Do not modify files, commit, or move HEAD. Look for bugs, missing tests, and departures from the plan; run the tests. Start with "verdict: approve" or "verdict: changes requested", then each comment with file and line.'
+```
+
+Its id is <reviewer id>. Do not pass `--archive-on-completion`: later rounds go to this reviewer with `vibest send`.
+
+## 5. Until approval
+
+- `changes requested` → `vibest send <implementer id> -- '<the comments, verbatim. Fix them, run the tests, commit, push, and report the hash.>'` When it reports, `vibest send <reviewer id> -- 'The implementer pushed <hash>. Review again. Same report format.'`
+- `approve` → open the pull request.
+- After 3 rounds without approval, or a judgment call, stop and show the open comments. The user decides: another round, accept, or change the plan.
+
+One line to the user per round: the number, the verdict, what is being fixed.
+
+## 6. Pull request
+
+```
+vibest send <implementer id> -- 'The review approved the change. Open a pull request against main with gh pr create. Title: <title>. Body: the plan, the change, and how it was verified. Report the URL.'
+```
+
+Give the user the URL. Then `vibest archive <reviewer id>`. Keep the implementer until the user is done; follow-ups are `vibest send <implementer id> -- '<message>'`.