Ask

EXECUTE NOW

Question: $ARGUMENTS

If no question provided, ask the user what they want to know.

Execute these steps:

1. Classify the question — determine which knowledge base tier(s) to consult (see Query Classification below)
2. Search the knowledge base — route to appropriate tiers based on classification
3. Read relevant claims and docs — load 3-7 most relevant sources fully (use mcp__qmd__multi_get when reading multiple IDs)
4. Check user context — read ops/derivation.md if the question involves their specific system
5. Synthesize an answer — weave claims into a coherent, opinionated argument
6. Cite sources — reference specific claims and documents so the user can explore further

START NOW. Reference below explains routing and synthesis methodology.

The Three-Tier Knowledge Base

The plugin's knowledge base has three distinct parts, each serving a different function. Effective answers often draw from multiple tiers.

Tier 1: Research Graph (WHY)

Location: ${CLAUDE_PLUGIN_ROOT}/methodology/ — filter by kind: research Content: 213 interconnected research claims grounded in cognitive science, knowledge system theory, and agent cognition research. Use for: Questions about principles, trade-offs, why things work, theoretical foundations.

What it contains:

• Claims about how knowledge systems work (human and agent)
• Cognitive science foundations (working memory, attention, retrieval)
• Methodology comparisons (Zettelkasten vs PARA, atomic vs compound)
• Design dimensions (trade-off spectrums with poles and decision factors)
• Failure modes and anti-patterns
• Agent-specific constraints (context windows, session boundaries)

Search strategy: Use mcp__qmd__deep_search (highest quality, LLM-reranked) for conceptual questions. Use mcp__qmd__vector_search for semantic exploration. Use mcp__qmd__search for known terminology. All searches use the methodology collection.

Tier 2: Guidance Docs (HOW)

Location: ${CLAUDE_PLUGIN_ROOT}/methodology/ — filter by kind: guidance Content: 9 operational documents covering procedures, workflows, and implementation rationale. Use for: Questions about how to do things, operational best practices, workflow mechanics.

Documents include:

• Schema enforcement rationale and procedures
• Pipeline philosophy and processing workflow
• MOC methodology and navigation patterns
• Maintenance patterns and condition-based triggers
• Memory architecture and session management
• Vocabulary transformation procedures
• Failure mode prevention patterns
• Multi-domain composition rules
• Onboarding and evolution decisions

Search strategy: mcp__qmd__search with keywords from the question using the methodology collection. To narrow to guidance docs, add kind:guidance to your grep filter on results.

Tier 3: Domain Examples (WHAT IT LOOKS LIKE)

Location: ${CLAUDE_PLUGIN_ROOT}/methodology/ — filter by kind: example Content: 12 domain-specific compositions showing what generated vaults look like in practice. Use for: Questions about how to apply methodology to specific domains, inspiration for novel domain mapping.

Examples include domains like:

• Research vaults (academic literature reviews, claim extraction)
• Personal assistant vaults (life management, therapy, health wellness)
• Project management vaults (decision tracking, stakeholder context)
• Creative vaults (worldbuilding, character tracking)
• Engineering, legal, trading, student learning, relationships

Search strategy: Use mcp__qmd__vector_search across the methodology collection for semantic domain matching. To list all examples: rg '^kind: example' ${CLAUDE_PLUGIN_ROOT}/methodology/.

Reference Documents (structured derivation context)

Location: ${CLAUDE_PLUGIN_ROOT}/reference/ Content: Structured reference documents supporting derivation and system architecture. Use for: Deep dives into specific architectural topics, cross-referencing dimension positions, understanding interaction constraints.

Core Architecture:

• methodology.md — universal principles and processing pipeline
• components.md — component blueprints and feature blocks
• kernel.yaml — the 12 non-negotiable primitives
• three-spaces.md — self/notes/ops architecture and boundary rules

Configuration & Derivation:

• dimension-claim-map.md — which research claims inform which dimensions
• interaction-constraints.md — how dimension choices create pressure on others
• tradition-presets.md — named points in configuration space
• vocabulary-transforms.md — universal-to-domain term mapping
• derivation-validation.md — validation tests for derived systems

Behavioral & Quality:

• personality-layer.md — personality derivation and encoding
• conversation-patterns.md — worked examples of full derivation paths
• failure-modes.md — how knowledge systems die and prevention patterns

Lifecycle & Operations:

• use-case-presets.md — preset configurations for common domains
• session-lifecycle.md — session rhythm, context budget, orient-work-persist
• evolution-lifecycle.md — seed-evolve-reseed, condition-based maintenance
• self-space.md — agent identity generation, self/ architecture
• semantic-vs-keyword.md — search modality selection guidance
• open-questions.md — unresolved research questions and deferred items

Also read: claim-map.md — the routing index showing which claims map to which topics. Start here when you need to find relevant claims quickly.

Query Classification

Before searching, classify the user's question to determine which tier(s) to consult.

Classification Rules

Multi-Tier Questions

Many questions require consulting multiple tiers. The classification above shows primary and secondary tiers. Always check: would the answer be stronger with evidence from another tier?

Example multi-tier routing:

Question: "Why does my system use atomic notes instead of longer documents?"

1. WHY tier — search research graph for claims about atomicity, granularity, composability
2. Reference — check dimension-claim-map.md for the granularity dimension's informing claims
3. User context — check ops/derivation.md for their specific granularity position and reasoning
4. WHAT tier — optionally pull an example showing what atomic notes look like in a similar domain

Question: "How should I handle therapy session notes that are very long?"

1. HOW tier — search guidance for processing workflow, chunking strategies
2. WHAT tier — check examples for therapy or personal domains with similar challenges
3. WHY tier — search for claims about context degradation, chunking benefits, large source handling

Search Strategy

Step 1: Route to Claim-Map

Read ${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md first. This is the routing index — it shows which topic areas are relevant to the user's question and which claims to start with. Do NOT skip this step and search blindly.

Step 2: Search the Appropriate Tier

For WHY questions (Research Graph):

mcp__qmd__deep_search  query="[user's question rephrased as a search]"  collection="methodology"  limit=10

Use mcp__qmd__deep_search (hybrid + LLM reranking) for conceptual questions because the best connections often use different vocabulary than the question. Results will include all kinds; prioritize kind: research results.

For HOW questions (Guidance Docs):

mcp__qmd__search  query="[key terms from question]"  collection="methodology"  limit=5

Use keyword search first since guidance docs use consistent terminology. Fall back to semantic if keyword misses. Prioritize kind: guidance results.

For WHAT questions (Domain Examples):

mcp__qmd__vector_search  query="[domain + what the user wants to see]"  collection="methodology"  limit=5

Use semantic search to find the most relevant domain examples even if the exact domain name differs. Prioritize kind: example results.

Fallback chain for qmd lookups:

• MCP tools (mcp__qmd__deep_search, mcp__qmd__vector_search, mcp__qmd__search)
• qmd CLI (qmd query, qmd vsearch, qmd search)
• direct file reads/grep on ${CLAUDE_PLUGIN_ROOT}/methodology/ and ${CLAUDE_PLUGIN_ROOT}/reference/

For Reference documents: Read specific reference documents based on the topic. The claim-map will indicate which reference docs are relevant. Load the 2-4 most relevant — not all of them.

Step 3: Read Deeply

Do NOT skim search results. For the top 3-7 results:

1. Read the full claim note or document
2. Follow wiki links to related claims (1 hop)
3. Note connections between claims that strengthen the answer

The depth principle: A shallow answer citing 10 claims is worse than a deep answer weaving 4 claims into a coherent argument. Read fewer sources more deeply.

Step 4: Check User Context

If the question involves the user's specific system:

1. Read derivation — ops/derivation.md contains their dimension positions, vocabulary, constraints, and the reasoning behind every configuration choice
2. Apply vocabulary — use ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md to translate universal terms into their domain language. Answer about "reflections" not "claims" if they are running a therapy system
3. Check constraints — reference ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md to see if their configuration creates specific pressures relevant to the question
4. Cite dimension-specific research — use ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md to ground answers in the specific claims that inform their configuration

Step 5: Check Local Methodology

Read ops/methodology/ for system-specific self-knowledge. Methodology notes may be more current than the derivation document — they capture ongoing operational learnings that the original derivation did not anticipate.

# Load all methodology notes
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  cat "$f"
  echo ""
done

When methodology notes address the user's question:

• Cite them alongside research claims: "Your system's methodology notes say [X], which aligns with the research claim [[Y]]"
• If methodology notes contradict research claims, flag the tension: "Your methodology note says [X], but the research suggests [Y] — this may be worth investigating with /{DOMAIN:rethink}"
• Methodology notes about system behavior are more authoritative for "how does MY system work" questions than the general research graph

When to prioritize methodology over research:

• Questions about "why does my system do X" — methodology notes capture the specific rationale
• Questions about behavioral patterns — methodology notes capture system-specific learnings
• Questions about configuration — methodology notes may document post-init changes not in derivation.md

When to prioritize research over methodology:

• Questions about "why is X a good idea in general" — research claims provide the theoretical foundation
• Questions about alternative approaches — the research graph covers options the system did not choose
• Questions about methodology comparisons — research claims compare traditions systematically

Answer Synthesis

Structure

Every answer follows this structure:

1. Direct answer — Lead with the answer, not the search process. Do not say "I searched for X and found Y." Say what the answer IS.

2. Research backing — What specific claims support this answer. Cite by title: "According to [[claim title]]..."

3. Practical implications — What this means for the user's specific situation. Use their domain vocabulary if available from derivation.

4. Tensions or caveats — Any unresolved conflicts, limitations, or situations where the answer might not hold. The research has genuine tensions — share them honestly.

5. Further exploration — Related claims or topics the user might want to explore. These are departure points, not assignments.

6. Sources consulted — Briefly note which knowledge layers were used: "Research: [N] claims consulted. Local methodology: [M] notes consulted." When local methodology was relevant, name the specific note: "Your methodology note [[title]] informed the [specific part] of this answer."