# Pick For The Problem

> Re-anchor the discipline that a tool, library, framework, language, or approach is chosen to fit the actual problem — not reached for out of habit, availability, incumbency, or preconception — then audit the selection in flight and re-derive it from the problem. Use when: 'pick for the problem', 'right tool for the job', 'which library should we use', 'what framework', 'should we build this or us…

- **Type:** Skill
- **Install:** `agentstack add skill-melodic-software-claude-code-plugins-pick-for-the-problem`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [melodic-software](https://agentstack.voostack.com/s/melodic-software)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [melodic-software](https://github.com/melodic-software)
- **Source:** https://github.com/melodic-software/claude-code-plugins/tree/main/plugins/discipline/skills/pick-for-the-problem

## Install

```sh
agentstack add skill-melodic-software-claude-code-plugins-pick-for-the-problem
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Pick for the problem

A drift corrector for selection discipline: the tool must fit the problem,
not the reflex. The method — re-anchor, audit the work in flight, correct
forward, report, and the tone that firing this is not an accusation — lives
in
[`${CLAUDE_PLUGIN_ROOT}/context/re-anchor-audit-correct.md`](../../context/re-anchor-audit-correct.md).
Read it; this file adds only what is specific to selecting a tool, library,
framework, language, or approach.

## The discipline this re-anchors

A selection is a design decision, not a reflex. Resolve the source of truth
per the method doc's ladder: if the consuming project states a
technology-selection or dependency-adoption rule in its own `CLAUDE.md` /
`.claude/rules/`, re-anchor THAT. Otherwise re-anchor this portable
baseline.

**The four selection sins** — an unexamined choice usually traces to one:

- **Habit** — "I always use X." The reach is muscle memory, not analysis.
- **Availability** — "X is already at hand." Convenience picked it, not fit.
- **Incumbency** — "the repo already uses X, so new work assumes X." Current
  state is treated as the requirement.
- **Preconception** — "I came in believing X is the answer." The verdict
  preceded the problem.

**The discipline that replaces them:**

- **Define the actual problem first.** Name what is being solved — the real
  requirements — before any candidate is on the table. Do not let the first
  solution shape decide the problem.
- **Survey the field.** More than one candidate, judged against the stated
  requirements and the plausible future ones (variables that could shift and
  turn a choice into future pain).
- **Walk the preference ladder** — an earlier rung wins when it covers the
  requirements and the plausible future requirements:
  1. **Native** — what the platform, language, or framework already
     provides: no new dependency, no new coupling.
  2. **Official / authoritative** — the first-party or canonical option when
     native falls short.
  3. **Vetted third-party** — only when the rungs above genuinely miss, and
     only if it is well-maintained, well-known, safe, and secure.
- **Every dependency is a coupling point.** Weigh, at adoption time, the
  cost this coupling can impose later: abandonment, a pricing pivot, a
  license change, security posture, and exit cost. A dependency adopted
  without that weighing is an unpriced liability.
- **Building what already exists is a finding.** Re-implementing a solved,
  well-served problem (native or vetted) is a selection error in the other
  direction — name it.

## Mandatory routing — no verdict from memory

When the selection is load-bearing, the field survey and the maintenance /
security / license / adoption judgement must come from CURRENT research, not
training-data recall — a tool's maintenance status, licensing, and security
posture drift constantly. Route to a research capability rather than judging
from memory: `/discovery:research`, or `/discovery:research-deep` for a large
surface. Degrade to an explicit in-thread research pass (fetch the primary
sources yourself and cite them) when that capability is not installed —
never a bare recalled verdict.

## Audit — what to look for

Name concrete, located findings (per the method doc's step 2). This fires
both at an explicit choice-time AND over choices already embedded in the
work in flight:

- a tool named before the problem it solves was stated;
- a single candidate with no field surveyed;
- a choice tracing to habit, availability, incumbency, or preconception
  rather than fit;
- a third-party dependency adopted with no maintenance / security / license /
  exit-cost weighing;
- a native or authoritative option skipped straight to third-party;
- a hand-built solution to an already-solved, well-served problem.

Correct each forward now: re-derive the choice from the stated problem, run
(or route) the survey, walk the ladder, and price the coupling. Where the
evaluation is load-bearing, route it to research rather than self-checking
from the same recall that produced the reflex.

## Distinct axis — the incumbency overlap

The incumbency sin here is selection-specific — "the repo uses X, so this
new work uses X". The general interrogation of inherited precedent is
`/discipline:reason-dont-recite`; this skill applies that lens narrowly to a
technology choice and adds the field survey, the ladder, and the coupling
price. Route a broader inherited-design challenge there.

## What this skill does NOT do

- **Does not churn a well-fitted choice.** A tool re-derived from the problem
  and found to fit audits clean — including an incumbent one; the duty is to
  re-derive, not to switch for its own sake.
- **Does not issue a verdict from recall.** A load-bearing evaluation routes
  to research; the skill does not pronounce a maintenance or security verdict
  from memory.
- **Does not fabricate a finding.** A choice already problem-derived and
  field-surveyed audits clean; say so.

## Gotchas

- **The reflex hides as a reason.** "We use X here" and "X is what I know"
  are the incumbency and habit sins wearing the costume of a rationale; a
  real rationale names the requirement X satisfies, not its familiarity.
- **A deep dependency-inventory variant is deliberately deferred.** Auditing
  an entire repo's dependency graph for coupling risk is out of scope here;
  that sibling lands on the first real dependency-inventory audit request,
  not before — not shipped speculatively.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [melodic-software](https://github.com/melodic-software)
- **Source:** [melodic-software/claude-code-plugins](https://github.com/melodic-software/claude-code-plugins)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-melodic-software-claude-code-plugins-pick-for-the-problem
- Seller: https://agentstack.voostack.com/s/melodic-software
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.