@delegance/claude-autopilot 7.11.0 → 7.11.1

package/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 - v5.6 Phase 7 (docs reconciliation) — pending.
 
+## 7.11.1 — 2026-05-25
+
+### Added
+
+- **Concurrent multi-PR dispatch default in `skills/autopilot/SKILL.md`.** When the user describes multiple independent deliverables in one invocation, the autopilot skill now instructs dispatch as parallel Agent subagent invocations (each in its own worktree-isolated branch). Only serializes on explicit user request or genuine cross-PR dependency. Previously this default was only documented in operator-side overrides.
+
 ## 7.11.0 — 2026-05-20
 
 **v7.11.0 — Concurrent subagent dispatch (GA).** This release closes the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@delegance/claude-autopilot",
-  "version": "7.11.0",
+  "version": "7.11.1",
   "type": "module",
   "publishConfig": {
     "tag": "latest"

package/skills/autopilot/SKILL.md

@@ -145,6 +145,25 @@ Rules:
 - Specs may contain sensitive architecture details (tenant/RLS behavior, auth flows, schema names, internal endpoints). The "no secrets" rule extends to "no production-sensitive design content in tempfiles you'd be uncomfortable surfacing"; paraphrase such content before writing
 - Never write secrets, API keys, or production credentials to tempfiles regardless of location
 
+## DEFAULT: Concurrent multi-PR dispatch when the user supplies multiple independent deliverables
+
+When the user describes multiple independent deliverables in one invocation (e.g., "ship A, B, and C as separate PRs"), dispatch them as **parallel Agent subagent invocations** in a single message — each in its own isolated worktree (`isolation: "worktree"`), each running its own end-to-end pipeline (brainstorm → spec → plan → implement → validate → PR → codex-review → bugbot). Do not serialize them. Concurrent dispatch is the default unless explicit serialization is requested. Only serialize when the user explicitly says so OR the deliverables depend on each other.
+
+### Independence preflight (run before dispatching concurrently)
+
+Before fanning out, do a quick dependency/conflict scan. Serialize (or designate ONE coordinator PR for the shared edit) when any of the following are true for two or more proposed deliverables:
+
+- **Shared release metadata**: root `package.json` version, `package-lock.json`, workspace `package.json` versions, `CHANGELOG.md`, release notes.
+- **Shared schema or contracts**: DB migrations (`data/deltas/` or equivalent), RLS policies, generated types (`types/supabase.ts` or equivalent), public API contracts, OpenAPI/JSON schemas.
+- **Shared infrastructure**: queue/topic names, env-var registry, shared TypeScript types/interfaces consumed by all PRs, monorepo config (`tsconfig`, `nx.json`, workspace globs).
+- **Same module/route**: PRs that all touch the same handler, the same React component tree, or the same service file.
+
+If file ownership across the PRs is genuinely disjoint AND none of the shared-artifact categories above apply, proceed concurrently. Otherwise, either serialize (run sequentially in dependency order) or split out the shared edit into a single coordinator PR that lands first, then dispatch the dependent PRs concurrently against the post-merge base.
+
+### Avoid duplicated global edits across concurrent subagents
+
+When dispatched concurrently, individual feature subagents should NOT independently bump versions, edit `CHANGELOG.md`, regenerate lockfiles, or touch release metadata unless the parent operator has explicitly assigned that edit to exactly one subagent. The default for a fan-out is: feature code only in each subagent; release/version/changelog changes go in a separate coordinator PR or are added by the operator after the fan-out merges. This prevents merge conflicts on global artifacts that are otherwise unrelated to each PR's feature work.
+
 ## Step 0: Brainstorming with per-step Codex validation
 
 **Skip this step entirely if a spec already exists.** Otherwise: