feat(installer): add QwenPaw agent support alongside Claude Code and Codex

[Leo (CallMeHFK)]

Summary

ResearchStudio's plugins (Idea, Reel) are standard Agent Skills (SKILL.md folders), and the installers already support provisioning them into Claude Code and Codex. This PR adds QwenPaw (agentscope-ai/QwenPaw) as a third agent runtime, and restructures the agent handling in bin/install.mjs so adding further hosts is a one-line registry entry.

What QwenPaw support means

QwenPaw organizes skills differently from Claude Code/Codex: a shared skill pool at $QWENPAW_WORKING_DIR/skill_pool/ (default ~/.qwenpaw/skill_pool/), from which skills are broadcast into per-agent workspaces (workspaces/<agent_id>/skills/). Two behaviors were verified against QwenPaw's source and docs before implementing:

• Pool entries must be real copies, not symlinks. QwenPaw's safe_skill_dir resolves skill directories and rejects anything outside the pool root, so symlinked skills (the approach install.sh uses for Claude/Codex) would be silently dropped by its scanner.
• Manually placed pool skills register on the next manifest reconcile and the QwenPaw runtime loads <working-dir>/.env into the env its skills run in — which the skills' own .env walker also reaches from the pool (≤ 4 levels up).

Changes

bin/install.mjs

• Replaces the AGENTS map with a data-driven registry (label + skillsDir(base) + pool flag); adding a new agent host is one entry.
• Interactive flow now presents a multi-select agent list (Claude Code / Codex CLI / QwenPaw) instead of the yes/no Codex follow-up; RS_AGENTS=claude,codex,qwenpaw for non-interactive runs, with graceful skipping of unknown names.
• QwenPaw target: copies skills into the resolved skill pool (mirrors QwenPaw's constant.py resolution: QWENPAW_WORKING_DIR → legacy ~/.copaw → ~/.qwenpaw), writes the merged .env into the QwenPaw working dir (other agents keep the skills-dir .env), and best-effort runs qwenpaw skills list --pool to trigger the reconcile immediately. Pool agents have no project-scoped dir, so project scope still targets the pool with an explanatory note.

install.sh

• New --qwenpaw / --no-qwenpaw flags plus QWENPAW_WORKING_DIR / QWENPAW_POOL_DIR env overrides. Pool entries are copied (cp -R), never linked. Seeds ~/.qwenpaw/.env from .env.template when absent (re-runs never overwrite), nudges a pool reconcile when the CLI is on PATH, and prints workspace-loading guidance.

READMEs — main + Idea + Reel now list QwenPaw as a supported runtime.

Verification

• node --check / bash -n clean; non-interactive dry runs against sandboxed HOME / QWENPAW_WORKING_DIR for all three agents:
  • skills land in ~/.claude/skills, ~/.codex/skills, and <qwenpaw>/skill_pool respectively;
  • .env written to <qwenpaw>/.env and confirmed reachable by the skills' env walker;
  • qwenpaw skills list --pool reconcile registered the installed skills in skill_pool/skill.json (real copies, no symlinks in the pool).
• Unknown RS_AGENTS entries are skipped with a hint listing known agents.

Note for reviewers

After a pool install, skills still need to be loaded into a QwenPaw workspace (Console → Workspace → Skills → "Load from Skill Pool", or copy into workspaces/<agent_id>/skills/ + qwenpaw skills enable ...). That's QwenPaw's own pool→workspace model; the installers print this guidance rather than guessing an agent ID.

[Leo (CallMeHFK)]

@microsoft-github-policy-service agree