AmplifierSkills and tools for thoughtful work

Skill

Pipeline

Build the pipeline your project actually needs.

For developers creating, repairing or moving CI. Pipeline starts with your real commands and artifact consumers, makes job dependencies reviewable and then generates configuration for the selected platform.

Use PipelineWatch the 72-second filmWalk through an example
What you getFictional illustration
Proposed jobs
Test → supported Python versions, actual test command, timeout
Build → waits for Test, creates a wheel, retains the artifact

Permissions: read source; no release credential required
Trigger: review for pull-request trust boundary
Next check: native YAML validation and a disposable branch run
Deployment: outside this requested pipeline

Fictional pipeline design. It is a review outline, not executable APR or a successful CI run.

Start with working commands

Read manifests, lockfiles and existing tests before adding a job.

See dependencies before syntax

Use the optional abstract representation to review stages, artifacts, timeouts and secret names across platforms.

Keep release boundaries explicit

Separate a build, a green CI run and an approved deployment so generation does not silently publish anything.

The film

A build is not a release.

In 72 seconds, Pell the pelican drum major grabs a template, and the confetti cannon fires a release nobody asked for. Pipeline starts from the commands your project already runs, maps the order before any syntax, checks the map for loops, missing time limits and undeclared secrets, then writes the file for your platform with no publish step. Captions are on the player; a transcript is below.

Download the film 15-second cut Captions
Read the transcript

Meet Pell. Pell runs your checks, in order, whenever the code changes.

You ask for a build. Pell grabs a template and blows the whistle.

The tests call a command you don’t have. The package ships to the public.

Pipeline starts with the commands your project already runs.

Then it maps the order before any syntax. Build waits for test.

A small checker catches loops, missing time limits and undeclared secrets.

Then it writes the file for your platform, with no publish step. You asked for a build.

The checker reads the map, not the file. Next comes a trial run. Releasing needs your yes.

On screen: A build is not a release.

Pipeline. Build the pipeline your project actually needs.

The project, pebblecount, is a fictional example. The film shows how the skill behaves; it does not report results.

See the work take shape.

Fictional pipeline design. It is a review outline, not executable APR or a successful CI run.

Scout the project

Identify supported build and test commands, runtime versions, consumers and the current release path.

Fictional example

Build a wheel without publishing it

The brief Use Pipeline to inspect a fictional Python project and propose a test-and-wheel pipeline for GitHub Actions. Name the real commands and artifact consumer. Include timeouts and minimal permissions. Do not add deployment, secrets or publishing.

Before

A platform migration copies YAML syntax but drops release approvals and artifact dependencies.

After applying the method

An APR and native diff preserve triggers, jobs, approvals and consumers.

A shared intermediate representation makes consequential drift reviewable.

A clear job.
A useful stopping point.

Create, audit, repair or migrate a build/test/release pipeline.

Use it when

  • You need CI for an existing project with real build and test commands.
  • You are migrating between supported CI platforms.
  • A pipeline needs a dependency, permission or release-boundary audit.

Choose another route when

  • Deploying because someone asked for a build.
  • Treating the APR checker as a validator for arbitrary native YAML.

Scout

Project commands and deployment boundaries are unclear.

An evidenced project profile.

Design

The project profile is known.

A platform-neutral APR with dependencies, secrets and approval boundaries.

Generate

A target CI platform is selected.

Native config plus validation evidence and operational limits.

Read the canonical method

Pipeline

Scout the actual manifests, lockfiles, tests, release process and existing CI before choosing jobs. Record supported commands, runtime versions, artifact consumers and secrets by name only. Do not add deployment because a build pipeline was requested.

Design: read references/apr-schema.md and references/project-profile.md. Write an Abstract Pipeline Representation (APR) before platform syntax when migrating or targeting several platforms. Capture stage/job dependencies, timeouts, triggers, artifacts, environments and required secret names. Use scripts/apr.py APR.json to check the JSON subset of APR 1.0 for reference errors, cycles, missing timeouts and undeclared secrets. It does not validate arbitrary YAML or prove the pipeline can run.

Generate: read only the selected platform reference directory: references/platforms/github-actions, gitlab-ci or azure-devops. Render APR into native config, inspect permissions, untrusted pull-request paths, action/image pinning and the deployment approval boundary. Use the platform's actual validator or runner when available. Explain any unchecked native feature.

Audit: compare the APR and live config for drift; preserve platform idioms when they are deliberate. Test changes in a disposable branch or local runner before changing production triggers. A generated file, a syntax pass, a green run and an accepted deployment are distinct results. Installing this skill does not authorize publishing, provisioning secrets or releasing software.

The original scout/architect/auditor/platform-generator agents and automation recipes remain optional Amplifier adapters. They carry the original platform-specific mechanisms; the portable method and schema work in an ordinary coding agent.

Limits and prerequisites
  • Structural APR validation is not native syntax validation, a green CI run or deployment acceptance.

Your first useful run.

Point it at one project and ask for a build-and-test plan before changing CI triggers.

The download contains the complete skill folder. Extract it into the skills directory supported by your agent, keeping its references and license together. Or use the source installer below. Python 3.11+ is required for that installer.

Download the portable skillSource on GitHub

Start from the public source

git clone https://github.com/michaeljabbour/amplifier-skill-pipeline.git
cd amplifier-skill-pipeline
python3 scripts/capability.py install --dest ~/.agents/skills

Keep the complete skill folder together, including its references and license. The host applies the method in your context; the skill does not start a background service.

  • Python 3.11 or later is required by the portable install/build helper. The installed method runs through your agent host.
  • Install the portable skill and stdlib APR checker without a model key.
  • Platform references are loaded as needed; the actual CI service and runner remain separate.
  • Keep secret values out of the design; name only the required secrets.

Try this with your agent

Use Pipeline to inspect a fictional Python project and propose a test-and-wheel pipeline for GitHub Actions. Name the real commands and artifact consumer. Include timeouts and minimal permissions. Do not add deployment, secrets or publishing.

Use after installing in a host that loads skill folders. Supply your own task files and review the result.

Keep the guide nearby

Read the guide · License · Changes · Release metadata · CONSOLIDATION

Know what you can rely on.

The packaged APR checker exercises structural reference and cycle failures. Generated configuration still needs native validation, a real run and separate deployment acceptance.

Read the checks and their scope
  • Functional acceptance — passed

    3 structural APR tests passed; native CI syntax/runner/deployment acceptance remains separate.

  • Native host acceptance — not-run

    No live model, real desktop transaction, invitation, deployment or production data migration was performed by this functional baseline.

Source and conformance checks are separate from demonstrated benefit. Comparative effectiveness and outside-user outcomes are not established by this site.

Fictional examples explain the capability. Tests check the stated behavior. Outside-user outcomes need their own evidence.