Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计提醒

devils-advocate魔鬼代言人

Agent Skill

devils-advocate 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

879

周安装

37

GitHub Stars

1

下载量

308
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:devils-advocate(魔鬼代言人)
来源仓库:https://github.com/wojons/skills
仓库路径:skills/devils-advocate
安装命令:
npx skills add https://github.com/wojons/skills --skill devils-advocate
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/wojons/skills --skill devils-advocate

简介

devils-advocate 用于查找、检索和筛选相关信息,支持关键词匹配。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中快速定位候选结果。
  • 通过 npx skills add 命令从指定仓库安装,需结合原始 README 核验用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网或文件操作。
  • 注意该技能当前无底部简介,实际能力依赖仓库内实现。

SKILL.md

Devil's Advocate

Systematically challenge ideas, assumptions, designs, and decisions by playing devil's advocate to identify weaknesses, blind spots, and alternative perspectives before committing to a course of action.

When to use me

Use this skill when:

  • A team seems to be converging on a solution without debate
  • Important decisions are being made based on consensus rather than evidence
  • You need to stress-test ideas before implementation
  • Identifying potential failure modes and risks
  • Preventing groupthink and confirmation bias
  • Evaluating multiple alternatives before choosing
  • Preparing for stakeholder challenges or objections
  • Building resilience against criticism and failure

What I do

1. Argument Deconstruction

  • Identify core claims and assumptions in proposals, designs, or decisions
  • Analyze supporting evidence for strength, relevance, and reliability
  • Map logical connections between premises and conclusions
  • Detect rhetorical fallacies and cognitive biases in reasoning
  • Surface implicit beliefs that aren't explicitly stated

2. Counterargument Generation

  • Generate alternative explanations for the same evidence
  • Propose competing hypotheses that could also be true
  • Identify contradictory data or opposing viewpoints
  • Suggest different interpretations of facts and findings
  • Construct "what if" scenarios where current thinking is wrong

3. Weakness Identification

  • Find logical gaps in arguments and reasoning
  • Identify unexamined risks and potential failure modes
  • Spot overconfidence in predictions or estimates
  • Detect oversimplification of complex problems
  • Recognize missing perspectives or stakeholder views

4. Alternative Perspective Exploration

  • Adopt different stakeholder viewpoints (users, customers, regulators, competitors)
  • Consider opposite positions on controversial issues
  • Explore edge cases and boundary conditions
  • Apply different mental models or frameworks
  • Question fundamental premises rather than just conclusions

Devil's Advocate Techniques

For Technical Decisions:

  • Challenge technology choices: "What if this framework becomes unmaintained?"
  • Question architecture decisions: "How does this handle ten times the expected load?"
  • Probe security assumptions: "What attack vectors are we not considering?"
  • Test scalability claims: "What breaks first under stress?"
  • Examine dependency risks: "What happens if this third-party service changes?"

For Product/Feature Decisions:

  • Challenge user assumptions: "What if users don't behave as we expect?"
  • Question market fit: "What evidence contradicts our market assumptions?"
  • Probe value propositions: "Why would customers choose alternatives?"
  • Test business models: "What assumptions make this revenue model fail?"
  • Examine competitive threats: "How could competitors easily undermine this?"

For Process/Operational Decisions:

  • Challenge workflow efficiency: "What makes this process fragile?"
  • Question measurement validity: "Are we measuring the right things?"
  • Probe team dynamics: "What interpersonal issues could derail this?"
  • Test communication plans: "Where could misunderstandings occur?"
  • Examine incentive alignment: "What perverse incentives does this create?"

Examples

# Challenge a technical design decision
npm run devils-advocate:challenge -- --decision "use-microservices" --context "ecommerce-platform"

# Test a product assumption
npm run devils-advocate:test -- --assumption "users-want-mobile-app" --data "user-research.json"

# Identify weaknesses in a proposal
npm run devils-advocate:weaknesses -- --proposal "architecture-redesign.pdf" --perspective "security"

# Generate counterarguments for a business case
npm run devils-advocate:counterarguments -- --business-case "expand-to-europe.md" --stakeholder "competitor"

# Comprehensive devil's advocate review
npm run devils-advocate:review -- --document "project-plan.md" --thoroughness high

Output format

Devil's Advocate Analysis
──────────────────────────────
Subject: Microservices Architecture Proposal
Date: 2026-02-26
Analysis Duration: 45 minutes

Core Claims Identified:
1. "Microservices will improve development velocity by 40%"
2. "Team autonomy will increase with bounded contexts"
3. "System will be more resilient to failures"
4. "Scaling will be more efficient and cost-effective"
5. "Technology diversity will enable better tool selection"

Argument Analysis:

1. Claim: "Microservices improve development velocity by 40%"
   Supporting Evidence: Case studies from other companies

   Devil's Advocate Challenges:
   - Case studies may not apply to our context (different scale, team structure)
   - 40% improvement assumes optimal implementation and mature DevOps
   - Velocity gains may be offset by coordination overhead
   - Microservices introduce new failure modes (network, versioning, data consistency)
   - Learning curve could reduce velocity initially

   Alternative Explanation:
   The perceived velocity improvement may come from better practices
   (CI/CD, testing) that could be applied to monoliths too.

2. Claim: "Team autonomy increases with bounded contexts"
   Supporting Evidence: Conway's Law, team structure diagrams

   Devil's Advocate Challenges:
   - Bounded contexts require clear domain boundaries (do we have them?)
   - Teams need new skills (distributed systems, SRE practices)
   - Increased autonomy may lead to inconsistent standards
   - Cross-team coordination becomes more formal and slower
   - Some domains naturally span multiple services

   Alternative Perspective:
   Monolith with modular architecture might provide similar autonomy benefits
   without operational complexity.

3. Claim: "System more resilient to failures"
   Supporting Evidence: Failure isolation diagrams, redundancy claims

   Devil's Advocate Challenges:
   - Distributed systems have MORE failure modes (network partitions, service discovery)
   - Resilience requires sophisticated infrastructure (circuit breakers, retries, fallbacks)
   - Debugging failures across services is harder
   - Data consistency becomes a major challenge
   - Cascading failures possible if dependencies not managed

   Contradictory Evidence:
   Many companies report increased operational complexity and failure rates
   after microservices adoption without proper preparation.

Risk Assessment:
- High Risk: Data consistency across services
- Medium Risk: Operational complexity overwhelming team
- Medium Risk: Cross-team coordination overhead
- Low Risk: Technology choice limitations

Alternative Approaches Worth Considering:
1. Modular monolith with clear internal boundaries
2. Start with coarse-grained services, refine later
3. Hybrid approach: monolith for core domain, services for edge functions
4. Focus on DevOps maturity first, then evaluate service boundaries

Critical Questions Unanswered:
1. What specific metrics will measure "improved velocity"?
2. How will we handle distributed transactions?
3. What is the rollback plan if microservices don't deliver value?
4. How will team structure change to support service ownership?
5. What monitoring and observability investments are needed?

Recommendations:
1. Pilot with one non-critical service first
2. Define clear success metrics before proceeding
3. Invest in foundational capabilities (monitoring, deployment, testing)
4. Consider evolutionary architecture rather than big-bang rewrite
5. Document assumptions and revisit after 3 months

Analysis Value:
- Weaknesses identified: 8 significant, 3 critical
- Alternative perspectives generated: 5 viable alternatives
- Assumptions challenged: 12 core assumptions
- Risk areas highlighted: 3 high-risk areas needing mitigation
- Decision quality improvement: High (prevents potential costly mistake)

Notes

  • Devil's advocate is a role, not a personality – it's temporary and purposeful
  • The goal is better decisions, not winning arguments or blocking progress
  • Balance skepticism with constructive alternatives
  • Document challenges and responses for future reference
  • Use devil's advocate selectively for important decisions, not every discussion
  • The most valuable challenges are those that are hardest to answer
  • Pair devil's advocate with other perspectives for balanced analysis
  • Time-box devil's advocate analysis to prevent analysis paralysis
  • Focus on substance, not style – challenge ideas, not people
  • The best devil's advocate questions are those that make everyone think differently

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.13%
按下载量换算105

Claude

32.87%
按下载量换算101

Cursor

16.97%
按下载量换算52

Gemini CLI

9.1%
按下载量换算28

安全审计

Gen Agent Trust Hub

可疑

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills