second-opinion_skill

Overview

This skill proactively suggests getting another LLM’s perspective when a user faces non-trivial design, security, or trade-off decisions. It identifies situations where a second opinion can reduce risk and surface alternative approaches. Suggestions are tailored to the context and include options for public or private/model-comparison reviews.

How this skill works

The skill scans the user query for trigger signals like architectural decisions, complex trade-offs, or security-critical code, and for explicit phrases such as “second opinion,” “sanity check,” or “what do you think.” When triggered, it offers targeted follow-up commands (e.g., codex, gemini, ollama, llm-compare) and recommends the best command based on privacy and intent. It avoids interrupting users during simple tasks, active implementation, or when the user has firmly decided.

When to use it

• Choosing between major architectural patterns or service decompositions
• Evaluating complex trade-offs (performance vs readability, flexibility vs simplicity)
• Reviewing security-sensitive or privacy-related code (auth, crypto, PII handling)
• Inspecting performance-critical or concurrency-heavy implementations
• When the user explicitly asks for another perspective, sanity check, or second opinion

Best practices

• Be specific when asking for a second opinion — include goals, constraints, and context
• Use /ollama for proprietary or sensitive code to keep data local
• Use /llm-compare to surface differing model perspectives on ambiguous design choices
• Prefer targeted commands: /codex for deep analysis, /gemini for quick alternate takes
• Respect the user’s flow: don’t suggest when they’re actively implementing or have declined extra opinions

Example use cases

• Debating monorepo vs multi-repo for a microservices landscape and wanting model comparisons
• Reviewing JWT validation or authentication logic and requesting an extra security-focused review
• Assessing a concurrency algorithm for subtle race conditions and asking for edge-case analysis
• Deciding between repository vs service layer patterns and seeking varied trade-offs from multiple models
• Choosing between REST and GraphQL for a public API and wanting different model viewpoints