# Set up with a coding agent > Prompts to give Claude Code or another coding agent so it writes and checks your pipeline file, a snippet for CLAUDE.md or AGENTS.md, and the SquidCI plugin for Claude Code. 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`](https://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](/docs/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 ```text 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 ```text 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 ```text 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 ```text 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. ``` ## 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: ```markdown ## 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 # yaml-language-server: $schema=https://squidci.com/schema/pipelines.json ``` From a shell, with Node: ```bash 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. ```text /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.