Set up with a coding agent

A coding agent working in your repository can write most of .squidci/pipelines.yaml for you: it can see how the project is built and tested, and these docs are written for it as much as for you. Three things make it reliable:

• These docs as Markdown. squidci.com/llms.txt lists every page with a line on what it covers, each at its own URL plus .md. Every page also has Copy page and Open in Claude beside its title.
• The pipeline file’s JSON Schema, at https://squidci.com/schema/pipelines.json, to check a file before it is pushed rather than after a run fails.
• A prompt that says what you want: below.

Connecting AWS and GitHub stays yours to do in the app: see Getting started, steps 1 to 4.

Prompts

Copy one into Claude Code, or your agent of choice, from the repository’s root.

Write a first pipeline

This repository is going to build on SquidCI. Read https://squidci.com/llms.txt,
then the pipeline guide and the pipeline reference it links to.

Look at how this repository is built and tested today — package scripts,
Makefiles, any existing CI configuration — and write .squidci/pipelines.yaml:
a component for each part that is built on its own, with check, test and build
sections, using pnpm, docker or script steps where they fit and plain commands
otherwise. No deploys and no AWS access yet.

Put "# yaml-language-server: $schema=https://squidci.com/schema/pipelines.json"
on the first line, and validate the file against that schema before you
finish. Then tell me, in a sentence each, what every component does.

Move from GitHub Actions

Read https://squidci.com/llms.txt and the SquidCI pipeline guide and reference
it links to. Then translate the workflows in .github/workflows into
.squidci/pipelines.yaml: what runs on pull requests becomes check, test and
build sections; what publishes or releases becomes publish and deploy, with
environments. Keep the GitHub workflows for now.

Where an action has no SquidCI equivalent, write the commands it runs as
steps, and list each one you replaced. Validate the file against
https://squidci.com/schema/pipelines.json before you finish.

Add a deploy

Read https://squidci.com/docs/concepts/environments.md and
https://squidci.com/docs/pipelines/aws.md. Add a deploy to
.squidci/pipelines.yaml: environments dev then prod, prod after dev, dev
deployed every version and prod by hand. Each environment's aws names a
profile — dev and prod — and the region it deploys to. Use
$SQUIDCI_ENVIRONMENT in the deploy steps rather than repeating them per
environment. Validate the file against
https://squidci.com/schema/pipelines.json, and tell me what has to exist in
each AWS account for the deploy to work.

Find out why a run failed

This SquidCI job failed. Its log is below. Read https://squidci.com/llms.txt
for how SquidCI runs a job — the image, the checkout, how pnpm steps are set
up, what AWS access a job has — then find the cause in this repository and
fix it. If the fix belongs in .squidci/pipelines.yaml, validate the file
against https://squidci.com/schema/pipelines.json.

<paste the log here>

For CLAUDE.md or AGENTS.md

So that any agent working in the repository later knows what it is looking at, add this to its CLAUDE.md, AGENTS.md or equivalent:

## CI: SquidCI

This repository builds, tests and deploys on SquidCI, from
`.squidci/pipelines.yaml`. Docs: https://squidci.com/llms.txt (every page is
Markdown at its URL plus `.md`). Before committing a change to the pipeline
file, validate it against https://squidci.com/schema/pipelines.json — the
schema catches most mistakes; SquidCI checks the rest when it reads the file,
and an invalid file runs nothing. Pull requests run check, test and build
sections only, with no AWS access.

Checking a pipeline file

Editors with the YAML language server — VS Code’s YAML extension, JetBrains IDEs, Zed, Neovim — check the file as it is typed, from its first line:

# yaml-language-server: $schema=https://squidci.com/schema/pipelines.json

From a shell, with Node:

curl -fsSL https://squidci.com/schema/pipelines.json -o /tmp/squidci-pipelines.json
npx --yes ajv-cli@5 validate --spec=draft7 --strict=false \
  -s /tmp/squidci-pipelines.json -d .squidci/pipelines.yaml

What a schema cannot see, SquidCI still checks when it reads the file: that needs and after name components in the file and do not go round in a circle, that a schedule’s cron and time zone are real, at most 50 jobs, and that each aws profile is a target AWS account of one of your execution planes. A file it refuses runs nothing; the run says why on the build page and in its GitHub check.

The Claude Code plugin

The squidci plugin gives Claude Code a skill for writing and changing pipeline files: the handful of rules an agent gets wrong without being told, and where in these docs and the schema to look for the rest.

/plugin marketplace add SquidCI/claude-plugin
/plugin install squidci@squidci

It reads these docs live rather than carrying a copy, so it does not go stale when SquidCI changes.