Skip to content
Back to skills

Melech Distill Need

ASecurity

Uncover the real need behind a requested solution before building it.

  • 32 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 19, 2026
ai-agentsgo

Security analysis

A100/100

Pro scans all 5 files and shows the line behind each finding

Scanned September 19, 2026

npx -y skills add AdirD/agent-shell-hamelech --skill melech-distill-need --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Melech Distill Need?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Melech Distill Need
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/adird-melech-distill-need/badge)](https://www.skillsdirectory.com/skills/adird-melech-distill-need)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: melech-distill-need
description: Uncover the real need behind a requested solution before building it.
disable-model-invocation: true
---

# Distill Need

The user's request is not scripture. It is usually a **proposed solution**.

People often:

- do not know exactly what they are asking for
- do not know what they actually need
- do not know existing solutions already cover it

Naive AI bullseyes the words. Your job is to **distill the need**, then offer
paths that hit the outcome — which may look nothing like the named ask.

Classic pattern:

- Ask: "I need a faster horse."
- Distill: get to B faster.
- Better means: a car — or walk, if work is ten feet away.

## What You Are Trying To Achieve

Separate:

1. **Literal ask** — the named feature, tool, or implementation
2. **Actual need / goal** — what must be true for the user to be happy
3. **Context** — constraints that can collapse or change the problem
4. **Better means** — including reuse, process change, or don't-build

Then let the **user decide**. Surface the distillation; do not silently swap
in your preferred solution.

## Workflow

### 1. Catch the proposed solution

Restate the literal ask in one line. Mark it as a proposed solution, not the
mission.

### 2. Distill the outcome

Ask the smallest set of questions that reveal:

- what must be true when this is done
- why they want it now
- what pain happens if nothing changes

Prefer 1–3 high-leverage questions. Batch when forks are clear.
Do not run a long intake.

### 3. Check collapsing context

Look for facts that change the category of solution:

- constraints, proximity, frequency, urgency, scale
- who feels the pain
- what "done" means in their world

If context is missing and would change the answer, ask for it.
If you can infer safely from the repo/product, say the assumption.

### 4. Check existing solutions

Before inventing:

- is there already a wheel in the codebase, product, or process
- are they reinventing it
- worse: reinventing it as a rectangle
- if a known library, tool, or service may already do it, flag it for the user

Prefer integrate / reuse / configure over greenfield when it hits the need.

### 5. Offer solution categories

Give 1–3 meaningfully different means to the same outcome. At least consider:

- **don't build** / manual / process / existing tool
- **smallest change** to something that already exists
- **the named ask** (or a cleaned version), if it still earns its place

For each path: outcome fit, cost, what you sacrifice, and when you'd choose it.
Recommend one. User picks.

### 6. Hand off

- If the need dies or "walk" wins → stop. No plan, no code.
- If still build-shaped → move on to aligning the concept and picking the smallest useful path.
- If they already had a direction and only needed holes poked → pressure-test that direction instead.

## Question Filter

Ask only what would change:

- the outcome definition
- the solution category
- whether building is justified
- whether something existing already solves it

Do not ask implementation trivia. Do not invent requirements theater.

This is the intercept. It can end with **don't build**.

## Do / Don't

**Do:** "You asked for a faster horse. Outcome seems to be: get to work faster. You live 10 feet away — walking beats breeding. If the real constraint is weather/status/cargo, say which and we re-open."

**Don't:** Start designing a horse-optimization service.

**Do:** "You asked for a new notification microservice. Need seems to be: users notice failed billing. Existing email + in-app banner may cover it. Options: (1) reuse banners, (2) extend current notifier, (3) new service. I recommend (1)."

**Don't:** Scaffold the microservice because that was the noun in the sentence.

**Do:** "Literal ask: custom RBAC engine. Distilled need: hide admin screens from non-admins. Role check on two routes may be enough. Confirm the outcome before we invent a policy framework."

**Don't:** Treat the named architecture as sacred.

**Do:** Recommend, then wait for the user to choose.

**Don't:** Silently replace their ask with your pet solution and start coding.

Files in this skill

  • SKILL.md4.1 KB
  • evals/evals.json1.8 KB
  • evals/fixtures/support-product/README.md715 B
  • evals/fixtures/support-product/product-signals.md1.1 KB
  • evals/fixtures/support-product/routing.ts570 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.