> For the complete documentation index, see [llms.txt](https://docs.rumi.systems/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rumi.systems/rumi-cli/commands/dev.md).

# dev

> **⚠️ In Development**: The `rumi dev` command is currently in development. The content in this section is subject to change.

The `rumi dev` commands help you perform development activities on your Rumi applications, allowing you to incrementally evolve your applications by adding, removing, and modifying components.

## Overview

The `rumi dev` commands provide a structured way to manage your application's components without manually editing configuration files or writing boilerplate code. These commands follow Rumi's best practices and conventions.

## Command Categories

The `rumi dev` commands are organized into the following categories:

### Service Management

Manage microservices in your application:

```bash
# Add a new service
rumi dev service add <service-name>

# Remove an existing service
rumi dev service remove <service-name>
```

### Message Management

Manage messages and message definitions:

```bash
# Add a new message
rumi dev message add <message-name>

# Remove an existing message
rumi dev message remove <message-name>
```

### Handler Management

Manage message handlers:

```bash
# Add a message handler
rumi dev handler add <handler-name>

# Remove a message handler
rumi dev handler remove <handler-name>
```

### State Management

Manage state entities:

```bash
# Add a state entity
rumi dev state add <state-name>

# Remove a state entity
rumi dev state remove <state-name>
```

### Configuration Management

Manage application configuration:

```bash
# Add configuration
rumi dev config add <config-name>

# Update configuration
rumi dev config update <config-name>

# Remove configuration
rumi dev config remove <config-name>
```

## Command Structure

All `rumi dev` commands follow the hierarchical structure:

```bash
rumi dev <category> <action> [options]
```

Where:

* `<category>` is a noun representing the component type (service, message, handler, state, config)
* `<action>` is the operation to perform (add, remove, update, etc.)
* `[options]` are command-specific options and arguments

## Best Practices

When using `rumi dev` commands:

1. **Start from the top down** - Add services first, then messages, then handlers
2. **Use descriptive names** - Follow naming conventions for your components
3. **Test incrementally** - Test each component addition before moving on
4. **Use version control** - Commit changes after each component addition

## Common Workflows

### Creating a New Microservice

```bash
# 1. Add the service
rumi dev service add OrderProcessor

# 2. Add messages
rumi dev message add CreateOrder
rumi dev message add OrderCreated

# 3. Add handlers
rumi dev handler add OnCreateOrder

# 4. Add state entities
rumi dev state add Order
```

### Adding Functionality to an Existing Service

```bash
# Add a new message and handler
rumi dev message add CancelOrder
rumi dev handler add OnCancelOrder
```

## Related Documentation

For more information about developing Rumi applications, see the [Core Documentation](/rumi-core/guides/developing-applications.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rumi.systems/rumi-cli/commands/dev.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.