Autonomous goal pipeline

Autonomous Goal Pipeline

Overview

Carries one delegated goal from a single sentence to multiple shipped batches without coming back for approval.

Principle 1: autonomous means every stage has adversarial review behind it — not that nobody is checking. What you remove is the user's step-by-step nod, not the checking itself.

Principle 2: this skill supplies judgment criteria, not formats. Whatever artifact conventions the target repo already has, adopt them. Imposing a new layout fights hundreds of existing documents, and whoever resumes the work won't know which set to read.

When to use

• The user hands over the whole thing: "just do it", "you decide", "report back when done", "don't wake me up"
• The task is big enough to need its own spec, and implementation spans more than one ship

Don't use for: single-file edits, plain Q&A, exploratory research, or a finished plan that only needs executing. This pipeline runs 3–4 review rounds; on small work that is pure waste.

Stages

#	Stage	Exit condition
0	Read the contract: gates + existing artifact conventions	Both discovered and written into the design doc
0.5	Grill	The "must ask" list is empty
1	Design + prior-art research	Adversarial review: zero surviving findings
2	Spec	Zero surviving → self-approve → do not wait for the user
2.5	Batch split	Vertical-slice check + write-set check + cost check
3	Per batch	Plan review converges → inline execution → per-task review → code round (9 lenses) → local gates green → ship → production verification
4	Close out	Report includes "decisions I made for you" and "handoff items"

When design and spec share the same content, the two review rounds may merge — say so in the report.

"Per-task review" and "code round" are different things. The first is a single agent checking one task's diff and test evidence against the plan step, done as each task completes. The second runs once after the whole batch is done: 9 lenses across the batch diff plus three-vote refutation. A minimum-viable-tier batch may skip the code round, but the reason it was classified minimum-viable must be written into the plan — under cost pressure there is a real pull toward misclassifying a shared library as one-off code to dodge the most expensive round.

Stage 0: read the contract

Find the gates: CLAUDE.md / AGENTS.md / memory index / task runner (Makefile, tasks.py, package.json scripts) / test config / .github/workflows/ / any deploy skill. A gate you cannot find is a gate that does not exist — do not invent one.

Find the artifact conventions (equally important; skip this and you will start a parallel universe). Look for docs/**/{spec,specs,design,plan,plans,rfc,adr}/, or similar directories under .claude/ or .agent/. If you find them, read the 10 most recent and record five things:

1. Naming and directory layering — <date>-<slug>-design.md plus <date>-<slug>.md in two directories? Or one run directory holding everything?
2. How status is expressed — frontmatter status:? A bold line in the body? Only checkboxes?
3. How progress is tracked — - [ ] checkboxes? Commit references?
4. How batches are numbered — -batch-A? -<n>-<name>? Not at all?
5. How a child document points back at its parent — relative link? Number?

Write all five into this run's design doc. Every artifact you produce follows them.

Artifacts: adopt what exists, default only when nothing does

You adopt their form and inject this skill's criteria.

Repo already uses	Then use that — do not switch to
A body line like **Status**: converged, pending implementation	frontmatter status:
- [ ] checkboxes for progress	an additional status field
**Source spec:** [relative link] back to the parent	a numeric layer:
A file table (file / role / action in this plan)	a writes: YAML array
<slug>-batch-A or <prefix>-<n>-<name> batch naming	PLAN-<n>-<slug>.md
Spec and plan in two separate directories	one run directory holding everything

Not one criterion is dropped — only re-expressed:

• Write-set reconciliation: if the repo uses a file table, do it in the table. No two batches may share a row that is a substantive overlap.
• Parent pointer: if the repo uses relative links, use links. The depth cap of 2 still holds (count it by following links).
• Review evidence: if the repo has no audit_run: convention, write the review summary into the body. It should be portable anyway — see below.

Only when no convention exists at all do you fall back to docs/superpowers/runs/<YYYY-MM-DD>-<slug>/ with DESIGN.md / SPEC.md / PLAN-<n>-<slug>.md / DECISIONS.md, frontmatter carrying status / writes / layer / audit_run.

A decision log (question / sources consulted / candidates / ruling / reversibility / when to revisit) usually has no precedent anywhere. Create one regardless — in autonomous mode it is a necessity, not a formatting preference.

If the target repo has a "don't create documents unprompted" rule, the artifact path is an explicit exception. Everywhere else, obey it.

Progress and resumption

Which progress mechanism the repo uses matters less than whether it is actually maintained. A declared checkbox convention that nobody ticks is no progress mechanism at all — whoever picks it up sees "0 of 76, not started" while nine commits of that work are already landed, and has to reverse-engineer state from the git log or redo it.

Update after every step. Never batch it up to the end of a batch. During the interval you save up, a crash leaves progress existing only implicitly, inside git.

Resume by locating the stage from whatever status representation the repo uses. The rules are the same either way:

Status meaning	Where to resume
Written, not reviewed	Enter that stage's review
Review converged	Check the evidence first (below), then advance
Executing	Reconcile the working tree first (below), then resume at the first incomplete step
Shipped	Next batch
Blocked	Stop immediately. Read why. Do not resume on your own judgment.

Checking the evidence. When a review round converges, write the summary into the artifact body: lens coverage, P0/P1 counts and disposition, and the false-zero determination (was agents_error zero?). The summary must be portable — it goes into git. A workflow run id is a supplementary pointer only; it lives in a machine-local directory and will not resolve on another machine.

• Summary is self-consistent → trust it, advance
• Summary missing or self-contradictory (claims zero survivors while agents_error > 0; findings are hollow) → send it back for re-review
• Only the run id is unresolvable, but the summary is coherent and the ship timestamp matches git history → note "journal unreachable, corroborating evidence consistent" and advance without re-reviewing

That last rule exists for multi-machine work. Without it, every hand-off between machines re-runs a full review of code that is already in production.

Reconciling the working tree. Session death almost always lands mid-step — code half-changed, nothing committed, nothing ticked. Run git status / git diff first:

• Half-finished work belonging to this step → finish it
• Leftovers or unrelated changes → note them in the plan, then decide; never silently overwrite
• Cannot attribute it → git stash push -u to preserve it first (never checkout / reset / clean), then stop and write down the current state. "Stop" here means stop writing code; it does not invoke the rollback from three-strikes — unattributable uncommitted work may be the user's own.

If the work uses a worktree, confirm it still exists (git worktree list) and recreate it if not. Do not fall back into the main working tree.

Batch splitting: cut top-down, verify bottom-up

Write-set overlap is a validator, not a generator. Generate candidates by capability first, then verify. If verification fails, re-cut along a different axis — do not collapse everything into one mega-batch.

Step 1: generate candidates top-down (SPIDR)

Find the one axis that yields a thin, independently deliverable slice:

Axis	The cut
Spike	Split off "we don't know how yet" and resolve it first — research separate from implementation
Path	Happy path first, alternate and error paths later
Interface	One entry point first (one CLI, one format, one client), others later
Data	One data class / one market / one source first, the rest later
Rules	Basic rules first, complex validation and edge rules later

You do not apply all five. You find the one that produces a slice you would genuinely ship on its own.

The cut must be vertical. Vertical means it goes through every architectural layer and delivers one independently verifiable behavior change. Test: if a batch is named "database layer", "API layer", "infrastructure setup", or "frontend wiring", it is horizontal — re-cut. If it is named "a user can upload a file" or "valuation computes under the A-share convention", it is vertical.

Non-product work splits by intent, and the criterion inverts:

• Changing behavior (migration, ops change, new capability) → the criterion is an independently verifiable behavior change: is there a check you can run alone that proves the new behavior is live?
• Preserving behavior (pure refactor, extracting a shared layer, swapping an implementation) → the criterion inverts to independently verifiable behavior invariance: is there a comparison or regression check (characterization tests, before/after output diff) proving observable behavior is identical?

Get this backwards and you will manufacture an artificial behavior change inside a pure refactor just to satisfy the criterion — which is exactly the anti-pattern of mixing refactoring with behavior changes in one diff.

Step 2: verify bottom-up (write sets)

List the files each batch writes (read-only dependencies do not count) and reconcile pairwise. Classify every intersection:

Type	Test	Disposition
Substantive overlap	Both batches change the same logic in the same component — two halves of one end-to-end thing	Must merge into one batch with ordered tasks
Incidental sharing	Each appends unrelated entries to a shared manifest: different packages in a lockfile, different service blocks in compose, different keys in settings, a script-regenerated derived index, one line each in a registry	Not an intersection. Each batch adds a wrap-up task; splitting is not blocked

The test has two conditions, both required:

1. Mechanically separable — each merges independently, order is irrelevant, no rebase conflict that needs human judgment
2. Semantically orthogonal — swapping the application order yields the same result; neither batch's correctness depends on the other already being in effect

Satisfying only the first is still a substantive overlap. When two batches touch the same function or the same control flow, treat it as substantive by default even on different lines with no textual conflict — unless you can argue full orthogonality, and that argument goes into the plan for the code round to audit.

Disjoint write sets do not mean the order is interchangeable. There is a batch-level orthogonality check on top of the file-level one: does one batch's outward promise depend on another batch's implementation existing? Copy, documentation, interface declarations, alert text, error messages — all of these promise a concept, and that concept may be built by a different batch. The two batches share no files at all, so write-set reconciliation is blind to the coupling.

Real example: batch A's page copy adds a "before you buy" section promising a definition of "cautious entry price"; "cautious entry price" is implemented by batch B. The two batches share zero files, but A's copy cannot be written until B lands — while the plan said "A finishes first".

Disposition: do not merge (they genuinely are two batches; the write sets really are disjoint), but record the dependency direction in both plans' ordering statements and let the depended-upon batch go first. This coupling is the easiest thing to miss at split time, because every file-based check is immune to it.

Counter-example: batch A adds a single-flight lock to get_or_fetch(), batch B adds a TTL expiry check to the same function. Different lines, zero conflict — but the TTL check must run before the lock key is computed, or concurrent callers single-flight on a key that is about to expire and all read stale cache. Mechanically separable, semantically one thing.

Step 3: when verification fails

Substantive overlap → go back to step 1 and re-cut along a different SPIDR axis, at most twice. A sequentialthinking MCP server is useful for bookkeeping across re-cuts (isRevision / branchFromThought match this branch-and-revise shape) — it supplies the bookkeeping, SPIDR supplies the knowledge.

Both re-cuts fail → merge into one batch, write "splitting was considered and rejected because X" into the plan, and mark it a forced merge. Concerns jammed together are likelier to miss convergence in the code round, so a forced-merge batch that hits three strikes may be rolled back at task granularity rather than scrapped whole.

Legitimate reasons to keep a substantive overlap split (write them down, otherwise it is over-splitting): risk isolation, needing intermediate feedback before deciding the next step, a single batch exceeding one agent's context, or concern density so high the merged diff becomes unreviewable.

Step 4: cost check

Every additional batch adds a full fixed overhead: plan review (≤3 rounds) + per-task review + code round (9 lenses, ≤3 rounds) + local gates + ship + production verification. Five batches is on the order of hundreds of agent invocations.

If a batch's actual work is clearly smaller than its fixed review overhead, lean toward merging — unless one of the four reasons above applies.

Batch discipline (after the split)

• The batch order written in the plan is a commitment. To interleave, change the plan first and say why. Never leave "the plan says A finishes first" standing while execution interleaves.
• No commit spans two batches. A cross-batch commit makes both batches' diffs unreviewable as a set — neither can be attributed.
• A batch's declared boundary ("this batch does not touch X") is hard. To touch it, amend the declaration first.

Against over-splitting

Excuse	Reality
"Touching the same files and needing an order is a separate question from whether to merge the ship"	With substantive overlap it is the same question. Three serial PRs over the same logic = three rebases + three reviews of the same file mid-evolution + intermediate states nobody consumes.
"The user said split whatever can be parallel"	"Can be parallel" means no substantive write-set overlap. Changing the same logic in sequence is not parallelism, it is queueing. Following the words literally betrays the intent (less PR risk).
"Each piece is a complete increment on its own"	Being a complete increment is a necessary condition for merging, not a sufficient condition for splitting.
"Freeze the interface contract and they can go in parallel now"	Only when the implementation is large enough to amortize coordination cost. On a small spec the contract usually needs rework — premature abstraction.
"Smaller batches are easier to review"	Review overhead accumulates linearly with batch count. Below the point where a batch is smaller than its fixed overhead, total cost explodes and quality does not improve.

Red flag: "batch B waits until batch A ships because it changes what A changed" = they should be one batch. Not a red flag: batch B only reads what batch A produced — batches are supposed to share nothing but already-shipped code.

Sub-goal recursion is a layered state machine, not self-invocation

When one batch is large enough to need its own spec: do not re-invoke this skill. The harness has no call stack. Create child-layer artifacts, drive them with the same status semantics, and have the main loop iterate back into stages 2.5–3.

Depth is tracked by an explicit parent pointer, not by counting directories. Every child artifact names its parent (using the repo's own back-reference form; fall back to a numeric layer: only when there is no convention). The cap is 2 layers.

One exception, to avoid a deadlock: a layer-2 artifact that fails two re-cuts because a single batch exceeds one agent's context (not because of logical coupling) may open a third layer — merging back would simply recreate the overflow, so all three exits are blocked. Record that the reason is context size and flag it in the report. Logical coupling never qualifies; that case merges, and the cap is not to be circumvented by claiming size.

How review rounds converge

Orchestration: multi-lens rounds (design, spec, code) run as a workflow — resumable, and the journal is the objective evidence for judging a false zero. Per-task review runs as a single agent.

Fixed lens list (fixed so coverage does not drift): correctness / boundaries and error paths / concurrency and idempotence / security and secrets / performance and quota / SOLID and maintainability / test adequacy / contract and doc consistency / rollback-ability. Design and spec rounds use the first five plus contract consistency. The code round uses all nine.

Rule	Content
Three-vote refutation	Each P0/P1 gets three independent attempts to refute it; it is real only if ≥2 survive
False-zero test	If agents_error > 0, or any agent in the journal produced no real return, that round's "zero findings" is void — re-run the failed lenses. Non-null ≠ actually did the work: also scan returned content for hollowness, truncation, and off-topic answers
Insufficient votes	Never discard silently. The main loop personally re-checks the proof-of-concept at file:line — fix if it holds, close with a written reason if it does not
Acceptance before implementation	Every task's acceptance criteria go into the plan before work starts. Never define them after implementing
Reviewers are not told the threshold	Do not tell a reviewer how many findings constitute a pass
Cap	3 rounds per stage is the baseline; you may continue while the survivor count is still falling, but every extra round goes into the report with its round number and survivor count
Quota interruption	If finder results are already in hand, do all convergence fixes inline in the main loop — do not burn subagents waiting for a reset
Leave evidence	On convergence, write the summary into the artifact body
What gets reviewed	Point the round at a branch, not a pinned SHA you then keep committing on top of — a review holds a snapshot, and the moment execution moves, its findings become audit ghosts you spend time re-verifying against code that is already fixed

A guard must assert what the code computes, not how it is written. "This literal does not appear in the source", "the same symbol is imported", "it raises in the scenario I set up" — all of these are bypassed by a different spelling or a different input, and the change that bypasses them is usually the exact thing the guard exists to catch. Write the invariant as an executable equivalence (f(x) == the_composition_it_should_equal(x)), and make the cases cover the dimension along which the two implementations would diverge.

Every new guard needs a mutation check: not just green against the correct implementation, but red once you actually paste in the broken implementation it is supposed to catch. A guard that has not been through that is an unverified verification mechanism — and "correct code, useless test" looks identical from the outside to "everything is fine".

The opening grill

Ask everything up front, then go quiet. Batched rounds, ≤4 questions each, hard cap of 3 rounds.

Sort every open decision into two buckets first:

• Must ask: spending money, production and secret placement, what goes out publicly, irreversible actions, genuine value judgments (product direction, risk appetite)
• Decide yourself: researchable technical choices, implementation shape, naming, directory structure — look it up, read the repo's existing rulings, and rule

Stopping condition (decidable): you can write one paragraph with no "TBD" and no "depends", covering — the goal and acceptance criteria, what is explicitly out of scope, what environment it runs in, which production resources it touches, the default behavior on failure, how existing data is handled, and whether it goes through the standard ship process. If any part can only be written as "depends", you have not asked enough. When the "must ask" list is empty, start.

Questions must be grounded: read the repo before asking, and point at specific files and scripts. Do not ask about categories.

Still ambiguous after three rounds → do not open a fourth. Rule with "most conservative, most reversible, closest to rulings the repo already made", and record it in the decision log.

Autonomy boundaries — only three things stop you

1. Production resources, three zones

Zone	Actions	Handling
Green	Read-only diagnostics over SSH: docker ps / logs / inspect / health-check curl / df	Autonomous
Yellow	Reversible changes: deploy scripts, restart, scoped up -d --no-deps --force-recreate <svc>, scp of non-secret files	Autonomous, after confirming the rollback path is in place
Red	Deleting volumes, compose down, changing DNS or certificates, rotating keys, editing .env, force push, deleting remote branches	Stop and ask — however many times the user said "don't wake me"

Blast radius beats convenience. A project-level down tries to remove the networks that project defines. When another project shares one, either the removal fails and leaves you half torn down, or it succeeds and severs healthy, unrelated services. To change one service, use a scoped --no-deps --force-recreate. Never down.

A change made by hand on a remote host must also land in the repo. Most production hosts are not git checkouts; an edit made only on the host is overwritten by the next deploy. Push the change through the normal release path as well, or you have only bought a few hours.

2. The wallet is not in scope

"Don't ask me" delegates judgment, not the wallet. For any recurring cost, new subscription, or tier upgrade: exhaust free and already-available alternatives first (call the existing tools for real and verify field completeness — not just that the call succeeded), and if a gap remains, stop and ask, presenting the paths you ruled out and your recommendation. Never pick a default on the user's behalf between "spend money" and "cut the feature".

3. Three strikes

Any one of these → roll back, stop, write a failure report (what is done, rollback state, what each attempt changed, what the hypothesis was, what evidence refuted it):

• The same task fails three fix attempts
• The same stage's review goes three consecutive rounds without the survivor count falling
• Production verification fails — roll back, do not fix forward

"Not converging" is judged by trend, not by round count. 6 → 4 → 2 is converging — the artifact is simply complex, and you may continue. 6 → 6 → 6 is stuck. A flat round-count cap kills a plan that is actively improving and rolls back the parts already fixed. Every extra round goes into the report with the round count and the per-round survivor count, so the cost stays visible.

A forced-merge batch may roll back at task granularity rather than being scrapped whole.

The integrity line

You want to soften an assertion, loosen a fixture, or skip a gate to make things green — stop immediately. This does not count toward three strikes.

One exemption: independent evidence that the assertion itself is wrong. "Independent" means, operationally:

• The evidence already existed before this line was triggered — the user's own words, the grill transcript, a commit / spec / issue predating this task
• It is not a decision-log entry you wrote inside this task to unlock the exemption (that is signing your own certificate)
• It is directly about the assertion being changed, not an unrelated old record pressed into service
• Write the citation into the plan notes before changing the assertion

If you cannot tell whether it pre-existed, treat it as no evidence and stop.

Granularity of "stop": stop this one task and record the concern; unrelated tasks continue. Two exemptions across the whole run escalates to a report for the user — counted per run, not per batch, or splitting into finer batches would let you use one per batch and never escalate.

Tiering: when to build to the highest standard, when to keep it minimal

High-standard tier = a second caller will depend on it, or getting it wrong silently produces bad data or leaks secrets. Typical: shared libraries, the deploy chain, external interfaces, auth and secret paths, monetary and convention-sensitive calculations.

Minimum-viable tier = one-off scripts, report generation, a single migration, copy.

The reason for the classification goes into the plan for later spot-checking — it directly determines whether the most expensive round runs, so unverified self-assessment drifts.

SOLID is mandatory only in the high-standard tier and explicitly waived in the minimum-viable tier. Reviewers may not demand extra abstraction in the name of SOLID on one-off code — three lines of duplication beat a premature helper. Extra abstraction requires a second use case that has actually occurred, not a hypothetical one.

Verifying in production: only production's own response counts

The truth about production lives in production, not in git. A production host is usually not a git checkout, so a manual deploy is structurally invisible to anything reasoning from commits. After shipping, do not infer that it took effect from "CI is green" / "the deploy script exited 0" / "the commit is pushed" — those only prove it was sent. Probe at least three things: the real response for the changed behavior, one critical path this batch did not touch (a regression control), and one corroborating artifact carrying an independent timestamp (certificate issuance, image digest, container start time) to pin down when it took effect.

Same on resume: to decide whether a batch shipped, probe production as well as reading git. If the two disagree, treat that as a disagreement — don't pick one and believe it.

Observed: a config change was serving live traffic at 16:26 (proven by the Let's Encrypt certificate's issuance time) and was not committed until 17:12. For those 46 minutes anything reading only git would have reported "production untouched" — and a deploy run from master would have reverted it.

Probes lie too. HEAD returns 404 on endpoints that only implement GET. So does a path that is one segment short. On a 404, falsify "I probed it wrong" before concluding "the route is broken" — use a known-good sibling path as a control and probe both in one pass. Falsely reporting a production outage costs far more than a few extra requests.

A self-check nobody has ever seen emit is not a self-check. A log line tagged "grep this at deploy time", a new probe, an alert rule — confirm it actually produces output the moment you add it.

Observed: log.info("RS mode ENABLED ...") carried the comment "deployment self-check, grep this line", while that process's log level was never wired up — the line printed nothing at all across the two deploys where it was the one thing meant to be checked.

The finish line is a handoff, not "all green"

Some verification structurally cannot complete in the current session — most typically a client-level regression after deploying, where the session's connection was established before the deploy and now fails at the protocol layer across the board.

When you hit one: verify through an independent channel (the repo's own test scripts, a direct HTTP call). Whatever still cannot be verified goes into the report as "needs a fresh session to run X", listed under handoff items. Do not hammer it in-session and then claim it passed — and do not misread the failure as a production outage.

Likewise, when every call reports the same protocol-layer error at once, two hypotheses both fit: a stale session connection (harmless) or this deploy breaking a shared layer (serious). Only a channel independent of the current session can distinguish them. Do not skip that on the strength of a prior.

Red flags

• "Review returned zero findings, moving on" — check agents_error and the journal first
• "The repo already has specs/ and plans/, but I'll build my own layout per the skill" — adopt, don't found a colony
• "I'll tick the checkboxes at the end of the batch" — crash in between and progress exists only implicitly in git
• "The last stage says converged, trust it" — no summary in the body means send it back
• "Different machine, can't find the journal, better re-review" — a coherent summary is enough; don't re-review on every hand-off
• A batch named "the X layer" or "infrastructure setup" — horizontal; re-cut along a SPIDR axis
• "Batch B has to wait until A ships before it can change that file" — they should be one batch
• "The plan says A goes first, but a little B won't hurt" — amend the plan or pause B; do not leave the inconsistency standing
• "This commit knocked out work from both batches" — no commit spans two batches
• "Every batch touches the lockfile, so it all has to be one batch" — incidental sharing is not an intersection
• "Different lines, no conflict, so it's incidental" — it also has to pass semantic orthogonality; same function defaults to substantive
• A pure-refactor batch with no "behavior change" to point at — the criterion is inverted; refactors prove invariance
• Resuming without checking git status — you will stack onto a half-finished change or silently erase it
• "I'll note it in the decision log first, then cite it for the exemption" — self-certifying loop; the line still stops you
• "The user's asleep, I'll just decide this one" on money or a red-zone action — out of bounds
• "One more attempt should do it" after the third — three strikes
• "Can't reach it in-session, so call it passed / call it broken" — change channels, or hand off
• "CI is green / the deploy script exited 0, so it's live" — that only proves it was sent; probe production itself
• "I got a 404, the route is broken" — first falsify your own path and HTTP method
• "The guard test is written and green, so that's pinned down" — not until it has a mutation check; paste in the broken implementation and watch it go red
• "It asserts the literal is absent from the source / that the same symbol is imported" — that asserts spelling; a different spelling walks right past it
• "The self-check log line is in place, grep it at deploy" — not a self-check until you have seen it emit once
• "The code round is dispatched, it's reviewing <some SHA>" — if you keep committing, its findings turn into audit ghosts
• "Let me add an abstraction for future extensibility" in the minimum-viable tier — premature

Related skills

The orchestration lives here; the how-to does not get reimplemented:

• Stage 0.5 → superpowers:brainstorming
• Stage 2.5, writing plans → superpowers:writing-plans
• Stage 3 execution and per-task review → superpowers:subagent-driven-development, superpowers:requesting-code-review
• Writing code → superpowers:test-driven-development
• Hitting a bug → superpowers:systematic-debugging
• Before claiming any gate passed → superpowers:verification-before-completion (every assertion carries the command and its output tail)
• Batch isolation → superpowers:using-git-worktrees
• Ship and production stages → the target repo's own deploy skill is authoritative; absent one, follow its CI config