src/skills/debating-ideas/SKILL.md
Dialectic thinking for code and architecture decisions — spawn thesis and antithesis agents, verify claims against the codebase, then synthesize. Use when user says "debate", "argue both sides", "devil's advocate", "pros and cons of approach", or wants a design decision stress-tested against actual code. For conceptual or logical claims without a codebase, use thinking-tools:dialectic instead.
npx skillsauth add alexei-led/claude-code-config debating-ideasInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
$ARGUMENTS is the question or topic to debateIf no argument provided, ask the user what they want to evaluate.
Routing rule: if the user wants open-ended idea generation, option discovery, or "what could we build/do?", explicitly say this is open-ended brainstorming and route to brainstorming-ideas or an ideation workflow. Use this skill only when there is a specific design decision, thesis, or bounded trade-off to stress-test. If no clear opposing positions exist or evidence is unavailable, stop and ask for a sharper decision instead of inventing a debate.
Use TaskCreate / TaskUpdate to track these 4 phases:
Parse the topic from $ARGUMENTS. Identify:
Frame as a clear binary or spectrum question. Examples:
Spawn two Explore agents in a single message:
Task(
subagent_type="Explore",
run_in_background=true,
description="Thesis: argue FOR",
prompt="You are arguing FOR: {position A}.
Topic: {framed question}
Build the strongest possible case:
1. Search the codebase for evidence supporting this position
2. Identify concrete benefits with file:line references
3. Anticipate and preempt counterarguments
4. Rate your confidence (high/medium/low) with reasoning
Be specific — cite code, patterns, and constraints you find.
DO NOT hedge or present both sides. Argue your position fully."
)
Task(
subagent_type="Explore",
run_in_background=true,
description="Antithesis: argue AGAINST",
prompt="You are arguing AGAINST: {position A} (i.e., FOR {position B}).
Topic: {framed question}
Build the strongest possible case:
1. Search the codebase for evidence supporting this position
2. Identify concrete risks/costs of the opposing view with file:line references
3. Anticipate and preempt counterarguments
4. Rate your confidence (high/medium/low) with reasoning
Be specific — cite code, patterns, and constraints you find.
DO NOT hedge or present both sides. Argue your position fully."
)
Collect both results:
TaskOutput(task_id=<thesis_id>, block=true)
TaskOutput(task_id=<antithesis_id>, block=true)
If either agent reports no codebase evidence, flag the debate as theory-only: "No code evidence found — debate is conceptual. Verdict confidence capped at low." Do not fabricate supporting code. Proceed with available evidence.
Synthesize into a structured verdict:
For any factual claims made by either side (file references, pattern assertions, dependency claims):
DEBATE: {topic}
==============
Thesis: {position A}
Confidence: {high/medium/low}
Key evidence: {1-2 strongest points with file refs}
Antithesis: {position B}
Confidence: {high/medium/low}
Key evidence: {1-2 strongest points with file refs}
Verdict: {position} wins because {reason}
Caveat: {position} would win if {conditions}
Verified claims: {N}/{M} checked, {K} corrected
/debating-ideas Should we split the API into microservices?
/debating-ideas Is it worth adding Redis caching to the auth flow?
/debating-ideas Monorepo vs polyrepo for our frontend packages
If the debate reaches no clear conclusion, present both positions with evidence and let the user decide.
Start Phase 1 with the topic from $ARGUMENTS.
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview.
testing
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
development
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).