@su-record/vibe 4.1.20 → 4.1.22

package/skills/vibe-build/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe-build
-description: Build — implement approved scenarios one at a time; after each one, `vibe check <id>` lets the harness judge. Never say "done".
+description: For a `size: full` task only — parallel worktrees, irreversible scenarios, a failed scenario's `vibe context`. A `size: small` task needs no skill — build everything, one `vibe check --all`.
 user-invocable: false
 ---
 
@@ -8,12 +8,13 @@ user-invocable: false
 
 ## Procedure
 
+0. Whatever the size: build every remaining scenario, then one `vibe check --all` — no check per scenario, no `vibe context` before building, no handoff document unless the intent names one. `vibe context <id>` and `vibe check <id>` are for a scenario that failed, and for a question the files do not answer. Steps 1–2 are for `size: full` — an irreversible scenario, a review/http/eval check, a needs chain two deep, or more than eight scenarios.
 1. Take scenarios in the order of `remaining` from `vibe state --json` — parents before their `needs` dependents (`vibe state --graph` shows the edges). Put scenarios marked `irreversible` last.
    - Scenarios with no edge between them may be built by parallel agents, each in its own worktree, merged before `vibe check --all`. Never two agents in one working tree. Batch scenarios of one shape into one dispatch; never a nested subagent (a reviewer's reviewer counts for nothing). Hand artifacts to an agent as files, never pasted. When the context is nearly full, start a new session from `.vibe/` instead of compacting.
-2. Read `vibe context {id}` first — the files and symbols the check touches, the decisions and regressions that touched them, the conventions — then build only what that scenario needs. Make sure the check itself (`check.cmd`, `check.path`) can actually run.
+2. Build only what each scenario needs, and make sure the check itself (`check.cmd`, `check.path`) can actually run. `vibe map` and `vibe context {id}` are tools for a question — where a symbol lives, what a change reaches — not a step before every scenario.
    - Orientation reads ("what does this module do", "where is X handled") go through `vibe read <files> --ask "<question>"` — a low-reasoning model reads and answers with line numbers; read the file yourself only to edit or debug it.
-3. Run `vibe check {id} --json`.
-   - Pass (`code 0`): next scenario.
+3. When everything is built, `vibe check --all --json`; on a failure, `vibe context {id}` for that scenario — the files and symbols the check touches, the decisions and regressions around them — then fix and `vibe check {id} --json` for that scenario only.
+   - Pass (`code 0`): the next failing scenario, or `vibe check --all` when none is left.
    - Fail (`code 1`): read `tail` and fix. If the same failure happens twice the harness marks STUCK and leaves an inbox question — stop and show that question to the user.
    - Blocked (`status: blocked`): a parent has not passed; `vibe check {id}` runs unpassed parents first, so fix the parent named in `blockedBy`.
 4. When a project-local skill (`vibe skill list`) applies to the scenario, follow it and run `vibe skill used {name}` — prune decisions read the ledger.
@@ -28,7 +29,7 @@ Before actually executing an `irreversible` scenario (send, deploy, delete, spen
 vibe ask "{what is about to happen, one line}" --needs authorize:{action} --target "{target}" --json
 ```
 
-If the response carries a token, show it to the user and execute only after they paste it and `vibe authorize "{number}" --action {action} --target "{target}"` exits 0. If the project's token policy is `off`, the response has no token: run `vibe authorize --action {action} --target "{target}"` (recorded as auto) and proceed. Dry runs never need a token.
+If the response carries a token, show it to the user and execute only after they paste it and `vibe authorize "{number}" --action {action} --target "{target}"` exits 0 — as its own tool call, never chained in front of the action with `&&`: the hook reads the ledger before a command runs, so it blocks the chained command as unauthorized. If the project's token policy is `off`, the response has no token: run `vibe authorize --action {action} --target "{target}"` (recorded as auto) and proceed. Dry runs never need a token.
 
 ## Never
 

package/skills/vibe-handoff/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe-handoff
-description: Report and hand off — say what was built and which checks passed when, and leave a document the operator can run alone. The harness actually runs the commands in that document.
+description: Only when the intent asks for a HANDOFF.md, or the user asks for a document an operator runs alone. DONE itself needs no skill — answer from the `vibe check` output.
 user-invocable: false
 ---
 
@@ -20,7 +20,7 @@ Done: {intent title}
 - Proposals: {from `vibe state --json` proposals[] — e.g. an operator skill for an irreversible step, at most 3}
 ```
 
-3. Write the handoff document `HANDOFF.md` (or the location the user chose), in English. Four sections are mandatory: **How to run**, **When it fails (alerts · rerun)**, **How to roll back**, **Contacts / owner**. Say so first if any is missing.
+3. Write the handoff document `HANDOFF.md` (or the location the user chose), in English, only when the intent names a handoff scenario or the user asks for one; otherwise the report above is the handoff. Four sections are mandatory: **How to run**, **When it fails (alerts · rerun)**, **How to roll back**, **Contacts / owner**. Say so first if any is missing.
 4. The commands in the handoff document must be proven to run (`run` check). If an approved scenario already covers the handoff check, run `vibe check` on it. If not, ask the user whether to add a handoff scenario and re-approve.
 5. A final irreversible action (deploy, send) follows the token procedure in `vibe-build` exactly.
 6. If something should be kept for the next request (a repeated question, a customer convention), propose `vibe knowledge add`.

package/skills/vibe-prove/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe-prove
-description: Prove — run every scenario and regression at once with `vibe check --all` to reach DONE. On STUCK, stop and ask.
+description: Only on STUCK (the same failure twice) — read `vibe context <id>`, answer the inbox, `vibe check --all`. A passing task needs no skill.
 user-invocable: false
 ---
 
@@ -19,3 +19,5 @@ user-invocable: false
 DONE means every gate scenario passed on this exact tree. Changing any file sends the state back to RUNNING; run `vibe check --all` again.
 
 On STUCK, read `vibe context {id}` before touching anything — the decisions and regressions around that scenario are usually the reason.
+
+After DONE, no further `vibe check`: a check after DONE spends a turn and changes nothing until a file changes.

package/skills/vibe-scope/SKILL.md

@@ -14,6 +14,7 @@ user-invocable: false
    - When it is something a person looks at (screen, page, component, dashboard, slide, card news, poster), propose `check: { type: review, pack: design, path: <file or directory>, contract: <brief>, screenshot: <png, if an earlier scenario renders one> }`, same mark.
    - When the code will be read or maintained by someone else (a library, a contribution, a handoff), propose `check: { type: review, pack: code, path: <directory>, contract: <brief>, changed: true }`, same mark; `changed: true` reviews what changed against HEAD and its one-hop importers instead of the whole directory (a git ref instead of `true` diffs against it) — propose it on every `review` of a directory in a git repository; otherwise `vibe size` stays the code gate.
    - Next to a text `review` that has an evidence file, propose `check: { type: file, path: <file>, traceable: <evidence file> }` (every number in the text is in the evidence); next to a design `review` on html, `check: { type: file, path: <html>, a11y: true }` (alt, heading order, unnamed controls, unlabelled inputs, contrast). These check facts; the reviewers keep the judgment.
+   - A check observes. A `run` command that changes state (restore, reset, seed, migrate down, push, deploy) is detected and marked `irreversible`; `check --all` will not run it without `vibe authorize`, and it cannot become a regression. Rewrite such a check to observe — run against a copy, read the result — or declare `irreversible: <action>` and say so in the approval message.
    - Next to every `review`, propose its deterministic pre-gate on the same file: `check: { type: file, path: <file>, absent: "@placeholders" }` — the preset is the usual leftovers (lorem-ipsum text, a bracketed TODO, a to-be-decided mark, a company-name placeholder, unfilled double-brace fields, double-square-bracket notes); add the project's own words with `|`. For a directory, a `run` check with `grep -rlE` and `expect: 1`. Tell the writer that a note to the model goes between double square brackets, so the gate catches it if it survives into the artifact.
    - A condition you cannot check gets `human` explicitly. An irreversible action (push, deploy, send, delete, spend) gets `irreversible: <action>`.
    - A scenario that only makes sense after another one has passed gets `needs: [ids]`. The harness orders and parallelises checks from these edges; keep a connected graph under six scenarios.