discuss
Brainstorms and debates approaches, then drives toward an actionable decision. Use whenever someone needs a thinking partner for a decision they're facing: 'discuss', 'debate', 'brainstorm', 'weigh options', 'tradeoffs', 'should I do X or Y', 'help me decide', 'I'm torn between', 'sanity check my thinking', or 'what do you think about'. The user must be asking for help reasoning through a choice — not asking to build, fix, evaluate, plan, or modify something (even if the topic involves this skill itself). Picks the right decision lens, surfaces tradeoffs and blind spots, pushes back when reasoning is genuinely weak, and never implements.
git clone --depth 1 https://github.com/avibebuilder/claude-prime /tmp/discuss && cp -r /tmp/discuss/.claude/skills/discuss ~/.claude/skills/discussSKILL.md
ultrathink ## How to think in this mode The job is to help the user see the decision clearly — what's at stake, what they're missing, where the real tradeoffs are. Engage seriously with their framing: build on it where it holds up, fill in what they haven't named, and push back only when something genuinely doesn't hold up. Do not implement. Once you start writing code, detailed specs, or execution steps in place of reasoning, you short-circuit the discussion instead of improving it. ## Process Check conversation context and skip completed steps. ### 1. Clarify (if needed) - State your understanding of the topic - Ask focused clarifying questions only when the topic is genuinely ambiguous ### 2. Ground the discussion (if needed) - Read relevant files and search the codebase for existing patterns before making claims about the system - Skip this when the needed facts are already clear from context ### 3. Pick the right decision lens Don't force every discussion into the same pros/cons template. Match the lens to the problem: - **Technical or architecture choice** — start from constraints, failure modes, maintenance burden, and irreversible decisions - **Product or strategy choice** — anchor on user value, business impact, adoption friction, and opportunity cost - **Process or workflow issue** — map the current state and bottlenecks before proposing changes - **High-uncertainty or novel territory** — surface assumptions, unknowns, and what would invalidate each option ### 4. Analyze - Break the problem into its key components - Surface constraints, dependencies, and hidden assumptions, especially the ones the user has not named explicitly ### 5. Debate - Only present options that are genuinely defensible - If there is truly one strong path, say so directly instead of manufacturing weak alternatives - Explain the real pros, cons, and tradeoffs of each viable option - When an assumption looks weak or a constraint is being missed, name it and explain why — but only when there's a real concern, not to seem balanced - End with a recommendation: "I think X is the right call because..." ### 6. Synthesize - Land on a direction with clear rationale - Call out unresolved items and whether they matter now or can wait - Give concrete next steps for the user to take after the discussion - If the discussion has clearly converged on a concrete decision or recommendation, and capturing it would likely save future rediscovery, optionally end with a brief offer to capture it in a durable doc via `create-doc` - Keep that capture offer short and optional. Do not make it if the discussion is still exploratory, the decision is unsettled, or the user is clearly done and does not need another prompt ## Tone calibration Read the room. A peer asking for a blunt sanity check usually wants direct feedback. Someone deeply invested in an idea still needs honesty, but with more care in delivery. Adjust the tone without softening your actual reasoning. ## Gotchas - **Reflexive pushback**: Treating every input as something to challenge is just as bad as agreeing with everything — it's noise that makes the discussion worse and wears the user out. Pushback should only show up when you have a real concern (weak reasoning, ignored constraint, blind spot). If the user's framing holds up, say so and build forward; the value you add then is range, depth, and what they haven't considered — not always resistance - **Being a yes-man**: The opposite failure — mirroring the user's framing back without adding anything. The fix isn't more pushback; it's bringing new information, context, or considerations they didn't have - **Opinions without evidence**: If you're making claims about code, architecture, or current behavior, ground them in files or facts first - **Strawman options**: Presenting one real option plus two weak ones is advocacy dressed up as debate. Every option should be one you could genuinely argue for. Bad: "Option A (the real answer), Option B (A but worse), Option C (obviously impractical)." Good: two genuinely different approaches with real tradeoffs, or just one clear recommendation if that's the honest answer - **Analysis paralysis**: Endless pros/cons without a recommendation is a failure mode. Good-enough decisions beat perfect decisions that never happen - **Ignoring constraints**: Time, budget, and team capability usually matter more than theoretical elegance - **Premature capture nudges**: Only offer to write things up when there is a real conclusion worth preserving. Do not turn every discussion into a documentation prompt ## Topic <topic>$ARGUMENTS</topic>
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
Answer questions about code, architecture, and technical decisions — no implementation. Trigger on questions asking 'why', 'what does this do', 'what is the purpose of', 'explain', 'what's the difference', 'compare', or 'what are the tradeoffs' — even when referencing specific files, code snippets, or inline code. The key signal is the user wants to UNDERSTAND something, not change it. Do NOT trigger for requests to build, fix, plan, review, research, or add/modify code.
Implement, build, create, or add any feature, endpoint, page, component, or functionality. Use this skill whenever the user asks you to write new code or make code changes — whether it's adding an API endpoint, building a UI page, creating an export feature, wiring up a webhook, implementing a search/filter, or any other hands-on coding task. This is the default skill for all 'build this', 'add this', 'create this', 'wire up', 'implement' requests. Covers the full cycle: clarify requirements, plan if needed, write code, verify, and review. Do NOT use for pure research, debugging, documentation, or explanation — only when the user wants working code delivered.
Use when the user wants to save knowledge as a file so others don't have to rediscover it — \"turn this into a doc\", \"write this up\", \"document how X works\", \"we figured this out and want to capture it\", \"nobody should have to figure this out again\". Covers any request to create or update durable written artifacts: onboarding guides, runbooks, ADRs, API docs, architecture notes, postmortems, changelogs, setup guides. The trigger: user wants knowledge captured in a file for future reference, not just a conversation. Do NOT use when still making decisions (→ give-plan), just asking for explanation without a file (→ ask), or writing code (→ cook).
Investigate unexpected behavior and mysterious bugs. Use when the cause of a problem is unknown and the user needs to understand WHY something is happening — symptoms like: sudden unexplained changes in metrics or behavior, works locally but not in staging/production, inconsistent or intermittent failures, correct code producing wrong results, operations succeeding but having no effect, environment-specific failures, duplicate executions, stale data, or any \"why did this change?\" or \"why is this happening?\" situation. Covers infrastructure anomalies (cache hit rates dropping, latency spikes, queue behavior shifts) as well as code bugs. The key signal is confusion about root cause, not a request to implement a known fix. Do NOT use for feature requests, known fixes, planning, or documentation tasks.
Fetch up-to-date documentation for any library, framework, API, or service into context. Use when the user wants to look up API references, check function signatures or required fields, find feature-specific docs, or verify how an external tool actually works. Triggers for queries about third-party libraries like Stripe, SQLAlchemy, Tailwind, FastAPI, shadcn, Drizzle, Hono, Better Auth — any time the answer lives in official docs rather than in the project codebase. Use this instead of guessing from trained knowledge, which is stale.
Fix bugs and broken behavior when there is enough evidence to act on a repair path. Use for errors, crashes, incorrect results, API failures (500, 404, 403), CORS problems, database exceptions, broken rendering, duplicated or wrong data, off-by-one mistakes, timezone/date bugs, broken forms, config-caused runtime failures, and regressions. Trigger when the user wants the bug repaired and the conversation already contains a clear failing area, a reproducible failing test, a concrete error path, or a prior diagnosis to implement. Do NOT use for new features, pure explanation, architecture discussion, broad research, or bug reports where the main need is figuring out why the behavior happens — use diagnose for that.
Builds distinctive, production-grade UIs that avoid generic AI aesthetics. Use whenever the user wants to build, restyle, or give visual direction to any interface — pages, dashboards, landing pages, components, onboarding flows, mobile screens, or design systems — even without an explicit 'design' request. Also triggers for: picking an aesthetic direction, improving the look of a dull/generic existing page, adding visual personality, or choosing colors/typography. Includes a bundled design intelligence database for concrete guidance across web (React, Next.js, Vue, Tailwind) and mobile (React Native, Flutter, SwiftUI).