How do I install the Pipeline Task Executor Protocol skill?

Run npx skillmds@latest add gustavo-meilus/pipeline-task-executor-protocol in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pipeline Task Executor Protocol safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pipeline Task Executor Protocol?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pipeline Task Executor Protocol free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pipeline Task Executor Protocol?

gustavo-meilus (@gustavo-meilus) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pipeline Task Executor Protocol by gustavo-meilus

Name: Pipeline Task Executor Protocol
Author: gustavo-meilus

File contents

Pipeline Task Executor — Operational Protocol

Protocol

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.

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.

---name: pipeline-task-executor-protocoldescription: Loaded by the pipeline-task-executor agent to execute one assigned implementation task under the pipeline contract.---# 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 StatusEvery 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.

Frequently asked questions

Pipeline Task Executor Protocol