rooroo Documentation

repository·main·Indexed 18 days ago

https://github.com/marv1nnnnn/rooroo

A minimalist AI orchestration framework for VS Code that utilizes a team of specialized agents (Navigator, Planner, Developer, etc.) to manage software development through a structured, task-based workflow. It integrates with the Roo Code extension and uses a directory-based state management system (.rooroo/ or .state/) to track task queues, activity logs, and agent artifacts.

Tokens
7.1K
Snippets
5
Records
23
Agent score
63%

What's inside rooroo

  1. Overview of Rooroo Specialist Agents

    main

    The rooroo framework uses a team of specialized agents. For optimal cost-effectiveness, it is recommended to balance LLM tiers (Cheap/Fast vs. Smart/Expensive) based on the agent's role:

    • 🧭 Rooroo Navigator (⚡ Cheap/Fast Recommended): The central interface. Manages task flows, triages requests, dispatches tasks, and processes expert reports.
    • 🗓️ Rooroo Planner (🧠 Smart/Expensive Recommended): Decomposes complex goals into sub-tasks and creates context.md briefings for experts.
    • 🧑‍💻 Rooroo Developer (Custom / Varies): Executes coding and UI tasks based on context.md.
    • 📊 Rooroo Analyzer (⚡ Cheap/Fast Recommended): Performs analysis and generates reports.
    • ✍️ Rooroo Documenter (⚡ Cheap/Fast Recommended): Creates or updates documentation.
    • 💡 Rooroo Idea Sparker (🧠 Smart/Expensive Recommended): A Strategic Foresight Facilitator that guides users through problem exploration to produce a Handoff Document (stored in .rooroo/brainstorming/).
  2. How implementation tasks are handled in v0.1.0

    main

    In version 0.1.0, rooroo no longer uses a dedicated Apex Implementer specialist agent for writing code, tests, or performing refinements.

    Instead, the Workflow Coordinator delegates implementation, bug fixing, and test execution tasks directly to the IDE's built-in capabilities (such as code and debug modes in extensions like Roo Code or GitHub Copilot). This approach avoids functional redundancy and leverages the specialized, context-aware coding tools already present in the development environment.

  3. Understand the Task ID format and assignment process

    main

    To maintain a consistent and sequential task history, rooroo uses a standardized ID format for all tasks in project_overview.json:

    Standard Format: NNN#type#subject (where NNN is a numerical prefix, e.g., 010, 020, 030).

    Sub-task ID Lifecycle:

    1. Generation: When agents (like the Solution Architect) generate new sub-tasks, they use a temporary ID format: TEMP#type#subject within their new_tasks_to_integrate array.
    2. Centralized Assignment: The Workflow Coordinator manages the transition from temporary to permanent IDs. When processing a completed task, the Coordinator:
      • Identifies tasks with TEMP#... IDs.
      • Finds the highest numerical prefix currently used in project_overview.json.
      • Assigns the next available sequential prefix (incrementing by 10) to the temporary tasks.
    3. Integration: The tasks are then integrated into project_overview.json with their final, properly formatted NNN#type#subject IDs.
  4. Understand the rooroo orchestration workflow

    main

    The rooroo workflow follows a structured lifecycle managed by the Rooroo Navigator, moving through several distinct phases:

    Phase 0: Optional Brainstorming

    Users can initiate the process using the 💡 Rooroo Idea Sparker.

    Phase 1: User Interaction & Task Triage

    The Rooroo Navigator receives user input (a goal) and performs triage:

    • Complex/Uncertain goals: The Planner creates sub-tasks and context.md files, which the Navigator then adds to the queue.
    • Simple/Clear goals: The Navigator creates the task and context.md for direct execution or queuing.
    • Ambiguous goals: The Navigator asks the user for clarification.

    Phase 2: Queued Task Dispatch

    The Navigator checks the .rooroo/queue.jsonl. If tasks exist, the Navigator reads the task and calls the assigned Expert. The Expert executes the task using the provided context.md and produces artifacts.

    Phase 3: Expert Report Processing

    The Navigator receives a JSON Output Envelope from the Expert:

    • NeedsClarification: The Navigator asks the user and relays the response to the Expert.
    • Done: The Navigator logs the event and updates the queue. If the queue is not empty, it returns to Phase 2; otherwise, it moves to Phase 4.
    • Failed: The Navigator logs the error and moves to Phase 4.

    Phase 4: User Decision Point

    The Navigator prompts the user for decisions or next steps, which can loop back to any relevant phase or await new input.

    +----------------------------------------------------------------------+ Phase 0: Optional Brainstorming +----------------------------------------------------------------------+
    
    [User Initiates Brainstorming with 💡 Rooroo Idea Sparker]
    
    +----------------------------------------------------------------------+ Phase 1: User Interaction & Task Triage (Navigator) +----------------------------------------------------------------------+
    
    [User Input (Goal)] -> [🧭 Rooroo Navigator] -> {Triage}
        |
        |--- (Complex/Uncertain) --> [Planner: Sub-tasks & context.md] --> [Navigator: Add to Queue]
        |
        |--- (Simple, Clear for Dev/Analyzer/Doc) --> [Navigator: Task & context.md] --> [Direct Exec or Queue]
        |
        |--- (Ambiguous) --> [Navigator: Clarify with User]
        |
        +--- ("Proceed"/Auto) --> [Phase 2] / (Needs Input) --> [Phase 4]
    
    +----------------------------------------------------------------------+ Phase 2: Queued Task Dispatch (Navigator) +----------------------------------------------------------------------+
    
    [Navigator: Check Queue] --(Not Empty)--> [Navigator: Read Task, Call Expert]
        |                                                               |
       (Empty) --> [Inform User, Phase 4]                             v
                                                          [Expert: Execute (uses context.md, creates artifacts)]
                                                                        | (Expert returns JSON Output Envelope)
                                                                        v
                                                                    [Phase 3]
    
    +----------------------------------------------------------------------+ Phase 3: Expert Report Processing (Navigator) +----------------------------------------------------------------------+
    
    [Navigator: Receives JSON Output Envelope]
        |
        |--- ("NeedsClarification") --> [Navigator: Ask User] --> [Relay to Expert]
        |
        |--- ("Done"/"Failed") --> [Log, Update Queue, Inform User]
        |                             | 
        |                             +-- (If "Failed") --> [Phase 4]
        |                             +-- (If "Done" & Queue Not Empty) --> [Phase 2]
        |                             +-- (If "Done" & Queue Empty) --> [Phase 4]
    
    +----------------------------------------------------------------------+ Phase 4: User Decision Point (Navigator) +----------------------------------------------------------------------+
    
    [Navigator: Prompts User for Decision/Next Steps] --> [Loop to Relevant Phase or Await New Input]
  5. How agents report state in v0.2.0

    main

    Version 0.2.0 uses Decoupled State Reporting. Instead of agents updating a central state directly, they follow a push-pull pattern via local files.

    The State Reporting Pattern

    All executing agents (including coder-monk, solution-architect, ux-specialist, guardian-validator, and docu-crafter) must follow this lifecycle:

    1. Execute Task: Perform the requested work.
    2. Create Artifacts: Save outputs to consolidated storage (e.g., .state/specs/).
    3. Write State File: Create and write ONLY their own specific state file at .state/tasks/{taskId}.json.

    State File Content

    The state file must include the final outcome and relevant details. For example:

    • coder-monk reports its status (Done/Failed/Error), output_references (paths of modified files), and logs.
    • Other agents include details like planned_subtasks or validation_result_for_target.

    Coordinator Consumption

    The Workflow Coordinator waits for a completion signal, then pulls the authoritative result by reading the specific .state/tasks/{taskId}.json file created by the agent.

  6. Understand the Rooroo Navigator orchestration model

    main

    In v0.5.0, the Rooroo Navigator replaces the previous workflow-coordinator. It acts as an interactive, persona-driven guide that manages the entire task lifecycle.

    Key responsibilities:

    • Triage & Dispatch: Manages the flow of tasks from initial triage to specialized experts.
    • Direct Orchestration: Directly manages task execution and processes outputs.
    • User Interaction: Communicates task statuses and decisions to the user, often using tools like ask_followup_question to resolve ambiguities.
    • Task Identification: Uses a unified ROO# prefix for all task identifiers (e.g., ROO#PLAN_..., ROO#TEMP_..., ROO#SUB_...).
  7. Understand the v0.2.0 Coordinator-led Workflow

    main

    In version 0.2.0, the orchestration model shifted from a Planner-led approach to a Coordinator-led, signal-driven model.

    Key Roles & Responsibilities

    • Workflow Coordinator (Primary Orchestrator): The entry point for all user requests. It performs rule-based triage. It delegates planning to smart models and execution to specialists. It does not perform planning itself but follows the suggested_mode provided by the Planner. It waits for completion signals, reads agent-created state files, and performs batch updates to the project overview.
    • Strategic Planner (On-demand Specialist): Invoked by the Coordinator only when planning/design is required. It decomposes goals and populates project_overview.json using the NNN:type:subject taskId format. Crucially, the Planner does not create task state files; it only provides the delegation_details and suggested_mode.

    Workflow Logic

    1. User request enters via the Coordinator.
    2. Coordinator triages the request.
    3. If planning is needed, Coordinator calls the Planner.
    4. Planner provides suggested_mode and task details.
    5. Coordinator delegates execution to the appropriate specialist (e.g., coder-monk).
    6. Specialist executes and writes its own state file.
    7. Coordinator detects completion, reads the state file, and updates the overview.
  8. Use the .rooroo/ directory structure for task management

    main

    Version 0.5.0 replaces the .state/ directory with a centralized .rooroo/ namespace. All task context, logs, and outputs are stored here.

    Directory Schema:

    • .rooroo/queue.jsonl: Contains pending tasks managed by rooroo-planner and consumed by rooroo-navigator using ROO# IDs.
    • .rooroo/logs/activity.jsonl: A dedicated log file where the Navigator records events using the SafeLogEvent procedure.
    • .rooroo/tasks/TASK_ID/: The primary directory for a specific task.
      • context.md: The detailed briefing file for the assigned expert (created by rooroo-planner or rooroo-navigator).
      • artifacts/AGENT_SLUG/: A subdirectory where the specific expert stores its outputs (files, data, reports).
    • .rooroo/plans/: Stores overview documents generated by rooroo-planner.
    • .rooroo/brainstorming/: Stores notes from rooroo-idea-sparker.
  9. Understand the v0.1.0 Agent Architecture (Planner/Coordinator Split)

    main

    As of version 0.1.0, rooroo has moved away from a monolithic Master Orchestrator to a split architecture to improve simplicity and separation of concerns. The orchestration is now handled by two distinct roles:

    1. Strategic Planner: Responsible for the high-level reasoning phase. It interprets user goals, decomposes them into a high-level plan and specific tasks, and initializes the project state (creating project_overview.json and the .state/tasks/ directory). This role requires high reasoning capabilities.
    2. Workflow Coordinator: Responsible for the procedural execution phase. It is a reactive, state-driven role that monitors the current state, delegates tasks according to the plan, manages task-related interactions (such as test prompts), and updates the state based on task outcomes.

    This separation allows developers to optimize resource usage by assigning high-reasoning (expensive) LLMs to the Strategic Planner and faster, cheaper LLMs to the Workflow Coordinator.

  10. Understand the roles of Workflow Coordinator and Strategic Planner (v0.4.0)

    main

    The v0.4.0 architecture realigns agent responsibilities to separate mechanical dispatching from intelligent planning.

    Workflow Coordinator

    Role: A mechanical dispatcher using a cheaper model. Responsibilities:

    1. Triage user requests by adding a temporary task to task_queue.jsonl for the Planner.
    2. Consume the top task from task_queue.jsonl.
    3. Log actions (e.g., task_delegated) to task_log.jsonl.
    4. Rewrite task_queue.jsonl after consuming a task.
    5. Delegate tasks to agents and read their state from .state/tasks/{taskId}.json upon completion.
    6. Log completion/failure to task_log.jsonl and proceed to the next task.

    Strategic Planner

    Role: The intelligent authority managing the task queue using a smarter model. Responsibilities:

    1. Create initial plans and populate task_queue.jsonl.
    2. Assign all final task IDs using the NNN#type#subject format.
    3. Manage the queue: integrate new work items or sub-tasks into task_queue.jsonl at appropriate positions based on priority/dependencies.
    4. Handle error conditions and initiate refinement loops (e.g., adding tasks for the Solution Architect).
    5. Log planning actions (e.g., plan_updated, task_integrated_into_queue) to task_log.jsonl.
  11. Migrate from project_overview.json to JSONL (v0.4.0 Breaking Change)

    main

    In version 0.4.0, rooroo transitioned from a single central JSON file (project_overview.json) to a line-oriented JSONL (JSON Lines) architecture. This change improves robustness by replacing complex in-place JSON updates with simpler append/remove operations.

    Key Data Files:

    • task_queue.jsonl: The definitive source for tasks. Each line is a self-contained JSON object representing a single task. The Workflow Coordinator consumes the top task and rewrites the file without it, while the Strategic Planner manages the entire queue.
    • task_log.jsonl: An append-only audit trail. Both the Workflow Coordinator and Strategic Planner record significant events (e.g., task_delegated, plan_updated) as structured JSON objects on separate lines.

    Migration Note: Any existing workflows or tools that rely on reading or writing to project_overview.json will break and must be updated to use these new JSONL files.

  12. How the Rooroo Workflow works

    main

    The rooroo workflow follows a Navigator-led orchestration model designed to move from high-level goals to specific execution tasks:

    1. Initiation: Select the 🧭 Rooroo Navigator and state your goal.
    2. Triage: The Navigator assesses the request.
      • Complex/Uncertain tasks: The Navigator engages the 🗓️ Rooroo Planner to decompose the goal into sub-tasks. These sub-tasks are added to .rooroo/queue.jsonl with context.md briefings.
      • Simple tasks: The Navigator prepares a context.md briefing and may execute a single expert (Developer, Analyzer, or Documenter) directly or via the queue.
      • Ambiguous tasks: The Navigator asks you for clarification.
    3. Execution: The Navigator dispatches tasks from the queue to the assigned expert. The expert uses its context.md briefing and stores its outputs in .rooroo/tasks/TASK_ID/.
    4. Reporting: Experts return a JSON Output Envelope (containing status, message, and artifacts) to the Navigator.
    5. Iteration: The Navigator parses the envelope. If the status is NeedsClarification, it asks you; if Done or Failed, it logs the event and updates the queue.