feat(agents): tackle-issue and PR work must dispatch subagents whenever possible

[Luis85]

Problem or gap

When the orchestrating agent works on a GitHub issue or PR (e.g. via /issue:tackle, the issue-tackle conductor, or general PR follow-up), it tends to perform task resolution inline in the main agent context instead of dispatching to specialist subagents. This:

• Pollutes the main context with implementation detail that should stay scoped to a specialist.
• Bypasses the deliberate tool-scoping in .claude/agents/ (e.g. dev, qa, reviewer, architect) that enforces separation of concerns.
• Loses the parallelism win — independent tasks that could fan out to subagents run sequentially in one context window.
• Conflicts with the constitution's Article VI — Agent Specialisation (memory/constitution.md).

Current behaviour

Conductor reads the issue / PR → identifies tasks → executes them itself (Edit/Write/Bash) inside the main loop, even when a stage-mapped subagent (dev, qa, reviewer, etc.) or a general-purpose / Explore agent would be a better fit.

Expected behaviour

1. Default to dispatch. When working on an issue or PR, the conductor must evaluate each task and dispatch to a subagent whenever the task fits an existing agent class (lifecycle stage agents, Explore, Plan, general-purpose, claude-code-guide, etc.).
2. Inline only when justified. The conductor only resolves a task in its own context when (a) no subagent fits, (b) the task is a one-shot trivial edit, or (c) the task requires conversational state the conductor already holds. The reason must be stated.
3. Parallelism by default. Independent tasks within the same issue/PR are dispatched in parallel via a single message with multiple Agent tool calls (per superpowers:dispatching-parallel-agents).
4. PR review feedback applies too. When draining PR review comments, each independent finding should be considered for subagent dispatch (e.g. reviewer for re-review, dev for code fixes, qa for test follow-ups).

Why it matters

• Keeps the main conductor context lean and focused on orchestration, gating, and user interaction.
• Honors the deliberate tool restrictions on each agent class — see AGENTS.md agent-class table.
• Unlocks parallel execution for independent work, matching the superpowers:dispatching-parallel-agents and superpowers:subagent-driven-development skills already in the kit.
• Aligns with constitution Article VI (Agent Specialisation) and Article II (Separation of Concerns).

Acceptance criteria

• .claude/skills/tackle-issue/SKILL.md gains an explicit rule: every task or finding triages to a subagent first; inline execution requires a stated justification.
• .claude/agents/issue-breakdown.md and .claude/agents/issue-draft.md reference the same rule for their respective scopes.
• AGENTS.md operating rules add a "Dispatch by default" bullet covering issue/PR work.
• PR review-loop guidance (feedback_pr_review_loop.md) is updated so independent review findings are considered for parallel subagent dispatch.
• Documentation cross-links the existing superpowers:dispatching-parallel-agents and superpowers:subagent-driven-development skills.

Alternatives considered

• Hard rule, no inline allowed. Rejected — too rigid for trivial one-line fixes where dispatch overhead exceeds the work itself.
• Leave it to the model's judgment. Rejected — current behaviour shows the default drift is toward inline execution; an explicit rule is needed.

Does this touch the constitution? (memory/constitution.md)

• Yes — an ADR will be needed before implementation
• No — reinforces existing Article VI; no amendment required.

References

• memory/constitution.md — Article VI (Agent Specialisation), Article II (Separation of Concerns)
• AGENTS.md — agent-class table
• .claude/skills/tackle-issue/SKILL.md — issue-tackle conductor
• superpowers:dispatching-parallel-agents skill
• superpowers:subagent-driven-development skill
• Sibling: bug: agents working on issues don't create dedicated worktrees #459 (worktrees for issue work)