* feat(commands): add /compound-engineering-setup for configurable agents Adds a new setup command that allows users to configure which review agents to use instead of hardcoding them in workflows. This enables: - Multi-step onboarding with AskUserQuestion for easy setup - Auto-detection of project type (Rails, Python, TypeScript, etc.) - Three setup modes: Quick (smart defaults), Advanced, and Minimal - Configuration stored in .claude/compound-engineering.json - Support for both global (~/.claude/) and project-specific config Updated workflows to read from config: - /workflows:review - reads reviewAgents from config - /plan_review - reads planReviewAgents from config - /workflows:work - references config for reviewer agents - /workflows:compound - references config for specialized agents 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat: auto-trigger setup when no config exists Workflows now detect missing config and offer inline quick setup: - "Quick Setup" - auto-detect project type, create config, continue - "Full Setup" - run /compound-engineering-setup for customization - "Skip" - use defaults just this once This ensures users get onboarded automatically when running any workflow for the first time, without needing to know about the setup command beforehand. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat(review): wire all conditionalAgents categories Extended /workflows:review to invoke conditional agents for: - migrations (existing) - frontend (new): JS/TS/Stimulus changes - architecture (new): structural changes, 10+ files - data (new): model/ActiveRecord changes Each category reads from conditionalAgents.* config key and runs appropriate specialized agents when file patterns match. Resolves: todos/001-ready-p2-conditional-agents-not-invoked.md Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * chore: mark todo #001 as complete * feat(setup): add custom agent discovery and modify flow - Auto-detect custom agents in .claude/agents/ and ~/.claude/agents/ - Add modify existing config flow (add/remove agents, view config) - Include guide for creating custom review agents - Add customAgents mapping in config to track agent file paths - Update changelog with new config schema including customAgents Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * chore: remove completed todos directory Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * [2.29.1] Improve /workflows:brainstorm question flow - Add "Ask more questions" option at handoff phase - Clarify that Claude should ask the user questions (not wait for user) - Require resolving ALL open questions before offering to proceed Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * Simplify plugin settings: replace 486-line wizard with .local.md pattern - Rewrite setup.md (486 → 95 lines): detect project type, create .claude/compound-engineering.local.md with smart defaults - Make review.md and work.md config-aware: read agents from .local.md frontmatter, fall back to auto-detected defaults - Wire schema-drift-detector into review.md migrations conditional block - Delete technical_review.md (duplicated /plan_review) - Add disable-model-invocation to setup.md - Bump to v2.32.0 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Rewrite .claude/ paths for OpenCode/Codex targets, add npm publish workflow - Converters now rewrite .claude/ → .opencode/ (OpenCode) and .codex/ (Codex) in command bodies and agent bodies so .local.md settings work cross-platform - Apply transformContentForCodex to agent bodies (was only commands before) - Add GitHub Action to auto-publish to npm on version bump merge to main - Bump to v0.4.0 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * feat(workflows-work): require post-deploy monitoring section Add a mandatory Post-Deploy Monitoring & Validation section to the /workflows:work PR template, include no-impact fallback guidance, and enforce it in the quality checklist. * Add learnings-researcher to review workflow, fix docs site counts - Add learnings-researcher as parallel agent #14 in /workflows:review so past solutions from docs/solutions/ are surfaced during code review - Make /release-docs command invocable (remove disable-model-invocation) - Fix stale counts across docs site (agents 28→29, commands 19→24, skills 15→18, MCP servers 2→1) - Bump version to 2.32.1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Move /release-docs to local .claude/commands/, bump to 2.32.2 Repo maintenance command doesn't need to be distributed to plugin users. Update command count 24 → 23 across plugin.json, marketplace.json, and docs. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Move settings to project root: compound-engineering.local.md Tool-agnostic location — works for Claude, Codex, OpenCode without path rewriting. No global fallback, just project root. Update commands (setup, review, work) and converter tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Make /compound-engineering-setup interactive with auto-detect fast path Two paths: "Auto-configure" (one click, smart defaults) or "Customize" (pick stack, focus areas, review depth). Uses AskUserQuestion throughout. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Replace /compound-engineering-setup command with setup skill Setup is now a skill invoked on-demand when compound-engineering.local.md doesn't exist. Review and work commands just say "invoke the setup skill" instead of inlining the full setup flow. - Remove commands/setup.md (command) - Add skills/setup/SKILL.md (skill with interactive AskUserQuestion flow) - Simplify review.md and work.md to reference the skill - Counts: 29 agents, 22 commands, 19 skills Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Prepare v2.33.0 release: setup skill, configurable review agents - Bump version to 2.33.0 - Consolidate CHANGELOG entries for this branch - Fix README: update counts (29/22/19), add setup + resolve-pr-parallel skills - Remove stale /compound-engineering-setup command reference Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
4.8 KiB
name, description, argument-hint
| name | description | argument-hint |
|---|---|---|
| workflows:brainstorm | Explore requirements and approaches through collaborative dialogue before planning implementation | [feature idea or problem to explore] |
Brainstorm a Feature or Improvement
Note: The current year is 2026. Use this when dating brainstorm documents.
Brainstorming helps answer WHAT to build through collaborative dialogue. It precedes /workflows:plan, which answers HOW to build it.
Process knowledge: Load the brainstorming skill for detailed question techniques, approach exploration patterns, and YAGNI principles.
Feature Description
<feature_description> #$ARGUMENTS </feature_description>
If the feature description above is empty, ask the user: "What would you like to explore? Please describe the feature, problem, or improvement you're thinking about."
Do not proceed until you have a feature description from the user.
Execution Flow
Phase 0: Assess Requirements Clarity
Evaluate whether brainstorming is needed based on the feature description.
Clear requirements indicators:
- Specific acceptance criteria provided
- Referenced existing patterns to follow
- Described exact expected behavior
- Constrained, well-defined scope
If requirements are already clear:
Use AskUserQuestion tool to suggest: "Your requirements seem detailed enough to proceed directly to planning. Should I run /workflows:plan instead, or would you like to explore the idea further?"
Phase 1: Understand the Idea
1.1 Repository Research (Lightweight)
Run a quick repo scan to understand existing patterns:
- Task repo-research-analyst("Understand existing patterns related to: <feature_description>")
Focus on: similar features, established patterns, CLAUDE.md guidance.
1.2 Collaborative Dialogue
Use the AskUserQuestion tool to ask questions one at a time.
Guidelines (see brainstorming skill for detailed techniques):
- Prefer multiple choice when natural options exist
- Start broad (purpose, users) then narrow (constraints, edge cases)
- Validate assumptions explicitly
- Ask about success criteria
Exit condition: Continue until the idea is clear OR user says "proceed"
Phase 2: Explore Approaches
Propose 2-3 concrete approaches based on research and conversation.
For each approach, provide:
- Brief description (2-3 sentences)
- Pros and cons
- When it's best suited
Lead with your recommendation and explain why. Apply YAGNI—prefer simpler solutions.
Use AskUserQuestion tool to ask which approach the user prefers.
Phase 3: Capture the Design
Write a brainstorm document to docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md.
Document structure: See the brainstorming skill for the template format. Key sections: What We're Building, Why This Approach, Key Decisions, Open Questions.
Ensure docs/brainstorms/ directory exists before writing.
IMPORTANT: Before proceeding to Phase 4, check if there are any Open Questions listed in the brainstorm document. If there are open questions, YOU MUST ask the user about each one using AskUserQuestion before offering to proceed to planning. Move resolved questions to a "Resolved Questions" section.
Phase 4: Handoff
Use AskUserQuestion tool to present next steps:
Question: "Brainstorm captured. What would you like to do next?"
Options:
- Review and refine - Improve the document through structured self-review
- Proceed to planning - Run
/workflows:plan(will auto-detect this brainstorm) - Ask more questions - I have more questions to clarify before moving on
- Done for now - Return later
If user selects "Ask more questions": YOU (Claude) return to Phase 1.2 (Collaborative Dialogue) and continue asking the USER questions one at a time to further refine the design. The user wants YOU to probe deeper - ask about edge cases, constraints, preferences, or areas not yet explored. Continue until the user is satisfied, then return to Phase 4.
If user selects "Review and refine":
Load the document-review skill and apply it to the brainstorm document.
When document-review returns "Review complete", present next steps:
- Move to planning - Continue to
/workflows:planwith this document - Done for now - Brainstorming complete. To start planning later:
/workflows:plan [document-path]
Output Summary
When complete, display:
Brainstorm complete!
Document: docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
Key decisions:
- [Decision 1]
- [Decision 2]
Next: Run `/workflows:plan` when ready to implement.
Important Guidelines
- Stay focused on WHAT, not HOW - Implementation details belong in the plan
- Ask one question at a time - Don't overwhelm
- Apply YAGNI - Prefer simpler approaches
- Keep outputs concise - 200-300 words per section max
NEVER CODE! Just explore and document decisions.