---
name: splitty
description: >-
  Run a chunk-level pipes-and-filters analysis end-to-end. Use when the user
  says "splitty <do something>", "split this corpus", "map-reduce this",
  "fan out X across Y", "run a pipeline over <files>", or describes a goal that
  requires processing many chunks of text in parallel and unioning the results.
  This skill designs a pipeline (if none is given), then drives it to completion
  by spawning sub-agents one step at a time.
---

# splitty (full lifecycle)

The user has given you a goal in natural language. You will:

1. **Decide whether to design a new pipeline or reuse an existing one.**
2. **Run it to completion**, dispatching sub-agents step by step.

This skill composes `splitty-design` (pipeline authoring) and `splitty-run`
(orchestration). If the user supplied a `.yaml` pipeline path or asked you
to use one of the examples in `pipelines/examples/`, skip design and go
straight to run.

## Step 1 — locate or design the pipeline

Decision tree:

- If the user named a YAML file (or `pipelines/examples/<name>.yaml`):
  use it as-is. Validate first with:
  ```
  python3 ${CLAUDE_PLUGIN_ROOT}/scripts/splitty.py validate <path>
  ```
- Otherwise: invoke the **splitty-design** skill body (read its SKILL.md and
  follow the procedure) to author a new pipeline file from the user's request.
  Save it under `.splitty/pipelines/<name>.yaml` in the workspace.

State your intent in one sentence before proceeding (e.g., "Designing a
classify-then-extract pipeline for your notes/ folder.").

## Step 2 — run the pipeline

Invoke the **splitty-run** skill body (read its SKILL.md and follow the
procedure exactly). Do not improvise the orchestration loop — it is
deterministic by design.

## Step 3 — show the result

After `splitty finalize`, read the result file from the path it printed and
present a brief summary to the user (1-3 sentences) plus the path. Do not
re-summarize the entire result; the user can read it.

## Notes on scope

- This skill orchestrates **one** pipeline run per invocation. If the user
  wants multiple unrelated runs, run them serially or ask which to start.
- The orchestrator is *Claude itself in the main loop*. There is no daemon,
  no MCP server, no background process. Each `Task()` call you make spawns
  one filter sub-agent for one step.
- Sub-agents **never** call `Task` themselves. Fan-out is your job.