Normalize before synthesis — git metadata, unchanged context, and ANSI codes add tokens without aiding reasoning. Pipe verbose git output through node scripts/git-normalize.js (default cleanup; add --changed for large diffs). See Git Output Normalization.
Resolve a function name with search_functions(query, parser_type) before traversal. Use query_subgraph with max_depth:2 and direction all, upstream, or downstream for one-function context. Use trace_flow with direction out or in, selected rel_types, and max_depth:6 for indirect/callback-aware expansion; use find_paths for a known start and end, and analyze_workflow_impact for affected workflows and risk.
hi-knows is a unified knowledge retrieval skill: it answers questions about why-changed, impact-radius, architecture context, and history trace using evidence from Git, MCP, and memory files.
1. Goal and boundaries
hi-knows builds answers with traceability; it is not a syntax helper, implementation engine, or database mutation tool.
Use it for:
why code changed;
which commit created a behavior;
the impact radius of a symbol/module;
architecture rationale;
decision history;
reconciling Git, project knowledge, and memory.
Do not use it for:
simple syntax fixes;
pure implementation;
DB mutations;
questions that do not require historical/architectural evidence.
2. Mental model
Loading diagram…
3. Intent and source priority
3.1 Intent
Intent
Example question
why-changed
Why was this function changed?
impact-analysis
Where does changing this module have an impact?
architecture-context
Why did the system choose this pattern?
history-trace
Through which commits did this behavior take shape?
3.2 Priority by intent
Question type
Priority
Structure/Runtime
graph_mcp → Git → mind_mcp → memory
Historical/Rationale
mind_mcp → memory → Git → graph_mcp
This is the difference from a fixed search order. Source priority depends on the question type.
Memory is evidence that can help understand rationale, but it is not automatically more authoritative than code or Git. Freshness and source type must be assessed.
9. FalkorDB query suggestion
Do not execute direct FalkorDB/Neo4j queries. Only suggest them for the user to run in their own client.
Format:
Graph Query Suggestion (FalkorDB):
- Objective: what the query answers
- Rationale: why this path/depth
- Cypher: parameterized query
- Expectation: expected row shape
- Interpretation: how to read result
Example for callers:
MATCH (caller)-[:CALLS*1..4]->(target {name: $name})
RETURN caller.name, target.name
LIMIT 200
FalkorDB queries are only suggested, never executed.
Confidence does not exceed the evidence.
13. Example: history-trace
Question: "Why did the retry policy change from 3 attempts to 5?"
Preflight: classify history-trace, validate the path.
mind_mcp: find incident/decision docs.
memory: find observations about the incident.
Git: git log/git show on the retry module.
graph: determine current callers/impact.
Synthesis:
fact: the commit changed the limit;
rationale: the incident doc;
current impact: graph callers;
inference: the new workload may need verification;
gap: no load evidence yet.
14. Limitations
No single source is always right for every intent.
Memory can be stale or agent-generated.
Git blame gives author/time, not business rationale.
Graph impact is bounded by depth/index limits.
Cache TTL can make context stale if the project just changed.
A suggested query is not a query result.
15. Summary
hi-knows does not just find an answer; it chooses sources by intent, normalizes data, reconciles conflicts, and returns grounded confidence so readers know what is fact, what is inference, and what is missing.