Get research-backed architecture advice for your knowledge system. Describe your use case, constraints, and goals — get specific recommendations grounded in TFT research with rationale for each decision. Triggers on "/recommend", "what would you recommend", "architecture
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill 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/recommend
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Get research-backed architecture advice for your knowledge system. Describe your use case, constraints, and goals — get specific recommendations grounded in TFT research with rationale for each decision. Triggers on "/recommend", "what would you recommend", "architecture
📊 Stats
Stars3,451
Forks218
LanguageShell
LicenseMIT
📦 Ships with arscontexta
</> SKILL.md
recommend.SKILL.md
---name: recommend
description: Get research-backed architecture advice for your knowledge system. Describe your use case, constraints, and goals — get specific recommendations grounded in TFT research with rationale for each decision. Triggers on "/recommend", "what would you recommend", "architecture advice", "knowledge system for".
version: "1.0"
generated_from: "arscontexta-v1.6"
user-invocable: true
context: fork
model: opus
allowed-tools: Read, Grep, Glob, mcp__qmd__search, mcp__qmd__vector_search, mcp__qmd__deep_search, mcp__qmd__get, mcp__qmd__multi_get
argument-hint: "[use case description and constraints] — describe what you want to build"
---## 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:
### 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] for [which aspects]
- [Preset B] for [which aspects]
Starting from [Preset A] and adjusting [specific dimensions] toward [Preset B].
```
---
## Phase 3: Search for Relevant Research
### 3a. Topic-Based Search
Use `${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md` to identify which research topics apply to the user's use case. Read the claim map and identify relevant topic clusters.
### 3b. Semantic Search
Use qmd tools to find research claims that apply to the user's specific constraints:
Run 2-4 targeted searches based on the user's signals. Focus on:
- Domain-specific patterns (if the research covers their domain)
- Processing philosophy (batch vs continuous, deep vs light)
- Scale considerations (what changes as the system grows)
- Pain point research (what causes the friction they described)
### 3c. Read Relevant Claims
For each search result that looks relevant, read the claim via `mcp__qmd__get` (or `mcp__qmd__multi_get` for batch reads) to understand the full argument. You need enough depth to cite with confidence.
Collect 5-15 relevant claims. You won't cite all of them — but you need a pool to draw from.
---
## Phase 4: Map Signals to Dimensions
### 4a. Read Dimension-Claim Map
Read `${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md`. This maps each dimension position to the research claims that support it.
### 4b. Determine Each Position
For each of the 8 configuration dimensions, determine the recommended position:
- [scenario where A is better, with research reason]
Where [B] wins:
- [scenario where B is better, with research reason]
For your use case: [recommendation of which to start from, if user
provided enough context]
```
---
## Quality Standards
### Every Recommendation Must
1. **Trace to research** — no "I recommend X" without a claim reference. If no research covers a specific aspect, say so: "No specific research covers this; recommending based on general principles."
2. **Be honest about confidence** — low-confidence recommendations are valuable IF flagged. "I'm less certain about navigation tiers because your scale is unclear" is better than a false-confident recommendation.
3. **Respect simplicity** — default to simpler configurations. The user can always add complexity later. Recommend the MINIMUM viable configuration, then note what they'd add as they grow.
4. **Avoid over-engineering** — don't recommend features the user didn't ask about. If they want a simple journal, don't recommend 4-tier navigation and dense schemas. Match the system to their actual needs.
5. **Present trade-offs** — every position has costs. Make them visible so the user can make an informed choice.
### Anti-Patterns
- Recommending maximum everything (all dimensions at highest complexity)
- Recommending without reading the constraint map (producing invalid combinations)
- Asking more than 2 clarifying questions (analysis paralysis)
- Generating files (this is /setup's job, not /recommend's)
- Ignoring the user's stated pain points
- Recommending against the user's explicit preferences without strong research justification
---
## Edge Cases
### User Describes an Existing System
If the user already has a system and wants advice on improving it:
```
You already have a system. /recommend designs new systems from scratch.
For evolution advice on existing systems, run /architect — it reads your
current configuration and recommends evidence-based changes.
If you want to compare your current setup against the research-optimal
configuration, I can do that here. Want me to?
```
If they say yes, proceed with comparison: their current configuration vs what research suggests.
### User Describes Something Outside Knowledge System Scope
If the request is not about a knowledge system (e.g., "recommend a database for my app"):
```
/recommend is designed for knowledge system architecture — personal or
agent-operated systems for capturing, organizing, and retrieving knowledge.
Your request sounds more like [what it sounds like]. I can help with
that directly, but /recommend's research backing is specific to knowledge
management patterns.
```
### No Presets Match
If no preset is a reasonable match:
```
No existing preset closely matches your use case. Building a custom
