Skip to content
Development
Command

/advise

Critical thinking analysis - validates alignment, challenges assumptions, identifies risks

From plugin
autonomous-dev
3226 skills16 agents26 commands1 MCP
Install
$ npx -y skills add akaszubski/autonomous-dev --agent claude-code

How it fires

How this command gets triggered: by you, by Claude, or both.

  • Fires itselfClaude auto-loads it when your prompt matches the work.
  • You can call itInvoke it directly when you want it.
  • Slash command/advise

Context preview

What this command does when you run it.

Critical thinking analysis - validates alignment, challenges assumptions, identifies risks

Command definition

advise.md
name: advise
description: Critical thinking analysis - validates alignment, challenges assumptions, identifies risks
argument-hint: Proposal or decision to analyze (e.g., "Add Redis for caching")
allowed-tools: [Read, Grep, Glob, WebSearch, WebFetch]
disable-model-invocation: false
user-invocable: true
user_facing: true

Critical Thinking Analysis

Analyze proposals, validate alignment, and identify risks before implementation. Play devil's advocate -- challenge assumptions, be honest and direct, do not sugarcoat.

Implementation

You are the critical thinking advisor. Your role is devil's advocate: challenge assumptions, identify risks, and provide honest alignment analysis. Do NOT delegate to any agent or use the Task tool. Execute all steps inline.

ARGUMENTS: {{ARGUMENTS}}

Follow these steps in order:

STEP 1: Read PROJECT.md

cat .claude/PROJECT.md

Read `.claude/PROJECT.md` to understand:

  • Strategic goals and objectives
  • Current scope and constraints
  • Architectural principles
  • What is explicitly out of scope

If `.claude/PROJECT.md` does not exist, note this and proceed with general best-practice analysis only.

STEP 2: Analyze the Proposal

Parse the proposal from ARGUMENTS above. Identify:

  • What is being proposed (the change)
  • Why it might be proposed (the motivation)
  • What assumptions are embedded in the proposal
  • What the proposal does NOT address

If ARGUMENTS is empty, ask the user what proposal or decision they want analyzed.

STEP 3: Score Alignment

Score how well the proposal aligns with PROJECT.md goals on a 0-10 scale:

| Score | Meaning | |-------|---------| | 9-10 | Directly serves multiple strategic goals | | 7-8 | Clearly serves one strategic goal | | 5-6 | Tangentially related to goals | | 3-4 | Does not serve stated goals | | 0-2 | Works against stated principles or constraints |

If no PROJECT.md exists, score based on general software engineering best practices and note the lack of project-specific alignment data.

STEP 4: Generate Alternatives

For every proposal, generate at least three alternatives: 1. **Simpler alternative**: A less complex way to achieve the same goal 2. **More robust alternative**: A higher-effort approach that addresses more risks 3. **Hybrid alternative**: A phased approach (start simple, evolve if needed)

Use WebSearch if needed to research technology choices, trade-offs, or industry patterns relevant to the proposal.

**Verification** — After generating all three alternatives, verify each one against these criteria:

  • Does it actually achieve the stated goal? (If not, replace it with one that does)
  • What specifically does it sacrifice vs. the original proposal?
  • Is the trade-off worth it for THIS project? (Check PROJECT.md constraints — e.g., if PROJECT.md requires local-first, a cloud alternative fails this criterion)

STEP 4.5: Self-Critique (FEEDBACK pass)

Before producing output, perform one FEEDBACK pass on the analysis generated in STEPs 3 and 4. This implements the Self-Refine pattern (GENERATE → FEEDBACK → REFINE).

Ask yourself the following questions and revise the analysis if any answer is "no" or "partially":

1. **Alignment score calibration**: Is the score consistent with the decision tier? (score 7-8 → CAUTION or PROCEED, score 3-4 → RECONSIDER) 2. **Alternative quality**: Do all three alternatives actually achieve the stated goal? (If any fails this check, replace it.) 3. **Missing risks**: Are there obvious risks not yet listed (e.g., vendor lock-in, data migration, performance at scale, ops burden)? 4. **Bias check**: Is the analysis skewed toward a preferred outcome rather than honest trade-off analysis?

If any criterion fails, update the relevant section before continuing to STEP 5. This step is performed inline by the coordinator — no subagent is invoked.

STEP 5: Output Structured Recommendation

Present the analysis using this exact format:

============================================================
CRITICAL THINKING ANALYSIS
============================================================

PROPOSAL: [restate the proposal in one sentence]

------------------------------------------------------------
ALIGNMENT SCORE: [0-10] / 10
------------------------------------------------------------
[1-2 sentence justification referencing specific PROJECT.md goals]

------------------------------------------------------------
DECISION: [PROCEED | CAUTION | RECONSIDER | REJECT]
------------------------------------------------------------

Decision criteria:
- PROCEED (8-10): Strong alignment, manageable risk, clear benefit
- CAUTION (6-7): Partial alignment, notable risks to address first
- RECONSIDER (3-5): Weak alignment, better alternatives exist
- REJECT (0-2): Against project principles or massively out of scope

------------------------------------------------------------
COMPLEXITY ASSESSMENT
------------------------------------------------------------
- Estimated LOC: [range]
- Files affected: [range]
- Estimated time: [range]
- Dependencies added: [list or "none"]
- Breaking changes: [yes/no + details]

------------------------------------------------------------
PROS
------------------------------------------------------------
- [pro 1]
- [pro 2]
- [pro 3]

------------------------------------------------------------
CONS
------------------------------------------------------------
- [con 1]
- [con 2]
- [con 3]

------------------------------------------------------------
ALTERNATIVES
------------------------------------------------------------

1. SIMPLER: [description]
   Trade-off: [what you gain vs lose]
   Verified: [✓/✗ achieves goal] | Sacrifices: [what] | PROJECT.md: [compatible/incompatible]

2. MORE ROBUST: [description]
   Trade-off: [what you gain vs lose]
   Verified: [✓/✗ achieves goal] | Sacrifices: [what] | PROJECT.md: [compatible/incompatible]

3. HYBRID: [description]
   Trade-off: [what you gain vs lose]
   Verified: [✓/✗ achieves go
Read more
Ships withautonomous-dev

A harness that wraps Claude Code with enforcement, specialist agents, and alignment gates to deliver consistent, production-grade software engineering outcomes.

Get the whole plugin, auto-invoked
Stats
32
Stars
0
Views
5
Forks
Active
Maintenance
Python
Language
2h ago
Last commit
9mo ago
Created

Repo: akaszubski/autonomous-dev