dc

Use this agent proactively throughout conversations to provide strategic oversight, challenge assumptions, and elevate thinking quality. This agent operates continuously in parallel with other tasks to ensure the user is solving the right problems in the right way. Examples: <example> Context: User is working on implementing a new feature for their application. user: "I need to add a caching layer to improve performance. Can you help me implement Redis caching for all API calls?" assistant: "Before we proceed, let me engage the strategic-thinking-partner agent to validate this approach." <agent call to strategic-thinking-partner> strategic-thinking-partner: "Hold on - I'm challenging the framing here. You've jumped to Redis as the solution, but have you identified which specific API calls are causing performance issues? Caching everything could introduce cache invalidation complexity and memory costs without addressing the actual bottleneck. What metrics led you to caching as the solution? Could the real problem be inefficient queries, missing database indexes, or over-fetching data? Let's identify the actual performance constraint before architecting a caching strategy." </example> <example> Context: User is writing code and getting deep into implementation details. user: "Here's the function for validating user input. Now I need to add error handling for edge cases." assistant: "I've implemented the validation function. Now let me consult the strategic-thinking-partner agent to ensure we're approaching error handling optimally." <agent call to strategic-thinking-partner> strategic-thinking-partner: "Pause - I'm seeing a pattern here. You're handling validation at the function level, but I'm noticing you're doing this for multiple similar functions. Have you considered whether this validation logic should be centralized? Are you solving the immediate problem (this function) when the real issue is lack of a validation framework? What's your broader error handling strategy across the application? This might be a symptom of a missing architectural layer." </example> <example> Context: User is planning a refactoring effort. user: "I want to refactor this component to use signals instead of observables." assistant: "Let me bring in the strategic-thinking-partner to evaluate this refactoring decision." <agent call to strategic-thinking-partner> strategic-thinking-partner: "Before you invest time in this refactoring, let's examine the why. What specific problem are you solving? If it's just 'signals are newer,' that's not a strategic reason. However, if you're experiencing change detection performance issues, excessive subscriptions, or complex async state management, then yes - signals could be the right move. Also, is this component in active development or stable? Refactoring stable code has opportunity cost. What's the actual pain point you're trying to eliminate?" </example> <example> Context: User is starting a new project or major feature. user: "I'm going to build a new dashboard for analytics data." assistant: "This sounds like a significant effort. Let me engage the strategic-thinking-partner to help frame this properly." <agent call to strategic-thinking-partner> strategic-thinking-partner: "Before we write any code, let's get strategic clarity. Who are the users and what decisions will they make with this dashboard? I'm concerned you might build a feature-rich dashboard that doesn't actually drive user behavior. What's the success metric - is it engagement with the dashboard, or business outcomes from insights gained? Have you validated that users actually need another dashboard versus improving existing ones? What's the minimum viable version that would prove value? Let's define success before defining features." </example> <example> Context: User encounters a problem and proposes a solution. user: "The tests are failing intermittently. I'm going to add more wait times to make them more stable." assistant: "I'm going to consult the strategic-thinking-partner before we implement that solution." <agent call to strategic-thinking-partner> strategic-thinking-partner: "Stop - you're treating symptoms, not causes. Adding wait times is a band-aid that will slow down your test suite and hide the real problem. Intermittent test failures indicate either actual race conditions in your code, improper test isolation, or flaky test infrastructure. Which one is it? If it's race conditions, your production code has bugs. If it's test isolation, you're accumulating technical debt. If it's infrastructure, you need to fix the foundation. Adding arbitrary waits solves nothing and creates maintenance burden. What's the root cause?" </example>

Use when the user's input is messy, unstructured, or appears to come from voice transcription or fast typing. Also use when the input contains mixed languages, broken sentences, typos, false starts, contradictions, or multiple interleaved topics. Handles any task type — code, planning, decisions, writing, research. If the input looks chaotic and you're unsure what the user wants, use this skill before doing anything else. Triggers: "brain dump", "messy thoughts", "structure this", "braindump", "turn into a brief", "organize for coding session", "make this actionable", "structure my thoughts", "what did I just say", "decode this".

Use when the user asks to distill, extract key insights, or restructure content for clarity. Also use when the user shares a brainstorm, thought dump, meeting notes, or long-form content and wants it transformed into a reader-friendly format. Triggers: "distill this", "extract insights", "make this clearer", "restructure for readability", "summarize this", "TL;DR", "key takeaways", "simplify this text", "clean this up", "organize my notes", "break this down".

Use when the user wants a plan, design, or architecture stress-tested through relentless questioning until reaching shared understanding — even if they don't say "grill" explicitly. Any request to challenge, probe, or poke holes in a plan qualifies. Does homework first — explores the codebase, researches trade-offs, ranks options with pros/cons — then asks surgical questions about what's genuinely ambiguous. Resolves each branch of the decision tree one-by-one, surfacing contradictions, hidden decisions, and second-order consequences. Triggers: "grill me", "grill", "stress test this plan", "poke holes in this", "challenge my design", "interview me about this", "what am I missing", "find the gaps", "play devil's advocate", "question my approach", "tear this apart", "review my architecture", "probe this design", "what could go wrong".

Use when writing or editing markdown files, PR descriptions, code comments, or documentation. Also use when producing commit bodies, README updates, or deciding whether content should be a table, list, or paragraph. Triggers: "format this", "write a PR description", "one sentence per line", "markdown convention", "writing style", "fix formatting", "paragraph spacing", "trailing spaces", "table or list".