setup

---
name: setup-842bce1fac12
description: Setup routing and environment configuration. Use for "setup", "configure", and "get started".
trigger: /oma:setup
---

## Skill: setup

Set up development environments and configurations.

## When to Use

- New project initialization
- Environment configuration
- First-time setup
- Onboarding to a project

## Setup Modes

### `/oma:setup new`
Create a new project structure.
- Initialize files
- Configure tools
- Set up dependencies

### `/oma:setup existing`
Configure for existing project.
- Detect project type
- Configure tools
- Verify setup

### `/oma:setup doctor`
Diagnose setup issues.
- Check dependencies
- Verify configurations
- Report status

### `/oma:setup mcp`
Configure MCP servers.
- List available servers
- Configure connections
- Test integrations

## Setup Steps

### 1. Detect Environment
- Project type
- Language/framework
- Existing configs

### 2. Check Prerequisites
- Required tools installed
- Permissions correct
- Network access

### 3. Configure
- Create config files
- Set up dependencies
- Configure tools

### 4. Verify
- Run basic checks
- Test configuration
- Confirm working

## Project Types

### JavaScript/TypeScript
- package.json
- tsconfig.json
- eslint/prettier
- Jest/Vitest

### Python
- requirements.txt
- pyproject.toml
- pytest
- virtual env

### Rust
- Cargo.toml
- rustfmt.toml
- clippy

### Multi-language
- Nx monorepo
- Turborepo
- Lerna

## Output Format

```
## Setup: {project}

### Environment
- **Type:** {project type}
- **Location:** {path}
- **Existing config:** {yes/no}

### Prerequisites
| Check | Status |
|-------|--------|
| {check} | ✅/❌ |

### Configuration
| Item | Status | Notes |
|------|--------|-------|
| {config} | ✅ | {notes} |

### Files Created
- {file 1}
- {file 2}

### Verification
```bash
{verify command}
```

### Next Steps
1. {step 1}
2. {step 2}
```

## Constraints

- Don't overwrite without backup
- Preserve existing config
- Verify after each step
- Document what was done
- Make setup repeatable

<Tool_Usage>
- **executor**: Primary agent for running the actual setup steps — executor creates files, installs dependencies, runs commands
- **analyst**: Use when the project type cannot be auto-detected — analyst determines what kind of project this is and what it needs
- **architect**: Consult when setup involves architectural decisions (e.g., choosing between monorepo vs. polyrepo, choosing a framework)
- **verifier**: After setup completes, use verifier to confirm the environment is healthy and ready for development
- **Direct Bash tools**: For reading existing config files, running diagnostics, and executing setup commands directly (not for spawning agents)
</Tool_Usage>

<Why_This_Exists>
OMA operates inside Auggie's CLI and needs a reliable way to initialize new projects or configure existing ones for use with OMA's orchestration tools. Setting up `.oma/`, `plugins/oma/`, MCP configurations, and skill directories is a prerequisite for most orchestration modes. Rather than scattering setup logic across agents, setup provides a dedicated entry point so the environment is correctly initialized before ralph, ultraqa, or team modes run — preventing failures from missing state directories or unconfigured MCP servers.
</Why_This_Exists>

<Examples>

### Good Usage

**First-time OMA setup on a new Auggie project:**
```
User: "/oma:setup"
OMA: [Detects: new project, no .oma directory]
OMA: [Creates .oma/state.json, .oma/notepad.json, .oma/plans/]
OMA: [Configures plugins/oma/ if not present]
OMA: [Runs setup doctor: MCP server reachable, Auggie CLI version check]
OMA: [Result: environment ready for /oma:ralph, /oma:team, etc.]
```

**Configure OMA on an existing project:**
```
User: "/oma:setup existing"
OMA: [Detects: existing TypeScript project with tsconfig.json]
OMA: [Checks for .oma/ — not found]
OMA: [Creates .oma/ directory structure]
OMA: [Writes initial .oma/state.json with project type]
OMA: [Result: OMA now aware of the project]
```

### Bad Usage

**Re-running setup on an already-configured environment:**
```
User: "/oma:setup"
OMA: [Detects: .oma/ already exists, .oma/state.json valid]
OMA: [Overwrites existing state, destroying in-progress mode state]
```
→ Use `/oma:setup doctor` instead to verify without re-initializing.

**Setup as a substitute for manual environment understanding:**
```
User: "/oma:setup" on a highly custom monorepo with non-standard tooling
OMA: [Auto-detects wrong project type due to non-standard structure]
OMA: [Misconfigures plugins/oma/ paths]
OMA: [Modes fail with confusing errors]
```
→ Use `/oma:setup doctor` first to see what was detected, then manually configure if needed.
</Examples>