claude: run /analyze in a forked subagent

[echarrod]

Summary

Adds context: fork + agent: general-purpose to the generated /analyze Claude skill so it runs in an isolated subagent context.

Refs #752 — scoped narrowly to /analyze rather than every command, because most spec-kit commands are interactive or have side effects and rely on conversation continuity.

Why /analyze specifically

/analyze is the strongest fit for context: fork in the spec-kit command set:

• Explicitly read-only. The template states STRICTLY READ-ONLY: Do not modify any files.
• Heavy inputs that collapse to a short report. Loads spec.md, plan.md, tasks.md, and the constitution; emits a compact findings table.
• No conversation history needed. The task is fully described by the skill content and $ARGUMENTS.
• Matches the docs' canonical example. Run skills in a subagent shows exactly this pattern.

Net effect: the artefact contents stay inside the subagent. The main session only sees the report — the user keeps a clean conversation context for follow-up work, which is the concern raised in #752.

Why general-purpose over Explore

Claude Code's Explore agent description warns it's unsuitable for "cross-file consistency checks, design-doc auditing, or open-ended analysis" — which is exactly what /analyze does. general-purpose has the same read-only tool surface without that caveat.

Why per-command opt-in (not a global flag)

Other spec-kit commands aren't safe to fork:

• /specify, /plan, /tasks, /implement, /clarify, /checklist, /constitution, /taskstoissues — all interactive, accept follow-up turns, or write files based on conversation context. Forking would break them.

So this PR introduces a FORK_CONTEXT_COMMANDS mapping mirroring the existing per-command ARGUMENT_HINTS pattern, with analyze as the single entry. New commands can opt in if they fit the same criteria.

Implementation

• FORK_CONTEXT_COMMANDS: dict[str, dict[str, str]] — stem → frontmatter overrides
• In ClaudeIntegration.setup(), after argument-hint injection, look up the stem in this mapping and inject each key/value via the existing _inject_frontmatter_flag helper (idempotent, so re-running setup is safe)
• Non-Claude integrations are untouched — context: fork is Claude-Code-specific frontmatter

Tests

Four new tests under TestClaudeForkContext:

• test_analyze_skill_runs_in_forked_subagent — speckit-analyze has context: fork + agent: general-purpose
• test_other_skills_do_not_fork — no other speckit-* skill gains context or agent
• test_fork_flags_inside_frontmatter — keys land in frontmatter, not body
• test_fork_injection_idempotent — re-running setup doesn't duplicate keys

Full suite: 2866 passed, 34 skipped locally.

Test plan for reviewers

1. uv run pytest tests/integrations/test_integration_claude.py -v — all 34 tests pass (30 existing + 4 new)
2. uv run specify init test-proj --ai claude --script sh --no-git --ignore-agent-tools and inspect test-proj/.claude/skills/speckit-analyze/SKILL.md — frontmatter should contain context: fork and agent: general-purpose
3. Run /speckit-analyze in a populated spec-kit project — output should be a single summarised report; the artefact contents should not appear in the main conversation

[mnriem]

Please deliver this as a preset as per https://github.com/github/spec-kit/tree/main/presets

[echarrod]

Please deliver this as a preset as per https://github.com/github/spec-kit/tree/main/presets

Hi @mnriem, my thinking was that this would be useful behaviour to all, regardless of whether you've opted in to the preset or not. Are you concerned with it becoming default behaviour?

[mnriem]

It is a matter of traceability. Not every one would want sub agents to get triggered automatically. Hence why it would be better as a preset so one can opt into it. And also making sure that the core stays agnostic as much as possible