@multileaf/ai-workflow 0.9.0 → 0.10.0

package/resources/skills/review-judge-b.md

@@ -0,0 +1,24 @@
+---
+name: review-judge-b
+description: Second blind reviewer of an adversarial review — a fresh, independent pass over the same diff with separately attributable findings.
+---
+
+# Review Judge B (blind)
+
+You are the second independent reviewer. Your pass must be fresh: **do not read, request, or rely on the first judge's findings** or any summary that mixes them. Disagreement between blind reviewers is signal, not noise.
+
+## Procedure
+
+1. Re-derive the review from the change itself (diff or files with line numbers) and the cited request context.
+2. Deliberately vary your reading order from the obvious one (entry points last, or tests first) so the two passes do not share a blind spot.
+3. Report every finding with: severity (`BLOCKER`, `CRITICAL`, `MAJOR`, `MINOR`), `file:line` evidence, and a one-line reproducible statement of impact.
+
+## Finding rules
+
+- A `BLOCKER` or `CRITICAL` finding MUST include either a reproducing command (with its expected observed output) or exact `file:line` citations that prove the claim by themselves.
+- Findings you cannot evidence are `MINOR` questions, never `BLOCKER`.
+- State what you verified and what you did not check.
+
+## Output
+
+Emit a numbered findings list (severity, evidence, impact) and a final line: `Inspection complete: <files/paths examined>`.

package/resources/skills/review-refuter.md

@@ -0,0 +1,28 @@
+---
+name: review-refuter
+description: Adversarial refuter for severe review findings — confirm or drop each claim with proof, degrading unevidenced severe findings to advisory.
+---
+
+# Review Refuter
+
+Your job is to **try to destroy severe findings**, not to defend them. For every `BLOCKER` or `CRITICAL` finding you receive, output one of three verdicts with proof references (`proof_refs`):
+
+- `corroborated` — the claim survives your refutation attempt;
+- `refuted` — you found concrete evidence the claim is wrong or cannot happen;
+- `inconclusive` — evidence is insufficient either way.
+
+## Command execution is a granted capability, never a default
+
+You may run a reproducing command **only when the user or host has explicitly granted command execution for this review**. In that case: run at most one reproducing command per claim, in an isolated disposable directory when the runtime provides one, with no network access, and cite the command and its observed output in `proof_refs`.
+
+When execution is **not** granted — the default — you work in evidence-reading mode: verify claims against the cited `file:line` content and repository state alone, and **append `no command executed` to every `proof_refs`** so the record never implies verification that did not happen.
+
+## Degradation rule
+
+A severe finding with neither a reproducing command nor self-proving `file:line` evidence degrades to `advisory` with the reason recorded. Only `corroborated` severe findings may block; `refuted` findings become advisories; `inconclusive` findings go to the bounded correction discussion.
+
+## Bounds
+
+- Never refute a claim you were not given; one verdict per issued claim.
+- Pre-existing, base-only, or unknown-causality findings are not yours to drop: mark them `inconclusive` and pass them on.
+- A human still accepts the final review outcome; your verdicts are evidence, not approval.

package/resources/skills/ticket.md

@@ -9,6 +9,8 @@ For every approval or optional skip, use the host's native blocking question wid
 
 Use this skill when the user provides a ticket ID (for example `PROJ-142`) or an already-clear requirement and wants to start work immediately.
 
+Lane decision (light lane): before starting, apply the resume test — the work is small when it is understood, risk is contained, and it could be resumed from the request plus `git diff`. If it is, offer the light lane with the blocking widget ("Light lane" / "Full lane"). Only after an explicit human choice, start with `--lane=light --lane-reason=<the resume-test call, one line>`; never choose the light lane yourself. Light-lane work records validation evidence with `aiw task evidence --validation="<command and result>"` and completes with `aiw workflow complete`; if scope grows, escalate with `aiw task escalate --reason=<why>` instead of authoring stage artifacts.
+
 1. Extract the ticket ID and a short title from the user's request. Start the task with `npx --yes --package=@multileaf/ai-workflow -- aiw task start --ticket=<TICKET> --title="<short title>"` (add `--id=<uuid>` only if the user provides one). If a session is already active, report it with `aiw task status` and stop.
 2. Brainstorming decision: the ticket already provides the requirement, but skipping is still a human decision. Ask with the blocking widget whether to skip brainstorming ("Accept skip" / "Do not skip"). Only after an explicit acceptance, record it with `npx --yes --package=@multileaf/ai-workflow -- aiw skip brainstorming --reason="Requirement provided by ticket <TICKET>"`. If the user prefers to brainstorm after all, run the brainstorming skill instead.
 3. Create the specification linked to the ticket with `npx --yes --package=@multileaf/ai-workflow -- aiw spec --ticket=<TICKET> --title="<title>"`, fill in requirements with stable IDs and Given/When/Then acceptance criteria derived from the ticket, then pass `aiw gate specification`, present the artifact, wait, and record the human reply with `aiw approve specification` (or `aiw reject specification --reason=<feedback>` and revise).