Generating with AI

Jimothy can use your own harnesses to write pipeline configuration for you, in two places:

• Build with AI in the New pipeline dialog designs a complete pipeline from a plain-language description.
• Generate with AI in the step editor writes or revises one step’s prompt, system prompt or shell command.

Both run on your machine through a harness you pick, and cost whatever that harness costs.

Build a pipeline with AI

1. Open Pipelines → New pipeline.
2. Under Describe it and let an agent build it, describe the pipeline. The placeholder shows the level of detail that works well: “Plan with Opus, build with Sonnet, run pytest and ruff in parallel, have Codex review and loop back on changes, then open a PR after I approve.”
3. Pick the harness that designs it. The list contains every enabled harness except the Simulator; CLI harnesses that weren’t detected are marked “(not detected)”. Claude Code is preselected when it’s installed. If the harness has models, a model picker appears (leave it on Default to use the harness default).
4. Click Build with AI (or ⌘↵). The status shows Designing… Ns. Cancel stops it.
5. When it’s done (“Pipeline drafted. Review it before running.”), the new pipeline opens in the editor. It’s already saved. Review every step, fill in the workspace (Local repository is usually empty), and adjust prompts before running.

If you started from a project (the Pipeline button on a project, or New pipeline in project settings), the generated pipeline is placed in that project.

What happens behind the scenes

• The harness runs with the pipeline-builder skill as its system prompt and a request containing your description plus a catalog of your harnesses: each enabled, non-Simulator harness’s id, name, kind (cli/api), whether it’s installed, its default model and its models. The skill tells the agent to use only those harness ids and to prefer installed ones.
• It runs in an empty temporary folder inside the data directory (removed afterwards), not in any repository, with a 10-minute timeout.
• Jimothy extracts the pipeline JSON from the reply: it tries each fenced code block starting from the last one, then the text between the first { and the last }, and uses the first candidate that parses as a JSON object.
• The draft is checked: name must be present, steps must be a non-empty array, every step type must be agent, shell or approval, agent steps must use an existing, enabled harness id, and the whole pipeline must pass validation. A missing or invalid repo.mode becomes Git worktree with an empty path; a missing branch template becomes jimothy/{{issue.key | slug}}.
• If the draft has problems, Jimothy sends one repair round: the previous answer and the list of problems, asking for corrected JSON. If that also fails, you get <Harness> did not produce a valid pipeline: followed by the problems.
• Only one pipeline generation runs at a time; starting another cancels the first.

Errors you may see:

Message	Cause
Describe the pipeline you want	Empty description
Choose an enabled harness	The selected harness is disabled or gone
The simulator cannot design pipelines. Choose a real harness.	The Simulator can’t design pipelines
The reply did not contain a pipeline JSON object	No parseable JSON in the reply (triggers the repair round)
Step "x": unknown harness "y"	The agent used a harness id you don’t have enabled

The pipeline-builder skill

The skill lives in the app repository at skills/pipeline-builder/SKILL.md. It’s what makes the generated pipelines follow Jimothy’s conventions. In summary, it instructs the agent to:

Output contract. Reply with exactly one fenced json block containing one pipeline object (with "jimothyPipeline": 1, name, description, icon from rocket/bug/sparkles/workflow, a hex color, repo, concurrency, variables, steps, optional subagents), and nothing after it. A one-paragraph rationale before it is allowed. No comments in the JSON.

Workspace. Use worktree for code work with localPath: "" unless you named a path; clone for a fresh clone; inplace only when asked; scratch for non-repository work (research, reports, triage, notifications).

Steps. Always set dependsOn explicitly ([] for first steps). Use suggested timeouts (coding agents 20–60 min, triage/small reviews 5–15, shell 5–20), retries: 1 on long coding steps, continueOnError for optional/advisory steps, pass patterns plus loopBackTo/maxLoops (2 is a good default) on reviewers and test steps, and runIf for conditional steps.

Harnesses. CLI harnesses are full coding agents (read, edit, run commands, commit); API harnesses are single-shot text calls with no file access, only for triage, summaries and classification. Use a strong model for planning and review and a faster one for mechanical work; put the reviewer on a different harness or model than the implementer. Default to claude-code (opus, sonnet, haiku) and anthropic-api if the catalog is empty.

Design. Keep it as small as the request allows (3–7 steps is typical) and don’t invent requirements. The usual flow is plan → implement → test (shell, loops back) → review (loops back) → optional approval → open PR. Run independent checks in parallel after implement and join them. Put an approval step before anything irreversible or outward-facing (pushing, PRs, deploys, posting comments) unless full automation was requested. No dependency cycles; loops only via loopBackTo.

Subagents. Add them only when a step clearly benefits, attached to claude-code steps.

Because it’s a regular agent skill file with front matter, you can also use it outside Jimothy (for example install it as a skill in Claude Code), ask for a pipeline there, and paste the JSON into Or import a pipeline JSON.

What makes a good agent prompt

The skill’s prompt guidance applies to any pipeline you write by hand too. Each agent runs in isolation and only knows what its prompt says, so every prompt should:

1. State the agent’s role (“You are the implementation agent…”).
2. Include the issue: key, title and {{issue.description}}.
3. Pass the upstream results it needs ({{steps.plan.output}}) and, for loop targets, the feedback that sent them back ({{#if steps.review.output}}…{{/if}}).
4. Say what to do and what not to do (planners and reviewers must not modify files).
5. Say what to output: coding agents commit referencing {{issue.key}} and end with a short summary; reviewers and gates end with a machine-checkable line such as VERDICT: APPROVE, matched by the step’s pass pattern.

Truncate large upstream outputs, for example {{steps.test.output | truncate:4000}}.

Generate a prompt, system prompt or command

In the step editor:

• Prompt section → Generate with AI (agent steps)
• System prompt (optional) → Generate with AI (agent steps)
• Command section → Generate with AI (shell steps)

The dialog (Generate prompt / Generate system prompt / Generate command) has:

Field	Notes
What should it do?	Your instructions. “The pipeline, its steps and the available template values are sent along as context.” If left empty, the harness is asked to “Write a good default for this step.”
Write it with	Any enabled harness, including API harnesses. Defaults to the step’s own harness for agent steps, else the one you used last, else the first detected non-Simulator harness.
Model	Free text with suggestions; empty uses the harness default.
Revise the current text instead of starting over	Shown when the field already has text; on by default. Sends the current text to be revised.

Click Generate (⌘↵). The result appears in an editable Result box, with the harness, model and cost in the footer. Regenerate tries again; Use this replaces the field’s content. Nothing changes until you click Use this, and the pipeline still needs saving.

What the harness receives:

• The pipeline name, description, workspace mode and a one-line summary of every step.
• The step being edited (id, name, type).
• The template syntax and every available value: the standard variables, the pipeline’s vars.*, and steps.<id>.output for the other steps.
• Rules for the target. For prompts: clear, actionable instructions, goal, constraints, expected output, use template variables, and state the exact final format if a later step parses it. For system prompts: keep it short (role, standing rules, conventions). For commands: it runs with the system shell in the workspace, non-zero exit fails the step, placeholders are auto-quoted (no extra quotes; | raw only when needed), $FACTORY_* variables are available, prefer one line or a short && script.
• A system prompt telling it to reply with only the text, and not to use tools, read or modify files, or run commands.

CLI harnesses run in an empty temporary folder that’s deleted afterwards, so they can’t touch a repository. The timeout is 5 minutes. A code fence around the answer is stripped automatically. Cancel aborts the request.

The Simulator is allowed here and returns canned answers (a generic prompt, a generic system prompt, or npm ci && npm test), so you can try the flow without an agent.