How do I install the Kijito Recall skill?

Run npx skillmds@latest add kijitoai/kijito-recall in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Kijito Recall safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Kijito Recall?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Kijito Recall free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Kijito Recall?

KijitoAI (@kijitoai) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Kijito Recall by kijitoai — Agent Skill

Name: Kijito Recall
Author: KijitoAI

Kijito Recall

Recall patterns that make Kijito answer hard questions well — decompose multi-part questions into per-hop sub-queries, merge under a fixed context budget, chain entities between hops, and keep abstention discipline. Use when a question needs several distinct facts from memory (a "multi-hop" question), when a single recall came back with a compromise neighborhood that misses the point, or when deciding how deeply to retrieve before answering.

KijitoAI Updated Sep 17, 2026

File contents

Kijito Recall — aiming retrieval, not widening it

kijito_recall embeds ONE query vector per call. A question that bundles several facts — "where did X move after the job Y mentioned, and who introduced them?" — retrieves a single compromise neighborhood that can miss every one of its parts. The fix is not a deeper recall; it is more, better-aimed recalls.

The decomposition pattern (multi-part questions)

Split the question into at most 3 self-contained sub-queries, each phrased in the words its answer was likely stored under (recall matches wording — front-loaded concrete terms beat abstractions). YOU do the decomposition, in your own reasoning — the engine makes no LLM call.
Recall them in ONE call with the native parameter: kijito_recall(query=<the original question>, sub_queries=[<sub-query 1>, <sub-query 2>, ...]). Each sub-query runs the normal recall pipeline server-side and the ranked lists are merged for you — round-robin interleave, dedup, truncated to limit — so the result is already the aimed, budget-bounded set. The reply names the merge (subquery_merge); if it instead says it degraded to a plain recall (blank list, or a single entry equal to query), your decomposition was not used — fix the sub-queries rather than reading the plain result as decomposed. Fallback only — on a server whose kijito_recall has no sub_queries parameter, recall each sub-query separately with a smaller limit per call (e.g. 3 recalls × limit 8 instead of 1 × 24) and merge + dedup the results yourself. Doing that against a server that HAS the parameter re-implements, client-side and less well, a merge the server has already measured.
Keep the budget fixed. Whichever path ran, keep the TOTAL context you carry no larger than what one deep recall would have given you (limit is the cap on the merged set). Decomposition is for aiming, not for smuggling a bigger context load.
Chain the hops. When an early hop's answer names the entity the next hop needs, rewrite the next sub-query around that entity and recall again — chaining is a second call, not a bigger first one.

When NOT to decompose

Leave single-part questions alone. A decomposition step on a simple lookup adds latency and near-miss context and helps nothing. Decompose only when the question genuinely needs several distinct facts joined together.

Abstention discipline

Abstain as readily as you would with a single recall. Decomposed retrieval surfaces more adjacent-but-wrong material, and near-miss context is exactly what tempts a confident answer to a question whose true answer is "that isn't in memory". If the merged results don't actually contain a hop, say so — don't bridge the gap with plausibility.

kijito_guide(topic="recall") — how recall scoring works (semantic + graph traversal + keyword boost) and why wording decides findability; this pattern is documented there too.
kijito_guide(topic="writing") — writing memories so future sub-queries can find them.

---name: kijito-recalldescription: Recall patterns that make Kijito answer hard questions well — decompose multi-part questions into per-hop sub-queries, merge under a fixed context budget, chain entities between hops, and keep abstention discipline. Use when a question needs several distinct facts from memory (a "multi-hop" question), when a single recall came back with a compromise neighborhood that misses the point, or when deciding how deeply to retrieve before answering.---# Kijito Recall — aiming retrieval, not widening it`kijito_recall` embeds ONE query vector per call. A question that bundles several facts — *"wheredid X move after the job Y mentioned, and who introduced them?"* — retrieves a single compromiseneighborhood that can miss every one of its parts. The fix is not a deeper recall; it is more,better-aimed recalls.## The decomposition pattern (multi-part questions)1. **Split** the question into at most 3 self-contained sub-queries, each phrased in the words its answer was likely *stored* under (recall matches wording — front-loaded concrete terms beat abstractions). YOU do the decomposition, in your own reasoning — the engine makes no LLM call.2. **Recall them in ONE call** with the native parameter: `kijito_recall(query=<the original question>, sub_queries=[<sub-query 1>, <sub-query 2>, ...])`. Each sub-query runs the normal recall pipeline server-side and the ranked lists are merged for you — round-robin interleave, dedup, truncated to `limit` — so the result is already the aimed, budget-bounded set. The reply names the merge (`subquery_merge`); if it instead says it degraded to a plain recall (blank list, or a single entry equal to `query`), your decomposition was not used — fix the sub-queries rather than reading the plain result as decomposed. *Fallback only* — on a server whose `kijito_recall` has no `sub_queries` parameter, recall each sub-query separately with a smaller `limit` per call (e.g. 3 recalls × limit 8 instead of 1 × 24) and merge + dedup the results yourself. Doing that against a server that HAS the parameter re-implements, client-side and less well, a merge the server has already measured.3. **Keep the budget fixed.** Whichever path ran, keep the TOTAL context you carry no larger than what one deep recall would have given you (`limit` is the cap on the merged set). Decomposition is for aiming, not for smuggling a bigger context load.4. **Chain the hops.** When an early hop's answer names the entity the next hop needs, rewrite the next sub-query around that entity and recall again — chaining is a second call, not a bigger first one.## When NOT to decomposeLeave single-part questions alone. A decomposition step on a simple lookup adds latency andnear-miss context and helps nothing. Decompose only when the question genuinely needs severaldistinct facts joined together.## Abstention disciplineAbstain as readily as you would with a single recall. Decomposed retrieval surfaces moreadjacent-but-wrong material, and near-miss context is exactly what tempts a confident answer to aquestion whose true answer is "that isn't in memory". If the merged results don't actually containa hop, say so — don't bridge the gap with plausibility.## Related- `kijito_guide(topic="recall")` — how recall scoring works (semantic + graph traversal + keyword boost) and why wording decides findability; this pattern is documented there too.- `kijito_guide(topic="writing")` — writing memories so future sub-queries can find them.

Frequently asked questions