/pipeline

description: "Run multi-command design pipelines. Subcommands: run <name> [input], list, show <name>, new."
argument-hint: "run <pipeline-name> [brief] | list | show <name> | new"
allowed-tools: ["Read", "Write", "Bash", "Glob", "mcp__plugin_playwright_playwright__browser_navigate", "mcp__plugin_playwright_playwright__browser_take_screenshot", "mcp__plugin_playwright_playwright__browser_snapshot"]

/pipeline

You are the Pipeline Orchestrator for naksha-studio. Parse `$ARGUMENTS` to determine the subcommand and act accordingly.

Argument Parsing

Split `$ARGUMENTS` on whitespace:

• First word → **subcommand** (`run`, `list`, `show`, or `new`)
• Second word → **pipeline name** (for `run` and `show`)
• Remaining words → **user input / brief** (for `run`)

If no subcommand is given, display the usage block below and stop:

Usage:
  /pipeline run <name> [brief]   — Execute a named pipeline
  /pipeline list                 — List all available pipelines
  /pipeline show <name>          — Show pipeline definition and steps
  /pipeline new                  — Interactively create a new pipeline

Examples:
  /pipeline run launch-prep "redesign the checkout page"
  /pipeline run research-and-design "https://stripe.com build checkout"
  /pipeline list
  /pipeline show research-and-design
  /pipeline new

v5 Pipeline YAML Schema

Pipelines are YAML files. v5 extends the v4 schema with new step types and memory fields — all additions are backward-compatible.

name: my-pipeline
description: What this pipeline does
version: "2"        # optional: marks v5.2 schema. Absent = v4 (still valid)
on-error: stop      # stop | continue

steps:
  # v4 command step (unchanged):
  - command: design
    args: "$INPUT"
    description: "Design the component"
    pass-output-as: context    # pass this step's output to the next step

  # v5 command step (adds memory_read and memory_write):
  - command: design-review
    pass-output-as: context
    description: "Review with full project constraints"
    memory_read: ["constraints", "component_patterns"]  # prepend these fields as context
    memory_write: component_patterns                    # write step output to this path

  # v5 browser step (NEW — requires Playwright MCP):
  - type: browser
    mode: research             # research | inspect
    url: https://stripe.com
    name: "Capture Stripe patterns"
    memory_write: browser_findings   # always writes to browser_findings

**`memory_read:`** — list of `project.json` fields to explicitly inject as context before this step runs. Useful for documenting intent and ensuring specific fields are available even in steps that don't read context by default.

**`memory_write:`** — for `browser:` steps: always `browser_findings`. For `command:` steps: a dot-notation path in `project.json` to record this step's output summary. The orchestrator emits a `project_json_patch` block after the step.

**`type: browser` step** — navigates a URL with Playwright, extracts design patterns, and writes findings to `browser_findings`. Skips gracefully when Playwright is unavailable (step is marked SKIPPED in summary). The captured patterns flow as context to the *following* command step (like `pass-output-as: context` for browser steps).

---

Subcommand: `list`

1. Use Glob to find built-in pipelines: `${CLAUDE_PLUGIN_ROOT}/skills/design/pipelines/*.yaml` 2. Use Glob to find user-defined pipelines: `.naksha/pipelines/*.yaml` (skip silently if the directory does not exist) 3. Read each YAML file and extract: `name`, `description`, `version` (if present), and the `steps` array length. 4. For step count: include all step types (command + browser). Annotate v5 pipelines with `[v5]`. 5. Display a formatted table:

Available Pipelines
───────────────────────────────────────────────────────────────────────
 Name                    Steps  Tag           Description
───────────────────────────────────────────────────────────────────────
 launch-prep               4    (built-in)    Full pre-launch design pass
 brand-audit               3    (built-in)    Complete brand health check
 component-build           3    (built-in)    Build a component end-to-end
 social-launch             3    (built-in)    Full social media launch
 research-and-design       3    (built-in) [v5]  Browser research → design → review
 design-score-track        3    (built-in) [v5]  Score → remember improvements
 <user-name>               N    (project)     <description>
───────────────────────────────────────────────────────────────────────

6. End with:

> Create your own: `/pipeline new` · Inspect any: `/pipeline show <name>` > User pipelines live in `.naksha/pipelines/` — same YAML format, project-local.

---

Subcommand: `show <name>`

1. Resolve the pipeline file using this search order:

• `.naksha/pipelines/<name>.yaml` (user-defined, project-local)
• `${CLAUDE_PLUGIN_ROOT}/skills/design/pipelines/<name>.yaml` (built-in)

2. If not found, output: > Pipeline '<name>' not found. Run `/pipeline list` to see available pipelines. Then stop. 3. Read the YAML and display a structured view:

Pipeline: <name>  [built-in | project]  {[v5] if version: "2"}
Description: <description>
Error handling: <on-error value>

Steps:
┌───────┬──────────────────────┬──────────────────┬──────────┬─────────────────────────────────────────┐
│ Step  │ Command / Type       │ Input            │ Memory   │ Description                             │
├───────┼──────────────────────┼──────────────────┼──────────┼─────────────────────────────────────────┤
│  1    │ /design              │ $INPUT (brief)   │          │ Create comprehensive design             │
│  2    │ 🌐 browser:research  │ captures url     │ →findings│ Capture competitor patterns             │
│  3    │ /design-review       │ prev step output │ ←constr. │ Review against project constraints      │
│  4    │ /design-handoff      │ prev step output │          │ Prepare