ask

name	ask
description	Query the bundled research knowledge graph for methodology guidance. Routes questions through a 3-tier knowledge base — WHY (research claims), HOW (guidance docs), WHAT IT LOOKS LIKE (domain examples) — plus structured reference documents. Returns research-backed answers grounded in specific claims with practical application to the user's system. Triggers on "/ask", "/ask [question]", "why does my system...", "how should I...".
version	1.0
generated_from	arscontexta-v1.6
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	[question about knowledge systems or methodology]

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

Question Type	Signals	Primary Tier	Secondary Tier
WHY	"why does...", "what's the reasoning...", "what's the theory behind...", "why not just..."	Research Graph	Guidance Docs
HOW	"how do I...", "what's the workflow for...", "how should I...", "what's the process..."	Guidance Docs	Research Graph
WHAT	"what does X look like...", "show me an example...", "how would this work for...", "what would a Y vault..."	Domain Examples	Guidance Docs
COMPARE	"X vs Y", "what's the difference between...", "should I use X or Y...", "trade-offs between..."	Research Graph	Examples
DIAGNOSE	"something feels wrong...", "why isn't this working...", "my system is doing X when it should..."	Guidance Docs + Reference (failure-modes.md)	Research Graph
CONFIGURE	"what dimension...", "how should I set...", "what configuration for...", "which preset..."	Reference (dimensions, constraints)	Research Graph
EVOLVE	"should I change...", "my system has grown...", "this doesn't fit anymore..."	Reference (evolution-lifecycle.md)	Guidance Docs

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."

Quality Standards

Ground answers in specific claims, not general knowledge. The knowledge base exists so answers are evidence-based. If you answer from general knowledge without consulting the graph, you are bypassing the tool.

Acknowledge gaps honestly. When the research does not cover something, say so. "The current research graph doesn't have claims about X" is a legitimate answer. Do not fabricate coverage.

Distinguish certainty levels. Some claims are well-established with multiple supporting claims. Others are preliminary observations or research directions. The confidence field in claim frontmatter signals this:

• No confidence field — standard established claim
• confidence: speculative — early-stage observation, not fully evaluated
• confidence: emerging — promising but needs more support
• confidence: supported — well-evidenced claim
• confidence: established — foundational, widely supported
• status: archived — superseded or dissolved claim

Be opinionated. The research has positions. Share them. "The research strongly suggests X because..." is better than "some sources say X, others say Y." If there IS genuine disagreement, present it as a tension, not as false balance.

Translate to user context. When the user has a derivation, apply findings to their system. Generic advice is less useful than specific application. "In your therapy vault, this means..." is better than "in general, this means..."

Worked Examples

Example 1: WHY Question

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

Classification: WHY -> Primary: Research Graph. Secondary: Reference (dimension-claim-map).

Search:

1. mcp__qmd__deep_search query="atomic notes vs compound documents granularity" collection="methodology" limit=8
2. Read reference/dimension-claim-map.md — find granularity dimension's informing claims
3. Read ops/derivation.md — check user's granularity position

Answer:

Your system uses atomic granularity because your conversation signaled "precise claims from papers." The research shows that atomic notes enable independent linking and recombination — according to [[atomic notes maximize recombinable surface area]], each note can be linked from any context without dragging unrelated content along. Your processing pipeline (extract -> reflect -> reweave -> verify) specifically requires atomic granularity to maintain the link fabric, because [[verify phase checks link density per note]] and compound documents would inflate link counts artificially.

The trade-off: atomic notes create more files and require denser navigation structures. [[flat organization requires semantic search at scale]] explains why your system includes semantic search — without it, finding notes in a flat atomic structure becomes impractical beyond ~50 notes.

Tension: [[composability and context compete at the note level]] — making notes small enough to link cleanly sometimes makes them too small to carry their own argument. Your system handles this through the description field and topic map context phrases.

Example 2: HOW Question

Question: "How do I process a large research paper?"

Classification: HOW -> Primary: Guidance Docs. Secondary: Research Graph.

Search:

1. mcp__qmd__search query="large source processing chunking" collection="methodology" limit=5
2. mcp__qmd__deep_search query="context degradation large documents extraction" collection="methodology" limit=5

Answer:

For sources over 2500 lines, chunk into segments of 350-1200 lines and process each chunk with fresh context. [Guidance: pipeline processing workflow] explains the chunking strategy in detail.

The reason is [[context quality degrades as conversation grows]] — your extraction quality in the later sections of a 3000-line document will be measurably worse than in the early sections. Fresh context per chunk ensures each section gets your best attention.

Practical steps:

1. Run /seed to create the extraction task
2. /reduce will automatically detect the source size and plan chunks
3. Each chunk extracts independently with a running duplicate list across chunks
4. The final extraction report covers all chunks combined

Your config has processing.depth: standard, which means chunks process sequentially in the current session. If you switch to deep, each chunk would get its own isolated context (maximum quality, but slower).

Example 3: WHAT Question

Question: "What would a cooking recipe vault look like?"

Classification: WHAT -> Primary: Domain Examples. Secondary: Guidance Docs.

Search:

1. mcp__qmd__vector_search query="cooking recipes culinary knowledge system" collection="methodology" limit=5
2. Read closest domain examples for structural inspiration

Answer:

[Answer synthesized from examples, showing concrete folder structure, note examples, topic map examples, and vocabulary choices specific to a culinary domain. References the closest existing domain example for structural patterns.]

---

Anti-Patterns

What NOT to Do

Anti-Pattern	Why It Fails	Instead
Answer without searching	Bypasses the knowledge base entirely	Always search, even for "obvious" questions
List claims without synthesis	Dumps search results, forces user to connect dots	Weave claims into a coherent argument
Search only one tier	Misses HOW when answering WHY, or vice versa	Check if secondary tier strengthens the answer
Ignore user's derivation	Generic advice when specific is available	Read ops/derivation.md for user context
Use universal vocabulary	Says "notes" when their system says "reflections"	Apply vocabulary transforms
Fabricate claim citations	Cites claims that do not exist in the graph	Only cite claims you actually read
Skip the claim-map	Searches blindly without routing	Read claim-map first for topic orientation
Present false balance	"Some say X, others say Y" when research has a clear position	Be opinionated — share the research's position

The Honesty Standard

If the knowledge base genuinely does not cover a topic:

1. Say so explicitly: "The current research graph doesn't have claims about X."
2. Offer what IS available: "The closest related research is about Y, which suggests..."
3. Flag it as a gap: "This might be worth investigating as a research direction."

Do NOT extrapolate wildly from tangentially related claims. An honest "I don't know, but here's what's adjacent" is more valuable than a fabricated answer.

---

Domain-Aware Answering

When the user's question involves their specific system (not abstract methodology):

Step 1: Read Their Derivation

Check for ops/derivation.md to understand:

• Their dimension positions (granularity, organization, processing depth, etc.)
• Their vocabulary choices (what are "notes" called in their domain?)
• Their tradition mapping (which methodology preset, if any?)
• Their personality settings (formal/warm, clinical/conversational)
• Their constraint profile (which interaction constraints are active?)

Step 2: Apply Domain Vocabulary

Use ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md to translate universal terms into their domain language. This is not cosmetic — it is about making the answer native to their system.

Universal Term	Therapy Domain	PM Domain	Research Domain
notes	reflections	decisions	claims
topic map	theme map	project map	MOC
reduce	surface	extract	reduce
reflect	connect	link	reflect
inbox	journal	intake	inbox

Step 3: Check Interaction Constraints

Reference ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md to understand whether their configuration creates specific pressures relevant to the question. Some dimension combinations create tensions that affect the answer:

• High granularity + flat organization = needs strong semantic search
• Permissive selectivity + deep processing = high volume, slower throughput
• Self space enabled + warm personality = rich identity layer

Step 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 choices. This makes the answer traceable: "Your system does X because claim Y supports it for your configuration."