From agent-flow
This skill should be used when querying the user's personal knowledge base (cross-project personal knowledge graph) for prior learnings, notes, or decisions that apply across projects.
npx claudepluginhub josix/agent-flow --plugin agent-flowThis skill uses the workspace's default tool permissions.
Query the user's personal knowledge base effectively, interpret results accurately, and stay within token budgets.
Applies Acme Corporation brand guidelines including colors, fonts, layouts, and messaging to generated PowerPoint, Excel, and PDF documents.
Guides strict Test-Driven Development (TDD): write failing tests first for features, bugfixes, refactors before any production code. Enforces red-green-refactor cycle.
Share bugs, ideas, or general feedback.
Query the user's personal knowledge base effectively, interpret results accurately, and stay within token budgets.
The personal-kb MCP server exposes the user's cross-project personal knowledge base as a pre-built knowledge graph stored at $AGENT_FLOW_PERSONAL_KB_PATH/graphify-out/graph.json. This is a graph built by the user from their own notes, journals, decision records, or any other personal documents — outside of any single project directory.
Owner: Riko (Explorer Agent) — Riko is the primary personal-kb query agent and owns interpretation of results. Consumers: Senku (Planner Agent), Lawliet (Reviewer Agent) — both may consult the personal KB during planning and review to surface cross-project decisions and patterns. Out of scope: Loid (Executor) and Alphonse (Verifier) do NOT have personal-kb access by design. This preserves the one-writer invariant and keeps write/verify agents focused on project artifacts.
All 7 tools are accessed via the MCP prefix mcp__personal-kb__*. See references/tool-reference.md for full signatures.
Contrast with graphify-usage:
graphify-usage — queries the current project's graph at graphify-out/graph.json (relative to project root). Use for structural questions about THIS codebase.personal-kb-usage — queries the user's personal graph at an absolute path outside the project. Use for cross-project recall: prior decisions, anti-patterns encountered before, personal preferences, notes from past work.| Trigger condition | Preferred approach |
|---|---|
| "Have I solved this problem before in another project?" | Personal KB: query_graph |
| "What did I decide about X in past projects?" | Personal KB: query_graph |
| "What patterns have I used for Y across codebases?" | Personal KB: query_graph |
| "What personal anti-patterns have I documented?" | Personal KB: god_nodes then get_community |
| "What is the dependency structure of THIS project?" | Project graph (graphify-usage) |
| "Which community does file F belong to in THIS repo?" | Project graph (graphify-usage) |
"Find the string literal TODO: fix" | Grep |
| "What does a specific config key say in THIS project?" | Read the file directly |
Personal KB is not configured (available: false in state) | Skip — use project graph or Grep |
Rule of thumb: Personal KB is for memory across sessions and projects. Project graph is for structure within this session's codebase. Grep/Read is for current file content.
Choose the right tool for the question type. See references/query-patterns.md for detailed decision sequences.
| Question type | Primary tool | Follow-up |
|---|---|---|
| What prior decisions exist on topic X? | query_graph (BFS, depth=2) | get_node on returned labels |
| What are my recurring patterns / hubs? | god_nodes | get_community to explore clusters |
| Which personal notes cluster around topic Y? | get_community | get_node on members |
| What connects concept A to decision B? | get_neighbors | get_node on connectors |
| Have I documented an anti-pattern like Z? | query_graph (BFS for broad, DFS for specific chain) | get_node on results |
| Full details on a known personal note/decision | get_node | — |
| Path between two cross-project concepts | shortest_path | get_node on intermediate nodes |
| Overall scale of personal KB | graph_stats | god_nodes for central concepts |
Hard rules for staying within context budget:
top_k / top_n when available. Default god_nodes returns 10 nodes — only request more if explicitly needed.token_budget on query_graph calls. The default is 2000 tokens; lower it (e.g., 500) for quick orientation queries.depth conservatively. Default depth is 3; start at 1-2 for narrow questions, increase only if the result is insufficient.source_location fields.label → source_location pairs. Downstream agents (Senku, Lawliet) need names and file paths, not raw graph output.graph_stats first, then decide if god_nodes is needed. Avoid firing all 7 tools simultaneously.How to read and trust what the personal KB returns:
source_location fields with ABSOLUTE pathsEvery node in the personal KB graph carries a source_location field (file path, sometimes line range). Because the personal KB lives outside the current project root, always report these as absolute paths:
Node: AuthDecision2025
source_location: /Users/you/personal/knowledge-base/decisions/auth-patterns.md:42
Never truncate these to relative paths — downstream agents working in a different project directory cannot resolve relative paths pointing into the personal KB.
The graph annotates edges with confidence labels:
| Tag | Meaning | Trust level |
|---|---|---|
| EXTRACTED | Directly observed in source text | High — treat as fact |
| INFERRED | Model-reasoned relationship | Medium — verify if load-bearing |
| AMBIGUOUS | Multiple interpretations possible | Low — always verify with Read |
When an edge is INFERRED or AMBIGUOUS, note this explicitly in your summary.
The personal KB reflects the user's personal notes and past decisions, not authoritative project documentation. When personal KB content conflicts with current project docs:
The personal KB graph is built once (at the user's last /graphify run on their KB) and is not updated during a session. If the user has recently added notes, those may not be indexed yet.
depth > 4 without a specific reason — output will overflow context.source_location citations — every claimed relationship needs a file anchor (absolute path).