pipeline-designer
Design and create structured output pipelines. Gathers requirements, designs step sequences with output schemas, generates valid YAML pipeline definitions, and validates them.
- License 许可
- Unlicense
- 最近更新
- 2026-11-12
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- pipeline-designer
- description
- Design and create structured output pipelines. Gathers requirements, designs step sequences with output schemas, generates valid YAML pipeline definitions, and validates them.
- allowed-tools
- shell_exec, file_write, file_read, ask_user_question, send_message
- argument-hint
- [ "description of what the pipeline should do" ]
03 SKILL.md 正文
/pipeline-designer — Structured Output Pipeline Designer
Design and create multi-step structured output pipelines for clawq. Each pipeline is a YAML file defining a sequence of LLM prompt steps with validated JSON Schema outputs. Steps can reference previous step outputs and compose other pipelines.
Note: This skill provides in-conversation pipeline authoring guided by the agent. For an interactive CLI setup wizard, use clawq pipeline wizard instead. Both approaches produce the same pipeline YAML files — use whichever fits your workflow.
Progress Reporting
At the start of each phase, call send_message to report progress:
- send_message(text="Pipeline Designer, step 1/5: Gathering requirements...")
- send_message(text="Pipeline Designer, step 2/5: Designing step sequence...")
- send_message(text="Pipeline Designer, step 3/5: Defining output schemas...")
- send_message(text="Pipeline Designer, step 4/5: Generating YAML definition...")
- send_message(text="Pipeline Designer, step 5/5: Validating pipeline...")
Always send the progress message before starting each phase.
Phase 1: Gather Requirements
First, call send_message(text="Pipeline Designer, step 1/5: Gathering requirements...").
If $ARGUMENTS provides a description, parse it for context and pre-fill answers. Confirm with the user.
Collect via ask_user_question (or conversationally if unavailable):
- Pipeline name (text) — short identifier using alphanumeric chars and hyphens (e.g. "research-report")
- Description (text) — what the pipeline should accomplish
- Inputs — what parameters the pipeline needs (name, type, description, required?, default value?)
- Desired outputs — what the final output should look like
- Number of steps (optional) — rough estimate of how many steps
Phase 2: Design Step Sequence
First, call send_message(text="Pipeline Designer, step 2/5: Designing step sequence...").
Based on requirements, design the step sequence:
- Identify logical stages (e.g. outline -> draft -> review)
- Determine data flow between steps (which step outputs feed into which step prompts)
- Decide if any steps should reference existing pipelines (composability)
- Choose appropriate models for each step if different from default (optional)
- Set retry counts for steps that may need multiple attempts (default: 2)
Present the proposed step sequence to the user for review before proceeding.
Phase 3: Define Output Schemas
First, call send_message(text="Pipeline Designer, step 3/5: Defining output schemas...").
For each prompt step, define a JSON Schema for the expected output. Follow these rules:
Supported JSON Schema Keywords
The pipeline validator supports this subset of JSON Schema:
Type keywords: type (one of: object, array, string, integer, number, boolean, null)
Object keywords:
properties— map of property name to sub-schemarequired— array of required property namesadditionalProperties— boolean (default true; set false to reject extra keys)
Array keywords:
items— schema for array elementsminItems,maxItems— integer bounds on array length
String keywords:
minLength,maxLength— integer bounds on string lengthenum— array of allowed values
Numeric keywords:
minimum,maximum— numeric bounds
Schema Design Guidelines
- Keep schemas focused — only require what subsequent steps actually need
- Use
requiredfor fields that downstream steps depend on - Prefer
stringfor free-text content,integerfor counts,arrayfor lists - Use
enumto constrain categorical values (e.g.["low", "medium", "high"]) - Nest objects for structured sub-components
- Set
additionalProperties: falseonly when strict shape control matters
Phase 4: Generate YAML Definition
First, call send_message(text="Pipeline Designer, step 4/5: Generating YAML definition...").
Generate the complete pipeline YAML file. Use file_write to save it to ~/.clawq/pipelines/<name>.yaml.
Pipeline YAML Format Reference
name: pipeline-name
version: "1.0"
description: What this pipeline does
inputs:
input_name:
type: string
description: What this input is for
required: true
default: optional-default-value
steps:
# Prompt step — calls an LLM and validates the output
- name: step-name
prompt: |
Your prompt text here.
Use {{input.input_name}} for input variables.
Use {{previous_step_name}} for full JSON output of a previous step.
Use {{previous_step_name.field}} for a specific field from a previous step.
system_prompt: Optional system prompt override
model: Optional model override (e.g. "openai:gpt-5.4")
output_schema:
type: object
properties:
field_name:
type: string
another_field:
type: integer
required: [field_name]
max_retries: 2
# Pipeline step — runs another pipeline as a sub-step
- name: sub-step-name
pipeline: other-pipeline-name
input_map:
other_input: "{{input.my_input}}"
derived_input: "{{previous_step_name.field}}"
Template Variable Syntax
{{input.X}}— replaced with the value of input parameterX{{step_name}}— replaced with the full JSON output of the named step{{step_name.field}}— replaced with a specific field extracted from a step's JSON output (top-level string/number fields only; objects/arrays use the full JSON representation)
Key Constraints
- Step names must be unique within a pipeline
- Step names must be valid identifiers (alphanumeric + hyphens)
- Pipeline steps can reference other pipelines by name (max nesting depth: 3)
max_retriesdefaults to 1 if omittedversionshould be a string (e.g. "1.0")
Phase 5: Validate Pipeline
First, call send_message(text="Pipeline Designer, step 5/5: Validating pipeline...").
After writing the YAML file, validate it:
shell_exec("clawq pipeline validate <name>")
If validation fails, fix the issues and re-validate. Common issues:
- Duplicate step names
- Invalid JSON Schema (unknown type, malformed properties)
- Missing required fields in pipeline definition
- YAML syntax errors
Optionally, show the user how to run the pipeline:
clawq pipeline run <name> --input key1=value1 --input key2=value2
Example Pipelines
Research Report Pipeline
A 3-step pipeline: outline the report structure, write the draft, then review it.
- Inputs:
topic(required),depth(default: "medium") - Steps: outline -> draft -> review
- Each step's schema validates the expected structure
Code Review Pipeline
A 2-step pipeline: analyze code, then generate review feedback.
- Inputs:
code(required),language(default: "ocaml") - Steps: analyze -> review
- Analysis step outputs: issues array, complexity score
- Review step outputs: summary, recommendations array, rating
Data Extraction Pipeline
A 2-step pipeline: extract entities, then classify them.
- Inputs:
text(required),categories(required) - Steps: extract -> classify
- Extract outputs array of entities with name and context
- Classify maps each entity to a category from the input list
04 同仓库更多 Skills
run-task
Runs a backlog item (bug, feature, task, epic, milestone, phase) end-to-end by gathering context, constructing a startup prompt, spawning a worktree-backed subagent, and managing the claim/done/review cycle. Use when the user wants to execute a backlog target like B123, F456, P2.M4.E3, etc.
idea
Log a planning idea to the backlog. Use when the user has a feature idea, enhancement suggestion, or brainstorm they want tracked.
feature
Automate the creation of a new feature for clawq. Gathers requirements, discovers existing capabilities, decomposes into implementation layers, gates risky work behind approval, and delegates implementation. Prefers skills/rigs/cron/templates over OCaml code changes.
telegram-formatting
Telegram HTML and MarkdownV2 formatting reference for clawq message code
pag-review-via-team
review work using teams + review-and-fix
clawq-version-bump
Bump clawq version, commit, tag, push, and create a GitHub release