search-kb

Search the product knowledge base for where a piece of work belongs — its domain, capability, and functionality — by reasoning over the KB router interface. Runs the inference sandwich (list domains, reason to the domain, read that shelf, reason to the capability/functionality) and emits a lightweight routing-result with the decision and why. Placement only — it does not evaluate product-profile conditions (that is selection, /shape's job). Use whenever a play or agent needs to know which part of the product model a request maps to.

Jump to install

Repository: kapilvirenahuja/garura
Last source activity: July 3, 2026 at 06:46
Detected SKILL.md language: English
Stars: 3
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/kapilvirenahuja/garura --skill search-kb

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

install-garura

Install Garura into a target project or repository so its skills, agents, and plays become discoverable by a host coding tool — Claude Code or the OpenAI Codex CLI. Reads this garura checkout's core/components and runs a per-tool ADAPTER that lays them down in the host's native shape: for claude, .claude/ skills + agents with model tiers resolved to Claude models; for codex, .agents/skills Agent Skills plus AGENTS.md and ~/.codex model/sandbox/approval profiles. Always writes a .garura/ tooling tree (config + STM scaffold) and copies shared memory to the machine-global ~/.garura, and records an install manifest so uninstall-garura can reverse exactly what was placed. Use when the user wants to install, set up, bootstrap, add, or enable Garura in another folder or repo for claude or codex — "install garura into X", "set up garura in this repo for codex", "bootstrap garura", "make codex see the garura skills". Takes the target path, an optional --tool, and an optional --scope (full = everything, the default; ha

2026-07-21

play-creator

Compile a deterministic "play" (a multi-step, gated workflow recipe) from an intent. Interviews for the intent triple, generates the expectation, identifies the skills, scripts, and agents the play needs, selects a workflow structure, generates evals, and emits a compiled play (a SKILL.md plus bundled scripts for its mechanical work). Use this whenever the user wants to create, build, compile, or review a play — or says "create a play", "new play", "compile this into a play", "play-creator", "turn this intent into a play", or "review my play for gaps" — even if they don't say the word "play" explicitly but are describing a repeatable, multi-step, checkpoint-gated workflow they want captured as a runnable recipe.

2026-07-21

play-editor

Modify an existing compiled play — change its goal, a constraint, a failure condition, a success scenario, a step, the workflow shape, or the agents/skills it uses — by editing the play's ICE source and recompiling, never by hand-patching the output into disagreement with its intent. This is the companion to play-creator (which makes new plays). Use this whenever the user wants to edit, change, modify, update, tweak, extend, or fix an existing play — or says "edit the play", "change this play", "add a constraint to the play", "the play needs a new failure condition / step / scenario", "play-editor", or "recompile the play after I changed its intent" — even if they don't say "play" outright but are clearly reshaping a workflow recipe that already exists.

2026-07-21

View all from this repository

name	search-kb
description	Search the product knowledge base for where a piece of work belongs — its domain, capability, and functionality — by reasoning over the KB router interface. Runs the inference sandwich (list domains, reason to the domain, read that shelf, reason to the capability/functionality) and emits a lightweight routing-result with the decision and why. Placement only — it does not evaluate product-profile conditions (that is selection, /shape's job). Use whenever a play or agent needs to know which part of the product model a request maps to.
version	0.1.0
user-invocable	false
model	sonnet
allowed-tools	Bash, Read

search-kb

Routes a piece of work to its place in the KB tree: domain → capability → functionality, with the decision and the reasoning recorded. This is C2 (#434).

The interface

You call the KB router interface — never the KB files directly:

KB = core/components/memory/knowledge/domains/.pageindex/kb.py
python3 $KB domains            # all domains + triggers (the routing entry)
python3 $KB shelf <domain>     # full shelf markdown (to reason to capability/functionality)
python3 $KB search "<keywords>"# secondary keyword hint only
python3 $KB rebuild            # regenerate the index (if stale/missing)

The interface is the stable seam — today a local CLI, later a server; this skill does not change when that moves.

Procedure — the inference sandwich

Reasoning is yours (the skill); the interface only retrieves.

List + reason to the domain (placement). Run python3 $KB domains. Read the ~10 triggers and reason which domain the work belongs to. Pick one; pick more only if the work genuinely spans domains. This is semantic placement — do NOT consider product-profile conditions here.
Read the shelf + reason to capability/functionality. Run python3 $KB shelf <chosen-domain>. Reason over its ## Capabilities to pick the capability and the functionality(ies) the work maps to. Note their profile conditions as metadata — do not evaluate them (that is selection, not placement).
Emit the routing result (schema below) with why for each placement.

If step 1 finds no domain that fits, set unmatched: true and stop — the nothing-fits path (the /route caller) handles drafting a new node for review.

Output — routing_result (lightweight; NOT an ADR)

routing_result:
  work: "add SMS password reset for locked-out users"
  placements:
    - domain: user-management
      capability: Account Recovery
      functionality: [Password reset, Multi-channel support]
      confidence: high            # high | medium | low
      why: "credential recovery delivered over a non-default channel (SMS)"
      conditions:                 # metadata, copied — NOT evaluated here
        - "Multi-channel support — when shape.surfaces spans more than one, or shape.users: public"
  spans_multiple_domains: false
  unmatched: false

Emit it as JSON (the machine form). It must validate against .pageindex/validate_route.py.

Rules

Placement, not selection. Never reject a placement because a profile condition fails — the asker already decided to build it. Return conditions as metadata only.
Reason over the small set. With ~10 domains, do not lean on keyword search; read the whole domains list and reason. search is a hint, never the decision.
Record why. Every placement carries a one-line rationale.
Honest confidence. low when the work is vague or could sit in several places; flag spans_multiple_domains when it truly does.

search-kb

Source facts

Install options

Review the source files

More from this repository

More from this repository

search-kb

The interface

Procedure — the inference sandwich

Output — routing_result (lightweight; NOT an ADR)

Rules

search-kb

The interface

Procedure — the inference sandwich

Output — routing_result (lightweight; NOT an ADR)

Rules