@vibest/cli 0.0.1-beta.12 → 0.0.1-beta.14

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

@@ -1,6 +1,6 @@
 ---
 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.
+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
@@ -12,19 +12,20 @@ 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> --access write -- '<self-contained task>'
+vibest run <harness> --title '<Title>' -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --access read --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).
-- `--access write` (the default) starts a new worktree. `--access read` stays in the project directory, read-only, with no new worktree.
+- 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.
 - 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.
@@ -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 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.
+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

@@ -1,19 +1,19 @@
 ---
 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").
+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.
+Plan → the user agrees → implement → 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.'
+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. `--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.
+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.
 
 ## 2. Agree
 
@@ -23,19 +23,18 @@ 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> --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.'
+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. That diff is for this write session, which has a worktree.
+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.
 
 ## 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.
+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.12",
+  "version": "0.0.1-beta.14",
   "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,5 @@
 #!/bin/sh
-# @vibest/cursor 0.0.1-beta.12: `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.14: `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).

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

@@ -1,6 +1,6 @@
 ---
 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.
+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
@@ -12,19 +12,20 @@ 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> --access write -- '<self-contained task>'
+vibest run <harness> --title '<Title>' -- '<self-contained task>'
 ```
 
 Its id is <id>.
 
 ```
-vibest run <harness> --access read --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).
-- `--access write` (the default) starts a new worktree. `--access read` stays in the project directory, read-only, with no new worktree.
+- 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.
 - 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.
@@ -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 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.
+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

@@ -1,19 +1,19 @@
 ---
 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").
+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.
+Plan → the user agrees → implement → 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.'
+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. `--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.
+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.
 
 ## 2. Agree
 
@@ -23,19 +23,18 @@ 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> --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.'
+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. That diff is for this write session, which has a worktree.
+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.
 
 ## 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.
+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`.