feat: add context: fork to all skills and commands

[nucliweb]

Closes #35

What

Adds context: fork to the YAML frontmatter of all 20 SKILL.md files and all 7 .claude/commands/*.md slash commands.

Why

Skills and commands currently inject their instructions directly into the active conversation context. With context: fork, each skill or command runs in an isolated subagent context instead, which brings five concrete benefits:

1. Context isolation — the skill runs free from prior conversation history
2. Consistent, repeatable execution — same clean state on every invocation
3. Token efficiency — execution tokens are spent in the fork, not the main session
4. Stronger skill fidelity — harder for the agent to rationalize skipping steps
5. Cleaner handoff — only the result surfaces back, not intermediate reasoning

Per the official docs, .claude/commands/ files and SKILL.md files share the same frontmatter spec and context: fork is valid in both.

Files changed

Commands (.claude/commands/) — 7 files
Skills (skills/*/SKILL.md) — 20 files

[federicobartoli]

Thanks for the PR — the rationale for context: fork is solid.

However, I have some doubts after reading the docs closely.

The commands are good candidates for fork. Files like review.md ("Review the current changes across all five axes"), code-simplify.md ("Simplify recently changed code"), and ship.md ("Run through the complete pre-launch checklist") are self-contained tasks with explicit instructions — exactly what context: fork is designed for.

The SKILL.md files are a different story. They're hybrid documents — they contain process steps but also large sections of reference material ("When to Use", "Common Rationalizations", "Red Flags", "Handling Disagreements"). They don't have a self-contained task; the task comes from the command that invokes them. The docs warn:

"context: fork only makes sense for skills with explicit instructions. If your skill contains guidelines like 'use these API conventions' without a task, the subagent receives the guidelines but no actionable prompt, and returns without meaningful output."

Subagent nesting is a concern. Every command starts with Invoke the agent-skills:xxx skill. If the command runs as a fork (subagent) and the invoked skill also has context: fork, the subagent would need to spawn another subagent — but the subagent docs state: "subagents cannot spawn other subagents".

So context: fork on the commands could work well, but then the skills they invoke should probably NOT have context: fork — otherwise you hit the nesting limitation. Have you tested this interaction?

[nucliweb]

Thanks @federicobartoli, you're right on both counts.

I verified the nesting limitation in the official docs:

"This prevents infinite nesting (subagents cannot spawn other subagents)" — sub-agents docs

And the warning about guidelines-only skills also applies here — SKILL.md files are hybrid documents with reference sections (When to Use, Common Rationalizations, Red Flags) that don't form a self-contained task prompt.

I've pushed a fix: context: fork is now removed from all 20 SKILL.md files. The 7 .claude/commands/ files keep it, since each command IS a self-contained task with explicit instructions.

Good catch, learned something new about subagent architecture here.

[federicobartoli]

Nice fix on removing context: fork from the SKILL.md files — the PR is much cleaner now.

One more thought after looking at the individual commands: context: fork isolates the subagent from conversation history, which works great for commands that operate purely on the current codebase state but could be a problem for commands that depend on what the user discussed earlier.

Good fit for fork:

• /review — operates on staged/recent commits, self-contained
• /code-simplify — operates on recently changed files, self-contained
• /ship — runs a checklist against the current codebase, self-contained

Potentially problematic:

• /spec — the command itself says "Ask clarifying questions about the objective and target users", but the forked subagent doesn't have AskUserQuestion and can't see prior conversation where the user may have described what they want to build
• /plan — needs to understand what to plan, which often comes from conversation context
• /build — "Pick the next pending task from the plan" works if tasks are in a file, but if they were discussed in conversation the subagent is blind. Also loses Agent (no parallel work) and TodoWrite

Borderline:

• /test — depends on whether the user described the bug/feature in conversation or if it's discoverable from code alone

Have you tested all seven commands with fork in a real session (not just single-prompt)? I'd be curious to hear your results. I'll take the time to test them all end-to-end on my side too.

Thanks for iterating on this — the discussion has been valuable!

[nucliweb]

Closing this in favor of the consolidated approach in #316, same direction as #272.

Rather than editing context: fork into the frontmatter of every skill and command by hand, #316 keeps the shared SKILL.md files portable (spec fields top-level, vendor config under metadata or in per-agent adapter files) and proposes a generator that emits the per-agent output from a single source of truth. The Claude Code context: fork + allowed-tools pattern from this PR is captured there as the canonical home for that guidance.

The intent here is good and still wanted, it just belongs in the per-agent config doc rather than as global frontmatter changes. Folding it into #316. Thanks!