Add --skip-frameworks flag to /workflows:review

[marcindyguda]

@kieranklaassen I am an absolute fan of the compound engineering plugin and mindset in general. I am implementing it right now in our own product which is on a completely different stack, and has a huge codebase. I want to extend our PR review specific with your sub-agents, but don't want to invoke your sub-agents directly, because there might be more in the future, but rather would like to exclude the ones who are not relevant for us.

Why

The /workflows:review command always runs Rails-specific agents (kieran-rails-reviewer, dhh-rails-reviewer, rails-turbo-expert) even on non-Rails codebases. These agents produce irrelevant findings on non-Rails repos while consuming valuable context window. The other generic agents (security, performance, architecture, etc.) are still super valuable regardless of framework. The --skip-frameworks flag lets you skip the framework-specific ones, saving context for the agents that matter.

Summary

• Adds --skip-frameworks flag to the /workflows:review command
• When passed, skips the 3 framework-specific agents (kieran-rails-reviewer, dhh-rails-reviewer, rails-turbo-expert) so non-Rails codebases get faster, more relevant reviews
• Default behavior (no flag) is unchanged — all agents run as before

Test plan

• Run /workflows:review 123 — all 13 agents should run (unchanged default)
• Run /workflows:review 123 --skip-frameworks — only 10 generic agents should run, framework-specific agents skipped
• Verify --skip-frameworks is stripped from the review target before PR lookup

🤖 Generated with Claude Code

[kieranklaassen]

Thanks for this — you're solving a real problem! Running Rails-specific agents on non-Rails codebases wastes context.

Good news: #124 already solves this with a more flexible approach. Instead of a --skip-frameworks flag, it adds a compound-engineering.local.md settings file in your project root where you configure exactly which agents to run:

---
review_agents: [code-simplicity-reviewer, security-sentinel, performance-oracle, architecture-strategist]
---

# Review Context

Our stack is Next.js + Python. Focus on API boundary security and type safety.

Running /compound-engineering-setup auto-detects your project type and creates the file with smart defaults. No Rails agents for non-Rails projects. And the markdown body gets passed to every agent as additional review context — so you can include stack-specific instructions.

This also helps with the context limit issues in #166, since you're only running the agents that matter for your stack instead of all 13.

Going to close this in favor of #124 — your use case is exactly what it's designed for. Would love your feedback once it lands!

[marcindyguda]

nice, thanks! that's going to be a great context saver :)