@multileaf/ai-workflow 0.9.0 → 0.11.0

package/resources/package.yaml

@@ -32,6 +32,9 @@ resources:
     - { id: prisma-data-access, version: 0.1.0, path: skills/prisma-data-access.md }
     - { id: vite-frontend, version: 0.1.0, path: skills/vite-frontend.md }
     - { id: ticket, version: 0.1.0, path: skills/ticket.md }
+    - { id: review-judge-a, version: 0.1.0, path: skills/review-judge-a.md }
+    - { id: review-judge-b, version: 0.1.0, path: skills/review-judge-b.md }
+    - { id: review-refuter, version: 0.1.0, path: skills/review-refuter.md }
   rules:
     - { id: language-policy, version: 0.1.0, path: rules/language-policy.md }
     - { id: tdd-policy, version: 0.1.0, path: rules/tdd-policy.md }

package/resources/skills/code-review.md

@@ -9,4 +9,6 @@ For every approval, rejection, or optional skip, use the host's native blocking
 
 Review behavior, boundaries, cohesion, naming, types, error handling, duplication, complexity, tests, and documentation. Prioritize actionable findings with severity and evidence.
 
+When the adversarial review skills are installed, run the stronger protocol: two blind judges (`review-judge-a`, `review-judge-b`) review the same diff independently, then `review-refuter` attempts to refute every severe finding — only corroborated severe findings may block, unevidenced ones degrade to advisory, and verdicts carry proof references. Attribute each judge's findings separately in the report.
+
 Write `.aiw/generated/reports/code-review.md` with the scope, findings (including an explicit `None` when clear), checks, residual risks, and decision. Run `aiw gate review`, present the exact report, and ask whether to address findings or accept the residual risk. Stop and wait for an explicit decision. Only after approval, record it with `aiw approve review`; do not start traceability before it succeeds. If changes are requested, first record `aiw reject review --reason=<feedback>`, return to implementation, and require verification and review again. Review completeness is an automated gate; it does not replace human approval. Invoke commands through `npx --yes --package=@multileaf/ai-workflow -- aiw <command>` when no global binary exists.

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

@@ -0,0 +1,24 @@
+---
+name: review-judge-a
+description: First blind reviewer of an adversarial review — inspect the diff independently and report findings with required evidence.
+---
+
+# Review Judge A (blind)
+
+You are one of two independent reviewers. Review the change **without consulting any other review, judge output, or conversation summary about this change**: your value is independence. If another review's findings reach you, ignore them.
+
+## Procedure
+
+1. Read the exact change you are given (diff or files with line numbers). Do not assume intent beyond what the change and its cited request context state.
+2. Inspect the code paths the change touches, including callers of changed exports where visible in the repository.
+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. A silent gap reads like coverage.
+
+## Output
+
+Emit a numbered findings list (severity, evidence, impact) and a final line: `Inspection complete: <files/paths examined>`.

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).