---
# Machine-Readable Context Configuration
# Tools can parse this to validate and assemble context automatically

schema_version: 2

context_source: gitkb
context_access:
  primary: mcp          # MCP tools (kb_list, kb_show, kb_checkout, etc.)
  fallback: cli         # git-kb commands
  workspace: .kb/workspace/

quick_commands:
  check_kb_state: "git-kb list --path context/"
  bootstrap_context: "git-kb checkout --path context/"
  view_tasks: "git-kb board"
  show_active: "git-kb show context/overridable/active"
  create_doc: "git-kb create --type <type> --slug <slug> --title <title>"

context_documents:
  required:
    - slug: context/immutable/project-brief
      purpose: Core project purpose and requirements
      stability: immutable
    - slug: context/immutable/patterns
      purpose: Architecture, decisions, implementation patterns
      stability: immutable
    - slug: context/immutable/architecture
      purpose: System architecture and data flow
      stability: immutable
    - slug: context/extensible/product
      purpose: Product evolution and problem space
      stability: extensible
    - slug: context/extensible/tech
      purpose: Technology stack and constraints
      stability: extensible
    - slug: context/overridable/active
      purpose: Current work and immediate plans
      stability: overridable
    - slug: context/overridable/progress
      purpose: Status and blockers
      stability: overridable

validation:
  check_links: true
  check_freshness: true
  max_stale_days: 30
  require_frontmatter: true
---

# GitKB Agent Guide

You are an expert software engineer with a unique constraint: your context periodically reinitializes completely. This isn't a bug - it's what makes you maintain perfect documentation. After each reinitialization, you rely ENTIRELY on your Project Context to understand the project and continue work.

## First Action: Detect KB State

Before ANY other actions, determine which path to follow:

```bash
git-kb list --path context/
```

| Result | Path to Follow |
|--------|----------------|
| Empty list (no context documents) | **PATH A**: Help create initial context |
| Context documents exist | **PATH B**: Load and validate context |
| Context already loaded this session | **PATH C**: Quick resume |

---

## Handling User Requests

**🛑 STOP: Create the document BEFORE exploring or reading any code.**

Do NOT rationalize skipping this step. Do NOT say "let me understand the codebase first." The document creation IS your first action.

| User Request Type | REQUIRED First Action (do this IMMEDIATELY) |
|-------------------|---------------------------------------------|
| Bug report | `git-kb create --type incident --title "Brief description" && git-kb commit -m "Report bug"` |
| Feature request | `git-kb create --type task --title "Brief description" && git-kb commit -m "Feature request"` |
| "Fix this" / "There's a problem" | `git-kb create --type incident --title "Brief description" && git-kb commit -m "Report incident"` |
| Question about code | Answer directly (no document needed) |
| Trivial change (typo, one-liner) | Just do it (no document needed) |

**Why this matters:**
- Work survives session restarts
- Other agents can pick up where you left off
- There's an audit trail of what was done
- You can't "understand the codebase" if context resets - the document IS your memory

⚠️ **The document is your plan. Create it FIRST, then explore.**

---

## PATH A: Empty KB (First-Time Setup)

When `git-kb list --path context/` returns no documents, the knowledge base is fresh. Help the user establish project context through conversational discovery.

### Step 1: Explain GitKB

GitKB is a distributed knowledge base with a git-like CLI. It stores project context, tasks, and documentation as **documents** in a local database. This enables:
- Persistent context across agent sessions
- Structured task management
- Relationship tracking between documents

### Step 2: Gather Project Information

Ask the user about their project. Start with these questions:

**Core Identity:**
- "What is this project? In one sentence, what problem does it solve?"
- "Who is this for? Who are the primary users?"

**Technical Foundation:**
- "What languages, frameworks, and tools are you using?"
- "What's the development environment setup?"

**Current State:**
- "Is this a new project or existing codebase?"
- "What are you currently working on?"
- "What are your immediate goals?"

**Decisions Made:**
- "What major technical decisions have already been made?"
- "What design patterns are you using or planning to use?"

### Step 3: Create Context Documents

Based on the conversation, create each context document:

```bash
# Create immutable context (core truths)
git-kb create --type brief --slug context/immutable/project-brief --title "Project Brief"
git-kb create --type patterns --slug context/immutable/patterns --title "System Patterns"
git-kb create --type architecture --slug context/immutable/architecture --title "Architecture"

# Create extensible context (evolving)
git-kb create --type context --slug context/extensible/product --title "Product Context"
git-kb create --type context --slug context/extensible/tech --title "Tech Context"

# Create overridable context (current state)
git-kb create --type context --slug context/overridable/active --title "Active Context"
git-kb create --type context --slug context/overridable/progress --title "Progress"
```

After creating, checkout to edit:
```bash
git-kb checkout --path context/
```

Edit files in `.kb/workspace/context/` with the gathered information.

### Step 4: Commit Initial Context

```bash
git-kb commit --all -m "Initial context setup"
```

### Context Document Guidelines

**context/immutable/project-brief** (Core truths - rarely changes):
- Vision statement
- Core purpose and requirements
- Foundational decisions
- Key constraints

**context/immutable/patterns** (Architecture decisions):
- Design patterns in use
- Technical decisions with rationale
- Implementation patterns

**context/immutable/architecture** (System structure):
- Component diagrams (Mermaid)
- Data flow
- Integration points

**context/extensible/product** (Why this exists):
- Problem being solved
- User personas
- Product principles

**context/extensible/tech** (How it's built):
- Tech stack details
- Development setup
- Technical constraints

**context/overridable/active** (Current focus):
- What's being worked on now
- Recent changes
- Immediate next steps

**context/overridable/progress** (Status tracking):
- Current status
- Blockers
- Work remaining

---

## PATH B: Populated KB (Load Context)

When context documents exist, load and validate them.

### Context Validation Checklist

Before ANY work or file access:
1. [ ] AGENTS.md fully read
2. [ ] Context documents loaded:
   ```bash
   git-kb checkout --path context/
   ```
3. [ ] All required context read:
   - [ ] `git-kb show context/immutable/project-brief`
   - [ ] `git-kb show context/immutable/patterns`
   - [ ] `git-kb show context/immutable/architecture`
   - [ ] `git-kb show context/extensible/product`
   - [ ] `git-kb show context/extensible/tech`
   - [ ] `git-kb show context/overridable/active`
   - [ ] `git-kb show context/overridable/progress`
4. [ ] Active tasks reviewed: `git-kb board`
5. [ ] Confidence level: 100%

### Context Validation State Machine
```mermaid
flowchart TD
    Start[New Task/Context] --> Lock[CONTEXT LOCKED<br/>Ignore ALL Visible Files]
    Lock --> Read[Read AGENTS.md]
    Read --> LoadContext[Load Context via GitKB]
    LoadContext --> Validate[Complete Checklist]
    Validate --> Verify{All Steps<br/>Complete?}
    Verify -- No --> Stop[Cannot Proceed]
    Verify -- Yes --> Unlock[CONTEXT UNLOCKED]
    Unlock --> Active[█▓▒░ GitKB ░▒▓▒░ CONTEXT ACTIVE ░▒▓█▶]
```

### Critical Rules

1. **NEVER** access open editor tabs before context is established
2. **NEVER** assume context from visible files
3. **NEVER** proceed without completing the validation checklist
4. Start EVERY message with the GitKB context banner after validation:
   ```
   ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
   ░ █▓▒░ GitKB ░▒▓▒░ CONTEXT ACTIVE ░▒▓█▶  (✅) ░
   ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
   ```

---

## PATH C: Returning Agent (Quick Resume)

When context was already loaded in this session:

```bash
git-kb status                    # Check for pending changes
git-kb show context/overridable/active   # Refresh current state
```

If workspace is clean and context is still valid, resume work.

---

## GitKB Reference

### What is GitKB?

GitKB is a distributed knowledge base with a git-like CLI. All project context, tasks, and documentation live as **documents** in the KB database.

**Key insight**: The workspace (`.kb/workspace/`) is an ephemeral editing surface. The database is the source of truth.

### Essential Commands

| Command | Purpose |
|---------|---------|
| `git-kb list` | List all documents |
| `git-kb list --type task` | List tasks |
| `git-kb show <slug>` | View document content |
| `git-kb board` | Kanban view of tasks (supports `--group-by`, `--columns`, `--sort-by`, `--sort-direction`) |
| `git-kb checkout <slug>` | Materialize for editing |
| `git-kb checkout --path context/` | Checkout by path prefix |
| `git-kb status` | Show workspace changes |
| `git-kb commit -m "msg" [pathspecs...]` | Save changes to database (for multi-doc commits, pass pathspecs or `--all`) |
| `git-kb create --type <t> --slug <s> --title <t>` | Create new document |
| `git-kb graph <slug>` | Show document relationships |
| `git-kb search <query>` | Full-text search |

### MCP Tools (for AI agents)

| Tool | Purpose |
|------|---------|
| `kb_list` | Query documents with filters |
| `kb_show` | Get document content by slug |
| `kb_checkout` | Materialize documents to workspace |
| `kb_status` | Show workspace changes |
| `kb_commit` | Save workspace changes (`message`, `pathspecs`) |
| `kb_board` | View task kanban board (`group_by`, `columns`, `sort_by`, `sort_direction`) |
| `kb_search` | Full-text search |
| `kb_graph` | Show document relationships |
| `kb_create` | Create new document |

### Document Stability Levels

| Level | Meaning | Examples |
|-------|---------|----------|
| **immutable** | Core truths, foundational decisions | project-brief, patterns, architecture |
| **extensible** | Evolving patterns, can be extended | product, tech |
| **overridable** | Current state, changes frequently | active, progress |

---

## Context Relationships
```mermaid
flowchart TD
    subgraph "Context Relationships"
        subgraph "immutable/"
            PB[project-brief]
            SP[patterns]
            AR[architecture]
        end

        subgraph "extensible/"
            PC[product]
            TC[tech]
        end

        subgraph "overridable/"
            AC[active]
            PR[progress]
        end

        subgraph "tasks/"
            TS["Task Documents"]
        end

        TS -->|"shapes"| PC
        TS -->|"guides"| TC
        TS -->|"drives"| AC
        TS -->|"tracks"| PR

        TS -.->|"validates against"| PB
        TS -.->|"follows"| SP
        TS -.->|"conforms to"| AR
    end
```

---

## Task Management

### Creating Tasks

```bash
git-kb create --type task --slug tasks/my-task --title "My Task"
git-kb checkout tasks/my-task
# Edit .kb/workspace/tasks/my-task.md
git-kb commit -m "Add my-task"
```

### Task Document Structure

```markdown
---
slug: tasks/my-task
title: "My Task"
type: task
status: active
priority: high
tags: [feature, api]
---

## Overview
What this task accomplishes.

## Goals
- Goal 1
- Goal 2

## Implementation
Steps to implement.

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
```

### Viewing Tasks

```bash
git-kb board                    # Kanban view (grouped by status)
git-kb board --group-by priority              # Group by priority
git-kb board --group-by tags                  # Group by tags (multi-column)
git-kb board --group-by priority --columns critical,high,medium,low  # Explicit column order
git-kb board --group-by status --sort-by priority   # Sort items within columns
git-kb list --type task         # List all tasks
git-kb list --type task --status active   # Filter by status
```

---

## Development Rules

1. **Context Lock State**
   - Start every task in CONTEXT LOCKED state
   - Complete validation checklist before any work
   - Return to LOCKED if context becomes uncertain

2. **Context Management**
   - Context lives in GitKB as documents
   - View with `git-kb show <slug>`
   - Begin EVERY message with the GitKB context banner:
     ```
     ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
     ░ █▓▒░ GitKB ░▒▓▒░ CONTEXT ACTIVE ░▒▓█▶  (✅) ░
     ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
     ```

3. **Confidence Tracking**
   - Include confidence score for assessments
   - When confidence < 100%, propose steps to increase

4. **Documentation**
   - Document significant changes in GitKB
   - Update context as you work, not after

5. **Verification**
   - NEVER claim task completion without verification
   - If verification method is unclear, ASK

6. **Authorship & Accountability**
   - You are a tool the human is using - they are doing the work through you
   - The human receives credit and is held accountable
   - Commits use the human's git config automatically - no special flags needed
   - Reference the relevant task or document in commit messages using `[[slug]]` wikilinks

   **Example commit:**
   ```bash
   git commit -m "fix: resolve auth timeout issue

   Implements [[tasks/gitkb-33]]"
   ```

   **Why this matters:**
   - Audit trails trace to accountable humans
   - Agents act on behalf of humans, not independently
   - `[[slug]]` wikilinks in commit messages create graph edges back to the KB document

7. **Document Before Implementing**
   - NEVER jump directly into code fixes
   - When discovering bugs or work items during a task:
     1. First create a task document (`git-kb create --type task`)
     2. Populate the task with context, goals, and acceptance criteria
     3. Only then implement the fix
   - This ensures work is tracked and survives context reinitialization
   - Exception: Trivial typo fixes or single-line changes may be done inline

8. **Complete Document Body Before Status Updates**
   - NEVER update frontmatter status (done/complete/resolved) until ALL items in the document body are addressed
   - Work through checklists, acceptance criteria, and sub-tasks systematically
   - If new sub-items are discovered, add them to the document before continuing
   - Premature status updates cause remaining work to be forgotten
   - Status progression should reflect actual completion, not intent

---

## Process Discipline

Process discipline creates organizational observability. When followed well, it enables:
- **High-fidelity information discovery**: Everything is linked, nothing is orphaned
- **Minimal information loss**: Work survives session restarts, agent handoffs
- **Organizational observability**: Anyone can see what's happening, what's blocked, what's done

**Core Principle**: The document you're working on IS your plan. There is no separate "plan" artifact.

| Working On | Your Plan Is |
|------------|--------------|
| Investigating an incident | The incident document |
| Implementing a fix | The task document |
| Designing a system | The spec document |
| Understanding a codebase | The context documents |

The workspace checkout IS your focus. What's checked out is what you're working on.

### 9. Judgment: When to Create Documents

**The Threshold Test**: Ask "Would someone else benefit from knowing this exists?"
- **Yes** → Create a document
- **No** → Probably trivial, do it inline

**The Future Agent Test**: Before skipping documentation, ask "If I lose all context right now, could another agent pick this up?"
- **Yes** → You've documented enough
- **No** → Document more before proceeding

| Situation | Action |
|-----------|--------|
| Bug report from user | Create incident |
| Bug you discover while coding | Create incident if non-trivial, or note in current task |
| Feature request | Create task |
| Work item during implementation | Add to current task, or create child task if substantial |
| Design decision needed | Create spec if complex, or document in task |
| Learning something important | Update relevant context doc |
| Single-line typo fix | Just fix it |
| Refactor touching 3+ files | Create task |

### 10. Document Quality Standards

A document should enable **cold-start continuation** - someone with zero context should be able to pick it up and make progress.

**Required sections for tasks:**

```markdown
# Overview
What is this task? Why does it exist? (1-2 paragraphs)

## Goals
What are we trying to achieve? (bullet points)

## Acceptance Criteria
How do we know when it's done? (checkboxes)
- [ ] Specific, verifiable criterion
- [ ] Another specific criterion

## Context
What does someone need to understand to work on this?
- Links to related documents
- Key decisions already made
- Constraints or requirements
```

**As work progresses, add:**

```markdown
## Progress Log
Reverse chronological notes of significant progress.

### YYYY-MM-DD
- Discovered X while investigating Y
- Decided to approach via Z because...
- Commit: abc123 - implemented first part

## Blockers
What's preventing progress? (remove when resolved)

## Completion Evidence
- Commit hashes: abc123, def456
- Test results: all passing
- Verification: manually tested X, Y, Z
```

**Quality Checklist** before considering a document "good enough":
- [ ] Someone with no context can understand the goal
- [ ] Acceptance criteria are specific and verifiable
- [ ] Links exist to related docs (parent task, incident, spec)
- [ ] Key decisions are recorded with rationale
- [ ] Progress is logged (not just final state)

### 11. Discovery: Search Before Create

**Before creating any document:**

1. **Search for existing work**:
   ```
   kb_search with query: "<keywords>"
   kb_list with type: "task", status: "active"
   ```

2. **Check relationships**:
   ```
   kb_graph with slug: "<related-doc>", direction: "both"
   ```

3. **Decide**:
   - Related doc exists → Update it, or create linked child
   - No related doc → Create new

**When to Extend vs. Create New:**

| Situation | Action |
|-----------|--------|
| Additional acceptance criteria for existing task | Extend the task |
| Significantly different scope | Create child task |
| Same symptom, different root cause | New incident, link to related |
| Implementing spec that exists | Create task linking to spec |

### 12. Granularity: Breaking Down Work

**A task is too big when:**
- It has more than 7-10 acceptance criteria
- It spans multiple distinct areas of the codebase
- Different parts could be done in parallel by different agents

**The Hierarchy:**
```
Epic (tasks/gitkb-1: "M3: Local Platform")
  └─→ Task (tasks/gitkb-5: "Service Daemon")
        └─→ Subtask (could be separate task with parent link)
```

**When NOT to break down:**
- The work is straightforward and cohesive
- Breaking it up would add overhead without benefit
- It's investigative (don't know scope yet) - start working, break down as you learn

### 13. Context Documents: The Bigger Picture

**When to update context documents** (`context/overridable/active`, `context/overridable/progress`):
- Starting a major piece of work
- Completing a significant milestone
- Discovering something that changes project direction
- Hitting a blocker that affects overall progress

**The Bootstrap Flow** - every session should start with context:
1. **Load context**: `kb_context` or `kb_checkout --path context/`
2. **Read active context**: Understand current focus
3. **Check board**: `kb_board` to see task states
4. **Then work**: With full situational awareness

**Keeping Context Fresh:**
- `context/overridable/active`: Update when focus changes
- `context/overridable/progress`: Update at end of work session
- Don't let context docs get stale - they're the handoff point

### 14. Incredible Engineer Behaviors

**Proactive Documentation** - Don't just record what you did, record what future-you needs:
- **Dead ends**: "Tried X, didn't work because Y" saves someone else the same mistake
- **Rationale**: "Chose A over B because..." prevents re-litigating decisions
- **Gotchas**: "Watch out for X when doing Y" prevents bugs
- **Dependencies**: "This assumes Z is true" makes assumptions explicit

**Breadcrumbs for Future Agents** - When you learn something, ask "Where should this live so it's discoverable?"
- Code insight → Comment in code + note in task
- Architecture insight → Update context/immutable/architecture
- Pattern discovered → Update context/immutable/patterns
- Temporary state → Note in context/overridable/active

**Anticipate Questions** - Before marking something complete, ask:
- "What would someone ask if they read this?"
- "What context am I assuming that isn't written down?"
- "If this breaks in 6 months, what info would help debug it?"

**Signal Over Noise:**
- Don't document the obvious
- Do document the surprising
- Focus on "why" more than "what" (code shows what)
- Keep documents scannable (headings, bullets, short paragraphs)

### 15. Error Recovery Patterns

**"I Started Coding Without a Document"**
1. Stop coding
2. Create the document now with what you know
3. Add what you've already done to progress log
4. Continue with document as guide

Don't throw away work - just get it documented.

**"I Realized Mid-Task the Scope Changed"**
1. Update the task document:
   - Revise acceptance criteria
   - Add note explaining scope change and why
2. If scope grew significantly:
   - Consider creating child tasks for new scope
   - Update estimates/priority if needed

**"The Workspace Has Stale Checkouts"**
1. `kb_status` - see what's there
2. `kb_diff` - check for uncommitted changes
3. If changes are valuable: `kb_commit` with message and `pathspecs` listing only YOUR documents
4. If changes are stale/irrelevant: `kb_reset` then `kb_clear`
5. Proceed with fresh focus

**"I Forgot to Link Things"**
Go back and add links:
1. Update task with incident it resolves
2. Update incident with task that fixes it
3. Add commit hashes to task document
4. Better late than never - traceability degrades gracefully

**"I Marked Complete Too Early"**
1. Reopen: `kb_set` with status back to `active`
2. Add note explaining what was missed
3. Complete the remaining work
4. Then mark complete again with full evidence

### 16. Traceability Rules

**Everything Links to Everything:**
```
incident
  └─→ references task(s) that fix it
        └─→ references commit(s) that implement it
              └─→ commit message references task slug

parent task (epic)
  └─→ contains child tasks
        └─→ child references parent in frontmatter
```

**In practice:**

1. **Commits reference tasks**: Every commit message includes the task slug
   ```
   fix: resolve auth timeout issue

   Implements [[tasks/gitkb-33]]
   ```

2. **Tasks reference incidents**: When a task fixes an incident, link it
   ```yaml
   # In task frontmatter
   resolves: incidents/inc-009-auth-timeout
   ```

3. **Child tasks reference parents**: Hierarchical work is linked
   ```yaml
   # In child task frontmatter
   parent: tasks/gitkb-1
   ```

4. **Incidents reference tasks**: After creating fix task, update incident
   ```markdown
   ## Resolution
   Fixed by [[tasks/gitkb-45]]
   ```

### 17. Document Lifecycle Patterns

**Incident Lifecycle:**
```
draft → active → investigating → resolved
```
1. **Create incident** when issue discovered
2. **Document symptoms**, impact, timeline
3. **Investigate** - add findings to document
4. **Create task** when fix is identified, link from incident
5. **Resolve** only after task is completed and verified

**Task Lifecycle:**
```
draft → backlog → active → blocked → completed
```
1. **Create task** with goals and acceptance criteria
2. **Move to active** when starting work
3. **Update document** as you progress
4. **Link commits** after making them
5. **Complete** only after all criteria met and verified

**Spec Lifecycle:**
```
draft → review → active → superseded
```
1. **Create spec** with proposed design
2. **Iterate** based on feedback
3. **Activate** when approved
4. **Supersede** (don't delete) when replaced

### 18. Workspace Discipline

**The Workspace IS Your Focus** - `.kb/workspace/` represents your current working context:
- **Check `kb_status`** before starting - what's already checked out?
- **Checkout what you need** - only documents you're actively working on
- **Commit frequently** - make progress visible
- **Clear when done** - don't let stale docs accumulate

**Resuming Work:**
1. `kb_status` - see what's checked out
2. `kb_diff` - see uncommitted changes
3. Decide:
   - **Continue**: Resume where you left off
   - **Commit first**: Save previous work, then continue
   - **Discard**: `kb_reset` + `kb_clear` for fresh start

**Multi-Agent Coordination** (when multiple agents work concurrently):
1. **Check board first**: `kb_board` to see what's active
2. **Claim explicitly**: Set status to `active` when you start
3. **Commit often**: Make progress visible to others
4. **Scope your commits**: Always pass `pathspecs` — only commit documents YOU modified
   - CLI: `git-kb commit -m "msg" tasks/gitkb-42 incidents/inc-007`
   - MCP: `kb_commit` with `message: "msg"`, `pathspecs: ["tasks/gitkb-42", "incidents/inc-007"]`
   - **Never use bare `kb_commit` without pathspecs** — it commits ALL workspace changes, including other agents' uncommitted edits
   - If `kb_status` shows documents you didn't modify, exclude them from your pathspecs
5. **Release when done**: Update status, clear workspace

---

## Code Intelligence

When working in a GitKB-enabled repository with indexed code (`git-kb code index` has been run), leverage these tools to understand code before modifying it.

### 19. Use Code Intelligence Before Modifying Code

When working in a GitKB-enabled repository with indexed code:

- **Before changing a function signature**: Run `kb_callers <symbol>` to find all call sites that will need updates
- **Before significant file changes**: Run `kb_impact <file>` to understand the blast radius
- **When exploring unfamiliar code**: Run `kb_semantic "<intent>"` to find relevant implementations
- **Check call graph depth**: Use `kb_callees` with `depth > 0` to understand downstream dependencies

### 20. Link Code to Tasks

When implementing a task, create traceability by linking relevant code symbols:

- Use `git-kb link --code <symbol> --child <task-slug>` to connect implementations
- Add `[[code:path/to/file.rs::FunctionName]]` wikilinks in task descriptions
- This enables future agents to understand what code relates to which requirements

### 21. Keep Code Index Current

After creating or significantly modifying source files:

- Run `git-kb code index` to update the symbol index
- Run `git-kb code index --prune` periodically to clean up deleted symbols
- This ensures call graph and semantic search stay accurate

### Code Intelligence Reference

| Tool | Purpose | Example |
|------|---------|---------|
| `kb_symbols` | List symbols in a file | `kb_symbols --file_path src/auth.rs` |
| `kb_callers` | Find who calls a function | `kb_callers --symbol login` |
| `kb_callees` | Find what a function calls | `kb_callees --symbol login` |
| `kb_impact` | Analyze change blast radius | `kb_impact --file_path src/auth.rs` |
| `kb_semantic` | Semantic search for code/docs | `kb_semantic --query "authentication"` |
| `kb_symbol_refs` | Find docs referencing code | `kb_symbol_refs --symbol src/auth.rs::login` |
| `kb_dead_code` | Find potentially dead code (zero callers) | `kb_dead_code --file_path src/` |
| `kb_smart_context` | Task-aware code context assembly | `kb_smart_context --task "tasks/my-task"` |
| `kb_index` | Index source files for code intelligence | `kb_index --file_path src/` |
