recommend

## Runtime Configuration (Step 0 — before any processing)

Read these files to configure recommendation behavior:

1. **`${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md`** — tradition and use-case presets
   - Pre-validated coherence points in the 8-dimension space
   - Starting points for customization, not final answers

2. **`${CLAUDE_PLUGIN_ROOT}/reference/methodology.md`** — universal methodology principles

3. **`${CLAUDE_PLUGIN_ROOT}/reference/components.md`** — component blueprints (what can be toggled)

4. **`${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md`** — maps each dimension position to supporting research claims

5. **`${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md`** — hard blocks, soft warns, cascade effects between dimensions

6. **`${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md`** — topic navigation for the research graph

If any reference file is missing, note the gap but continue with available information. The recommendation degrades gracefully — fewer citations, same structure.

---

## EXECUTE NOW

**Target: $ARGUMENTS**

Parse immediately:
- If target is empty or a question: enter **conversational mode** — ask 1-2 clarifying questions, then recommend
- If target contains a use case description: proceed directly to **recommendation mode**
- If target contains `--compare [A] [B]`: enter **comparison mode** — compare two presets or configurations

**START NOW.** Reference below defines the workflow.

---

## Philosophy

**Advisory, not generative.**

/recommend exists for exploration. The user is considering a knowledge system — maybe they have a use case, maybe they're comparing approaches, maybe they're curious what the research says about a specific pattern. /recommend answers with specific, research-backed reasoning without creating any files.

This is the entry point before commitment. /setup generates a full system. /recommend sketches what that system would look like and WHY, so the user can decide whether to proceed. Every recommendation traces to specific research claims. "I recommend X" is never enough — "I recommend X because [[claim]]" is the minimum.

**The relationship to other skills:**
- **/recommend** → advisory sketch (no files)
- **/setup** → full system generation (creates everything)
- **/architect** → evolution advice for EXISTING systems (reads current state)
- **/refactor** → implements changes to EXISTING systems (modifies files)

/recommend is the only one that works without an existing system. It's pure reasoning from research.

---

## Phase 1: Understand the Constraints

### 1a. Parse User Input

Extract signals from the user's description. Every word is a signal:

| Signal Category | Examples | Maps To |
|-----------------|----------|---------|
| **Domain** | "therapy sessions", "research papers", "trading journal" | Closest preset, schema design |
| **Scale** | "just starting", "hundreds of notes", "massive corpus" | Granularity, navigation tiers |
| **Processing style** | "quick capture", "deep analysis", "both" | Processing depth, automation level |
| **Platform** | "Obsidian", "Claude Code", "plain files" | Platform capabilities, linking type |
| **Existing system** | "I use PARA", "I have a Zettelkasten", "starting fresh" | Tradition preset baseline |
| **Pain points** | "can't find anything", "too much ceremony", "notes go stale" | Dimension adjustments |
| **Goals** | "track claims", "build arguments", "personal reflection" | Note design, schema density |
| **Operator** | "I'll maintain it", "AI agent runs it", "both" | Automation, maintenance frequency |

### 1b. Conversational Mode (when input is sparse)

If the user's description lacks critical signals, ask **at most 2 clarifying questions**. Frame them as choices, not open-ended:

```
To recommend the right architecture, I need two things:

1. **What kind of knowledge?** (pick closest)
   - Research/learning — tracking claims, building arguments
   - Creative — drafts, revisions, inspiration
   - Operational — tasks, decisions, processes
   - Personal — reflections, goals, relationships
   - Mixed — multiple of the above

2. **Who operates it?**
   - Mostly you (human-maintained)
   - Mostly an AI agent
   - Both (shared operation)
```

Do NOT ask more than 2 questions. The recommendation can always be refined. Get enough to start, then recommend.

### 1c. Signal Insufficiency

If after parsing (and optional questions) you still lack critical information, make reasonable defaults and STATE them:

```
Assuming:
- Platform: Obsidian (most common for personal knowledge)
- Scale: moderate (50-200 notes in first year)
- Operator: human-primary with occasional AI assistance

These assumptions affect the recommendation. Correct any that don't match.
```

---

## Phase 2: Match to Preset

### 2a. Read Presets

Read `${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md`. This file contains:
- **Tradition presets** — Zettelkasten, PARA, Evergreen, Cornell, etc.
- **Use-case presets** — research, creative writing, engineering, therapy, etc.

### 2b. Find Closest Match

Score each preset against the user's signals:

| Criterion | Weight | How to Score |
|-----------|--------|-------------|
| Domain match | High | Does the preset's intended domain match? |
| Processing style match | High | Does the preset's processing depth match the user's style? |
| Scale match | Medium | Is the preset designed for the user's expected scale? |
| Pain point coverage | Medium | Does the preset address the user's stated friction? |
| Goal alignment | High | Does the preset optimize for what the user wants? |

### 2c. Report the Match

State the closest preset and explain the match:

```
Closest preset: [preset name]
Match quality: [strong/moderate/partial]

Why: [1-2 sentences explaining the match]
Adjustments needed: [what needs to change from the preset baseline]
```

If the user's description blends multiple presets, explain the blend:

```
This blends two presets:
- [Preset A] f