@multileaf/ai-workflow 0.1.5 → 0.2.0

package/resources/package.yaml

@@ -69,6 +69,8 @@ resources:
     - { id: task, version: 0.1.0, path: templates/task.md }
     - { id: test-plan, version: 0.1.0, path: templates/test-plan.md }
     - { id: verification-report, version: 0.1.0, path: templates/verification-report.md }
+    - { id: implementation-evidence, version: 0.1.0, path: templates/implementation-evidence.md }
+    - { id: code-review, version: 0.1.0, path: templates/code-review.md }
     - { id: security-review, version: 0.1.0, path: templates/security-review.md }
     - { id: migration-report, version: 0.1.0, path: templates/migration-report.md }
 provides:

package/resources/skills/brainstorming.md

@@ -7,4 +7,4 @@ description: Turn an early product idea into structured goals, assumptions, cons
 
 Separate facts, hypotheses, decisions, and open questions. Identify users, desired outcomes, constraints, risks, and non-goals. Do not prematurely prescribe implementation. Produce a versioned brainstorm artifact in English.
 
-When the request is already clear, skip brainstorming. Once the goal and constraints are clear, hand off to `requirements-specification` and link the specification to this brainstorm when one exists.
+Start an AI Workflow session for each feature with `npx --yes --package=@multileaf/ai-workflow -- aiw workflow start` unless one is already active. When the request is already clear, explain why brainstorming can be skipped, ask the human to accept the skip, stop, and record only an explicit acceptance with `aiw skip brainstorming --reason=<accepted reason>`. Otherwise create `.aiw/generated/specs/brainstorm.md`, run `aiw gate brainstorming`, present the exact artifact and a concise summary, and ask whether to proceed to requirements. Stop the turn and wait. Only after an explicit approval, record it with `aiw approve brainstorming`; do not start or scaffold requirements before that command succeeds. If changes are requested, first record `aiw reject brainstorming --reason=<feedback>`, then revise the artifact, rerun its gate, and ask again. Use `npx --yes --package=@multileaf/ai-workflow -- aiw <command>` when no global CLI is available.

package/resources/skills/code-review.md

@@ -7,4 +7,4 @@ description: Review code for correctness, maintainability, design quality, and r
 
 Review behavior, boundaries, cohesion, naming, types, error handling, duplication, complexity, tests, and documentation. Prioritize actionable findings with severity and evidence.
 
-If findings require changes, send them back to implementation and require verification again. If there are no blocking findings, record the review result and complete traceability. This skill is a review checklist, not a CLI quality gate.
+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/implementation-planning.md

@@ -7,4 +7,4 @@ description: Break an approved design into independently verifiable implementati
 
 Create small ordered tasks. Each task must reference requirements, affected modules, tests, commands, dependencies, and completion evidence.
 
-After the plan passes its gate, implement in task order. Use `tdd-development` when it is installed and the project has a test workflow; otherwise use the repository's existing validation methods. Hand completed work to `verification`.
+Write `.aiw/generated/plans/implementation-plan.md` with ordered tasks, requirement links, affected modules, tests, validation, dependencies, risks, and completion evidence. After `aiw gate plan` passes, present the exact plan to the human and ask for explicit approval. Stop and wait; a gate pass is not approval. Do not edit implementation files until approval arrives and `aiw approve plan` succeeds. If changes are requested, first record `aiw reject plan --reason=<feedback>`, then revise the plan, rerun its gate, and ask again. After approval, implement in task order. Use `tdd-development` when installed and the project has a test workflow; otherwise use existing validation. When implementation is complete, write `.aiw/generated/reports/implementation-report.md` with changed files, tests, validation results, and deviations; run `aiw gate implementation`, present the diff and evidence to the human, stop, and wait for explicit approval. Record approval with `aiw approve implementation` before verification. Invoke CLI commands through `npx --yes --package=@multileaf/ai-workflow -- aiw <command>` when no global binary exists.

package/resources/skills/requirements-specification.md

@@ -7,4 +7,4 @@ description: Convert a product idea into testable, traceable requirements.
 
 Give each requirement a stable identifier. Define observable behavior, acceptance criteria, constraints, and unresolved questions. Link requirements to their source brainstorm and distinguish confirmed facts from assumptions. Do not approve ambiguous critical requirements.
 
-After requirements are confirmed, use `technical-design` when the change affects architecture or has consequential design choices; otherwise hand off to `implementation-planning`.
+Create `.aiw/generated/specs/specification.md` and run `aiw gate specification`. Present the exact requirements and unresolved questions to the human and ask for explicit approval. Stop the turn and wait; a passing gate is not approval. Only after approval, run `aiw approve specification`; do not create design or plan artifacts before it succeeds. If changes are requested, first record `aiw reject specification --reason=<feedback>`, then revise the specification, rerun its gate, and ask again. After approval, use `technical-design` when the change affects architecture or has consequential design choices. Otherwise explain why design can be skipped, ask the human to accept, stop, and record an explicit acceptance with `aiw skip technical-design --reason=<accepted reason>` before planning. Invoke commands through `npx --yes --package=@multileaf/ai-workflow -- aiw <command>` if `aiw` is not installed globally.

package/resources/skills/tdd-development.md

@@ -7,4 +7,4 @@ description: Implement repository changes through test-first development.
 
 Follow Red, Green, Refactor, Verify. Write a failing behavioral test first, implement the smallest change, refactor for clarity and design quality, then run the relevant quality gate. Never weaken a test to make an implementation pass.
 
-After implementation tasks are green and refactored, hand off to `verification` with the changed requirements, test commands, and evidence.
+After implementation tasks are green and refactored, write `.aiw/generated/reports/implementation-report.md` with changed files, tests, validation results, and deviations. Run `aiw gate implementation`, present the diff, changed requirements, test commands, and exact evidence to the human. Ask for explicit approval to proceed to verification, end the turn, and wait. Do not invoke verification until the human approves and `aiw approve implementation` succeeds. If changes are requested, first record `aiw reject implementation --reason=<feedback>`, remain in implementation, repeat relevant tests, update the report, rerun its gate, and ask again. Invoke CLI commands through `npx --yes --package=@multileaf/ai-workflow -- aiw <command>` when no global binary exists.

package/resources/skills/technical-design.md

@@ -7,4 +7,4 @@ description: Design modular technical solutions from approved requirements.
 
 Map requirements to components, interfaces, data flows, and validation strategy. Compare meaningful alternatives and record decisions with rationale, risks, and consequences. Prefer small cohesive modules, explicit contracts, dependency inversion, and reversible changes.
 
-Link each design and ADR to the affected requirements. Once decisions are recorded, hand off to `implementation-planning`.
+Write the reviewable design to `.aiw/generated/reports/technical-design.md` using the technical-design template. Link each design and ADR to affected requirements. Run `aiw gate technical-design`, present the exact design and decisions to the human, and ask for explicit approval. Stop and wait; do not create an implementation plan until approval arrives. Only after approval, record it with `aiw approve technical-design`. If changes are requested, first record `aiw reject technical-design --reason=<feedback>`, then revise the design/ADRs, rerun the gate, and ask again. If no technical design is needed, obtain explicit human acceptance and record `aiw skip technical-design --reason=<accepted reason>`. Use `npx --yes --package=@multileaf/ai-workflow -- aiw <command>` when no global CLI is available.

package/resources/skills/verification.md

@@ -7,4 +7,4 @@ description: Verify implementation against requirements and produce traceable ev
 
 Check every acceptance criterion, quality gate, security requirement, and affected adapter. Report passed checks, missing evidence, failures, and residual risks. A task is not complete when required evidence is missing.
 
-Create the verification report and validate it with `npx --yes --package=@multileaf/ai-workflow -- aiw gate verification`. Then hand off to `code-review` when installed; after review, update traceability and completion evidence.
+Write `.aiw/generated/reports/verification-report.md` using the verification-report template and validate it with `npx --yes --package=@multileaf/ai-workflow -- aiw gate verification`. Present the exact report, checks, missing evidence, and residual risks to the human. Ask for explicit approval to proceed, end the turn, and wait; an automated gate pass is not human acceptance. Only after approval, record it with `aiw approve verification`. Do not start code review or final traceability before that command succeeds. If verification fails or changes are requested, record `aiw reject verification --reason=<feedback>` before editing the report or returning to implementation, then repeat verification, update the report, rerun the gate, and ask again. Use npx package invocation for other `aiw` commands when no global binary exists.

package/resources/templates/code-review.md

@@ -0,0 +1,21 @@
+# Code Review
+
+## Scope
+
+Describe the diff and requirements reviewed.
+
+## Findings
+
+List findings with severity, file/line evidence, and actionable remediation. State `None` when there are no findings.
+
+## Checks
+
+List checks performed and their results.
+
+## Residual Risks
+
+State remaining risks or `None`.
+
+## Decision
+
+Recommend accept, revise, or reject, with rationale.

package/resources/templates/implementation-evidence.md

@@ -0,0 +1,17 @@
+# Implementation Evidence
+
+## Changed Files
+
+- `path/to/file` — reason for the change.
+
+## Tests
+
+- Command and result; list relevant tests.
+
+## Validation
+
+- Command and result for required project checks.
+
+## Deviations
+
+None, or explain approved plan deviations and their impact.