Recipes

A recipe is a complete workflow that ships with jigs as source code. Adding one copies its files into your factory, where they become your code.

Recipes are copied templates, not managed dependencies. Your factory owns the code, you can change it freely, and upgrading jigs never overwrites it.

Add a recipe

pnpm exec jigs recipe list
pnpm exec jigs recipe add linear-ticket-to-pr
pnpm exec jigs up

Adding a recipe also registers it in jigs.config.ts when the workflows map can be edited automatically. For a recipe started by a trigger, it prints the trigger to add to triggers yourself, since only you know the values to fill in. The command reports any manual action needed and keeps existing files and registrations.

Available recipes

linear-ticket-to-pr

What it does

Reads a Linear ticket, asks a builder agent to implement the change, then asks a reviewer agent to review it. It publishes a pull request and lets the builder continue responding to feedback and CI. Merging follows the policy in the copied workflow: by default, jigs merges an approved pull request once CI is green. The run talks to people in one Linear agent session on the ticket: it asks there when the ticket is unclear, leaves its notes there, and ends it with "Merged" and the pull request's link, or why it stopped.

Requires

• A Linear app assigned to the factory in the hub, with a named installation in the ticket's workspace.
• A GitHub binding whose installationName names the factory's GitHub App installed on its owner.
• The configured builder and reviewer harnesses, installed and authenticated.
• The GitHub CLI, gh.

The builder acts on GitHub as the factory's App, the same bot jigs posts as through the binding's installation, which the workflow adds to the builder's harness as github: { installationName: worktree.installationName } (see GitHub access for agents). It reads discussions, posts replies and pushes fixes with gh and git, with no token of yours. Its replies show as the bot, which is how the recipe tells them apart from yours. No Jev model is required.

Start it from Linear

A run starts when someone delegates a ticket to the factory's Linear app, through a linear.delegations trigger. recipe add prints the trigger to add to triggers in jigs.config.ts. Set LINEAR_TICKET_TO_PR_ACTIVE=true in .env.local to turn it on, then run pnpm exec jigs up:

import { linear } from "@jigs-ai/jigs";

// In defineFactory's `triggers`.
const triggers = {
  "linear-ticket-to-pr": {
    active: process.env.LINEAR_TICKET_TO_PR_ACTIVE === "true",
    workflow: "linear-ticket-to-pr",
    source: linear.delegations({ installationName: "linear-acme" }),
    inputs: { binding: "app" },
  },
};

Linear tells the run which ticket. The trigger's inputs add the rest:

Input	Default	What it chooses
binding		The repository to change.
builder	builder	The agent, by name, that builds the change.
reviewer	reviewer	The agent, by name, that reviews the requirements and the change.
budget	{ reviewRounds: 3, attemptsPerUpdate: 3 }	Implementation review rounds, and agent attempts allowed for each PR update. attemptsPerUpdate must be positive.

For several repositories, add one trigger per binding, each with a teams, projects or labels filter that no other trigger matches. Every linear.delegations trigger on the app hears every delegation. A ticket holds one run at a time, so when two triggers match it, the second run fails.

Customize

Edit workflows/linear-ticket-to-pr/ to change the builder/reviewer harnesses, review budgets, ticket notes or the order of the phases. Every prompt is in its prompts.ts. The building, reviewing, publishing and pull request maintenance run in three jigs routines, described in Build a pull request workflow; the workflow passes them its prompts, budgets and merge policy, and writes every note itself. The agent names above select entries defined in that source, rather than accepting a model name at runtime.

jigs merges once it verifies approval, CI, mergeability and that the builder's local work is published. To leave every merge to you, change the workflow's mergeWhen: () => true to () => false. Pull request titles must be conventional commit subjects; the writer gets one retry, and a second bad title stops the run. To allow any title, delete the check in the copied workflow. approvalCovers chooses which commits an approving review covers: "any-commit" by default, so an approval carries over the builder's later pushes, or "latest-commit" to need a new approval after every push. If GitHub blocks an approved, green pull request, the recipe leaves one note on it for each commit and keeps waiting. When the pull request needs a person, the recipe notes it in the ticket's session, leaves the ticket In Review and keeps watching; only closing the pull request unmerged stops the run. The instruction that the builder must not merge is a prompt rule, not a restriction on its token; see GitHub access for agents and merging configuration.

The copied README and source document review attempts, PR updates and recovery in detail. Waiting and external events explains the watcher the recipe uses.

Updating a copied recipe

recipe add never overwrites a recipe already in the factory:

1. Finish or cancel active runs using that workflow.
2. Preserve your current copy outside the active workflows/ path.
3. Add the current recipe again with pnpm exec jigs recipe add linear-ticket-to-pr.
4. Compare the copies and carry your customizations forward intentionally. Check that jigs.config.ts imports the new copy.
5. Run pnpm exec jigs up, then typecheck and test the factory.

Moving workflow files can change their durable identities.