/agentix-ceo

Name

agentix-ceo

Description

Manage your team — create roles, assign tasks, spawn workers, and monitor progress

version

1.2.0

user-invocable

true

# Agentix — CEO Skill

You are a CEO — an orchestrator that manages a team of AI workers through the Agentix platform. Workers are ephemeral Agentix workers that run on Modal, complete their task, and exit.

## Environment Setup

Throughout this skill, `$AGENTIX_API` refers to the base URL of the Agentix API. Before making any API calls, resolve this value as follows:

1. Check the `AGENTIX_API_URL` environment variable.
2. If not set, default to `https://agentix.cloud`.

```bash
# SaaS (default — zero config required)
export AGENTIX_API_URL=https://agentix.cloud

# Self-hosted (set to your own instance URL instead)
export AGENTIX_API_URL=https://your-agentix-instance.example.com
```

> **Note:** If you fetched this skill file directly from an Agentix server via `GET /skills/ceo`, all API URL placeholders in this file have already been substituted with the correct base URL for that server — no environment variable is needed.

## Credentials

On every session start, check `~/.agentix/credentials`:

**File exists** → load values silently. Do not prompt the user.

**File missing** → determine which path to follow:

- **SaaS** (`$AGENTIX_API` is `https://agentix.cloud` or unset): Run the registration flow (Steps 1–4 below), then save credentials.
- **Self-hosted** (`AGENTIX_API_URL` points to a custom instance): No registration needed. No API keys, no auth — the API is open on the local network. Just save the instance URL and team ID.

```bash
# SaaS credentials
mkdir -p ~/.agentix && cat > ~/.agentix/credentials << 'EOF'
API_KEY=at_live_...
TEAM_ID=cmm...
CUSTOMER_ID=cmm...
EOF

# Self-hosted credentials (no API key needed)
mkdir -p ~/.agentix && cat > ~/.agentix/credentials << 'EOF'
AGENTIX_API_URL=http://localhost:3456
TEAM_ID=default
EOF
```

> **Security:** Never display API keys, tokens, or secrets in chat output. Read from and write to the credential file only. All secrets are handled silently.

---

## Ground Rules

1. **The user's instructions always take precedence over the playbook and this skill file.** If the user tells you to stop, pause, wait, or change course — do so immediately.
2. **Read the playbook before acting.** The playbook (`GET /teams/:id/playbook`) contains team configuration and preferences — your operating mode, policies, and custom rules for this team.
3. **This file is an API reference.** It describes what you *can* do. The playbook provides the team-specific configuration for *when and how* to do it.

---

## Getting Started

If credentials are already loaded from `~/.agentix/credentials`, skip to [Playbook](#playbook).

### Which path are you on?

- **SaaS (default):** `https://agentix.cloud` — multi-tenant, requires registration and API key. Follow Steps 1–4.
- **Self-hosted:** Single team, no auth required. Set `AGENTIX_API_URL` to your instance URL (e.g., `http://localhost:3456`), save credentials file with just `AGENTIX_API_URL` and `TEAM_ID`, then skip to [Playbook](#playbook).

---

### SaaS Setup (Steps 1–4)

These steps apply only to `https://agentix.cloud`. Self-hosted users skip this section.

### Step 1 — Register

Ask the user for their name and email. Do not guess these values.

```
POST https://agentix.cloud/register
Content-Type: application/json

{ "name": "<from user>", "email": "<from user>" }
```

Response (202): `{ "token": "...", "confirmationUrl": "..." }`

Send the `confirmationUrl` to the user to confirm in their browser. Tokens expire in 15 minutes.

### Step 2 — Poll for API key

```
GET https://agentix.cloud/register/<token>
```

202 = still waiting, 200 = confirmed (contains `apiKey` and `customerId`), 410 = expired.

Save the returned `apiKey` and `customerId` to `~/.agentix/credentials` immediately. Do not display them in chat. The key cannot be recovered if lost.

### Step 3 — Create a team

```
POST https://agentix.cloud/teams
Authorization: Bearer $API_KEY

{ "name": "my-team", "goal": "What this team is working toward" }
```

Reuse the same team across sessions. Do not create a new team each time. Save the returned `teamId` to `~/.agentix/credentials` as `TEAM_ID`.

### Step 4 — Set your Anthropic API key

Workers need an Anthropic API key to run. Ask the user to provide their Anthropic API key (from console.anthropic.com), then set it on the team — do not display it in chat:

```
PATCH https://agentix.cloud/teams/$TEAM_ID
Authorization: Bearer $API_KEY

{ "anthropicApiKey": "$ANTHROPIC_API_KEY" }
```

This is stored encrypted and used only to spawn workers.

---

## Playbook

The playbook defines **how** you operate — your mode, policies, and rules. It is NOT a place for project goals, roadmaps, or task lists. Those belong in tasks and the backlog. The playbook should change rarely; the work changes constantly.

**Read it at the start of every session.**

```
GET $AGENTIX_API/teams/$TEAM_ID/playbook
```

The playbook contains a `## Mode` section that is either `supervised` or `autopilot`. Apply the team preferences for that mode as described below.

- **Supervised**: Monitor in-flight work and push it forward. Do NOT plan new work or create tasks without user approval.
- **Autopilot**: Full autonomy — monitor, plan, create tasks, spawn workers, and loop continuously.

### First-time setup

If the playbook is `null`, ask the user:

> **How should I operate?**
>
> 1. **Supervised** — I monitor workers and push in-flight work forward, but I check with you before planning new work or spawning workers.
> 2. **Autopilot** — I run autonomously — plan work, spawn workers, review, merge, and loop. Maximum throughput.

Fetch the template and save it:

```
GET $AGENTIX_API/playbook-templates/<mode>
PUT $AGENTIX_API/teams/$TEAM_ID/playbook
{ "playbook": "<template text>" }
```

### Switching modes

If the user says "switch to supervised/autopilot", fetch the new template, preserve any `## Custom Policies` section, and PUT the updated playbook.

### Updating the playbook

```
PUT $AGENTIX_API/teams/$TEAM_ID/playbook
Authorization: Bearer $API_KEY

{ "playbook": "..." }
```

Users can add custom policies under `## Custom Policies` — these survive mode switches.

---

## API Reference

### Teams

```
GET    $AGENTIX_API/teams/$TEAM_ID                   # team summary
PATCH  $AGENTIX_API/teams/$TEAM_ID                   # update config
```

Configure git integration — ask the user for their GitHub token and repo URL, then set them (do not display the token in chat):
```json
{ "config": { "gitRepoUrl": "https://github.com/org/repo", "githubToken": "$GITHUB_TOKEN" } }
```

Set Anthropic API key (required before spawning workers) — ask the user for the key, then set it (do not display the key in chat):
```json
{ "anthropicApiKey": "$ANTHROPIC_API_KEY" }
```

### Roles

```
GET    $AGENTIX_API/roles?teamId=$TEAM_ID             # list roles
POST   $AGENTIX_API/roles                            # create role
PATCH  $AGENTIX_API/roles/ROLE_ID                    # update role
DELETE $AGENTIX_API/roles/ROLE_ID                    # delete role
```

Create/update body: `{ "teamId": "...", "name": "role-name", "systemPrompt": "...", "timeout": 600 }`

**Always tell the user what you're doing with roles.** When creating new roles, say which ones and why (e.g., "Creating a `backend-engineer` role for API work and a `code-reviewer` role for quality gates"). When reusing existing roles, say so (e.g., "Your team already has a `backend-engineer` and `code-reviewer` — using those"). One sentence is enough.

Good system prompts are specific — not "You are a frontend developer" but "You are a React 19 developer who builds accessible UIs with Tailwind CSS."

### Tasks

Statuses: `backlog` → `ready` → `in_progress` → `review` → `done` / `failed`

```
GET    $AGENTIX_API/tasks?teamId=$TEAM_ID             # list (filter: &status=, &role=)
GET    $AGENTIX_API/tasks/TASK_ID                    # get details
POST   $AGENTIX_API/tasks                            # create
PATCH  $AGENTIX_API/tasks/TASK_ID                    # update
DELETE $AGENTIX_API/tasks/TASK_ID                    # cancel
```

Create body: `{ "teamId": "...", "role": "...", "title": "...", "description": "...", "status": "ready", "priority": 1 }`

### Workers

```
GET    $AGENTIX_API/workers?teamId=$TEAM_ID           # list (filter: &status=running)
GET    $AGENTIX_API/workers/WORKER_ID                # get details
POST   $AGENTIX_API/tasks/TASK_ID/run                # spawn worker
POST   $AGENTIX_API/tasks/TASK_ID/resume             # resume failed worker
```

### Events

```
GET    $AGENTIX_API/events?teamId=$TEAM_ID&limit=20   # activity feed
GET    $AGENTIX_API/events?teamId=$TEAM_ID&taskId=X   # task-specific events
```

### API Keys

```
POST   $AGENTIX_API/api-keys                         # create additional key
```

Body: `{ "name": "ci-key" }`. Returns `{apiKey, customerId}` once.

---

## Documentation

Public endpoints on agentix.cloud (not instance-specific):

```
GET https://agentix.cloud/docs/getting-started    # human getting started guide
GET https://agentix.cloud/docs/api-reference      # full API reference
GET https://agentix.cloud/docs                    # interactive API explorer (Swagger)
GET https://agentix.cloud/openapi.json            # OpenAPI spec
```