[martin-conur]

Summary

In a repo with both assistants installed, task-config set assistant claude used to keep claude and quietly uninstall kiro, which is not what anyone typing "set assistant" expects. It is now refused and changes nothing, pointing at task-config use to switch and at a new, explicit task-config remove assistant <other> to drop one.

Closes #303

What changed

• bin/task-config _set_dual: when the target is already installed (set assistant A, or set loadout A-<same tracker>), refuse with exit 1 before any preview/prompt, so --yes cannot bypass it. The message names both loadouts, task-config use A, and task-config remove assistant <other>. set loadout onto another tracker still replaces both; set tracker stays refused.
• New task-config remove assistant <B> (the mirror of add; picked over --drop-other per the PM's lean): previews via la_plan, --dry-run stops there, confirms on a TTY, la_removes only B (the local tracker's shared tasks/ scaffolding stays), sets the kept assistant active. Refuses the only installed assistant (points at set assistant / task-remove), one not installed, a different-tracker pair, and --impl.
• show on a dual repo with an active assistant: switch: task-config use <other> · launch one: task-work … --agent <other>.
• Single-assistant repos: unchanged, set assistant still swaps.

Tests

tests/dual_assistant.bats: refusal both directions and for set loadout claude-gh (clean git status, active setting untouched, kiro files present), refusal without --yes and with no prompt, remove assistant touching only .kiro/ and setting active, its --dry-run, its refusals, a single-assistant swap after a remove, the show hint both ways. The two old "keep A, remove the other" tests became remove assistant tests.

Mutation check: skipping the refusal branch, dropping its exit 1, and dropping remove's _set_active each turned tests red.

Green: ./run_tests.sh 1592/1592, tools/check-drift.sh, shellcheck -x bin/task-config.

Docs

README dual-repo section, .claude/gh-workflow.md, all seven steering templates, --help, CHANGELOG (behaviour change from #293). No task-init re-run required.

🤖 Generated with Claude Code

[martin-conur]

Spec compliance

Checked against #303; every deliverable is present.

• Refusal: set assistant A with A installed exits 1 before any preview or prompt, so --yes cannot bypass it. The message names both loadouts, task-config use A, and task-config remove assistant <other>. Nothing is changed.
• Same refusal for set loadout <A>-<same tracker>: it goes through the same _set_dual branch. set loadout onto another tracker still replaces both, and set tracker stays refused.
• Explicit removal: remove assistant <B> (the PM's lean). It previews through la_plan, --dry-run stops there, and it confirms on a TTY. It removes only B and sets the kept assistant active. It also refuses the only installed assistant, one that is not installed, a different-tracker pair, and --impl.
• Single-assistant repos: set assistant still swaps.
• show hint: the switch: task-config use <other> · launch one: task-work … --agent <other> line appears on a dual repo with an active assistant.
• Docs: README, --help, .claude/gh-workflow.md, all seven steering templates and CHANGELOG are updated. The PR body opens with ## Summary. I grepped the remaining set assistant mentions and none still describe the old "keep A, remove the other" behaviour.
• Tests: ./run_tests.sh dual_assistant passes locally, 54/54. The tests cover the cases the issue's acceptance list asks for.

Code-review findings

No blockers and no correctness issues found in bin/task-config. I read the diff for _set_dual, cmd_remove and _show_dual.

• cmd_remove guards 0 and 1 matches, the different-tracker case via _dual_tracker, and a target that is not installed before it reaches keep/gone, so keep is always set.
• _go_ahead runs before la_remove, so the dry-run and the TTY confirm are honoured.
• _show_dual picks other with grep -vxF and head -1, which is safe under pipefail here.

CI

A run exists for head 1ebaeba. At review time ShellCheck, the drift check and Rust (all variants) had passed, and the three bats jobs were still pending. I could not confirm the bats jobs as green. My local dual_assistant run passed, but PM should wait for the pending jobs before merging.

Verdict

clean. No findings to fix in this PR.