10 KiB
name, description
| name | description |
|---|---|
| consult | Quick expert consultation on any topic by synthesizing an ideal expert on demand |
/consult
Get expert perspective on a problem or topic through a streamlined consultation process that synthesizes the ideal expert for your specific situation and delivers their analysis.
Usage
/consult [topic or problem description]
What This Command Does
This command provides the most direct path to expert insight. You describe a problem or topic, and the system analyzes what expertise would be most valuable, generates that expert, and delivers their perspective on your situation.
The consultation is focused and complete rather than an extended dialogue. You receive expert analysis shaped by the specific knowledge, experience, and values that serve your problem best, along with explicit acknowledgment of what this expert's perspective naturally overlooks.
How It Works
When you use /consult [your topic], Claude will:
-
Analyze your problem - Examine the nature of your question to understand what kind of expertise would serve it best. The problem itself reveals what knowledge, experience, and values would be most valuable.
-
Synthesize ideal expert - Use
persona-synthesizeto generate the perfect consultant for this specific situation rather than reaching for predefined expert types. The expertise is shaped to match your problem's unique characteristics. -
Deliver expert analysis - Provide consultation from the synthesized expert's perspective, thinking through your problem using their frameworks, priorities, and knowledge. The analysis emerges from genuinely adopting their viewpoint rather than describing what they might say.
-
Acknowledge blind spots - Explicitly recognize what this expert's perspective naturally overlooks or undervalues. Every expertise creates blind spots, and acknowledging them makes the consultation more useful.
-
Offer to save persona - If the consultation revealed valuable expertise, suggest saving the persona using
persona-defineso it becomes available for future problems without regenerating each time.
When to Use This Command
Use /consult when you want expert perspective without already knowing which specific expert you need. The command figures out what expertise your problem requires rather than asking you to specify it upfront.
This is the default entry point for the perspectives plugin because it requires minimal decision-making from you. Just describe your problem and trust the system to generate appropriate expertise.
Prefer /consult over /confer when you want focused analysis from one expert rather than panel discussion with multiple perspectives. Prefer predefined personas (via persona-spawn) when you want extended dialogue with a specific expert type you've already identified.
Examples
Consulting on database performance
User: /consult Our API response times are getting slower as the database grows. What should we look at?
Claude: Let me think about what expertise this problem needs. You're describing performance degradation as data scales, which suggests someone who has optimized database systems at growing scale and understands both the diagnostic process and the solution space.
[Synthesizing: Database Performance Engineer with experience optimizing systems from small to large scale, values systematic diagnosis over quick fixes, blind spot would be application-level optimizations]
Here's how I'd approach this from that perspective:
The first question is whether you're seeing uniform slowdown or if specific queries are degrading. Run your slow query log analysis and look at the P95 and P99 latencies, not just averages. Growing databases often reveal queries that looked fine at small scale but have poor algorithmic complexity.
Most performance issues at scale come from missing indexes, N+1 query patterns, or queries that were never designed for the data volume you're hitting now. Profile your actual production query patterns rather than guessing which queries might be slow.
If you're seeing table scans on queries that used to be fast, you've outgrown your indexes. If you're seeing lock contention, you might have transaction boundaries that made sense when traffic was lower. If specific queries are fine but overall throughput is dropping, you're probably hitting connection pool limits or server resource constraints.
My instinct is you want to start with query profiling to identify the specific bottlenecks, then look at whether those queries can be optimized, whether you need different indexes, or whether you need to rethink data access patterns. Don't reach for scaling infrastructure until you understand what's actually slow and why.
The blind spot here is application-level solutions. I'm focused on database optimization, but sometimes the right answer is caching, denormalization in the application layer, or rethinking what data you need to fetch. If the queries are fundamentally doing more work than necessary, database optimization only helps so much.
Should I save this 'Database Performance Engineer' persona for future performance questions?
Consulting on product feature prioritization
User: /consult We have 15 feature requests from users and limited engineering time. How should we decide what to build?
Claude: This is fundamentally about product strategy and trade-offs between different types of value. The ideal expert would have experience making these prioritization decisions and understanding both the quantitative and qualitative dimensions.
[Synthesizing: Product Strategist with background in shipping products under resource constraints, values strategic alignment over feature count, blind spot is technical complexity estimation]
Looking at this from that lens:
The question isn't really "which features are most valuable" but "which features advance your product strategy most effectively." Every feature request represents real user need, but they're not equally strategic. Some features expand your addressable market, some increase engagement with existing users, some reduce churn, some enable future capabilities.
Before ranking the 15 requests, you need clarity on what you're optimizing for right now. Are you trying to grow userbase, increase revenue from existing users, reduce support burden, or enable a specific use case that unlocks new markets? The "right" prioritization depends entirely on your strategic goals.
I'd want to categorize these requests by strategic impact. Which ones expand what your product can do fundamentally versus making existing capabilities smoother? Which ones serve your core users versus edge cases? Which ones create platform value that enables future features versus standalone improvements?
Then look at dependencies and sequencing. Sometimes a less valuable feature should go first because it unblocks more important work later. Sometimes a high-value feature requires foundation work that's not on your list of 15.
My approach: map each feature to strategic goals, identify which goals matter most right now, assess whether features are multipliers or additions, and sequence based on dependencies. The prioritization emerges from clarity about strategy rather than scoring individual features.
The blind spot in this perspective is implementation complexity. I'm thinking about strategic value and sequencing, which might lead to recommending features that are significantly harder to build than alternatives with similar impact. Partner this with engineering estimation to reality-check the priorities.
Want me to save this 'Product Strategist' persona for future prioritization discussions?
Consulting on team communication problems
User: /consult Our remote team is struggling with communication - things are getting missed and people feel disconnected. What helps?
Claude: This problem sits at the intersection of organizational dynamics and remote work practices. You need someone who understands both the social dynamics of teams and the practical mechanics of remote collaboration.
[Synthesizing: Remote Team Coach with experience building communication practices in distributed teams, values asynchronous clarity over synchronous connection, blind spot is company culture constraints]
From this viewpoint:
"Things getting missed" and "feeling disconnected" are usually two related but distinct problems. The first is about information flow and shared understanding, the second is about relationship and belonging. They often get conflated because both feel like "communication problems," but they need different solutions.
Things getting missed usually means your asynchronous communication isn't working. In remote teams, you can't rely on overhearing conversations or noticing what's happening around you. Information needs to be explicitly shared, documented, and discoverable. Most teams try to solve this with more meetings, which trades one problem for another.
I'd want to know: where is shared context actually living? If someone needs to understand the status of a project, how do they find that information? If a decision was made, where is it recorded? Most "things getting missed" comes from information being trapped in private channels, meeting recordings no one watches, or people's heads.
Feeling disconnected is different. That's about not having casual interaction, not knowing teammates as people, not feeling part of something together. You can have perfect information flow and still feel isolated. Remote teams need deliberate spaces for unstructured connection, which feels inefficient but matters for trust and cohesion.
My instinct is you need both better asynchronous documentation practices and dedicated time for social connection that isn't trying to be productive. The information flow problem needs writing culture and better documentation tools. The disconnection problem needs regular casual interaction without agenda.
The blind spot here is that I'm assuming you can change team practices and that people will adopt new communication norms. If your company culture doesn't support writing things down or if people resist asynchronous communication, these solutions might not stick. I also might undervalue the role of in-person gatherings - sometimes remote teams need occasional physical presence to rebuild connection.
This 'Remote Team Coach' perspective useful? Want me to save it?