# Executor
`valdr-executor` is the capability-first wrapper for task execution. It does not begin by asking the user to choose an executor agent. Instead, it loads the executor capabilities, resolves the assignee instructions for the task key, and requires the active agent to adopt that returned task prompt before continuing.

> [!IMPORTANT]
> The executor wrapper must run the persona gate and adopt the returned `assigneeHandle` before any task mutation or code work starts.

Executor is available on **Vanguard** and **Sovereign** plans with MCP access.

## Use Executor When You Have

- A concrete task key to execute
- Assigned work that should start moving through the task lifecycle
- A need to enforce the assignee's current instructions before touching code or task state

## How To Use It

Start with:

```text
/valdr-executor
```

Then give it a task key and the boundary you want it to respect:

- Basic execution prompt:

```text
Execute task WEB-142.
```

- Execution with an explicit stopping point:

```text
Execute task WEB-142 and stop at the review gate when the work is ready.
```

- Execution with extra task context:

```text
Pick up task OPS-31, follow the assignee instructions exactly, and call out any missing acceptance criteria before you mutate the task.
```

Executor is task-key driven. If you cannot name the task yet, start with [Orchestrator](../valdr-orchestrator/) to discover the right work item first.

## Wrapper Contract

The current wrapper always performs the same load sequence:

1. Load the executor system capability:

```json
mcp__valdr__pm_capability → { "action": "prompt", "key": "valdr.executor.task.system" }
```

2. Load the workflow wrapper:

```json
mcp__valdr__pm_capability → { "action": "prompt", "key": "valdr.executor.workflow" }
```

3. Run handle resolution before any mutation:

```json
mcp__valdr__pm_capability → { "action": "prompt", "key": "valdr.executor.workflow.handle-resolution" }
```

4. Fetch the task prompt and adopt the assignee instructions:

```json
mcp__valdr__pm_task → { "action": "get_prompt", "taskKey": "<task-key>" }
```

The returned assignee instructions and `assigneeHandle` are mandatory. The wrapper cannot continue if they are missing or unusable.

## What the Wrapper Owns

The wrapper is responsible for:

- Loading the executor system prompt
- Loading the workflow wrapper
- Running handle resolution
- Fetching the task-specific prompt
- Stopping if any required capability or task prompt fails to load

The wrapper is **not** where execution policy should live long-term. Checklist discipline, review handoff, verification rules, and task-lifecycle details belong in the loaded executor capabilities.

## Why This Design Holds Up

It keeps execution behavior consistent without locking workflow details inside a static markdown wrapper:

- The executor capability can change without republishing the wrapper.
- The assignee instructions stay task-specific.
- The active agent is forced to adopt the right persona before work starts.

## Related Skills

- **[Orchestrator](../valdr-orchestrator/)** — Find the task, assignee, or broader project context first
- **[Planner](../valdr-planner/)** — Create the work that Executor eventually runs
- **[Reviewer](../valdr-reviewer/)** — Own the review flow after execution reaches the gate