feat(mt#1305): parallel-work guard at /plan-task gate (g) and /implement-task spot-check

[minsky-ai]

Summary

Adds Tier-2 enforcement of feedback_check_parallel_work_before_decomposing into the lifecycle skills. After four parallel-work incidents in four days (mt#1192/mt#1199, mt#1068/mt#1240, mt#1261/mt#1281, plus the meta-incident of mt#1299 vs mt#1305 itself filed one day apart), memory-only enforcement is demonstrably insufficient.

Key Changes (final scope)

.claude/skills/plan-task/SKILL.md — primary enforcement at PLANNING → READY:

• New gate criterion (g) "No parallel work in flight" alongside the existing (a)–(f) gates
• Three required checks: path/file collision via list_pull_requests + pull_request_read get_diff, signature search via tasks_search + git_log --grep, parent/sibling enumeration via tasks_parent / tasks_children
• Any hit is a blocking gap; task stays in PLANNING until resolved

.claude/skills/implement-task/SKILL.md — secondary spot-check before session creation:

• New §0a "Late parallel-work spot-check" between the entry gate (§0) and memory retrieval (§1)
• Step-ordering note clarifies §0a should fetch the spec early via tasks_spec_get if not yet loaded
• Abbreviated check (open-PR sweep + 24h merged sweep) — hours or days may pass between READY and IN-PROGRESS
• Halts before session_start if either sweep hits

.claude/skills/orchestrate/SKILL.md — reverted to main:

• Initial draft modified §3 Pre-work assessment, but mt#1249 (PR landed mid-iteration) repurposed the entire /orchestrate skill to multi-task coordination. The new orchestrate explicitly delegates session creation to /implement-task and has its own §A "Pre-decomposition: sweep for parallel work" — making my orchestrate edits structurally moot.
• Reverted via commit d2c8714cb. Orchestrate is no longer modified by this PR; main's mt#1249 version is left in place.

Memory file (feedback_check_parallel_work_before_decomposing.md, outside repo at ~/.claude/projects/.../memory/):

• Frontmatter description and prelude updated to reflect that skill-step enforcement landed
• Original guidance preserved below for the until-Tier-3 fallback path
• MEMORY.md index entry shortened and re-pointed

Tier-3 follow-up filed: mt#1362 — PreToolUse hook on session_start for structural enforcement (the ceiling; this PR is the floor).

Iteration narrative

This PR is itself a documented instance of the parallel-work problem it's solving:

• Round 1 (commit 2c05f009d) added all three skill changes plus orchestrate cite-only
• Reviewer-bot round 1 flagged BLOCKING gap in orchestrate ("orchestrate's flow doesn't actually call /plan-task or /implement-task")
• Round 2 (commit 0f211a4bc) restored a minimal local check in orchestrate to close the gap, plus two non-blocking fixes
• During iteration mt#1249 merged on main with a complete /orchestrate rewrite that structurally eliminated the problem reviewer-bot identified
• Round 3 (commit d2c8714cb) reverted orchestrate to match main; merged session forward via session_update

The reviewer-bot's round-1 BLOCKING finding is now structurally resolved by the new orchestrate (which explicitly never calls session_start), so the gap it identified does not exist in the merged base. Plan-task gate (g) and implement-task §0a remain — those target their own files (untouched by mt#1249) and provide the parallel-work guard at PLANNING and pre-session_start phases.

Testing

Walk-through verification:

1. mt#1068 incident replay — /plan-task mt#1068 with gate (g) active: spec lists src/domain/ask/ in In-scope; list_pull_requests --state open returns PR feat(mt#1240): Ask reconciler + asks.list/reconcile CLI #788 (mt#1240 chain) touching the same surface. Hit → blocking gap → mt#1068 stays in PLANNING.

2. mt#1305 meta-incident replay — /plan-task mt#1305 with gate (g) active: signature search for "parallel-work guard skill steps" returns mt#1299 (filed 2026-04-25). Hit → blocking gap. Caught in PLANNING (which is exactly what manual investigation produced earlier today).

3. mt#1249 collision replay — Had this been an active task in PLANNING when mt#1305 was being planned, gate (g) signature search "orchestrate skill" or "/orchestrate multi-task" would have surfaced mt#1249. The recursive case proves the rule: this very iteration would have been prevented.

Format check: bunx prettier --write applied. No lint or test surface modified.

(Had Claude assist in drafting this — AI-authored bot PR.)

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

Findings

• [BLOCKING] .claude/skills/orchestrate/SKILL.md: Pre-work assessment §3 — removal of local “Check file overlap” without ensuring equivalent enforcement will run in this workflow path

  • Evidence: In this PR, the bullet “Check file overlap” was replaced with: “Parallel-work guard: This is owned by /plan-task gate criterion (g)… with a re-check at /implement-task §0a… Do not duplicate the check here…”
  • Failure mode: The orchestrate flow does not actually invoke /implement-task; it performs its own session creation (Step 2 using mcp__minsky__session_start) and then directly dispatches a subagent via session_generate_prompt (Step 4). Thus, neither the /plan-task gate (g) nor the /implement-task §0a spot-check is guaranteed to have run in this path. By removing the local overlap check and delegating to skills that are not called here, this creates a gap where orchestrate can proceed from TODO (per its “must be TODO or IN-PROGRESS” status check) to an active session and dispatch without any parallel-work guard running. This is a silent behavioral weakening relative to the previous instruction that explicitly told operators to check file overlap before dispatch. It directly contradicts the PR’s stated goal (“enforcement lives at lifecycle phase boundaries”) for the orchestrate pathway and can lead to concurrent edits on the same files.
  • Impact category: Data-loss/correctness on user-facing behavior — the orchestrate workflow can now bypass the parallel-work guard the PR claims to enforce, increasing the risk of conflicting changes and wasted work.
  • Required fix: Either (a) have orchestrate explicitly gate on tasks being READY (not TODO/IN-PROGRESS) and/or explicitly call /plan-task before session creation, and explicitly dispatch /implement-task so §0a runs; or (b) retain a minimal overlap check locally in orchestrate when it is not guaranteed the other skills were run. The current text incorrectly assumes those checks will have already run.

• [NON-BLOCKING] .claude/skills/implement-task/SKILL.md: Step “0a. Late parallel-work spot-check” depends on the spec’s “In scope” list, but spec retrieval happens later at Step 2

  • Evidence: §0a instructs: “Scan titles and branches for any PR whose scope plausibly overlaps the spec’s ‘In scope’ files.” The spec is fetched at “2. Read and verify the task spec.”
  • Concern: The sequence implies §0a runs before the spec is retrieved, making it unclear how to obtain the “In scope” file list at that time. This is a procedural inconsistency that can confuse implementers or lead to incomplete checks.
  • Suggested remedy: Either move spec retrieval earlier (before §0a) or restate §0a to operate on the already-known scope data (if available) and explicitly say to fetch the spec if the scope is not yet loaded.

• [NON-BLOCKING] .claude/skills/plan-task/SKILL.md: Tool reference may be inaccurate — “mcp__minsky__session_pr_list --status open (filter by task: "mt#X")”

  • Evidence: Gate (g) point 3 cites a tool/flag combination that may not exist or may be named differently in this repo’s MCP tool registry. I cannot verify tool names beyond HEAD documentation.
  • Risk: If this exact tool or option does not exist, following the doc will fail or send agents searching for a non-existent capability.
  • Suggested remedy: Verify the exact tool name and parameters in the MCP server/tooling and adjust the doc to the canonical invocation (e.g., whether this is part of mcp__minsky__session_pr_list, a filter on mcp__github__list_pull_requests, or another method).

• [NON-BLOCKING] [NEEDS VERIFICATION: out-of-repo/missing-in-diff] PR description claims memory updates that are not present in the diff

  • Evidence: The PR body lists: “Memory file (feedback_check_parallel_work_before_decomposing.md)… MEMORY.md index entry shortened and re-pointed.” I inspected the repo tree at HEAD and do not see those changes in this diff; I also cannot find a .claude/memories/ or memory file matching that name at HEAD.
  • Note: Because I cannot inspect historical state or out-of-repo paths, this may reflect concurrent changes or an oversight in the PR description. If these updates were intended in this PR, they appear missing and should be added or the description corrected.

Spec verification

No explicit task spec was provided. The PR description is the only source of intent.

• Add enforcement of parallel-work guard at planning and a spot-check at implementation startup:
  • Plan-task SKILL.md: Met — Gate (g) added with detailed procedure.
  • Implement-task SKILL.md: Partially Met — §0a added, but its reliance on spec “In scope” conflicts with the current step ordering. Also, this enforcement only triggers if the implement-task skill is actually used by the workflow.
  • Orchestrate SKILL.md: Not Met — The doc removes local overlap check and delegates to plan-task/implement-task checks that are not invoked by orchestrate in its documented flow (it creates a session and dispatches directly). This leaves a hole in enforcement for the orchestrate path.

Documentation impact

• This PR changes the documented lifecycle responsibilities and enforcement points across three skills. Architecture/workflow docs that describe:
  • Which skill owns the parallel-work guard and at which transition
  • Preconditions for starting sessions from orchestrate (status gating: TODO vs READY)
  • The cross-skill call graph (whether orchestrate calls implement-task or subagents directly)
• If there is a central developer workflow doc (e.g., CONTRIBUTING.md or docs/architecture.md) that outlines task lifecycle, it likely needs an update to reflect:
  • The new plan-task Gate (g)
  • The implement-task §0a spot-check
  • The clarified orchestrate pathway and its reliance (or not) on those checks
• Given the enforcement claims, I recommend ensuring a single authoritative doc explains the expected gate sequence and the invariants (e.g., “Sessions are only started for READY tasks” if that’s the new rule).

Event: REQUEST_CHANGES

Rationale: The orchestrate change introduces a correctness-risking gap by removing an explicit overlap check while assuming other skills will enforce it, but orchestrate as documented does not call those skills. This is a material behavioral risk and conflicts with the PR’s own objective. The additional findings are non-blocking documentation clarity issues.

[minsky-ai]

Review: parallel-work guard at /plan-task gate (g) and /implement-task spot-check

CI status: pass (2/2 — build, Prevent Placeholder Tests)

Findings

No blocking findings. The diff is a tight, three-file process change that operationalizes an existing memory rule into structural skill steps.

Checked and clear

• All MCP tool references in the new sections are real. Verified mcp__github__list_pull_requests, mcp__github__pull_request_read (method get_diff), mcp__minsky__git_log, mcp__minsky__tasks_search, mcp__minsky__tasks_parent, mcp__minsky__tasks_children, and mcp__minsky__session_pr_list are loaded in this conversation's tool surface — no fictitious tool names introduced.
• Memory citation is consistent across all three files. Each cites feedback_check_parallel_work_before_decomposing by exact name, providing a single source of rationale to update if the memory ever moves.
• No duplicate enforcement copy. /orchestrate §3 is delegation-only ("Do not duplicate the check here"). This avoids drift between three skill files, which was an explicit request in the spec ("/orchestrate references both skills as the location of the check (no duplicate copy)").
• Placement matches the lifecycle ownership model. Gate (g) lives in /plan-task (owns PLANNING → READY) where signature phrases and scope are most explicit; §0a in /implement-task (owns READY → IN-PROGRESS) catches drift in the gap. /orchestrate is now multi-task coordination per the recent description shift, so single-task lifecycle enforcement correctly lives in the phase-owning skills.
• Override path is clear and consistent. All three sites use the same vocabulary on hit ("wait / coordinate / reframe / proceed with explicit acknowledgment").
• No live-target/probe scripts touched. §5a not applicable.
• No removals. §5b residue search not applicable.

Spec verification

Task: mt#1305

Criterion	Status	Evidence
/plan-task skill includes the Parallel work check step	Met	.claude/skills/plan-task/SKILL.md gate criterion (g) added between (f) and Step 4 (diff lines +128 to +166); three required checks specified.
/implement-task §0 references the check and surfaces /plan-task findings	Met	.claude/skills/implement-task/SKILL.md §0a added (diff lines +46 to +65). Implementation chose §0a as a peer step rather than extending §0; functionally equivalent, structurally cleaner — §0 retains its single concern (status gate).
/orchestrate references both skills (no duplicate copy)	Met	.claude/skills/orchestrate/SKILL.md §3 (diff line +61) cites /plan-task gate (g) and /implement-task §0a; explicit "Do not duplicate" instruction preserved.
Memory entry updated to cover sibling-task implementation actions	Met	feedback_check_parallel_work_before_decomposing.md frontmatter description and prelude updated to reflect the skill-step landing; original guidance preserved as fallback. Outside repo so not in this diff.
PreToolUse hook (or follow-up task) for session_start	Met	mt#1362 filed as child of mt#1305 with full Tier-3 spec (success criteria, scope, acceptance tests).
Walk-through verification — mt#1068 incident	Met	Replay: gate (g) path/file-collision check on src/domain/ask/ would return PR #788 (mt#1240 chain), block READY transition.
Walk-through verification — mt#1305 meta-case	Met	Replay: gate (g) signature search "parallel-work guard skill steps" returns mt#1299 (filed 2026-04-25), blocks READY transition. The skill steps would have caught their own genesis incident.

All seven success criteria met.

Documentation impact

No update needed — this PR is itself a documentation/process change (skills are the docs). No architectural shift, no new VSM organ, no command-registry change, no user-facing CLI/config change. CLAUDE.md §"Key Workflows (via skills)" lists skills by name and purpose; the gate (g) and §0a are internal sections that don't require a top-level CLAUDE.md update. docs/theory-of-operation.md and docs/architecture.md are unaffected.

(Had Claude look into this — AI-assisted review on a self-authored PR; submitted as COMMENT since minsky-ai[bot] cannot self-APPROVE per the GitHub platform constraint and the Critic Constitution.)

Dismissing as superseded. The round-1 BLOCKING finding ("orchestrate flow goes session_start → dispatch directly without invoking /plan-task or /implement-task, leaving an enforcement gap") was correct against the orchestrate that existed at commit e9473a2. While this PR was iterating, mt#1249 merged on main (commit 43b8b63) and fully repurposed /orchestrate to multi-task coordination — the new orchestrate explicitly delegates session creation to /implement-task and never calls session_start itself. The gap this finding identified does not exist in the merged base. PR #836 has been updated: my orchestrate edits were reverted (commit d2c8714) since they targeted the prior structure that no longer exists. The PR's remaining scope is /plan-task gate (g) + /implement-task §0a, both of which target files mt#1249 did not touch. Re-review against the current head (7932ef7) is welcome.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

reviewer-service error: chain-of-thought leakage detected

The upstream model emitted raw internal reasoning into the review body. The reviewer service sanitised the output but could not locate a valid Findings section to preserve, so the leaked content was discarded. The PR will receive a fresh review on the next commit. See docs/architecture/critic-constitution-reliability.md for details.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

reviewer-service error: chain-of-thought leakage detected

The upstream model emitted raw internal reasoning into the review body. The reviewer service sanitised the output but could not locate a valid Findings section to preserve, so the leaked content was discarded. The PR will receive a fresh review on the next commit. See docs/architecture/critic-constitution-reliability.md for details.