### Conductor Tasks CLI Common Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/README.md

Examples of frequently used Conductor Tasks CLI commands for project initialization, parsing PRD files, listing, getting, updating, generating steps for, and visualizing tasks.

```bash
# Initialize Conductor Tasks in a new or existing project
conductor-tasks init --projectName "My Awesome App" --projectDescription "Building the future"

# Parse a PRD file and create/update TASKS.md
conductor-tasks parse-prd ./path/to/your/prd.md --createTasksFile

# List all tasks
conductor-tasks list

# Get the next suggested task
conductor-tasks next

# Get details for a specific task
conductor-tasks get --id <TASK_ID>

# Update a task (e.g., set status to 'in_progress')
conductor-tasks update --id <TASK_ID> --status in_progress

# Generate detailed implementation steps for a task
conductor-tasks generate-steps --id <TASK_ID>

# Visualize tasks
conductor-tasks visualize --kanban
conductor-tasks visualize --dependency-tree
```

--------------------------------

### Configure xAI (Grok) LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the xAI (Grok) LLM provider. Includes XAI_API_KEY for authentication and XAI_MODEL to specify the Grok model version.

```bash
XAI_API_KEY=...
XAI_MODEL=grok-1
```

--------------------------------

### Configure Groq LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the Groq LLM provider. Includes GROQ_API_KEY for authentication and GROQ_MODEL to specify the Groq model version.

```bash
GROQ_API_KEY=gsk_...
GROQ_MODEL=llama3-8b-8192 # or llama3-70b-8192, gemma-7b-it
```

--------------------------------

### Install Conductor Tasks CLI

Source: https://github.com/hridaya423/conductor-tasks/blob/main/README.md

Instructions for installing the Conductor Tasks command-line interface globally using npm, or using npx for a temporary execution without global installation.

```bash
# Install globally (recommended for CLI use)
npm install -g conductor-tasks

# Or use npx without installing globally
# npx conductor-tasks <command>
```

--------------------------------

### Configure Google (Gemini) LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the Google (Gemini) LLM provider. Includes GEMINI_API_KEY for authentication and GEMINI_MODEL to specify the Gemini model version.

```bash
GEMINI_API_KEY=... # Google AI Studio API key
GEMINI_MODEL=gemini-1.5-pro # or gemini-1.5-flash, gemini-1.0-pro
```

--------------------------------

### Configure Perplexity LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the Perplexity LLM provider. Includes PERPLEXITY_API_KEY for authentication, PERPLEXITY_MODEL to specify the Perplexity model version, and an optional PERPLEXITY_API_BASE_URL for custom API endpoints.

```bash
PERPLEXITY_API_KEY=...
PERPLEXITY_MODEL=llama-3-sonar-medium-32k-online 
PERPLEXITY_API_BASE_URL=https://api.perplexity.ai
```

--------------------------------

### Configure OpenAI (GPT) LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the OpenAI (GPT) LLM provider. Includes OPENAI_API_KEY for authentication, OPENAI_MODEL to specify the GPT model version, and an optional OPENAI_API_BASE_URL for custom API endpoints.

```bash
OPENAI_API_KEY=sk-...
OPENAI_MODEL=gpt-4o # or gpt-4-turbo, gpt-3.5-turbo
OPENAI_API_BASE_URL=https://api.openai.com/v1 # only needed if using a custom API base URL
```

--------------------------------

### Configure Ollama Local LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the Ollama local LLM provider. Includes OLLAMA_ENABLED to activate Ollama, OLLAMA_MODEL to specify the local model, and an optional OLLAMA_BASE_URL for the Ollama server address.

```bash
OLLAMA_ENABLED=true
OLLAMA_MODEL=llama3 # or any model you have installed in Ollama
OLLAMA_BASE_URL=http://localhost:11434
```

--------------------------------

### Initializing Conductor Project with TASKS.md

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Describes the initial steps for setting up a Conductor project, including creating TASKS.md and the basic Conductor Tasks setup using 'initialize-project', and parsing PRDs with 'parse-prd'.

```APIDOC
initialize-project
parse-prd --input='<path_to_prd>'
```

--------------------------------

### Configure Mistral AI LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the Mistral AI LLM provider. Includes MISTRAL_API_KEY for authentication, MISTRAL_MODEL to specify the Mistral model version, and an optional MISTRAL_API_BASE_URL for custom API endpoints.

```bash
MISTRAL_API_KEY=...
MISTRAL_MODEL=mistral-large-latest # or mistral-medium, mistral-small, mixtral-8x7b
MISTRAL_API_BASE_URL=https://api.mistral.ai # only needed if using a custom API base URL
```

--------------------------------

### Configure Anthropic (Claude) LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the Anthropic (Claude) LLM provider. Includes ANTHROPIC_API_KEY for authentication, ANTHROPIC_MODEL to specify the Claude model version, and an optional ANTHROPIC_API_BASE_URL for custom API endpoints.

```bash
ANTHROPIC_API_KEY=sk-ant-...
ANTHROPIC_MODEL=claude-3.7-sonnet-20240607 # or claude-3-opus-20240229, claude-3-haiku-20240307
ANTHROPIC_API_BASE_URL=https://api.anthropic.com # only needed if using a custom API base URL
```

--------------------------------

### Set Default LLM Provider Preference

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This section explains the system's default LLM provider preference order when multiple API keys are available and no specific provider is selected. It also provides an example of how to override this order by setting the `DEFAULT_LLM_PROVIDER` environment variable to a preferred provider name.

```APIDOC
When multiple API keys are provided and no specific provider is selected, the system uses the following preference order:
1. Anthropic (Claude)
2. OpenAI (GPT)
3. Groq
4. Google Gemini
5. Mistral AI
6. xAI (Grok)
7. Perplexity
8. Ollama (Local)
9. OpenRouter

Valid provider names: anthropic, openai, groq, gemini, mistral, xai, perplexity, ollama, or openrouter.
```

```shell
DEFAULT_LLM_PROVIDER=openai
```

--------------------------------

### Project Initialization Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

Commands used to set up a new project or parse existing Project Requirement Documents (PRDs) within the AI workflow, typically at the start of a new task or project.

```CLI
initialize-project
```

```CLI
parse-prd --input='<path_to_prd>'
```

--------------------------------

### Read Project README File

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_ask.txt

Access essential project information such as goals, setup instructions, and the technology stack by reading the `README.md` file. This is a primary step for understanding the project context.

```APIDOC
read_file README.md
```

--------------------------------

### Conductor Tasks Environment Variables Configuration

Source: https://github.com/hridaya423/conductor-tasks/blob/main/README.md

An example .env file demonstrating how to set required LLM API keys and optional configuration variables like default LLM provider, specific model names, custom base URLs, and logging level for Conductor Tasks.

```dotenv
# Required Keys (add all you intend to use)
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=ant-...
GOOGLE_API_KEY=AIza...

# Optional Defaults & Customization
DEFAULT_LLM_PROVIDER=openai
OPENAI_MODEL=gpt-4o
ANTHROPIC_MODEL=claude-3-opus-20240229
# OPENAI_BASE_URL=http://localhost:11434/v1 # Example for local Ollama
LOG_LEVEL=info
```

--------------------------------

### Cline Project Initialization Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/cline.txt

Commands for setting up a new project or parsing existing Project Requirement Documents (PRDs) within the Cline environment. These are typically used at the start of a new project or phase.

```CLI
initialize-project
```

```CLI
parse-prd --input='<path_to_prd>'
```

--------------------------------

### Configure OpenRouter LLM Provider

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

Environment variables for configuring the OpenRouter LLM provider. Includes OPENROUTER_API_KEY for authentication and OPENROUTER_MODEL to specify any model available on OpenRouter. Optional variables like OPENROUTER_API_BASE_URL, OPENROUTER_SITE_URL, and OPENROUTER_APP_NAME are also provided.

```bash
OPENROUTER_API_KEY=sk-or-v1-...
OPENROUTER_MODEL=anthropic/claude-3-opus # Example: Specify any model available on OpenRouter
# OPENROUTER_API_BASE_URL=https://openrouter.ai/api/v1 # Usually not needed to change
# OPENROUTER_SITE_URL= # For self-hosted instances, if applicable
# OPENROUTER_APP_NAME= # Your app name for headers
```

--------------------------------

### Guiding Principles for AI Interaction with Conductor Tasks

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Explains the fundamental rules for the AI, including exclusive use of MCP tools, detailed record-keeping, user-centric communication, relative file paths, and avoiding guesswork. It lists the primary MCP tools for interaction.

```APIDOC
MCP Tools:
- list-tasks
- get-task
- update-task
- add-task-note
- read_file
- apply_diff
- execute_command
- ask_followup_question
```

--------------------------------

### Guiding Principles for AI Interaction with Conductor Tasks

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Outlines the core principles for AI interaction, emphasizing exclusive use of MCP tools, detailed record-keeping via add-task-note, user-centric communication, relative file paths, and the importance of ask_followup_question for clarity.

```APIDOC
MCP Tool Primacy:
  Interaction is solely through MCP tools (e.g., list-tasks, get-task, update-task, add-task-note, read_file, apply_diff, execute_command, ask_followup_question).
Detailed Record Keeping:
  Use add-task-note extensively for documenting process, findings, and actions.
User-Centric Communication:
  Clear notes and accurate task status updates are vital for user understanding.
File Path Relativity:
  All file paths in MCP tool parameters must be relative to the project workspace root.
No Guesswork:
  Use ask_followup_question if requirements, file paths, or any other aspect is unclear.
```

--------------------------------

### Configure Conductor Tasks with MCP Environment Variables

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This JSON snippet demonstrates how to set up the Conductor Tasks application within an editor's Model Control Protocol (MCP) settings. It includes the command to run the application and a comprehensive list of environment variables for configuring various LLM API keys and default model parameters such as DEFAULT_LLM_PROVIDER, MODEL, TEMPERATURE, MAX_TOKENS, TOP_P, FREQUENCY_PENALTY, PRESENCE_PENALTY, DEFAULT_SUBTASKS, and DEFAULT_PRIORITY.

```json
{
  "mcpServers": {
    "conductor-tasks": {
      "command": "npx",
      "args": [
        "-y",
        "conductor-tasks",
        "--serve-mcp"
      ],
      "env": {
        "ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE",
        "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
        "MISTRAL_API_KEY": "YOUR_MISTRAL_API_KEY_HERE",
        "GROQ_API_KEY": "YOUR_GROQ_API_KEY_HERE",
        "GEMINI_API_KEY": "YOUR_GEMINI_API_KEY_HERE",
        "XAI_API_KEY": "YOUR_XAI_API_KEY_HERE",
        "PERPLEXITY_API_KEY": "YOUR_PERPLEXITY_API_KEY_HERE",
        "OLLAMA_ENABLED": "true",
        "OPENROUTER_API_KEY": "YOUR_OPENROUTER_API_KEY_HERE",
        
        "DEFAULT_LLM_PROVIDER": "anthropic",
        
        "MODEL": "claude-3.7-sonnet-20240607",
        "TEMPERATURE": "0.7",
        "MAX_TOKENS": "4000",
        "TOP_P": "0.9",
        "FREQUENCY_PENALTY": "0.0",
        "PRESENCE_PENALTY": "0.0",
        
        "DEFAULT_SUBTASKS": "3",
        "DEFAULT_PRIORITY": "medium"
      }
    }
  }
}
```

--------------------------------

### AI Tool: Read File for Project Overview

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_ask.txt

Access file content using `read_file` to gather project goals, setup instructions, and tech stack from files like `README.md` or `TASKS.md`.

```APIDOC
read_file(file_path: str) -> str
  file_path: The path to the file to be read (e.g., "README.md", "TASKS.md").
  Returns: The content of the specified file.
Usage Example: read_file README.md
```

--------------------------------

### Implementing File Modifications and Creations

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Outlines the procedure for modifying existing files using 'read_file' to get current content and 'apply_diff' with precise SEARCH and REPLACE blocks, and creating new files with 'write_to_file' providing complete content.

```APIDOC
read_file <path>

apply_diff:
  SEARCH: |
    // Existing code block to find
    function oldFunction() {
      // ...
    }
  REPLACE: |
    // New code block to insert
    function newFunction() {
      // ...
    }
  PATH: <path_to_file>

write_to_file <path>:
  Content: |
    // Complete content for the new file
    console.log("Hello, World!");
```

--------------------------------

### Customize LLM Generation Parameters

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This section outlines environment variables for fine-tuning text generation parameters such as `TEMPERATURE` (randomness), `MAX_TOKENS` (output length), `TOP_P` (nucleus sampling), `FREQUENCY_PENALTY`, and `PRESENCE_PENALTY`. These settings influence the quality and style of generated text.

```APIDOC
Environment Variable | Description | Default Value
----------------------|-------------|--------------
TEMPERATURE | Controls randomness (0-1) | 0.7
MAX_TOKENS | Maximum tokens to generate | 4000
TOP_P | Nucleus sampling parameter | *Provider default*
FREQUENCY_PENALTY | Penalty for token frequency | *Provider default*
PRESENCE_PENALTY | Penalty for token presence | *Provider default*
```

--------------------------------

### Managing Iterative Subtasks with Windsurf MCP Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

This section provides a step-by-step guide on how to manage iterative subtasks using Windsurf's MCP command-line tools. It covers understanding task requirements, planning, logging progress, updating status, and verifying completion.

```Shell
get-task --id <subtask_id>
```

```Shell
add-task-note --id <subtask_id> --note "Initial Plan: [Comprehensive details: file paths, line numbers, proposed diffs, reasoning...]"
```

```Shell
update-task --id <subtask_id> --status "in progress"
```

```Shell
add-task-note --id <subtask_id> --note "Progress Update: [New findings, what worked/didn't, code snippets, decisions, deviations from plan...]"
```

```Shell
update-task --id <subtask_id> --status "completed"
```

```Shell
add-task-note --id <subtask_id> --note "Implementation complete and verified. [Summary of solution]."
```

--------------------------------

### Configure LLM Model Selection via Environment Variables

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This section details environment variables used to specify the default LLM model globally or for specific providers like Anthropic, OpenAI, Mistral, Groq, Gemini, xAI, Perplexity, Ollama, and OpenRouter. It allows users to control which language model is used for different AI operations.

```APIDOC
Environment Variable | Description | Default Value
----------------------|-------------|--------------
MODEL | Global default model to use if no provider-specific model is set | Provider-dependent
ANTHROPIC_MODEL | Model to use with Anthropic | claude-3-opus-20240229
OPENAI_MODEL | Model to use with OpenAI | gpt-4o
MISTRAL_MODEL | Model to use with Mistral AI | mistral-large-latest
GROQ_MODEL | Model to use with Groq | llama3-8b-8192
GEMINI_MODEL | Model to use with Google | gemini-1.5-pro
XAI_MODEL | Model to use with xAI | grok-1
PERPLEXITY_MODEL | Model to use with Perplexity | llama-3-sonar-medium-32k-online
OLLAMA_MODEL | Model to use with Ollama | llama3
OPENROUTER_MODEL | Model to use with OpenRouter. Specify model by its full OpenRouter path. | User Defined (e.g., anthropic/claude-3-opus)
```

--------------------------------

### Understanding Current Conductor Task State

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Details how the AI can get an overview of tasks, identify the immediate focus, and analyze specific task details using 'list-tasks', 'get-next-task', 'get-task', and 'read_file' for broader project context.

```APIDOC
list-tasks
get-next-task
get-task --id <task_id>
read_file TASKS.md
```

--------------------------------

### CLI Workflow for Function Optimization and Task Management

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

This snippet details a comprehensive command-line interface (CLI) workflow for a software development task. It covers retrieving task information, planning, reading and modifying code, writing and executing tests, and meticulously documenting each step and outcome using various CLI commands. The example focuses on optimizing a Python function and verifying performance improvements.

```CLI
get-next-task
get-task --id TSK-15
read_file src/utils.py
add-task-note --id TSK-15 --note "Initial Plan for TSK-15: Current calculate_sum in utils.py uses a list comprehension then sum(). Will replace with a direct generator sum or math.fsum for potential performance gain on large lists. Will verify with a new pytest benchmark."
update-task --id TSK-15 --status "in progress"
apply_diff src/utils.py (with SEARCH block from read_file and new optimized code in REPLACE for calculate_sum)
add-task-note --id TSK-15 --note "Progress Update: Applied diff to src/utils.py to optimize calculate_sum. Next: write and run tests."
write_to_file src/tests/test_utils_performance.py --content "..."
add-task-note --id TSK-15 --note "Progress Update: Created src/tests/test_utils_performance.py with benchmark for calculate_sum."
execute_command "pytest src/tests/test_utils_performance.py"
add-task-note --id TSK-15 --note "Progress Update: pytest output: [key results showing performance improvement or issues]."
update-task --id TSK-15 --status completed
add-task-note --id TSK-15 --note "Implementation complete for TSK-15. Refactored calculate_sum in utils.py, performance improvement verified with pytest benchmark. Optimized by replacing list comprehension with a direct sum."
```

--------------------------------

### AI Tool: Get Task Details for Dependency Analysis

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_ask.txt

Retrieve details of a specific task, including its dependencies, to understand potential sequencing influences for conceptual estimations.

```APIDOC
get-task(id: str) -> dict
  id: The ID of the task to retrieve.
  Returns: A dictionary containing details of the specified task, including dependencies.
Usage Example: get-task --id <id>
```

--------------------------------

### Conductor Task: Search Files

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_code.txt

Searches files within the project to find examples of how a particular function is used elsewhere or to locate related utility functions.

```APIDOC
search_files
```

--------------------------------

### Assign Task Types to Specific LLM Providers

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This advanced feature allows assigning specific LLM providers to different task types using environment variables like `ANTHROPIC_TASKS`, `PERPLEXITY_TASKS`, `OPENAI_TASKS`, and `MISTRAL_TASKS`. This optimizes performance, cost, and quality by matching task requirements with suitable models. Tasks not explicitly mapped will use the default provider or preference order.

```shell
# Assign task types to specific providers
ANTHROPIC_TASKS="initialize-project, parse-prd"
PERPLEXITY_TASKS="research-topic"
OPENAI_TASKS="generate-implementation-steps, help-implement-task"
MISTRAL_TASKS="suggest-task-improvements"
```

--------------------------------

### Conductor Task Management and Code Optimization Workflow

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/cline.txt

This snippet illustrates a complete workflow for managing a development task (TSK-15) from initial planning to completion. It involves using various command-line tools to get task details, read/write files, apply code changes, add notes, update task status, and execute tests to verify performance improvements.

```CLI
get-next-task
get-task --id TSK-15
read_file src/utils.py
add-task-note --id TSK-15 --note "Initial Plan for TSK-15: Current calculate_sum in utils.py uses a list comprehension then sum(). Will replace with a direct generator sum or math.fsum for potential performance gain on large lists. Will verify with a new pytest benchmark."
update-task --id TSK-15 --status "in progress"
apply_diff src/utils.py
add-task-note --id TSK-15 --note "Progress Update: Applied diff to src/utils.py to optimize calculate_sum. Next: write and run tests."
write_to_file src/tests/test_utils_performance.py --content "..."
add-task-note --id TSK-15 --note "Progress Update: Created src/tests/test_utils_performance.py with benchmark for calculate_sum."
execute_command "pytest src/tests/test_utils_performance.py"
add-task-note --id TSK-15 --note "Progress Update: pytest output: [key results showing performance improvement or issues]."
update-task --id TSK-15 --status completed
add-task-note --id TSK-15 --note "Implementation complete for TSK-15. Refactored calculate_sum in utils.py, performance improvement verified with pytest benchmark. Optimized by replacing list comprehension with a direct sum."
```

--------------------------------

### Understand LLM Provider Retry Mechanisms

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This section describes the built-in retry logic for LLM providers, which automatically handles transient errors like network issues and rate limits. It explains that the system uses exponential backoff to prevent API overload and provides detailed error reporting in logs, ensuring robust communication with LLM services.

```APIDOC
- Automatically retries on network errors and rate limits
- Uses exponential backoff to avoid overwhelming APIs
- Provides detailed error reporting in logs
```

--------------------------------

### Configure LLM Provider Fallback Behavior

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This section explains the system's provider fallback mechanism, which attempts requests with other configured providers in the preference order if a primary provider fails due to non-recoverable errors. It also notes that this feature can be disabled by setting `DISABLE_PROVIDER_FALLBACK=true`.

```APIDOC
- Attempts the request with each available provider in the preference order
- Only happens on non-recoverable errors (not rate limits)
- Can be disabled by setting DISABLE_PROVIDER_FALLBACK=true
```

--------------------------------

### Configure Task Management Behavior

Source: https://github.com/hridaya423/conductor-tasks/blob/main/docs/mcp-setup.md

This section describes environment variables for customizing task management within Conductor Tasks, including `DEFAULT_SUBTASKS` (number of subtasks), `DEFAULT_PRIORITY` (task priority), `CONDUCTOR_TASKS_FILE` (custom path for TASKS.md), and `WORKSPACE_DIR` (custom workspace directory). These settings control how tasks are generated and managed.

```APIDOC
Environment Variable | Description | Default Value
----------------------|-------------|--------------
DEFAULT_SUBTASKS | Number of subtasks to generate for each task | 3
DEFAULT_PRIORITY | Default priority for new tasks | medium
CONDUCTOR_TASKS_FILE | Custom path for the TASKS.md file | TASKS.md in workspace root
WORKSPACE_DIR | Custom workspace directory path | Auto-detected
```

--------------------------------

### Read and Analyze Log Files

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_debug.txt

Employ `read_file` to inspect log files, optionally specifying start and end lines, to identify timestamps, error messages, and stack traces.

```Command Line
read_file <log_file_path> [start_line] [end_line]
```

--------------------------------

### Get Task Details for Dependency Analysis and Sequencing

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_ask.txt

Retrieve detailed information about a specific task using `get-task --id <id>`. This command is crucial for analyzing task dependencies and understanding their implications on sequencing for conceptual effort estimations.

```APIDOC
get-task --id <id>
```

--------------------------------

### Code Comment for Task Traceability

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_code.txt

An example of adding a comment to significant code blocks to reference a task ID, aiding traceability and understanding of the code's purpose in relation to specific tasks.

```Generic
// TASK-123: Refactored user authentication logic for OAuth2 support.
```

--------------------------------

### Roo Code Conductor Tasks AI Configuration Settings

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_mode.txt

Defines the core operational mode, framework, language detection, and integration method for Roo Code's AI when interacting with Conductor Tasks. These settings guide the AI's interaction with the project environment via MCP server tools.

```YAML
mode: development # Default mode, can be overridden by user
framework: conductor-tasks
language: auto-detect # Roo Code might try to determine this
integration: mcp # Critical: Indicates AI interacts via MCP server tools
```

--------------------------------

### AI Workflow: Project Initialization with Conductor Tasks

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Describes the initial steps for an AI, including creating TASKS.md using initialize-project if missing, and considering parse-prd for PRDs.

```APIDOC
initialize-project: Creates TASKS.md and the basic Conductor Tasks setup.
parse-prd --input='<path_to_prd>': Parses a Product Requirements Document (if available as MCP tool).
```

--------------------------------

### Initialize Conductor Project

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

Commands to initialize a new project or parse a Product Requirements Document (PRD) if TASKS.md is absent, setting up the initial project structure for Conductor tasks.

```Shell
initialize-project
parse-prd --input='<path_to_prd>'
```

--------------------------------

### Clarifying Requirements with ask_followup_question

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_general.txt

Instructions for using the `ask_followup_question` tool when requirements are vague, file paths are uncertain, or task details are insufficient. It is critical to use this tool immediately, provide specific questions, and suggest 2-4 actionable answers for the user, avoiding assumptions.

```APIDOC
ask_followup_question Tool Usage:
  - Use immediately for vague requirements, uncertain file paths, or insufficient task details.
  - Provide specific questions.
  - Suggest 2-4 actionable answers for the user.
  - Do not make assumptions.
```

--------------------------------

### Initialize Conductor Project

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_general.txt

Commands to initialize a new project if TASKS.md is missing, or to parse Product Requirement Documents (PRDs).

```CLI
initialize-project
```

```CLI
parse-prd --input='<path_to_prd>'
```

--------------------------------

### Configure Conductor Tasks MCP Server for Editor Integration

Source: https://github.com/hridaya423/conductor-tasks/blob/main/README.md

This JSON configuration block sets up the Conductor Tasks MCP server within an editor's settings. It defines the command to run, arguments, and environment variables for API keys (OpenAI, Anthropic, Google, etc.) and the default LLM provider, enabling seamless integration and AI chat interactions.

```JSON
{
  "mcpServers": {
    "conductor-tasks": {
      "command": "npx",
      "args": ["conductor-tasks", "--serve-mcp"],
      "env": {
        "OPENAI_API_KEY": "YOUR_OPENAI_KEY_HERE",
        "ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_KEY_HERE",
        "GOOGLE_API_KEY": "YOUR_GOOGLE_KEY_HERE",
        "DEFAULT_LLM_PROVIDER": "openai"
      }
    }
  }
}
```

--------------------------------

### Executing Shell Commands and Analyzing Output

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Details how to execute shell commands using 'execute_command' for builds, tests, and linters. Emphasizes careful analysis of output for success or errors and logging key results with 'add-task-note'.

```APIDOC
execute_command "your_shell_command"
```

--------------------------------

### Conductor Tasks: Asking Follow-up Questions for Clarification

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

If requirements are vague, file paths uncertain, or task details insufficient, the AI assistant must immediately use `ask_followup_question`. Specific questions should be provided, along with 2-4 actionable answers for the user to choose from, avoiding assumptions.

```Shell
ask_followup_question --question "<YOUR_QUESTION>" --options "<OPTION1>" "<OPTION2>" "<OPTION3>"
```

--------------------------------

### Gathering Information and Analyzing Project Structure

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Explains how the AI can explore the project structure, examine file contents, search for specific code or text, and list code definitions using 'list_files', 'read_file', 'search_files', and 'list_code_definition_names'.

```APIDOC
list_files .
list_files src/
read_file <path_to_file> [start_line] [end_line]
search_files --path <dir> --regex "pattern" --file_pattern "*.ext"
list_code_definition_names <path_to_file_or_dir>
```

--------------------------------

### AI Workflow: Information Gathering and Analysis

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Explains the iterative process for the AI to gather and analyze project information, including listing files, reading file content, searching for code, and listing code definitions.

```APIDOC
list_files <path>: Lists files in a directory (e.g., 'list_files .', 'list_files src/').
read_file <path_to_file> [start_line] [end_line]: Reads content of a file or a specific section.
search_files --path <dir> --regex "pattern" --file_pattern "*.ext": Searches for specific code or text within files.
list_code_definition_names <path_to_file_or_dir>: Lists class/function structures.
```

--------------------------------

### Conductor Task Overview and Selection

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_general.txt

Commands to list all tasks, identify the next immediate task based on dependencies and priority, and retrieve full details for a specific task. Also includes reading the TASKS.md file for broader context.

```CLI
list-tasks
```

```CLI
get-next-task
```

```CLI
get-task --id <task_id>
```

```CLI
read_file TASKS.md
```

--------------------------------

### AI Workflow: Tool-Driven Implementation

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Details the methods for the AI to implement changes, including modifying existing files using read_file and apply_diff, creating new files with write_to_file, and executing shell commands with execute_command.

```APIDOC
read_file <path_to_file> [start_line] [end_line]: Used to get current content before modification.
apply_diff <diff_content>: Applies a diff operation to a file, requiring a SEARCH and REPLACE block.
write_to_file <path> <content>: Creates a new file or overwrites an existing one with complete content.
execute_command "your_shell_command": Executes a shell command.
```

--------------------------------

### Explore Codebase for Task Implementation

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_general.txt

Commands for thoroughly investigating relevant parts of the codebase and project, including reading files, searching content, listing files, and listing code definition names, to aid in planning task implementation.

```CLI
read_file
```

```CLI
search_files
```

```CLI
list_files
```

```CLI
list_code_definition_names
```

--------------------------------

### Search Project Files by Keyword and Pattern

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_ask.txt

Perform a targeted keyword search across specified file types within the project directory using `search_files`. This helps in finding relevant information in code or documentation, with adjustable file patterns.

```APIDOC
search_files --path . --regex "keyword" --file_pattern "*.md,*.txt,*.java,*.js,*.py"
```

--------------------------------

### Windsurf: Iterative Subtask Management Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

This snippet provides a sequence of command-line instructions for managing subtasks within the Windsurf environment. It covers fetching task requirements, logging plans and progress, updating task status, and adding final summaries, ensuring a detailed audit trail for each subtask.

```bash
get-task --id <subtask_id>
```

```bash
add-task-note --id <subtask_id> --note "Initial Plan: [Comprehensive details: file paths, line numbers, proposed diffs, reasoning...]"
```

```bash
update-task --id <subtask_id> --status "in progress"
```

```bash
add-task-note --id <subtask_id> --note "Progress Update: [New findings, what worked/didn't, code snippets, decisions, deviations from plan...]"
```

```bash
update-task --id <subtask_id> --status "completed"
```

```bash
add-task-note --id <subtask_id> --note "Implementation complete and verified. [Summary of solution]."
```

--------------------------------

### Cline Task Overview and Selection Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/cline.txt

Tools for gaining situational awareness of current tasks and selecting the next immediate focus. These commands help users understand the project's state and prioritize work.

```CLI
list-tasks
```

```CLI
get-next-task
```

```CLI
get-task --id <task_id>
```

```CLI
read_file TASKS.md
```

--------------------------------

### Task Implementation and Execution Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

Core commands for performing actual work, including modifying existing files using diffs, creating new files with complete content, and executing arbitrary shell commands as part of task implementation.

```CLI
apply_diff <path>
```

```CLI
write_to_file <path>
```

```CLI
execute_command "shell_command"
```

--------------------------------

### AI Workflow: Task Progress and Critical Documentation

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Explains the importance of updating task statuses and meticulously documenting all actions, findings, and issues using add-task-note.

```APIDOC
update-task --id <task_id> --status <new_status>: Updates the status of a task (e.g., 'in progress', 'completed', 'blocked', 'review').
add-task-note --id <task_id> --note "<note_content>": Records detailed notes about the AI's process, findings, and actions.
```

--------------------------------

### Task Overview and Selection Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

Commands for gaining situational awareness, listing all tasks, identifying the next immediate focus, and retrieving full details for a specific task from the project's task list.

```CLI
list-tasks
```

```CLI
get-next-task
```

```CLI
get-task --id <task_id>
```

```CLI
read_file TASKS.md
```

--------------------------------

### Applying Code Changes with apply_diff

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_general.txt

Guidelines for using the `apply_diff` tool, emphasizing the critical requirement for the `SEARCH` block to be an exact match of the current file content, including all whitespace and indentation. Verification with `read_file` immediately before constructing the diff is crucial for accuracy.

```APIDOC
apply_diff Tool Usage:
  - The 'SEARCH' block within the diff must be an exact match of the current file content.
  - This includes all whitespace and indentation.
  - Verify with 'read_file' immediately before constructing the diff.
```

--------------------------------

### Conductor MCP Tools for AI Interaction

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

This snippet lists the exclusive set of Conductor MCP command-line tools that an AI assistant must use for all interactions with Conductor Tasks and the project environment within the Cline IDE. Direct file system operations or parsing CLI output are prohibited.

```Command Line
get-task
update-task
add-task-note
read_file
apply_diff
execute_command
search_files
ask_followup_question
```

--------------------------------

### Task Breakdown and Planning Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

Commands to expand complex tasks into manageable sub-tasks and to log initial plans or notes for refinement before the actual implementation phase begins.

```CLI
expand-task --id <task_id> --prompt "<optional_context>"
```

```CLI
add-task-note --id <current_task_id> --note "Initial Plan for <task_title/objective>: [Files to act on, proposed diffs/content, commands to run, reasoning...]"
```

--------------------------------

### AI Tool: List Files in Directory

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_ask.txt

Explore specific directories to find relevant information using `list_files`.

```APIDOC
list_files(directory_path: str) -> list[str]
  directory_path: The path to the directory to list files from.
  Returns: A list of file and directory names within the specified path.
Usage Example: list_files <suspected_directory>
```

--------------------------------

### AI Workflow: Task Breakdown and Refinement

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Describes how the AI can break down complex tasks into sub-tasks and refine them.

```APIDOC
expand-task --id <task_id> --prompt "<optional_context>": Creates sub-tasks for a complex task.
update-task: Used for refining sub-tasks.
add-task-note: Used for refining sub-tasks.
```

--------------------------------

### Review Existing Tasks and Avoid Duplication

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_ask.txt

Understand ongoing work, avoid duplicating efforts, and gain insight into the project's current state by reviewing `TASKS.md` or listing all existing tasks.

```APIDOC
read_file TASKS.md
```

```APIDOC
list-tasks
```

--------------------------------

### AI Tool: Search Files for Keyword Information

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_ask.txt

Find relevant information in code or documentation files by searching for keywords using `search_files`. Adjust file patterns as needed.

```APIDOC
search_files(path: str, regex: str, file_pattern: str) -> list[str]
  path: The directory path to start the search from (e.g., ".").
  regex: The regular expression keyword to search for.
  file_pattern: A comma-separated string of file patterns to include (e.g., "*.md,*.txt,*.java,*.js,*.py").
  Returns: A list of file paths containing the keyword.
Usage Example: search_files --path . --regex "keyword" --file_pattern "*.md,*.txt,*.java,*.js,*.py"
```

--------------------------------

### Information Gathering and Analysis Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

Commands for exploring the project environment, reading file contents, searching for patterns, and listing code definitions to gather necessary information and context for task execution.

```CLI
list_files <path>
```

```CLI
read_file <path> [start_line] [end_line]
```

```CLI
search_files --path <directory> --regex "pattern" --file_pattern "*.ext"
```

```CLI
list_code_definition_names <path_to_file_or_directory>
```

--------------------------------

### AI Workflow: Understanding Current Task State

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

Details how the AI should assess the current project and task status, including listing all tasks, identifying the next focus, and retrieving detailed task information.

```APIDOC
list-tasks: Provides a full overview of tasks, statuses, and IDs.
get-next-task: Identifies the immediate task focus.
get-task --id <task_id>: Retrieves all details for a specific task (description, status, dependencies, notes, subtasks).
read_file TASKS.md: Reads the TASKS.md file for broader project context.
```

--------------------------------

### Conductor Task Overview and Selection

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

Commands to gain situational awareness of project tasks, list all tasks with their statuses and IDs, identify the next immediate focus based on dependencies and priority, and retrieve full details for a specific task.

```Shell
list-tasks
get-next-task
get-task --id <task_id>
read_file TASKS.md
```

--------------------------------

### List Code Definition Names with Conductor `list_code_definition_names` Command

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_architect.txt

The `list_code_definition_names` command helps architects understand current component structures and their public APIs by listing definitions within high-level directories.

```CLI
list_code_definition_names
```

--------------------------------

### Conductor Tasks: Applying Incremental Changes and Verification

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

The AI assistant should prefer smaller, targeted changes using `apply_diff`. After changes, if applicable and relevant, tests or linters should be suggested or run using `execute_command`, and their output analyzed for verification.

```Shell
apply_diff <file_path> --diff "<SMALLER_TARGETED_DIFF_CONTENT>"
```

```Shell
execute_command "<COMMAND_TO_RUN_TESTS_OR_LINTERS>"
```

--------------------------------

### Conductor Tasks: Documenting Actions with Comprehensive Notes

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

It is critical to document every significant action, finding, decision, or assumption using `add-task-note`. This includes tools used, files affected, commands run, and the rationale behind the approach, ensuring clarity and traceability.

```Shell
add-task-note --id <task_id> --note "Tools used: get-task, read_file. Key parameters/outcomes: ...\nFiles affected: ...\nCommands run: ...\nRationale: ..."
```

--------------------------------

### Iterative Task Implementation Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

A comprehensive set of commands used throughout the iterative task implementation process, covering understanding requirements, exploring the codebase, logging plans and progress, executing actions, and verifying completion.

```Shell
get-task --id <current_task_id>
read_file
search_files
list_files
list_code_definition_names
add-task-note --id <current_task_id> --note "Initial Plan for <task_title/objective>: [Comprehensive details: files to read/modify/create, specific diffs, commands, reasoning, potential challenges...]"
update-task --id <current_task_id> --status "in progress"
apply_diff
write_to_file
execute_command
add-task-note --id <current_task_id> --note "Progress Update: [Action taken (e.g., applied diff to X.js), outcome, new findings, what worked/didn't, code snippets, decisions, deviations from plan...]"
update-task --id <current_task_id> --status "completed"
add-task-note --id <current_task_id> --note "Implementation complete and verified for <task_title/objective>. Summary: [Brief summary of solution and verification]."
```

--------------------------------

### Cline Task Implementation and Progress Tracking Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/cline.txt

Core commands for executing task actions, modifying files, running shell commands, and logging progress. This section covers the iterative process of implementing and documenting task completion.

```CLI
get-task --id <current_task_id>
```

```CLI
add-task-note --id <current_task_id> --note "Initial Plan for <task_title/objective>: [Files to act on, proposed diffs/content, commands to run, reasoning...]"
```

```CLI
update-task --id <current_task_id> --status "in progress"
```

```CLI
read_file
```

```CLI
apply_diff <path>
```

```CLI
write_to_file <path>
```

```CLI
execute_command "shell_command"
```

```CLI
add-task-note --id <current_task_id> --note "Progress Update: [Action (e.g., 'Executed: pytest -k test_feature'), Outcome (e.g., '2 tests passed, 1 failed: ...'), Analysis/Next Step...]"
```

```CLI
update-task --id <current_task_id> --status "completed"
```

```CLI
add-task-note --id <current_task_id> --note "Implementation complete for <task_title/objective>. Verified via [method, e.g., 'pytest all passing']. Summary: [Brief solution]."
```

--------------------------------

### MCP Task Data Structure Reference

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

This section details the expected data structure for tasks retrieved from MCP tools like `get-task`. It describes the various fields, their types, and their purpose, providing a reference for understanding task information.

```APIDOC
Task Structure:
  id: Unique identifier (string)
  title: Brief title (string)
  description: Task summary (string)
  status: Current state (string, e.g., "pending", "in progress", "completed")
  dependencies: Array of prerequisite task IDs (array of strings)
  priority: Importance level (string)
  details / notes: In-depth instructions, context, and logged notes (string)
  subtasks: Array of sub-task objects (array of objects)
```

--------------------------------

### List Directory Contents with Conductor `list_files` Command

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_architect.txt

The `list_files` command enables architects to explore the file system, identifying existing architectural documents, diagrams, or key modules within specified directories like `src/` or `docs/arch`.

```CLI
list_files src/
```

```CLI
list_files ./docs/arch
```

--------------------------------

### Updating Task Progress and Documenting Actions

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Explains the critical steps for keeping task statuses current using 'update-task' and meticulously documenting all actions, findings, assumptions, and problems encountered with 'add-task-note'.

```APIDOC
update-task --id <task_id> --status <new_status>
add-task-note --id <task_id> --note "Your detailed note here."
```

--------------------------------

### Documenting Actions with add-task-note

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/cline.txt

This command is critical for an AI assistant to document every significant action, finding, decision, or assumption. It serves as the primary communication channel for progress and context within the Cline IDE.

```Command Line
add-task-note --id <task_id> --note "..."
```

--------------------------------

### Cline Information Gathering and Analysis Commands

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/cline.txt

Commands for exploring the project codebase and files, reading content, searching for patterns, and understanding code structure. These are essential for iterative information gathering during task implementation.

```CLI
list_files <path>
```

```CLI
read_file <path> [start_line] [end_line]
```

```CLI
search_files --path <directory> --regex "pattern" --file_pattern "*.ext"
```

```CLI
list_code_definition_names <path_to_file_or_directory>
```

--------------------------------

### Documenting Actions with add-task-note Command

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/cline.txt

The `add-task-note` command is critical for the AI assistant to document every significant action, finding, decision, or assumption. It serves as the primary communication channel for progress and context, ensuring transparency and traceability within the Conductor Tasks system.

```Shell
add-task-note --id <task_id> --note "..."
```

--------------------------------

### Log Plan and Execute Conductor Task Actions

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_general.txt

Commands to log initial plans for a task, set its status to 'in progress', and perform core implementation actions such as applying diffs, writing to files, or executing shell commands.

```CLI
add-task-note --id <current_task_id> --note "Initial Plan for <task_title/objective>: [Comprehensive details: files to read/modify/create, specific diffs, commands, reasoning, potential challenges...]"
```

```CLI
update-task --id <current_task_id> --status "in progress"
```

```CLI
apply_diff
```

```CLI
write_to_file
```

```CLI
execute_command
```

--------------------------------

### Breaking Down Complex Conductor Tasks

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/windsurf.txt

Describes the process of breaking down large tasks into smaller sub-tasks using 'expand-task' and refining them with 'update-task' or 'add-task-note' for clarity and accuracy.

```APIDOC
expand-task --id <task_id> --prompt "<optional_context>"
update-task
add-task-note
```

--------------------------------

### Conductor Tasks: Contextual Understanding for Code Modification

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

Before any code modification, the AI assistant must thoroughly understand the existing code and context. This involves using tools like `read_file` and `search_files` to gather information. For `apply_diff`, the `SEARCH` block must be an exact match of the current file content, verified immediately before diff construction.

```Shell
read_file <file_path>
```

```Shell
search_files <pattern>
```

```Shell
list_code_definition_names <file_path>
```

```Shell
apply_diff <file_path> --diff "<DIFF_CONTENT_WITH_EXACT_SEARCH_BLOCK>"
```

--------------------------------

### Ask Follow-up Question for Task Clarification

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_ask.txt

Utilize `ask_followup_question` to elicit deep requirements for unclear or ambiguous tasks, or to clarify technical jargon. Formulate specific, targeted questions to gather necessary details from the user.

```APIDOC
ask_followup_question
```

--------------------------------

### Search File Content with Conductor `search_files` Command

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_architect.txt

The `search_files` command is used to find discussions of architectural patterns, ADRs, or specific technologies within the codebase or documentation, crucial for system understanding and impact analysis.

```CLI
search_files
```

--------------------------------

### Expand and Refine Conductor Tasks

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_general.txt

Commands for breaking down complex tasks into sub-tasks using an optional prompt for context, and for refining task details or adding notes to existing tasks.

```Shell
expand-task --id <task_id> --prompt "<optional_context>"
update-task
add-task-note
```

--------------------------------

### List Files in Suspected Directory

Source: https://github.com/hridaya423/conductor-tasks/blob/main/build/ide/rule_templates/roo_ask.txt

Explore the contents of a specific directory using `list_files` to locate potentially relevant information or to understand the directory's structure and files.

```APIDOC
list_files <suspected_directory>
```

--------------------------------

### AI Tool: List Existing Tasks

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/roo_ask.txt

Review ongoing work and avoid duplication by listing existing tasks using `list-tasks`.

```APIDOC
list-tasks() -> list[dict]
  Returns: A list of dictionaries, each representing an existing task.
Usage Example: list-tasks
```

--------------------------------

### APIDOC: MCP Task Data Structure

Source: https://github.com/hridaya423/conductor-tasks/blob/main/src/ide/rule_templates/windsurf.txt

This section details the expected data structure for tasks retrieved from MCP tools like `get-task`. It defines key properties such as unique identifiers, titles, descriptions, status, dependencies, priority, and nested details or subtasks, providing a comprehensive overview of task object attributes.

```APIDOC
Task Data Structure:
  id: Unique identifier (string)
  title: Brief title (string)
  description: Task summary (string)
  status: Current state (e.g., "pending", "in progress", "completed") (string)
  dependencies: Array of prerequisite task IDs (array of strings)
  priority: Importance level (string)
  details / notes: In-depth instructions, context, and logged notes (string/array)
  subtasks: Array of sub-task objects (array of objects)
```