Pipeline task executor protocol

Skill gustavo-meilus/superpipelines/skills/pipeline-task-executor-protocol

Loop Engineering for AI coding agents, with real review boundaries. Your AI reviewer cannot edit code. Structurally.

Install

npx -y skills add gustavo-meilus/superpipelines --skill pipeline-task-executor-protocol

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

3.1 KB, as published. Nobody here has run it

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.