wicked-garden-deliberate git:20260711.6a4c633A

Immutable. This exact content never changes and is served at /api/v1/blob/1711a81859f26905.

---
name: wicked-garden-deliberate
user-invocable: true
description: |
  Critical thinking framework applied before doing work. Challenges assumptions,
  reframes problems, identifies hidden opportunities, and validates whether the stated
  ask is the right ask. A way of approaching work, not a specialist discipline.

  Use when: challenging assumptions before implementation, reframing a stated
  problem, asking whether the right thing is being asked at all, "deliberate
  on this", "deliberate #42" (a GitHub issue number), "critically analyze
  this request before implementing", `--deep` (blast-radius analysis),
  `--batch` (multiple issues, shared root causes), or any former
  /wicked-garden:deliberate invocation.
phase_relevance: ["clarify", "design"]
archetype_relevance: ["*"]
---

# Deliberate

A structured way of thinking about work **before doing it**. Applied to any request —
bugs, features, enhancements, content, design, infrastructure — to ensure we're solving
the right problem the right way.

## When to Use

- Before accepting any work request at face value
- During crew **clarify** and **design** phases (auto-integrated)
- When triaging issues, tickets, or ad-hoc asks
- Any time the gut response is "just do it" — pause and deliberate first

## The Five Lenses

### 1. Is This Real?

Challenge the premise before solving it.

- Is the reported problem actually a problem, or is it working as intended?
- Is this a symptom or the root cause? Would fixing it just move the pain?
- What's the evidence? Observed behavior, user feedback, or speculation?
- What's the cost of doing nothing? Sometimes inaction is the right action.

### 2. What's Actually Going On?

If the problem is real, dig to the root.

- Trace the issue to its origin — don't stop at the first explanation
- Is this a design flaw wearing a different mask?
- Map the blast radius: what else shares the same root cause?
- Is the framing itself wrong? (e.g., "the button is broken" vs "the flow is confusing")

### 3. What Else Can We Fix While We're Here?

Every change is a window into the surrounding code/content/system.

- Are there adjacent areas suffering from the same weakness?
- Can we generalize instead of point-fixing?
- Is there duplication that should be consolidated?
- Would a structural change prevent entire categories of similar asks?

See [refs/opportunity-patterns.md](refs/opportunity-patterns.md) for common patterns.

### 4. Should We Rethink the Design?

Step back further. Is the current approach the right one?

- Would a different structure make this problem disappear entirely?
- Are we patching around a leaky abstraction or flawed model?
- Is the boundary in the wrong place?
- What would we build if starting fresh with today's knowledge?

See [refs/rethink-framework.md](refs/rethink-framework.md) for evaluation.

### 5. Is There a Better Way?

Before committing to the obvious solution, explore alternatives.

- Can we solve this by **removing** instead of adding?
- Can we solve this with configuration instead of code?
- Is there a simpler approach that covers 90% of cases?
- What are we trading off with each option?

## Output: Deliberation Brief

```markdown
## Deliberation Brief: {title}

### Assessment
**Validity**: Real problem / Symptom / Not a problem / Wrong framing
**Root cause**: {actual cause, not what was reported}
**Blast radius**: {what else is affected by the same root cause}

### Opportunities
**Cleanup**: {what can be improved alongside}
**Generalization**: {can we abstract or consolidate?}
**Rethink**: {should we redesign the approach?}

### Recommendation
**Strategy**: Fix / Redesign / Generalize / Defer / Close
**Rationale**: {why this approach over alternatives}
**Scope**: Expand / Contract / Same — {what changed from original ask}

### Guidance
{specific direction for whoever does the work}
```

## Domain-Specific Depth

The five lenses are universal. The refs provide depth for specific contexts:

- [refs/run-workflow.md](refs/run-workflow.md) — **Operational runbook** for user-invoked deliberations: GH issue parsing, context gathering, Explore-agent dispatch, brief presentation, memory storage, crew integration, batch mode
- [refs/opportunity-patterns.md](refs/opportunity-patterns.md) — Structural patterns that signal cleanup opportunities
- [refs/rethink-framework.md](refs/rethink-framework.md) — When and how to propose a redesign
- [refs/code-lens.md](refs/code-lens.md) — Code-specific patterns (error handling, abstractions, tech debt)
- [refs/content-lens.md](refs/content-lens.md) — Content/docs patterns (messaging, structure, audience)
- [refs/design-lens.md](refs/design-lens.md) — Design patterns (UX flows, information architecture)
- [refs/architecture-lens.md](refs/architecture-lens.md) — System patterns (boundaries, dependencies, scaling)
- [refs/data-lens.md](refs/data-lens.md) — Data patterns (pipelines, schemas, quality, contracts)
- [refs/ops-lens.md](refs/ops-lens.md) — Ops patterns (incidents, reliability, deployment, observability)
- [refs/security-lens.md](refs/security-lens.md) — Security patterns (auth, vulnerabilities, threat models, compliance)
- [refs/product-lens.md](refs/product-lens.md) — Product patterns (user needs, prioritization, value, strategy)
- [refs/testing-lens.md](refs/testing-lens.md) — Testing patterns (test strategy, flakiness, coverage, test design)
- [refs/timing-lens.md](refs/timing-lens.md) — Timing patterns (urgency, sequencing, premature optimization)
- [refs/assumptions-lens.md](refs/assumptions-lens.md) — Assumption patterns (hidden dependencies, fragile premises)

## Integration

- **Crew workflow**: Auto-invoked during clarify and design phases
- **Standalone**: invoke this skill with `{description or GH#} [--deep] [--batch]` — then follow [refs/run-workflow.md](refs/run-workflow.md)
- **Batch**: `--batch "280,281"` — process multiple issues together to find shared root causes (see the runbook)