Extension commands aren't rendered as skills for non-active skills-mode agents on add/install/upgrade

[PascalThuet]

Summary

Extension commands are not rendered as skills for an explicitly installed skills-mode agent unless that agent is the active one. They are rendered as command files instead. This affects extension add, integration install, and integration upgrade. Only integration switch renders them as skills because it makes the target the active agent first.

This is about parity for integrations that are already being registered in skills mode. It is not asking to change multi-install safety rules or make unsafe multi-install automatic.

Root cause

init-options.json tracks a single active agent (ai) and one ai_skills flag. There is no per-agent skills tracking. Extension skill rendering is scoped to that active agent:

• register_enabled_extensions_for_agent (src/specify_cli/extensions.py) computes skills_mode_active from active_agent == agent_name and is_ai_skills_enabled(init_options), so a non-active target never takes the skills path.
• _register_extension_skills / _get_skills_dir resolve the skills dir and frontmatter from init_options["ai"] (the active agent), not the target agent.
• register_commands_for_all_agents (used by extension add) has the same active-agent scoping.

So for any skills-mode agent that is not active, extensions fall back to command files.

Steps to reproduce

specify init --here --integration claude
specify extension add git
specify integration install copilot --integration-options "--skills" --force

--force is intentional here because this reproduction uses an integration that is not declared multi-install-safe today; this issue is about the files produced after the user explicitly opts into that multi-install path.

Inspect .specify/extensions/.registry and the filesystem:

• extensions.git.registered_commands contains copilot (registered as commands).
• .github/agents/speckit.git.feature.agent.md exists.
• .github/skills/speckit-git-feature/SKILL.md does not exist.

Compare with specify integration switch copilot --integration-options "--skills", which does produce .github/skills/speckit-git-feature/SKILL.md because it activates the target agent before registering.

Expected

A skills-mode agent should receive extension skills matching how its own core commands are scaffolded, when that agent is being explicitly registered or refreshed. This should provide parity with switch for add / install / upgrade, without changing which integrations are considered multi-install-safe.

Proposed direction

Make extension skill rendering agent-aware: derive the skills directory and frontmatter from the target agent's config rather than the active-agent init-options, so register_commands_for_all_agents and register_enabled_extensions_for_agent can render skills for any skills-mode agent that is already in the registration path.

This is separate from #2886, which only wires install / upgrade to call register_enabled_extensions_for_agent for parity with switch in the common active-agent case.

Scope / acceptance criteria

Keep the fix narrowly scoped to parity with switch:

• A target agent installed or upgraded in skills mode receives extension commands as SKILL.md files even when another agent remains active. For integrations that are not multi-install-safe, this applies only after the user explicitly opts into that path with --force.
• extension add applies the same target-agent-aware behavior when registering commands for all detected agents.
• Skills are rendered from the target agent integration config, including skills directory, frontmatter, argument handling, and post-processing, not from init-options["ai"].
• Default command-file registration for non-skills-mode agents remains unchanged.
• Do not change any integration's multi-install safety status or make unsafe multi-install automatic.
• Avoid introducing a broad per-agent state model unless it is required for the narrow parity fix.

For the reproduction above, the target agent should end up with .github/skills/speckit-git-feature/SKILL.md, and should not receive .github/agents/speckit.git.feature.agent.md for that extension command.

Follow-up to #2886.

[PascalThuet]

Before anyone invests in this, I want to confirm scope and preferred direction, since the fix touches shared skill-rendering code.

Which would you prefer?

1. Parity via target-agent-aware rendering — derive the skills directory and frontmatter from the agent being registered rather than from init-options["ai"], so install / upgrade / extension add render skills for a skills-mode agent the same way switch already does. Scoped per the acceptance criteria above: no change to any integration's multi-install safety, and no broad per-agent state model.
2. Block or warn on the forced multi-install of a skills-mode agent instead of writing command files — simpler, no rendering changes.
3. Status quo — keep the active-agent scoping; the command-file fallback for a non-active skills-mode agent stays documented as a known limitation (see fix: register enabled extensions for agent on integration install/upgrade #2949).

If (1) is in scope I'll open a PR along those lines. I'd rather agree the direction first than send a large change that may not match what you want.