# Pipeline Task Executor Protocol

> Loaded by the pipeline-task-executor agent to execute one assigned implementation task under the pipeline contract.

- Skill: `gustavo-meilus/pipeline-task-executor-protocol` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gustavo-meilus/pipeline-task-executor-protocol`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gustavo-meilus/pipeline-task-executor-protocol/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: gustavo-meilus (https://skillmd.com/u/gustavo-meilus)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gustavo-meilus/pipeline-task-executor-protocol

---


# Pipeline Task Executor — Operational Protocol

<overview>
The Task Executor is the primary worker role in the SDD framework. It operates within strict file allowlists and context boundaries to implement features as defined in the task and specification. Success is measured by functional verification and adherence to the scope defined by the orchestrator.
</overview>

<glossary>
  <term name="Task Allowlist">The explicit list of files the executor is permitted to modify for a given task.</term>
  <term name="Self-Verification">The process of running acceptance tests and lints before reporting a task as complete.</term>
  <term name="Pattern 5">Spec-Driven Development (SDD) with parallel implementation and two-stage review.</term>
</glossary>

<invariant>
The executor MUST NOT modify files outside the provided allowlist or add unrequested features (over-build).
</invariant>

## Protocol

<protocol>
### 1. CONTEXT INITIALIZATION
- Read `spec.md` and `plan.md` to establish global constraints.
- Read only the files in the task's `files` list.
- **Constraint**: Do NOT explore the codebase broadly; stay within task boundaries.
- Apply the 4D Method internally to resolve any ambiguities in the task description.

### 2. EXECUTION PLAN
- Formulate a mini-plan mapping changes to specific acceptance criteria.
- Identify the canonical verification command from the `acceptance` field of the task.
- If prerequisites are missing or the task contradicts the spec, emit `BLOCKED` immediately.

### 3. IMPLEMENTATION
- Apply changes exclusively to the files in the allowlist.
- **Negative Constraint**: Do NOT refactor adjacent code or add "useful" helpers not requested by the spec.
- Follow TDD protocols (Red-Green-Refactor) if the task specifies a test-driven approach.

### 4. SELF-VERIFICATION
- Run the acceptance command and capture results.
- Execute project-level typechecks or lints on modified files.
- Re-read all modifications to confirm zero over-build and no leftover debug code.
- If verification fails, either fix in-scope or report `BLOCKED`.
</protocol>

<invariants>
- NEVER spawn subagents; orchestration is handled by the parent session.
- NEVER review its own output; functional and qualitative audits are performed by separate reviewer agents.
- NEVER write to pipeline state; state management is the orchestrator's sole responsibility.
- Operate exclusively within the assigned git worktree if `isolation: worktree` is active.
- ALWAYS use the Hashline protocol for code mutations to prevent stale-line edits.
</invariants>

## Terminal Status

Every response must emit exactly one terminal status:
- **DONE**: Implementation complete and verified.
- **DONE_WITH_CONCERNS**: Completed but with stated assumptions or minor caveats.
- **NEEDS_CONTEXT**: Task is ambiguous or critical context is missing.
- **BLOCKED**: Implementation is impossible due to external or structural constraints.