| name | knowledge-base |
| description | 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. |
Knowledge Base Foundation
Before You Start
Read these docs to orient yourself:
docs/common/concepts/glossary.md - Terminology (Cell, Piece, Space,
Spell, etc.)docs/specs/pattern-construction/overview.md - Authoritative system
designAGENTS.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 enginepackages/runner/src/builder/ - Compilationpackages/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.
Not evidence: docs/history/
docs/history/ holds frozen point-in-time records (audits, executed plans,
superseded designs — see docs/history/README.md). They describe the system as
it was on their created date, not as it is. Use them for background and
provenance only, never as authority about current behavior, and never update
them.
The Rule
Concrete beats abstract. Specifications beat speculation. Code beats comments.
Tests beat documentation.
When Sources Conflict
- Check specs first (
docs/specs/)
- Look at working code (tests, patterns)
- Read runtime implementation
- Use docs/common as learning guide only
- If still unclear, surface the conflict explicitly
