LOAD_MODE

progressive

full

progressive

• RP1_ROOT

  : !

  rp1 agent-tools rp1-root-dir

  (extract

  data.root

  from JSON response)

DEPRECATED: This command is deprecated. All rp1 commands are now self-contained and load KB context automatically via their agents. You no longer need to run

/knowledge-load

before using other commands.

For agent developers: Use direct Read tool calls to load KB files progressively. See the Progressive Loading Pattern below.

1. Check Load Mode: Determine if progressive (default) or full mode
2. Analyze Parameters: Determine repository structure (single project, monorepo root, or monorepo subproject) and optimal loading strategy
3. Load Documentation: Ingest markdown files based on mode:
   • Progressive mode: Load only

     index.md

     (agents load additional files on-demand)
   • Full mode: Load all markdown files from context directory
4. Extract Knowledge: Identify entities, relationships, and cross-references
5. Build Knowledge Graph: Create internal representation
6. Optimize for Budget: Apply compression techniques to stay within memory limits
7. Validate Completeness: Ensure required knowledge for the mode has been loaded
8. Report Status: Provide completion confirmation with mode indicator

• Single Project: Unified structure, single project focus
• Monorepo Root: Multiple projects, system-wide analysis needed
• Monorepo Subproject: Focused on specific project within monorepo

• Load: index.md, concept_map.md, architecture.md, modules.md, patterns.md
• Optional: api.md, runtime.md, data.md

• Load: index.md, architecture.md, dependencies.md, patterns.md
• Optional: concept_map.md, shared/*.md
• Project summaries: projects/*/overview.md

• Load: dependencies.md, patterns.md, projects/{project_name}/*.md
• Context: index.md, architecture.md, shared/*.md

• Entities: Business concepts, technical components, APIs, data models, processes
• Relationships: Dependencies, implementations, extensions, communications, containment
• Cross-references: Links to other projects or shared components

1. Remove tertiary project details (keep interfaces only)
2. Compress unused shared code
3. Summarize verbose descriptions
4. Remove historical information
5. Compress validation details (keep critical issues)
6. Compress target project details (last resort)

• Prioritize project-specific entities and direct dependencies
• Minimize system-wide context

• Balance project details with system architecture
• Include cross-project relationships

• Standard allocation between project and system context

• Single Project: "READY [progressive]"
• Monorepo Root: "READY [progressive, system: X projects]"
• Monorepo Subproject: "READY [progressive, project: {project_name}]"

• Single Project: "READY [full: N files]"
• Monorepo Root: "READY [full: N files, system: X projects]"
• Monorepo Subproject: "READY [full: N files, project: {project_name}]"

DEPRECATION WARNING: This command is deprecated. Commands now load KB automatically.

READY [progressive]

Loaded: index.md (~80 lines)
Available: architecture.md, modules.md, patterns.md, concept_map.md
Use Read tool to load additional files as needed.

DEPRECATION WARNING: This command is deprecated. Commands now load KB automatically.

READY [full: 5 files, ~1180 lines]

• "ERROR: [specific error description]"

• Required documentation files not found
• Knowledge base exceeds memory budget after compression
• Specified project path not found
• Knowledge graph construction failed
• Cross-references could not be resolved

1. Parameter Analysis: Examine the provided parameters (rp1_root, load_mode) and determine repository structure and requirements.
2. Repository Structure Detection: Based on the parameters, determine whether this is a single project, monorepo root, or monorepo subproject, and explain the indicators that led to this conclusion.
3. File Loading Plan: List the specific documentation files you plan to load based on the detected repository structure, including both required and optional files.
4. Memory Allocation Strategy: Plan how you'll allocate the memory budget according to the focus mode, specifying percentages for project vs. system context.
5. Constraint Identification: Identify any potential issues such as missing paths, budget constraints, file availability, or other factors that might affect the loading process.
6. Loading Strategy: Create a step-by-step plan for executing the knowledge loading workflow efficiently.

• Do ALL analysis work in <thinking> tags (NOT visible to user)
• Do NOT output verbose explanations, internal logic, or step-by-step progress
• Only output the final response: "READY" or "ERROR: [message]"
• User sees only the result, not the process

READY [monorepo: 2 projects - rp1-base, rp1-dev]

Now analyzing parameters...
I see that RP1_ROOT is set to .rp1/...
Loading index.md file...
File loaded successfully, now parsing...
Extracting repository structure...
Found monorepo with 2 projects...
Loading concept_map.md...
etc. (too verbose!)

• Context efficiency: Load ~80 lines vs ~1180 lines for most tasks
• Better instruction following: Smaller context means better adherence to agent instructions
• Faster responses: Less context to process

{{$RP1_ROOT}}/context/index.md

• For pattern consistency checks -> Read

  {{$RP1_ROOT}}/context/patterns.md

• For architecture understanding -> Read

  {{$RP1_ROOT}}/context/architecture.md

• For component details -> Read

  {{$RP1_ROOT}}/context/modules.md

undefined

{{$RP1_ROOT}}/context/*.md

• {{$RP1_ROOT}}/context/index.md

  - Project overview

• {{$RP1_ROOT}}/context/architecture.md

  - System design

• {{$RP1_ROOT}}/context/modules.md

  - Component breakdown

• {{$RP1_ROOT}}/context/concept_map.md

  - Domain terminology

• {{$RP1_ROOT}}/context/patterns.md

  - Code conventions

{{$RP1_ROOT}}/context/

/knowledge-build

undefined