@yemi33/minions 0.1.2391 → 0.1.2393

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.2391",
+  "version": "0.1.2393",
   "description": "Multi-agent AI dev team that runs from ~/.minions/ — five autonomous agents share a single engine, dashboard, and knowledge base",
   "bin": {
     "minions": "bin/minions.js"

package/playbooks/plan-to-prd.md

@@ -135,7 +135,7 @@ Rules for items:
       { "id": "P-bbb2", "name": "UI client",    "project": "web-dashboard",   ... }
     ]
     ```
-    The engine routes each item to that project's SQL work-item scope. The verify task at plan completion picks the project with the most completed items and runs cross-repo verification from there. See the **Cross-repo plans** section below for the full output contract when `{{target_projects}}` is set.
+    The engine routes each item to that project's SQL work-item scope. At plan completion, the engine creates one project-scoped verify work item per touched project (each project with an active PR linked to a completed plan item). If no linked PRs surface, it falls back to one verify work item on the primary project. See the **Cross-repo plans** section below for the full output contract when `{{target_projects}}` is set.
 - `depends_on` lists IDs of items that must be done first
 - Keep descriptions actionable — name the files, functions, patterns, or integration points the implementing agent should touch whenever the plan makes them clear
 - Include `acceptance_criteria` so reviewers know when it's done
@@ -161,7 +161,7 @@ Apply these rules on top of (and where they conflict, instead of) the single-pro
    - `parallel`: omit `feature_branch` entirely (the engine derives per-item branches as `user/<loginname>/<wi-id>-<slug>` in each project).
    - `shared-branch` (only with explicit justification): use the canonical `user/<loginname>/PL-<short-kebab-slug>` form. The engine will pre-create a matching branch in every project listed in `{{target_projects}}` (P-1c0f5e84) so each item can push to the same branch name in its own repo.
 
-The verify task at plan completion picks the project with the most completed items and runs cross-repo verification from there; items with no PRs (e.g. docs-only changes that landed via direct commit) are still counted via their `done` status.
+At plan completion, the engine creates one verify work item per touched project, where a touched project has at least one active PR linked to a completed plan item. Those project-scoped verify tasks run independently in parallel. If no linked PRs surface (for example, items completed without PR records or legacy state), the fan-out collapses to one verify work item on the primary project — the project with the most completed items — as a fallback.
 
 {{/target_projects}}
 ## Reusing an Existing PRD