Subtasks freeze and stop responding

[rcollette]

Describe the bug

In autopilot mode I use a command like

/fleet use speckit-automate implement skill Which uses the speckit.implement agent/skill but also loops through the speckit-converge agent/skill and back to speck-implement.

At some point in the session I get the messages

 ● Unknown tool name in the tool allowlist: "apply_patch"                                                                                                                      
 ● Unknown tool name in the tool allowlist: "rg"        

And then the subtask will slow down and freeze. I have to kill the subtask.

This has the appearance of a memory leak, perhaps due to the looping nature of the skill.

This issue can be repeated consistently.

speckit extension command

---
description: >-
  Run a selected Spec-Kit workflow stage with bounded planning, task-consistency, implementation-convergence, and
  quality loops.
---

## Purpose

Use `/speckit.automate` to run an automated Spec-Kit workflow stage without replacing or shadowing the core commands.
`/speckit.workflow-automation.automate` remains available as the canonical extension command. The first argument is
required and selects one stage:

- `plan` — plan, checklist, and bounded artifact-improvement loop.
- `tasks` — generate tasks, analyze cross-artifact consistency, then run the bounded task-improvement loop.
- `implement` — implement approved tasks, converge against the feature artifacts, and run bounded quality loops.

## Validate and Dispatch the Stage

1. Parse the first argument as the stage and treat all remaining text as context for the selected core command.
2. If the stage is missing or is not exactly `plan`, `tasks`, or `implement`, report the following usage and stop. Do
   not invoke a core command:

   ```text
   Usage: /speckit.automate <plan|tasks|implement> [context]
   ```

3. For a valid stage, announce that this workflow-automation extension is in use before executing the selected stage.

Before starting, suggest that the user runs in `autopilot` or `bypass approvals` mode. When using the Copilot CLI coding
agent, suggest to the user the prompt `/fleet use the speckit.automate implement skill` for implementation; use the
equivalent supported invocation for other coding agents.

## Universal Rules

- Load the active feature artifacts and `.specify/memory/constitution.md` before dispatching a stage.
- Respect all extension hooks required by every command this workflow invokes.
- Respect confirmation requirements from invoked commands unless the user has explicitly selected a supported
  `bypass approvals` mode.
- Preserve user steering and stop for a decision involving security, privacy, compliance, authentication, authorization,
  tenant isolation, data retention, encryption, credential handling, permissions, threat modeling, or risk acceptance.
  Do not invent a missing decision.
- Stop and report if a required command fails, produces no output, corrupts an artifact, or cannot locate the required
  Spec Kit structure.
- A bounded loop stops when it converges, when an unchanged unresolved finding repeats, or after three cycles. On a
  non-converged stop, report the unresolved finding, affected artifacts or task IDs, attempts made, and the decision or
  manual follow-up required.
- Never claim an acceptance scenario passed based solely on mocks or internal invocation when the generated program and
  its relevant extension or integration support that scenario. Follow the constitutional generated-program acceptance
  gate.
- Never materially alter the design of the application (ex. contracts) without human input. The primary intention is
  feature completeness and code quality, not system design.

## Stage: `plan`

1. Run `/speckit.plan` with the supplied context.
2. Run `/speckit.checklist` to assess the resulting feature artifacts.
3. If the checklist has incomplete items, run this bounded loop:
   1. Send the open items and affected artifacts to `/speckit.iterate.define`.
   2. Apply the resulting pending iteration with `/speckit.iterate.apply`, honoring its confirmation requirement.
   3. Re-run `/speckit.checklist` and mark only genuinely completed items complete.
4. Stop after a complete checklist for manual review and approval of the plan. Do not begin task generation or
   implementation from this stage.

## Stage: `tasks`

1. Run `/speckit.tasks` with the supplied context.
2. Run `/speckit.analyze` and verify that every task's phase label, declared dependencies, and execution wave are
   compatible. Cross-cutting work may run in an earlier wave only when explicitly linked to its phase-completion gate.
3. If analysis identifies incomplete, missing, conflicting, or inconsistent tasks, run this bounded loop:
   1. Send the task findings and all affected artifacts to `/speckit.iterate.define`.
   2. Apply the resulting pending iteration with `/speckit.iterate.apply`, honoring its confirmation requirement.
   3. Confirm every artifact named by the iteration was updated; fail the cycle if one was omitted.
   4. Re-run `/speckit.analyze`.
4. When task consistency is achieved
   1. Report to the user the tasks that were generated as a result of using speckit.analyze and through security review.
   2. Hand off to `/speckit.implement` only if the user explicitly requested that follow-on work in the same invocation.
      Otherwise stop with the generated task list ready for review.

## Stage: `implement`

1. Confirm that the feature's tasks are approved. If they are not approved, stop and request approval rather than
   starting implementation.
2. Initialize a convergence-cycle counter and an empty set of normalized finding signatures. A signature consists of a
   convergence finding's source reference, gap type, and remaining-work description.
3. Run `/speckit.implement`. Use available parallel execution facilities only for tasks that are genuinely independent.
4. Run `/speckit.converge`, increment the convergence-cycle counter, and inspect any appended tasks.
5. If convergence reports remaining work:
   1. Compare its normalized finding signatures with prior cycles.
   2. Stop if a signature repeats without material change; otherwise record the new signatures and return to step 3.
6. After convergence reports no remaining implementation work, run all applicable quality gates:
   1. Run the unit, contract, architecture, and coverage tests required by the feature and constitution.
   2. If specified by the project's guiding documentation such as constitution and/or AGENTS.md, perform acceptance
      verification as guided by those documents.
   3. If specified by the project's guiding documentation, and an IDE diagnostics, linting and/or error fetching tools
      are available, inspect new or modified code and resolve actionable warnings and errors.
   4. If specified by the project's guiding documentation, and available, use locally available static analysis tools
      (ex. Sonar Community server and Sonar MCP/connector), scan the project, query new-code findings for the complete
      project component, and resolve every actionable finding in new or modified code. A narrowly scoped false-positive
      suppression must be documented with its justification.
7. If an acceptance or quality gate fails, use `/speckit.iterate.define` and `/speckit.iterate.apply` to plan and apply
   the required artifact updates, honoring `/speckit.iterate.apply`'s confirmation requirement, then return to step 2
   before rerunning quality gates.
8. Repeat the quality loop no more than three times. Track issues, resolutions, and proposed preventive updates in
   `flywheel.md` without overwriting earlier entries. `flywheel.md` entries must include for each resolved issue:
   1. Filepath(s)
   2. Line number(s) of original faulty code or documentation, if applicable
   3. Original code or text that was faulty, if applicable
   4. Insertion line number(s) for new content, if applicable
   5. Modified or newly added code or text
   6. Summary explanation of what the original issue was and how the replacement content addresses the issue to prevent
      it from recurring in the future

## Completion Report

Report the selected stage, each invoked command, completed cycles, validation evidence, unresolved findings (if any),
and the next safe action. For implementation, include the generated-program acceptance-verification result or the
documented blocking release gate.

Affected version

No response

Steps to reproduce the behavior

1. /autopilot on
2. /fleet use speckit-automate implement skill

Expected behavior

Shouldn't freeze

Additional context

• macOS 15.7.8
• bash

NOTE I am using a personal account to file this bug because my org does not allow any editing or input outside of our organization's repo with our corporate credentials. We are most definitely a paying customer.