[FEATURE] Support sub-agents using '--watch' flags on 'build' and 'test' commands to eliminate dry-start costs

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Improve sub-agents ability to monitor long-running processes like build or test invoked with a --watch flag and continuously report updates to the primary agent. For example, an Angular app test suite might be invoked with ng test --watch

In a workflow that asks Claude to confirm tests pass after changes, a lot of time is lost waiting for test suite spin-up. A developer avoids this wait by running the build/test suite in a second terminal with --watch, maybe a forked agent can emulate this behaviour.

Proposed Solution

My Claude workflow asks the primary agent to run the test suite after making changes, in the spirit of test-driven development's tight iteration cycles and constant vigilance to the test suite status.

A lot of time is lost waiting for the primary agent to dry-start the test suite. It would be convenient if it analyzed the test suite for the project, determined how to run the test suite with a --watch flag, and use a sub-agent monitoring the watched suite to provide low latency status updates to the primary agent.

Presumably other watch-able commands, like build, lint, format etc. could be supported.

Although this dry-start latency is especially egregious in workflows that run the test suite very often, like TDD does, it would still be beneficial for other styles of workflow to provide rapid feedback to the primary agent.

Alternative Solutions

Currently I just tolerate the extra latency waiting for test suites to start. I could run the test suite with a --watch flag on my own in a second terminal, and relay the results to Claude, but that would be cumbersome.

Priority

Low - Nice to have

Feature Category

Performance and speed

Use Case Example

Example scenario:

• I ask Claude to implement a new feature.
• It follows a TDD workflow, and uses the 'red, green, refactor' mantra to guide the order of operation.
• Claude implements a failing test, runs the suite, and verifies that the suite failed in the expected manner.
• Claude implements the code required to pass the test, and runs the test suite a second time, verifying that it fully passes.
• Claude analyzes for appropriate refactors. If any refactors are warranted, they are made, then the test suite is run again to ensure no regressions.

This covers a single cycle and implements a single requirement for the feature. Already we expect the test suite to run two or three times. That's a lot of down-time for the primary agent to wait for dry starts.

Typically a feature will require multiple cycles, each cycle targeting a single requirement. So the time loss is multiplied by the complexity of the feature.

As a developer, I avoid the dry start time loss by monitoring a second terminal with the test suite running in --watch mode. Presumably a sub-agent could emulate this.

Additional Context

_No response_