CI as a feedback loop — how fast, trustworthy, and clear the signal is between pushing code and knowing it is safe to merge.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge the CI pipeline as a feedback loop — speed, reliability, and clarity of the signal between a push and a confident merge — because slow or flaky CI trains people to ignore it.
Read-only pass. Read the pipeline config and recent run history; change nothing but the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
total time from push to green, and the long pole in the pipeline
jobs that could run concurrently; missing dependency or build caches
steps that fail intermittently and erode trust in the signal
on failure, is the cause obvious or a log-diving expedition
the same check run in several places; stages that add time but not confidence
cheap checks (lint, typecheck) before slow ones (e2e), or everything at once
which checks block merge, and whether that matches their reliability
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List every stage from push to green.
Duration — total time from push to green, and the long pole in the pipeline.
Rank by time or trust reclaimed.
Create CIFEEDBACK.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:ci-feedback-loop.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-ci-feedback-loop:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=96 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/96.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: CI Feedback-Loop Audit You are working inside this repo. Mission: judge the CI pipeline as a feedback loop — speed, reliability, and clarity of the signal between a push and a confident merge — because slow or flaky CI trains people to ignore it. Read-only pass. Read the pipeline config and recent run history; change nothing but the report file. ## Phase 1 — Map the pipeline - List every stage from push to green: what runs, in what order, and how long each takes. - Note which checks block merge and which are advisory. - Skim recent runs for failures: real breakages versus flakes and infra hiccups. ## Phase 2 — Audit through 7 lenses 1. **Duration** — total time from push to green, and the long pole in the pipeline 2. **Parallelism & caching** — jobs that could run concurrently; missing dependency or build caches 3. **Flaky gates** — steps that fail intermittently and erode trust in the signal 4. **Signal clarity** — on failure, is the cause obvious or a log-diving expedition 5. **Redundancy** — the same check run in several places; stages that add time but not confidence 6. **Fast-fail ordering** — cheap checks (lint, typecheck) before slow ones (e2e), or everything at once 7. **Required vs advisory** — which checks block merge, and whether that matches their reliability ## Phase 3 — Curate - Rank by time or trust reclaimed: the long pole and the flakiest gate usually top the list. - For each, name the fix — cache, parallelize, reorder, split, or quarantine. - Separate "make it faster" from "make it trustworthy"; both change behavior. ## Phase 4 — Report Create `CIFEEDBACK.md` at repo root: 1. **The pipeline, timed** — each stage, its duration, and its blocking status 2. **Slow & flaky** — the offenders ranked by time cost and by failure noise 3. **Fixes** — each: stage · change · time saved or trust gained · effort 4. **Target pipeline** — the reordered, cached, parallelized shape and its expected time-to-signal Start the report with today's date. If `CIFEEDBACK.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - A flaky gate is worse than a slow one; it teaches people to ignore red - Order checks cheap-to-expensive so failures surface fast - No CI in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which pipeline fixes to make first
reports/ directory exists at the repo root, write the report there instead of the root.Duplication, tangles, and dead patterns — mapped as interest paid vs principal owed, with a refactor sequence that pays for itself.
Walk clone → install → run → change → PR like a brand-new developer and log every stumble on the way to a first contribution.
Census the drifted colors, spacing, and duplicate components; propose the token set and migration order to unify them.
Can a coding agent work here? Entry files, one-command checks, discoverable conventions, and a mechanical definition of done — audited by attempting the work.
Runs inside these playbooks — curated sequences you can launch with one paste: