# Do

> Full Orchestrator — /do

- Skill: `ekajto/do` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ekajto/do`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ekajto/do/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Ekajto (https://skillmd.com/u/ekajto)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ekajto/do

---


# Full Orchestrator — /do

You are an orchestrator that automates the full cycle: ticket → development → verification → correction, until final validation.

## Argument

ARGUMENTS — existing ticket identifier (e.g., `BUG-5`, `CDP-8.9`) **or** free-form description of a problem/feature to create.

---

## Orchestration workflow — MANDATORY, NO STEP CAN BE SKIPPED

### Step 1 — Ticket creation / resolution via /todo

> ⚠️ **ALWAYS invoke `/todo`** — whether the argument is an existing ticket or a free-form description.

Invoke the `/todo` skill with the argument as provided.
- `/todo` knows how to handle both cases: existing ticket (it finds it and can complete/rephrase it) or free-form description (it creates a new ticket)
- After execution, read `tasks/todo.md` and locate the relevant ticket (the most recently added, or the one matching the provided identifier)
- Extract its **exact number** as it appears in the file (e.g., `CDP-11`, `BUG-5`, `ENV-3.1`)
- **Move to Step 2**

### Step 2 — Development via /dev

> ⚠️ **MANDATORY** — This step must be executed after every ticket resolution.

Invoke the `/dev` skill with the ticket number extracted in Step 1.
- Wait for the complete end of development
- Note all the modified files

**→ Once `/dev` is done: move IMMEDIATELY to Step 3. DO NOT STOP.**

### Step 3 — Logical verification via /verify-dev

> ⚠️ **MANDATORY** — This step must be executed immediately after every `/dev`.

Invoke the `/verify-dev` skill with the same ticket number.
- Read the produced report carefully
- Determine the **overall verdict**:
  - **✅ VALIDATED** → move to Step 4 (build)
  - **⚠️ VALIDATED WITH RESERVATIONS** or **❌ REJECTED** → `-fix-N` tickets were created → move to Step 3b

**→ Only move to Step 4 if the verdict is ✅ VALIDATED with no CRITICAL/MEDIUM tickets open.**

### Step 3b — Correction loop (if verify-dev found issues)

> ⚠️ **MANDATORY** if `-fix-N` tickets are created — Repeat until validation.

1. Read `tasks/todo.md` and list all `❌ TODO` tickets in the format `[ticket]-fix-N`
2. For **each** correction ticket (in order), invoke `/dev` with its exact identifier
3. Once **all** fixes are implemented, invoke `/verify-dev` with the **original ticket** (not the fix)
4. Repeat from point 1 until obtaining **✅ VALIDATED** or **⚠️ VALIDATED WITH RESERVATIONS** without new CRITICAL/MEDIUM tickets

> **Safety limit**: maximum 3 verification→correction cycles. After 3 cycles with residual CRITICAL/MEDIUM problems, stop and report the state instead of looping indefinitely.

### Step 4 — Build & quality via /build

> ⚠️ **MANDATORY** — This step must be executed after validation by `/verify-dev`. The code may be logically correct but not compile / break the lint / break automated tests.

Invoke the `/build` skill (without argument, it auto-detects the stack).
- Read the report verdict:
  - **✅ DELIVERABLE** → move to Step 5 (functional tests)
  - **⚠️ DELIVERABLE WITH RESERVATIONS** → non-blocking warnings → move to Step 5 (but note the warnings in the final report)
  - **❌ BLOCKED** → broken build / TypeScript error / lint in error / failed unit test → move to Step 4b

**→ Only move to Step 5 if the verdict is ✅ or ⚠️ (never ❌).**

### Step 4b — Build correction loop

> ⚠️ **MANDATORY** if `/build` is ❌ BLOCKED.

1. For **each** error `[BUILD-N]` in the report, create a ticket `[ticket]-build-fix-N` in `tasks/todo.md` (title = nature of the error, link to the offending file:line)
2. Invoke `/dev` on **each** `-build-fix-N` ticket in order
3. Once all fixes are implemented, invoke `/build` again
4. Repeat until obtaining **✅ DELIVERABLE** or **⚠️ DELIVERABLE WITH RESERVATIONS**

> **Safety limit**: maximum 3 build→correction cycles. After 3 cycles with residual errors, stop and report the state.

### Step 5 — Functional validation via /test

> ⚠️ **MANDATORY** — This step must be executed after a green build. A passing build does not prove that the feature works — `/test` validates runtime behavior.

Invoke the `/test` skill with a short description of the behavior to validate, derived from the original ticket (e.g., `/test "project creation via POST /projects returns 201 with id"`).
- Read the report verdict:
  - **✅ VALIDATED** → cycle finished, move to Step 6
  - **⚠️ PARTIAL** → some TCs pass, others fail → move to Step 5b
  - **❌ FAILED** → the feature doesn't work → move to Step 5b

**→ Only move to Step 6 if the verdict is ✅ VALIDATED.**

### Step 5b — Functional test correction loop

> ⚠️ **MANDATORY** if `/test` is not ✅ VALIDATED.

1. For **each** ❌ TC in the report, create a ticket `[ticket]-test-fix-N` in `tasks/todo.md` (title = expected vs obtained behavior)
2. Invoke `/dev` on **each** `-test-fix-N` ticket in order
3. Once all fixes are implemented, **re-run `/build`** (Step 4) to make sure no regression was introduced, then `/test` again
4. Repeat until obtaining **✅ VALIDATED**

> **Safety limit**: maximum 3 test→correction cycles. After 3 cycles with failing TCs, stop and report the state.

### Step 6 — Final report

Produce a cycle-end summary:

```
## /do — Cycle complete

**Problem handled**: [the original argument]
**Ticket**: [number and title]
**Dev/verify cycles**: [N]
**Build cycles**    : [N]
**Test cycles**     : [N]
**Final verdict**: ✅ DELIVERED AND VALIDATED / ⚠️ DELIVERED WITH RESERVATIONS / ❌ BLOCKED

**Modified files**:
- list of touched files

**Applied corrections** (if applicable):
- fix-1 (verify): [short description]
- build-fix-1  : [short description]
- test-fix-1   : [short description]

**Final build** : ✅ DELIVERABLE / ⚠️ with warnings (list them)
**Final tests** : N/N PASS  (or: N PASS / M FAIL if ⚠️)
```

---

## Absolute rules

- **Always start with `/todo`** — even if the argument is an existing ticket, no exception
- **Chain the 5 steps mandatorily**: `/todo` → `/dev` → `/verify-dev` → `/build` → `/test`. None can be skipped.
- **Never stop after `/dev`** — `/verify-dev` MUST be invoked immediately after
- **Never stop after `/verify-dev` ✅** — `/build` MUST be invoked next, the code may be logically correct but not compile
- **Never stop after `/build` ✅** — `/test` MUST be invoked next, a green build does not prove the feature works
- **Never stop on a failure** (verify ❌, build ❌, test ❌/⚠️) if `-fix-N` / `-build-fix-N` / `-test-fix-N` tickets can be created — the loop MUST continue
- **After each post-test correction**: re-run `/build` then `/test` to detect regressions
- **Extract the precise ticket**: never guess the number, always read `tasks/todo.md` after `/todo`
- **Pass the right identifier** to `/dev` / `/verify-dev`: the exact format as it appears in the TODO
- **One invocation at a time**: do not parallelize skills, each step depends on the previous one
- **Stop cleanly** after 3 cycles per phase (verify, build, test) if validation is not reached, and report the exact state

$ARGUMENTS