# Knowledge Base

> Shared foundation for Oracle & Corrector agents. Establishes the source hierarchy for resolving conflicts between documentation, code, and specs. Load this skill first when investigating how the system works.

- Skill: `majiayu000/knowledge-base-6` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/knowledge-base-6`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/knowledge-base-6/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/majiayu000/knowledge-base-6

---


# Knowledge Base Foundation

## Before You Start

Read these docs to orient yourself:

1. **`docs/glossary.md`** - Terminology (Cell, Piece, Space, Spell, etc.)
2. **`docs/specs/recipe-construction/overview.md`** - Authoritative system design
3. **`AGENTS.md`** - Documentation reading list and codebase guidelines

## Source Hierarchy

When sources conflict, this is the authoritative order:

### 1. Specs (Highest Authority)
`docs/specs/` - Technical specifications with unambiguous intent

When specs contradict other docs, **specs win**.

### 2. Working Code
Tests and patterns that demonstrate actual behavior:
- `packages/patterns/` - Pattern examples showing what works
- `**/test/**` - Test files proving expected behavior

These show reality, not aspirations.

### 3. Runtime Code
Core system implementation:
- `packages/runner/` - Execution engine
- `packages/runner/src/builder/` - Compilation
- `packages/memory/` - Storage layer

Code is always right about what it does.

### 4. Plain Text Docs (Lowest Authority)
`docs/common/` - Guides, tutorials, learning materials

Good for learning, but may contain outdated or speculative information. Validate against code when precision matters.

## The Rule

**Concrete beats abstract. Specifications beat speculation. Code beats comments. Tests beat documentation.**

## When Sources Conflict

1. Check specs first (`docs/specs/`)
2. Look at working code (tests, patterns)
3. Read runtime implementation
4. Use docs/common as learning guide only
5. If still unclear, surface the conflict explicitly