@vibest/cli 0.0.1-beta.13 → 0.0.1-beta.15

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

@@ -12,18 +12,19 @@ You direct subagents. You stay with the user. Each result arrives in your inbox
 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> -- '<self-contained task>'
+vibest run <harness> --title '<Title>' -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --archive-on-completion -- '<task>'
+vibest run <harness> --title '<Title>' --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.
+`--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. Any turn that ends normally archives it, a question included, so do not use it for a session that may need an answer. A `failed` result has not archived it: send the correction 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).
+- Always pass `--title`: three to six words, verb first, first letter capitalised, no kebab-case, saying what is done rather than how ("Fix login redirect loop"). The user's language is fine.
 - Each session gets its own 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.
@@ -36,10 +37,11 @@ Tell the user in one or two lines what is running, then end your turn. Never gue
 
 ## Check the result
 
-An `<agent-result>` is a claim. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
+An `<agent-result>` is a claim. Its `<status>` is only whether the turn ended normally (`completed`) or with an error (`failed`); whether the work succeeded is in the `<result>` text. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
 
-- `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.
+- The result asks a question → `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</status>`, a result that reports a failure, 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.
+- A result or notice that says the turn ended without a report, was interrupted in its pane, or did not start (`task_not_started`) carries no screen text. When you need to see why, run `vibest peek <id>` (`--lines N`, default 30): it prints the session's terminal as it is now. Read it before you decide to resend, correct, 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.
 

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

@@ -10,7 +10,7 @@ Plan → the user agrees → implement → review until the reviewer approves
 ## 1. Plan
 
 ```
-vibest run <harness> -- '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.'
+vibest run <harness> --title 'Plan <topic>' -- '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. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
@@ -23,7 +23,7 @@ Show the plan in full, including open questions. Do not implement until the user
 
 ```
 vibest project write scratch pipeline-<topic>-plan.md --if-version new -- '<the agreed plan, verbatim>'
-vibest run <harness> -- '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.'
+vibest run <harness> --title 'Implement <topic>' -- '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.
@@ -34,7 +34,7 @@ Its id is <implementer id>. The absolute path is `scratchPath` from `vibest proj
 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.
 
 ```
-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.'
+vibest run <harness> --title 'Review <topic>' --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`.

package/harnesses/cursor/.cursor-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "vibest",
-  "version": "0.0.1-beta.13",
+  "version": "0.0.1-beta.15",
   "description": "vibest's Cursor CLI plugin: a session's turn-end result and the tool guard, loaded with `cursor-agent --plugin-dir`."
 }

package/harnesses/cursor/hooks/vibest.sh

@@ -1,5 +1,26 @@
 #!/bin/sh
-# @vibest/cursor 0.0.1-beta.13: `vibest integration guard` before a tool call, `vibest integration prompt` when the user submits, `vibest integration stop` at a turn end.
+# @vibest/cursor 0.0.1-beta.15: `vibest integration guard` before a tool call, `vibest integration prompt` when the user submits, `vibest integration stop` at a turn end.
+# The vibest vibestd started this agent with (VIBEST_COMMAND, a JSON argv), not the first vibest on PATH. A value this
+# cannot read safely (not a JSON array of plain strings: a backslash in it) falls back to PATH.
+vibest() {
+  case "${VIBEST_COMMAND:-}" in
+    *'\'*) ;;
+    '["'*'"]')
+      words=$(printf '%s' "$VIBEST_COMMAND" | sed -e 's/^\["//' -e 's/"\]$//' -e 's/","/\
+/g')
+      ifs=$IFS
+      IFS='
+'
+      set -f
+      set -- $words "$@"
+      IFS=$ifs
+      set +f
+      "$@"
+      return
+      ;;
+  esac
+  command vibest "$@"
+}
 case "${1:-}" in
   guard)
     # preToolUse runs fail-closed, where no answer refuses: outside vibest, allow (it grants no approval).

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

@@ -12,18 +12,19 @@ You direct subagents. You stay with the user. Each result arrives in your inbox
 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> -- '<self-contained task>'
+vibest run <harness> --title '<Title>' -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --archive-on-completion -- '<task>'
+vibest run <harness> --title '<Title>' --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.
+`--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. Any turn that ends normally archives it, a question included, so do not use it for a session that may need an answer. A `failed` result has not archived it: send the correction 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).
+- Always pass `--title`: three to six words, verb first, first letter capitalised, no kebab-case, saying what is done rather than how ("Fix login redirect loop"). The user's language is fine.
 - Each session gets its own 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.
@@ -36,10 +37,11 @@ Tell the user in one or two lines what is running, then end your turn. Never gue
 
 ## Check the result
 
-An `<agent-result>` is a claim. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
+An `<agent-result>` is a claim. Its `<status>` is only whether the turn ended normally (`completed`) or with an error (`failed`); whether the work succeeded is in the `<result>` text. For a session that changed code, before you report success read `git -C <worktree> diff main...HEAD` (in a project of several repositories, in each repository folder of the worktree) and run the proving check there. For research, judge the report text.
 
-- `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.
+- The result asks a question → `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</status>`, a result that reports a failure, 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.
+- A result or notice that says the turn ended without a report, was interrupted in its pane, or did not start (`task_not_started`) carries no screen text. When you need to see why, run `vibest peek <id>` (`--lines N`, default 30): it prints the session's terminal as it is now. Read it before you decide to resend, correct, 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.
 

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

@@ -10,7 +10,7 @@ Plan → the user agrees → implement → review until the reviewer approves
 ## 1. Plan
 
 ```
-vibest run <harness> -- '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.'
+vibest run <harness> --title 'Plan <topic>' -- '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. Do not pass `--archive-on-completion`: the user has not agreed yet, and a completed result would archive the session before they can answer.
@@ -23,7 +23,7 @@ Show the plan in full, including open questions. Do not implement until the user
 
 ```
 vibest project write scratch pipeline-<topic>-plan.md --if-version new -- '<the agreed plan, verbatim>'
-vibest run <harness> -- '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.'
+vibest run <harness> --title 'Implement <topic>' -- '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.
@@ -34,7 +34,7 @@ Its id is <implementer id>. The absolute path is `scratchPath` from `vibest proj
 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.
 
 ```
-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.'
+vibest run <harness> --title 'Review <topic>' --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`.