Subagent Development Mode Skill

subagent-development-mode.md

name	subagent-development-mode
description	Coordinate explicitly requested subagent-based development through focused implementation, separate review cycles, longer-running waits, and optional git checkpoints at verified phase boundaries. Use when the user asks for subagents, delegated development, worker/reviewer loops, or structured multi-agent development for a clear coding task.

Subagent Development Mode

Use this skill to keep the main conversation focused while development work is delegated into small, reviewable units.

Start from the user's actual goal. If the task is unclear, ask for clarification before delegating.

Core Workflow

For complex tasks, break the work into independently verifiable subtasks. Each subtask must go through this cycle before moving on:

1. Subagent Development

   • Assign one focused subtask to one development subagent.
   • Do not combine unrelated implementation tasks in the same subagent.
   • Give the subagent clear ownership of files, modules, or responsibility boundaries.
   • Tell the subagent that other agents may be working in the codebase and that it must not revert unrelated changes.
   • Ask the subagent to implement the change and report changed files, assumptions, and verification performed.

2. Subagent Review

   • Use a separate review pass for the completed subtask.
   • Review requirement coverage, correctness, edge cases, regressions, style, maintainability, and test coverage.
   • Prefer concrete findings with file and line references.
   • Treat missing verification as a review concern.

3. Iterate Until Passed

   • If review fails, send the findings back for a focused fix.
   • Repeat development and review until the subtask passes.
   • Do not start dependent subtasks before the current subtask has passed review.

Main Context Rules

Keep the main conversation limited to:

• Task decomposition
• Key architectural or product decisions
• Subagent assignments
• Review outcomes
• Integration notes
• Final summary and verification

Do not copy full subagent reasoning into the main context unless it affects a decision.

Waiting And Long-Running Subagents

Subagent work may take a long time. Prefer longer waits when the subagent is actively working or has not clearly stalled.

• Use longer wait_agent timeouts for substantial development or review tasks.
• Do not interrupt or close a subagent only because it is slow.
• Treat a subagent as stalled only when there is strong evidence, such as repeated timeout with no progress, explicit failure, tool deadlock, or a result that cannot complete the assigned task.
• While waiting, continue non-overlapping main-context work when possible.
• Avoid repeatedly polling at short intervals unless the next main step is blocked and the subagent is expected to finish soon.

Git Checkpoints

At suitable phase boundaries, create a git commit when it is appropriate and allowed.

Good commit points include:

• After one independently verifiable subtask passes review.
• After an integration step passes verification.
• After a meaningful bug fix or feature slice is complete.
• Before starting a risky follow-up change, when the current state is coherent.

Commit rules:

• Never run git commands in parallel.
• Inspect the worktree before committing.
• Commit only changes that belong to the completed subtask or integration step.
• Do not include unrelated user changes or unrelated agent changes.
• If unrelated changes exist in the same files, pause and clarify before committing.
• Use concise commit messages that describe the completed behavior, not the process.
• Do not commit failing, partially reviewed, or knowingly inconsistent work unless the user explicitly requests a checkpoint commit.

When To Skip Subagents

Skip subagent mode for small, self-contained tasks where delegation would add more process than value.

Even when skipping subagents, perform a basic self-check before finalizing:

• Confirm the change matches the request.
• Check edge cases touched by the change.
• Run relevant tests or explain why they were not run.
• Summarize the result clearly.

Subtask Design Rules

Each delegated subtask must be:

• Focused: one responsibility only.
• Verifiable: success can be checked independently.
• Bounded: clear file/module ownership or output expectation.
• Non-overlapping: avoid write conflicts with other active subtasks.
• Useful: it must materially advance the user's requested outcome.

Completion Rules

Close completed subagents promptly after their work passes review.

Before final response, confirm:

• All subtasks passed review.
• Integrated work is coherent across subtasks.
• Relevant verification was performed.
• Remaining risks or skipped checks are stated plainly.