ReddRadar
Agent skill
reasoning-dialectical
Synthesize competing positions through structured thesis-antithesis-synthesis process. Use when stakeholders disagree, trade-offs exist, or multiple valid perspectives need integration. Produces integrated positions with acknowledged trade-offs.
Install this agent skill to your Project
npx add-skill https://github.com/aiskillstore/marketplace/tree/main/skills/bellabe/reasoning-dialectical
SKILL.md
Dialectical Reasoning
Synthesize opposing views into higher-order resolution. The logic of productive disagreement.
Type Signature
Dialectical : Thesis → Antithesis → Synthesis
Where:
Thesis : Position × Evidence × Stakeholder → ArgumentA
Antithesis : ArgumentA → CounterPosition × Evidence × Stakeholder → ArgumentB
Synthesis : (ArgumentA, ArgumentB) → IntegratedPosition × Tradeoffs
When to Use
Use dialectical when:
- Stakeholders hold opposing valid positions
- Trade-offs need explicit analysis
- Strategic tension requires resolution
- Multiple perspectives each have merit
- "On one hand... on the other" situations
Don't use when:
- Cause-effect chain needed → Use Causal
- Explaining observation → Use Abductive
- Evaluating past decisions → Use Counterfactual
Core Principles
Charitable Interpretation
Each position must be represented at its strongest:
- Steel-man, don't straw-man
- Assume good faith and valid reasoning
- Identify the kernel of truth in each view
Genuine Synthesis
Synthesis is NOT:
- Compromise (splitting the difference)
- Victory (one side wins)
- Avoidance (postpone decision)
Synthesis IS:
- Integration at higher level of abstraction
- Resolution that addresses underlying concerns
- New position that transcends original framing
Three-Stage Process
Stage 1: Thesis
Purpose: Articulate first position at maximum strength.
Components:
thesis:
position:
statement: "Core claim being made"
underlying_concern: "What this position is really about"
stakeholder:
who: "Person/team holding this view"
role: "Their organizational function"
incentives: "What they optimize for"
evidence:
supporting:
- claim: "Evidence point"
source: "Where this comes from"
strength: 0.0-1.0
empirical: [DataPoint]
logical: [Argument]
implications:
if_adopted: "What happens if we go this way"
risks: [Risk]
benefits: [Benefit]
Example:
thesis:
position:
statement: "We should prioritize enterprise features over SMB growth"
underlying_concern: "Revenue concentration and deal size efficiency"
stakeholder:
who: "Sales leadership"
role: "Revenue generation"
incentives: "ARR, deal size, quota attainment"
evidence:
supporting:
- claim: "Enterprise deals average $400K vs SMB $5K"
source: "Q3 sales data"
strength: 0.95
- claim: "Sales cost per $ revenue 5x lower for enterprise"
source: "CAC analysis"
strength: 0.85
empirical:
- "3 enterprise deals = entire SMB revenue"
- "Enterprise churn 3% vs SMB 8%"
implications:
if_adopted: "Focus engineering on enterprise features, reduce SMB investment"
risks:
- "Lose SMB market to competitors"
- "Revenue concentration risk"
benefits:
- "Higher margins"
- "Larger average deal"
Stage 2: Antithesis
Purpose: Articulate counter-position at maximum strength.
Process:
- Identify what thesis misses or undervalues
- Find stakeholder with opposing view
- Build strongest case for alternative
- Identify where thesis assumptions break
Components:
antithesis:
position:
statement: "Counter claim"
underlying_concern: "What this position is really about"
stakeholder:
who: "Person/team holding this view"
role: "Their organizational function"
incentives: "What they optimize for"
critique_of_thesis:
- assumption_challenged: "Thesis assumes X"
counter_evidence: "But actually Y"
- risk_identified: "Thesis ignores Z"
evidence:
supporting: [EvidencePoint]
empirical: [DataPoint]
logical: [Argument]
implications:
if_adopted: "What happens if we go this way"
risks: [Risk]
benefits: [Benefit]
Example:
antithesis:
position:
statement: "SMB volume creates the foundation for sustainable growth"
underlying_concern: "Market presence, product iteration, and risk distribution"
stakeholder:
who: "Product leadership"
role: "Product-market fit and growth"
incentives: "Usage, retention, feature validation"
critique_of_thesis:
- assumption_challenged: "Enterprise features drive growth"
counter_evidence: "SMB usage generates product insights 10x faster"
- assumption_challenged: "Revenue concentration is acceptable"
counter_evidence: "Losing 1 enterprise deal = losing 80 SMB accounts"
- risk_identified: "Enterprise sales cycle is 9 months"
evidence:
supporting:
- claim: "SMB accounts generate 80% of feature requests"
source: "Product feedback analysis"
strength: 0.90
- claim: "SMB provides faster iteration cycles"
source: "Release metrics"
strength: 0.85
empirical:
- "SMB churn prediction accuracy 95% vs enterprise 60%"
- "Product improvements from SMB feedback shipped in 2 weeks"
implications:
if_adopted: "Maintain SMB investment, use as product lab"
risks:
- "Slower revenue growth short-term"
- "Lower margin overall"
benefits:
- "Diversified revenue base"
- "Faster product iteration"
- "Lower concentration risk"
Stage 3: Synthesis
Purpose: Integrate positions at higher level, resolving underlying tensions.
Synthesis Approaches:
| Approach | When to Use | Example |
|---|---|---|
| Integration | Both positions address valid concerns | "Enterprise revenue + SMB as product lab" |
| Sequencing | Temporal resolution possible | "SMB first for PMF, then enterprise scale" |
| Segmentation | Different contexts warrant different approaches | "SMB for product X, Enterprise for product Y" |
| Reframing | Original dichotomy was false | "The real question isn't SMB vs Enterprise, it's time-to-value" |
| Transcendence | Higher goal subsumes both | "Optimize for sustainable unit economics regardless of segment" |
Synthesis Components:
synthesis:
integrated_position:
statement: "What we will actually do"
framing: "How this resolves the tension"
how_thesis_is_addressed:
concern_validated: "What's true about thesis"
how_incorporated: "How we address that concern"
how_antithesis_is_addressed:
concern_validated: "What's true about antithesis"
how_incorporated: "How we address that concern"
trade_offs_acknowledged:
- trade_off: "What we're giving up"
mitigation: "How we reduce impact"
accepted_by: "Stakeholder who accepts this"
resolution_type: integration | sequencing | segmentation | reframing | transcendence
implementation:
actions: [Action]
metrics: [Metric] # How we know it's working
review_date: date # When we reassess
Example:
synthesis:
integrated_position:
statement: "SMB as rapid learning engine, enterprise as revenue engine,
with explicit feature graduation path"
framing: "Not SMB vs Enterprise, but learning velocity vs revenue efficiency
with a bridge between them"
how_thesis_is_addressed:
concern_validated: "Enterprise deals are more efficient per dollar"
how_incorporated: "Maintain enterprise sales motion, prioritize enterprise
features that have been validated through SMB"
how_antithesis_is_addressed:
concern_validated: "SMB generates faster product learning"
how_incorporated: "Protect SMB investment as product lab, use SMB metrics
to prioritize enterprise features"
trade_offs_acknowledged:
- trade_off: "Some enterprise-only features will ship slower"
mitigation: "Identify 'must have' enterprise features, fast-track those"
accepted_by: "Sales leadership (with fast-track list)"
- trade_off: "Some SMB features won't graduate to enterprise"
mitigation: "Clear graduation criteria defined upfront"
accepted_by: "Product leadership (with criteria agreement)"
resolution_type: integration
implementation:
actions:
- "Define feature graduation criteria (Product + Sales)"
- "Create SMB → Enterprise feature pipeline"
- "Allocate 60% engineering to graduated features, 40% to SMB lab"
metrics:
- "SMB feature graduation rate (target: 3/month)"
- "Enterprise close rate on graduated features (target: +20%)"
- "Combined revenue growth (target: 30% QoQ)"
review_date: "End of Q2"
Quality Gates
| Gate | Requirement | Failure Action |
|---|---|---|
| Thesis strength | Steel-manned, evidence-backed | Strengthen before proceeding |
| Antithesis genuine | Not straw-man, different stakeholder | Find genuine opposition |
| Synthesis integrative | Not compromise or victory | Reframe until true synthesis |
| Trade-offs explicit | All parties acknowledge costs | Surface hidden disagreements |
| Actionable | Concrete next steps | Add implementation detail |
Stakeholder Agreement Protocol
Synthesis isn't complete until affected stakeholders acknowledge:
- Their concern was understood (thesis/antithesis accurately represented)
- The synthesis addresses their core interest (not just their stated position)
- They accept the trade-offs (explicitly, not assumed)
stakeholder_acknowledgment:
thesis_stakeholder:
name: "Sales leadership"
concern_understood: true
synthesis_addresses_concern: true
accepts_trade_offs: true
conditions: "Fast-track list for critical enterprise features"
antithesis_stakeholder:
name: "Product leadership"
concern_understood: true
synthesis_addresses_concern: true
accepts_trade_offs: true
conditions: "Clear graduation criteria before implementation"
Common Failure Modes
| Failure | Symptom | Fix |
|---|---|---|
| False dichotomy | Positions aren't truly opposed | Reframe the actual tension |
| Straw-man | Weak representation of one side | Involve actual stakeholder |
| Mushy middle | Synthesis is just "do both" | Force resource allocation |
| Unacknowledged loss | Trade-offs hidden | Surface what's being given up |
| No implementation | Synthesis is abstract | Add concrete actions |
Output Contract
dialectical_output:
thesis:
position: string
stakeholder: string
evidence: [EvidencePoint]
strength: float # 0.0-1.0
antithesis:
position: string
stakeholder: string
evidence: [EvidencePoint]
strength: float
synthesis:
position: string
resolution_type: string
confidence: float
integration:
thesis_addressed: string
antithesis_addressed: string
trade_offs:
- trade_off: string
mitigation: string
accepted_by: string
stakeholder_agreement:
- stakeholder: string
agrees: bool
conditions: optional<string>
implementation:
actions: [string]
metrics: [string]
review_date: date
next:
suggested_mode: ReasoningMode # Usually causal
canvas_updates: [string]
trace:
duration_ms: int
rounds_of_refinement: int
Example Execution
Context: "Engineering wants to rebuild core platform (6 months). Sales wants new features for Q2 deals."
Stage 1 - Thesis (Engineering):
Position: "Technical debt is blocking velocity. Rebuild now or pay 10x later."
Evidence:
- Deploy time increased 300% YoY
- 40% of sprint spent on workarounds
- 3 critical bugs from architecture issues
Underlying concern: Sustainable development velocity
Stage 2 - Antithesis (Sales):
Position: "We have $2M in pipeline dependent on Q2 features. Delay = lose deals."
Evidence:
- 5 enterprise deals waiting on specific features
- Competitor launching similar features in March
- Q2 quota at risk without new capabilities
Underlying concern: Revenue target attainment
Stage 3 - Synthesis:
Integrated position: "Strangler fig pattern - rebuild incrementally while
delivering high-priority features"
How thesis addressed: Platform rebuild happens, but in modules alongside features
How antithesis addressed: Q2 features delivered, no delay
Trade-offs:
- Rebuild takes 9 months instead of 6 (Engineering accepts)
- Only top 3 features in Q2, not all 5 (Sales accepts with prioritization input)
Resolution type: Integration via sequencing
Implementation:
- Week 1: Joint prioritization session (top 3 features + first rebuild module)
- Q2: Deliver features on new modules where possible
- Q3-Q4: Complete rebuild with feature delivery continuing
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
aiskillstore/marketplace
perigon-backend
Perigon ASP.NET Core + EF Core + Aspire conventions
aiskillstore/marketplace
perigon-agent
Pointers for Copilot/agents to apply Perigon conventions
aiskillstore/marketplace
perigon-angular
Angular 21+ standalone/Material/signal conventions for Perigon WebApp
aiskillstore/marketplace
fastapi-mastery
Comprehensive FastAPI development skill covering REST API creation, routing, request/response handling, validation, authentication, database integration, middleware, and deployment. Use when working with FastAPI projects, building APIs, implementing CRUD operations, setting up authentication/authorization, integrating databases (SQL/NoSQL), adding middleware, handling WebSockets, or deploying FastAPI applications. Triggered by requests involving .py files with FastAPI code, API endpoint creation, Pydantic models, or FastAPI-specific features.
aiskillstore/marketplace
context7-efficient
Token-efficient library documentation fetcher using Context7 MCP with 86.8% token savings through intelligent shell pipeline filtering. Fetches code examples, API references, and best practices for JavaScript, Python, Go, Rust, and other libraries. Use when users ask about library documentation, need code examples, want API usage patterns, are learning a new framework, need syntax reference, or troubleshooting with library-specific information. Triggers include questions like "Show me React hooks", "How do I use Prisma", "What's the Next.js routing syntax", or any request for library/framework documentation.
aiskillstore/marketplace
browser-use
Browser automation using Playwright MCP. Navigate websites, fill forms, click elements, take screenshots, and extract data. Use when tasks require web browsing, form submission, web scraping, UI testing, or any browser interaction.
Didn't find tool you were looking for?