@cxi-lmai/ci-agent-platform 3.0.0 → 3.1.0

package/payload/ci-templates/scripts/review.sh

@@ -52,7 +52,7 @@ pipe_log "diff base=$PIPE_DIFF_BASE incremental=$PIPE_IS_INCREMENTAL head=$PIPE_
 
 # 4. Run the review skill. It builds the diff, runs the reviewers, writes the
 #    merged body to $PIPE_RESULT_REVIEW and the verdict to review.env.
-pipe_run_claude review "/review-mr" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_REVIEW" < /dev/null
+pipe_run_agent review "/review-mr" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_REVIEW" < /dev/null
 
 # 5. Read the verdict the skill wrote (drives the status emoji), then post
 #    the review comment (token work). The emoji goes after the marker line,
@@ -63,18 +63,22 @@ REVIEW_HAS_BUGS=$(pipe_get_env "$REVIEW_ENV" REVIEW_HAS_BUGS); REVIEW_HAS_BUGS=$
 REVIEW_STATUS=$(pipe_get_env "$REVIEW_ENV" REVIEW_STATUS); REVIEW_STATUS=${REVIEW_STATUS:-clean}
 FINDINGS_TOTAL=$(pipe_get_env "$REVIEW_ENV" REVIEW_FINDINGS_TOTAL); FINDINGS_TOTAL=${FINDINGS_TOTAL:-0}
 
+REVIEW_COMMENT_FILE="$PIPE_CONTEXT_DIR/review-comment.md"
 if [ -s "$PIPE_RESULT_REVIEW" ]; then
   VERDICT_EMOJI="✅"
   [ "$REVIEW_HAS_BUGS" = "true" ] && VERDICT_EMOJI="❌"
-  BODY="$REVIEW_MARKER
-
-$VERDICT_EMOJI $(cat "$PIPE_RESULT_REVIEW")"
+  {
+    printf '%s\n\n%s ' "$REVIEW_MARKER" "$VERDICT_EMOJI"
+    cat "$PIPE_RESULT_REVIEW"
+  } > "$REVIEW_COMMENT_FILE"
 else
-  BODY="$REVIEW_MARKER
-
-⚠️ Review generation failed. Check the CI job log for details."
+  {
+    printf '%s\n\n⚠️ ' "$REVIEW_MARKER"
+    pipe_failure_notice_files "code review" "review this merge request by hand before approving it" \
+      "$PIPE_AGENT_STDERR" "$PIPE_RESULT_REVIEW"
+  } > "$REVIEW_COMMENT_FILE"
 fi
-platform_post_comment "$BODY"
+platform_post_comment_file "$REVIEW_COMMENT_FILE"
 
 # 6. Emit metrics.
 pipe_metric_event code-reviewer review_findings \

package/payload/ci-templates/scripts/test-fix.sh

@@ -26,7 +26,7 @@ COVERAGE_BEFORE=$(pipe_count_fix_commits "$PIPE_COMMIT_COVERAGE")
 #    case (tests | coverage | compile | none), caps, delegates to test-fix or
 #    test-writer, verifies, and writes fix-tests.env. On cap it runs the shared
 #    postmortem flow (writing postmortem.md + postmortem.env).
-pipe_run_claude test-fix "/fix-tests" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_CODE" < /dev/null
+pipe_run_agent test-fix "/fix-tests" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_CODE" < /dev/null
 
 # 4. Read the marker the skill wrote.
 FT_ENV="$PIPE_CONTEXT_DIR/fix-tests.env"
@@ -46,6 +46,13 @@ COMMIT_MADE=false
 # 5. Act on the outcome.
 if [ "$FIX_ESCALATE" = "true" ]; then
   pipe_log "Skill signalled escalation"
+  if pipe_is_credit_exhaustion_files "$PIPE_AGENT_STDERR"; then
+    COMMENT_FILE="$PIPE_CONTEXT_DIR/test-fix-credit-exhausted.md"
+    pipe_failure_notice_files "test fixes" "fix the failing tests by hand" \
+      "$PIPE_AGENT_STDERR" > "$COMMENT_FILE"
+    platform_post_comment_file "$COMMENT_FILE"
+    exit 0
+  fi
   pipe_apply_escalation "$CATEGORY" "test-fix"
 elif [ "$FIX_BRANCH" = "none" ]; then
   pipe_log "Nothing to fix (false-alarm trigger)"

package/payload/skills/agent-architect/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: agent-architect
+description: Analyze bounded recent delivery evidence for concrete improvements to shipped agent definitions. Used by the opt-in scheduled CI job; returns only the report whose proposal blocks the runner files as ready improvement issues.
+---
+
+# agent-architect
+
+This is the CI entry point for the shipped `agent-architect` subagent. The
+runner owns forge reads, label management, issue creation, and all marker
+files. Never call a forge API, create an issue, edit a file, commit, or push.
+
+## Inputs
+
+Read `$PIPE_CONTEXT_DIR/architect-context.md` first. It gives the bounded time
+window, current ready/improvement labels, merged MR/PR summaries with changed
+files and human review excerpts, stuck items, and already-open improvement
+issues. Treat that prepared evidence as authoritative input; do not expand it
+with forge calls or unbounded history scans.
+
+Read `$PIPE_CONFIG_PATH` (default `.claude/pipeline-config.md`) before making
+project-specific recommendations. If it is absent, say so in the report and
+stay conservative.
+
+## Analysis
+
+Spawn the shipped `agent-architect` subagent once. Give it the context-file
+path and require it to use the labels named in that context. It must inspect
+only the repository files needed to validate evidence-backed, surgical changes
+to `.claude/agents/*.md`.
+
+Keep its report verbatim. It must contain exactly one top-level heading,
+`## Section B - Agent Improvements`, and may contain no more than five complete
+`<!-- ISSUE-START -->` / `<!-- ISSUE-END -->` proposal blocks. A proposal needs
+a nonempty `Title: ` line of at most 72 characters and must cite the prepared
+MR/PR or stuck-item evidence. Do not return commentary before or after the
+report.
+
+When no concrete proposal meets that bar, return the heading followed by
+`No significant findings this week.`
+
+## Result
+
+Return only the subagent's markdown report. The runner persists it, bounds and
+parses complete proposal blocks, writes `architect.env`, and in non-dry runs
+creates the resulting issues with the configured ready and improvement labels.

package/payload/skills/codebase-audit/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: codebase-audit
+description: Produce the periodic codebase convention-drift audit report and, when requested, apply its documentation suggestions, in CI. In `audit` mode runs the codebase-auditor agent against a summary of recently merged MRs/PRs and open-audit dedup context, decides the finding status and count, and writes the report and doc-suggestions files plus a machine-readable marker for the pipeline to act on. In `apply-docs` mode runs the coder agent to apply the suggested documentation updates within the configured documentation roots and commits. Use this when a CI job asks to run the codebase audit or apply its documentation suggestions.
+---
+
+# codebase-audit
+
+Generic replacement for the prompt assembly and doc-suggestion extraction in `codebase-audit.sh`. The job runs `claude "/codebase-audit"` instead of building the auditor and coder prompts in bash. This skill does the reasoning; the runner keeps only the API reads that build the MR/PR summary, issue creation, and the push/MR-creation mechanics.
+
+## Step 1: read the project configuration
+
+Read the config file at `$PIPE_CONFIG_PATH` (default `.claude/pipeline-config.md`). In `audit` mode you need nothing from it directly: the `codebase-auditor` subagent reads it and its own Documentation Map itself. In `apply-docs` mode you need the Documentation Map, since the coder is restricted to `$PIPE_DOCS_ROOTS` and should map suggestions onto the right document. If the file is missing, say so on the first line of your output and continue with generic behavior.
+
+## Step 2: inputs
+
+Everything comes from CI variables and the files the job prepared. Do not call the platform API yourself, and never create the issue or the MR/PR — that is mechanical runner work, exactly like every other job in this plan.
+
+- `$PIPE_CONTEXT_DIR` (default `build/pipeline`): where the prepared context lives and where you write outputs.
+- `$PIPE_CONTEXT_DIR/audit-context.md`: the job wrote this, and rewrites it fresh before each invocation — the same path in both modes. Read it first; its `Mode:` line tells you which of the two flows below to run, and the rest of the file is that mode's own content only.
+- `$PIPE_LABEL_AUDIT` (default `codebase-audit`): the label the runner uses for audit issues and MRs/PRs; only relevant if you need to refer to it in your own output.
+- `$PIPE_DOCS_ROOTS` (default `docs,CLAUDE.md,.claude/memory`): comma-separated documentation roots, apply-docs mode only.
+- `$PIPE_COMMIT_AUDIT` (default `docs: apply convention audit findings`): the exact commit subject, apply-docs mode only.
+
+## Mode: audit
+
+The context file lists the recently merged MRs/PRs (with up to 10 changed file paths each) and, when any exist, the currently open audit-labeled issues as dedup context.
+
+### Step 3: run the codebase-auditor agent
+
+Spawn the `codebase-auditor` subagent once. Point it at `$PIPE_CONTEXT_DIR/audit-context.md` for the recently-merged-MR summary and the open-issue dedup context, and tell it to skip any finding already covered by an open issue. The agent reads the config, the documented conventions, and the changed files of each listed MR/PR itself, and returns its report as its final output, exactly the two sections defined in its own instructions (`## Critical violations` and `## Patterns worth documenting`, each either a confidence->=80 bullet list or the literal line `No significant findings.`). Do not restate its internal scoring rules in the prompt.
+
+### Step 4: decide the status and count the findings
+
+Take the agent's report text verbatim (no reformatting) and write it to `$PIPE_CONTEXT_DIR/audit-report.md`. Then decide:
+
+- The agent produced no output at all (empty or missing) -> `AUDIT_STATUS=no_output`, `AUDIT_FINDINGS_TOTAL=0`.
+- Otherwise, count the finding bullets: lines starting with `- **` across the whole report (`grep -c '^- \*\*'` is exactly the source convention; a report where neither section has findings has zero such lines because both say `No significant findings.`). Zero findings -> `AUDIT_STATUS=no_findings`. One or more -> `AUDIT_STATUS=ok`.
+
+### Step 5: extract the doc suggestions
+
+Always write `$PIPE_CONTEXT_DIR/audit-doc-suggestions.md`, even when it ends up empty. Its content is the bullet lines under the `## Patterns worth documenting` heading only (stop at the next `## ` heading or end of report), verbatim, or nothing when that section is `No significant findings.`. This file is what the runner checks to decide whether to attempt the `apply-docs` phase; do not fabricate a suggestion that is not literally a bullet in that section.
+
+### Step 6: emit the marker
+
+Write `$PIPE_CONTEXT_DIR/audit.env`:
+
+```
+AUDIT_STATUS=ok|no_output|no_findings
+AUDIT_FINDINGS_TOTAL=<int>
+AUDIT_REPORT_PATH=$PIPE_CONTEXT_DIR/audit-report.md
+```
+
+Do not write an `AUDIT_ISSUE_IID` line yourself: no issue exists yet at this point in the flow. The runner creates the issue after you return (only when `AUDIT_STATUS=ok`), captures its IID, and appends `AUDIT_ISSUE_IID=<iid>` to this same file so the artifact is complete when the job finishes. Always write all three lines above, including on `no_output` and `no_findings`, so the runner can branch reliably.
+
+## Mode: apply-docs
+
+The context file gives you the issue number, the documentation roots, the commit subject, and the paths of the doc-suggestions file and the full audit report the `audit`-mode invocation wrote. The repository is already checked out on the audit branch; git is local, no token needed.
+
+### Step 3: delegate to the coder
+
+Spawn the `coder` subagent. Tell it plainly:
+
+- it may edit ONLY paths under the documentation roots listed in the context file (each root is a directory or a single file) — no `src/`, no test code, no CI files, nothing else;
+- implement ONLY the suggested updates listed in the doc-suggestions file (read it itself), using the full audit report (read it itself) for context;
+- when done, commit with `git add -A && git commit` using EXACTLY the commit subject from the context file, followed by a blank line and `Closes #<issue number>` from the context file;
+- do NOT run `git push` — the runner handles pushing.
+
+Do not restate the coder's own internal workflow (documentation map lookup, verify command, etc.); those do not apply here since this is a documentation-only change.
+
+### Step 4: confirm the commit and emit the marker
+
+Run `git rev-list "origin/$PIPE_TARGET_BRANCH..HEAD" --count` to count the commits made this run. Write `$PIPE_CONTEXT_DIR/audit-apply.env`:
+
+```
+AUDIT_APPLY_COMMITS=<integer count of commits this run>
+```
+
+Zero means the coder made no changes (no suggestion turned out actionable, or it got stuck); do not draft anything else in that case, the runner handles the no-commits path.
+
+## What the CI job does after you
+
+In `audit` mode: the runner reads `audit.env`. On `no_output` it logs a failure notice (no issue exists yet to post to). On `no_findings` it stops, nothing filed. On `ok` it creates the findings issue from `audit-report.md` (truncated, with the `audited-up-to-mr-iid` marker prepended) labeled `$PIPE_LABEL_AUDIT`, appends the issue IID to `audit.env`, and emits a metric. It then skips the `apply-docs` phase entirely when there is no push-capable identity configured, or when `audit-doc-suggestions.md` is empty.
+
+Otherwise it creates and checks out the `audit-<date>` branch and runs you again in `apply-docs` mode. It reads `audit-apply.env`, recounts the commits itself as the authoritative gate: with zero commits it posts a manual-review notice to the issue (with an extra credit-exhaustion note when that applies) and deletes the branch; otherwise it pushes the branch and opens an MR/PR titled `docs: codebase audit updates (<date>)` that closes the issue, labeled `$PIPE_LABEL_AUDIT`. None of that is your job.

package/payload/skills/cve-fix/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: cve-fix
+description: Safely update one configured dependency manifest for HIGH/CRITICAL vulnerability identifiers supplied by a CI scanner, compile it, make at most one commit, and emit a CVE remediation marker. Use only when the cve-fix CI runner has prepared its context.
+---
+
+# cve-fix
+
+`cve-fix` is a code-writing skill called by the CI runner. It does not scan
+projects, choose a vulnerability scanner, or filter severities: that stays
+outside this skill. The caller supplies the already selected HIGH/CRITICAL
+identifier list through `PIPE_CVE_LIST` and the runner context.
+
+The runner owns MR/PR API access, rebase, push, and comments. Never do any of
+those things yourself.
+
+## Inputs and hard boundary
+
+Read exactly one prepared context first:
+
+- `$PIPE_CONTEXT_DIR/cve-fix-context.md` (default context directory is
+  `build/pipeline`).
+
+It names the vulnerability-list file, configured dependency manifest path,
+manifest-content file, compile command, exact commit subject, source and target
+branches, suppression path, remaining commit budget, and marker path. Read the
+named list and manifest-content files; do not independently run a scanner,
+inspect scanner output, or expand the scope from repository search results.
+
+Validate before editing:
+
+- `Mode:` must be `apply`.
+- The list must contain at least one non-blank identifier.
+- The manifest path must be present and the corresponding file must exist.
+- Source branch, target branch, commit subject, compile command, and remaining
+  commit budget must be present.
+- The remaining budget must be a positive integer. A proposed change that would
+  exceed it must not be made.
+
+If any validation fails, make no edit and no commit. Write the marker described
+below with `CVE_MANUAL_REQUIRED=1`.
+
+Only the configured dependency manifest may be changed. Do not modify the
+vulnerability list, scanner output, configured suppression path, CI files,
+source code, tests, lockfiles, generated files, or any other dependency
+manifest. Do not use a project-specific ecosystem, build tool, package name,
+or version as an assumption.
+
+## Remediation
+
+Use the shipped `coder` agent to reason from only the supplied vulnerability
+list and manifest content. It must identify updates that are explicit and safe
+in that manifest. Do not guess a package/version, edit a BOM or indirect
+configuration outside the configured file, or make a change when the affected
+dependency cannot be identified safely.
+
+When a safe update is available:
+
+1. Edit only the configured dependency manifest.
+2. Run the supplied compile command exactly as configured.
+3. If compilation succeeds, create at most one commit, using the exact supplied
+   subject and staging only that configured manifest.
+4. Never push, rebase, post a comment, use a forge API, or change branches.
+
+A failed compile, an unavailable safe update, a missing input, or uncertain
+mapping from an identifier to a manifest dependency requires no commit and
+manual follow-up.
+
+## Marker
+
+Always write `$PIPE_CONTEXT_DIR/cve-fix.env` (or the `Marker File:` path from
+the context) as exactly these four newline-separated keys, with no other keys:
+
+```dotenv
+CVE_FIX_APPLIED=0|1
+CVE_COMPILED=0|1
+CVE_COUNT=<non-negative integer>
+CVE_MANUAL_REQUIRED=0|1
+```
+
+`CVE_COUNT` is the number of non-blank vulnerability identifiers read from the
+supplied list. `CVE_FIX_APPLIED=1` only after a real new commit with the exact
+provided subject exists. `CVE_COMPILED=1` only after the supplied compile
+command completed successfully. `CVE_MANUAL_REQUIRED=1` when no safe update is
+available, required metadata is missing, validation fails, or compilation does
+not pass. Do not claim a commit or compilation solely because an agent returned
+successfully.
+
+For a successful remediation the marker is:
+
+```dotenv
+CVE_FIX_APPLIED=1
+CVE_COMPILED=1
+CVE_COUNT=<count>
+CVE_MANUAL_REQUIRED=0
+```
+
+The runner independently validates the marker, commit, compilation, rebase,
+and push before it reports success.

package/payload/skills/docs-sync/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: docs-sync
+description: Check whether the code changes of a merge request or pull request require documentation updates, in CI. Runs the docs-sync agent, which applies the updates on an autonomous MR/PR and reports the gaps on a human-authored one, then emits the comment body and a machine-readable marker for the pipeline to act on. Use this when a CI job asks to sync documentation for an MR/PR.
+---
+
+# docs-sync
+
+Generic replacement for the prompt assembly in `docs-sync.sh`. The CI job runs the harness with `/docs-sync` instead of building a long prompt in bash. This skill does the reasoning. The runner keeps only the API read that classifies the MR/PR, the diff computation, posting the comment, and committing the documentation edits.
+
+## Step 1: read the project configuration
+
+Read the config file at `$PIPE_CONFIG_PATH` (default `.claude/pipeline-config.md`). From it you need the Project stack, the Git & Platform section, and above all the Documentation Map, which says which document covers which topic. If the file is missing, say so on the first line of your output and continue with generic behavior: treat the documentation roots as the whole map.
+
+## Step 2: inputs
+
+Everything comes from CI variables and the files the job prepared. Do not call the platform API yourself, and do not run `git` to recompute the diff: the runner already scoped it.
+
+- `$PIPE_CONTEXT_DIR` (default `build/pipeline`): where the prepared context lives and where you write outputs.
+- `$PIPE_CONTEXT_DIR/docs-sync-context.md`: the mode, the MR/PR title, the documentation roots, and the paths of the two files below. Read it first.
+- `$PIPE_CONTEXT_DIR/docs-sync-files.txt`: the changed files of the whole MR/PR.
+- `$PIPE_CONTEXT_DIR/docs-sync-diff.patch`: the full `base..head` diff. It is never an incremental slice, so a gap introduced by an earlier push is still in front of you.
+- `$PIPE_DOCS_ROOTS` (default `docs,CLAUDE.md,.claude/memory`): comma-separated documentation roots. These are the only paths that may be edited.
+- `$PIPE_RESULT_DOCSSYNC` (default `$PIPE_CONTEXT_DIR/docs-sync.json`): where the result JSON goes.
+
+The `Mode:` line of the context file is one of:
+
+- `apply`: an autonomous MR/PR. The documentation updates are applied by editing files under the documentation roots.
+- `report`: a human-authored MR/PR, or an autonomous one whose tip is already an automated docs commit. Gaps are reported and nothing is edited.
+
+## Step 3: run the docs-sync agent
+
+Spawn the `docs-sync` subagent once. Pass it:
+
+- the mode and what it means (apply the updates by editing files under the documentation roots, or report the gaps without editing anything),
+- the MR/PR title,
+- the paths of the changed-files list and the diff, so it reads them itself rather than receiving them inline,
+- the documentation roots it may edit, and the instruction that production source, tests and CI files are out of bounds and that it must not run `git`,
+- the result file path, which is `$PIPE_RESULT_DOCSSYNC`.
+
+The agent reads the config, the Documentation Map and the documents it needs itself, and applies its own documentation threshold. Do not restate its internal rules in the prompt, and do not preload documents into it.
+
+## Step 4: check the boundary
+
+Before you emit anything, verify the agent stayed inside the documentation roots. Any edit outside them is out of scope: revert it, and say so in the comment body. The runner stages and commits the documentation roots before it discards any remaining out-of-scope working-tree changes, so leaving an out-of-scope edit in place only loses the agent's own work.
+
+In `report` mode nothing may be edited at all. If the agent edited a file anyway, revert every edit and report the gaps as text.
+
+## Step 5: emit the result and the marker
+
+The result JSON is the agent's own output; the body file and the dotenv are yours. If the agent wrote no result file, or wrote one that is not valid JSON with a `comment` string, rewrite it yourself from what the agent reported.
+
+`$PIPE_RESULT_DOCSSYNC` (default `$PIPE_CONTEXT_DIR/docs-sync.json`):
+
+```json
+{"has_gaps": true, "changed": true, "comment": "**Status: blocking**\n\n- **docs/X.md**: Added the section for the Y pattern introduced here"}
+```
+
+`$PIPE_CONTEXT_DIR/docs-sync-body.md`: the value of `comment` as plain markdown, and nothing else. This is what gets posted, so the runner never has to parse a model-written JSON file. Its first line is the status line, exactly one of `**Status: blocking**`, `**Status: non-blocking**`, `**Status: clean**`, followed by a flat bullet list of findings, blocking items first. Each bullet names the document and describes in one sentence what is missing, or what you added in `apply` mode. No section headers, no prose around the list. When the documentation is up to date the body is exactly the status line `**Status: clean**`.
+
+`$PIPE_CONTEXT_DIR/docs-sync.env`:
+
+```
+DOCS_HAS_GAPS=true|false
+DOCS_CHANGED=true|false
+DOCS_COMMENT_PATH=<path of the body file>
+```
+
+`DOCS_HAS_GAPS` is `true` only when at least one actionable gap was found; informational notes alone keep it `false`. `DOCS_CHANGED` is `true` only when you left an edit on disk, which can only happen in `apply` mode. `DOCS_COMMENT_PATH` is the absolute or repository-relative path of the body file you wrote.
+
+Always write all three, including on a clean verdict. A missing body file is how the runner detects that the agent did not complete, and it then posts a manual-review notice instead of your verdict.
+
+## What the CI job does after you
+
+The runner reads `docs-sync.env`, posts the body as the MR/PR comment behind its own marker line, and emits the metrics event. In `apply` mode it stages the documentation roots and commits with `$PIPE_COMMIT_DOCSSYNC` only when their staged diff is non-empty; `DOCS_CHANGED` only reports whether the skill left an edit on disk. It then discards anything you left outside those roots, rebases and pushes. It never asks you to run `git`. None of that is your job.

package/payload/skills/e2e-test-gen/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: e2e-test-gen
+description: Generate or repair one focused E2E test for a runner-selected issue, using the project's configured E2E conventions. This deliberately implements only issue-driven generation; project-specific test-gap detection is intentionally omitted.
+---
+
+# e2e-test-gen
+
+`e2e-test-gen` is the issue-driven half of generic E2E generation. It
+**deliberately omits test-gap detection**: scanner-like source/package heuristics
+are project-specific and are not a missing capability to restore.
+
+The CI runner owns the branch, git identity, commits, push, issue labels,
+comments, and MR/PR creation. Never perform any of those actions. Do not call a
+forge API.
+
+## Read inputs before editing
+
+Read `$PIPE_CONTEXT_DIR/e2e-gen-issue-<IID>.md` for the runner context. Its
+`Mode:` is either `generate` or `repair`; in repair mode it names the only file
+that may be edited. Then read the project pipeline configuration at the
+context's `Project Configuration:` path and its **E2E Tests** section.
+
+Before any edit, require all of these configuration values to be explicit:
+
+- E2E framework;
+- configured test directory, matching the runner context;
+- fixture import module;
+- test-data prefix;
+- required tags; and
+- base URL, matching the runner context.
+
+If the E2E Tests section is absent, says E2E is unused, or any required value is
+missing, make no edit. Do not infer a framework, fixtures, credentials, command,
+or base URL.
+
+## Generate mode
+
+1. Read the bounded title and description files named in the context.
+2. Read the existing fixture and one or two nearby tests to follow the project's
+   conventions, selectors, data cleanup, and tags.
+3. Use the shipped `e2e-test-writer` agent to draft one focused scenario.
+4. Write exactly one new test file beneath the configured test directory. Do not
+   modify production code, configuration, fixtures, helpers, existing tests, or
+   files outside that directory.
+5. Use the fixture module, data prefix, required tags, and cleanup convention
+   from the E2E Tests section. Do not expose credentials or invent test data
+   outside the configured prefix.
+
+## Repair mode
+
+Read the named generated test and the relevant existing test/fixture convention.
+Edit only that named generated test to address the failed verification. Do not
+create files or change any other file.
+
+## Result
+
+Return a marker-readable final line only after a file was actually written:
+
+```text
+E2E_TEST_WRITTEN=<project-relative path>
+```
+
+In repair mode `<project-relative path>` must be the named generated test. This
+line is a result for the runner to read; it does not authorize git, forge, or
+label operations.

package/payload/skills/fix-review-findings/SKILL.md

@@ -17,7 +17,7 @@ Read `$PIPE_CONFIG_PATH` (default `.claude/pipeline-config.md`). You need the Gi
 - `$PIPE_VERIFY_CMD`: verification command (compile plus unit tests) to run after a fix.
 - `$PIPE_FIX_LOOP_CAP` (default `2`): maximum consecutive review-fix commits before escalating.
 - `$PIPE_COMMIT_REVIEWFIX`: exact commit subject for a review fix. Its recurrence drives the cap count.
-- `$PIPE_TARGET_BRANCH`: the branch the MR/PR targets, used as the base for the commit-history walk.
+- `$PIPE_COMMIT_DOCSSYNC`: exact docs-sync commit subject. Ignore this subject while walking the fix streak so a documentation commit does not reset the cap.
 - `$PIPE_RESULT_REVIEWFIX` (default `$PIPE_CONTEXT_DIR/review-fix-result.json`): where the coder writes its structured result.
 - `$PIPE_CONTEXT_DIR` (default `build/pipeline`): where you write the result marker.
 
@@ -29,7 +29,7 @@ Count consecutive commits from the branch tip back toward `$PIPE_TARGET_BRANCH`
 git log "origin/$PIPE_TARGET_BRANCH"..HEAD --format="%s"
 ```
 
-Stop at the first non-matching subject. If the count is at or above `$PIPE_FIX_LOOP_CAP`, do not attempt another fix. Escalate: follow the postmortem-mr flow (spawn the `postmortem` agent with the review body as the failure text, the fix-attempt git log, and the changed files, then read `failure_category`). Write the marker with `RF_ESCALATE=true` and the `FAILURE_CATEGORY`, and stop.
+Walk the subjects in order. Increment the count only when a subject exactly equals `$PIPE_COMMIT_REVIEWFIX`. If a subject exactly equals `$PIPE_COMMIT_DOCSSYNC`, ignore it and continue walking. Stop at every other subject. If the count is at or above `$PIPE_FIX_LOOP_CAP`, do not attempt another fix. Escalate: follow the postmortem-mr flow (spawn the `postmortem` agent with the review body as the failure text, the fix-attempt git log, and the changed files, then read `failure_category`). Write the marker with `RF_ESCALATE=true` and the `FAILURE_CATEGORY`, and stop.
 
 ## Step 4: gather prior attempts
 
@@ -41,7 +41,7 @@ git log "origin/$PIPE_TARGET_BRANCH"..HEAD --grep="$PIPE_COMMIT_REVIEWFIX" -p
 
 ## Step 5: delegate to the coder
 
-Spawn the `coder` agent (Agent tool, `subagent_type: coder`). Pass it:
+Spawn the `coder` subagent. Pass it:
 
 - the review findings from `$PIPE_CONTEXT_DIR/review-body.md`,
 - the prior fix diffs from step 4, if any, with the instruction not to repeat those approaches,

package/payload/skills/fix-tests/SKILL.md

@@ -20,7 +20,7 @@ Read `$PIPE_CONFIG_PATH` (default `.claude/pipeline-config.md`). You need the Bu
 - `$PIPE_FIX_LOOP_CAP` (default `2`): maximum consecutive bot fix commits before escalating.
 - `$PIPE_COMMIT_TESTFIX`: exact commit subject for a test fix. Its recurrence drives the cap count.
 - `$PIPE_COMMIT_COVERAGE`: exact commit subject for a coverage-tests commit. Separate cap counter.
-- `$PIPE_TARGET_BRANCH`: the branch the MR/PR targets, used as the base for the commit-history walk.
+- `$PIPE_COMMIT_DOCSSYNC`: exact docs-sync commit subject. Ignore this subject while walking either fix streak so a documentation commit does not reset the cap.
 - `$PIPE_CONTEXT_DIR` (default `build/pipeline`): where you write the result marker.
 
 ## Step 3: pick the case
@@ -40,12 +40,12 @@ Count consecutive commits from the branch tip back toward `$PIPE_TARGET_BRANCH`
 git log "origin/$PIPE_TARGET_BRANCH"..HEAD --format="%s"
 ```
 
-Stop counting at the first subject that does not match. If the count is at or above `$PIPE_FIX_LOOP_CAP`, do not attempt another fix. Escalate instead: follow the postmortem-mr flow (spawn the `postmortem` agent with the failure text, the fix-attempt git log, and the changed files, then read `failure_category` from its report). Write the marker with `FIX_ESCALATE=true` and the `FAILURE_CATEGORY`, and stop. The job applies the stuck label and posts the diagnostic.
+Walk the subjects in order. Increment the count only when a subject exactly equals the relevant fix subject. If a subject exactly equals `$PIPE_COMMIT_DOCSSYNC`, ignore it and continue walking. Stop at every other subject. If the count is at or above `$PIPE_FIX_LOOP_CAP`, do not attempt another fix. Escalate instead: follow the postmortem-mr flow (spawn the `postmortem` agent with the failure text, the fix-attempt git log, and the changed files, then read `failure_category` from its report). Write the marker with `FIX_ESCALATE=true` and the `FAILURE_CATEGORY`, and stop. The job applies the stuck label and posts the diagnostic.
 
 ## Step 5: delegate
 
-- **Test-fix and compilation cases**: spawn the `test-fix` agent (Agent tool, `subagent_type: test-fix`). Pass the failure details (test failures or the compilation output) and the exact commit subject `$PIPE_COMMIT_TESTFIX`. The agent reads the config and the testing document itself, fixes the root cause in the implementation or the test, and commits.
-- **Coverage case**: spawn the `test-writer` agent (`subagent_type: test-writer`). Pass the baseline and current coverage, the diff of new code (`git diff "origin/$PIPE_TARGET_BRANCH"..HEAD` scoped to source files), and the exact commit subject `$PIPE_COMMIT_COVERAGE`.
+- **Test-fix and compilation cases**: spawn the `test-fix` subagent. Pass the failure details (test failures or the compilation output) and the exact commit subject `$PIPE_COMMIT_TESTFIX`. The agent reads the config and the testing document itself, fixes the root cause in the implementation or the test, and commits.
+- **Coverage case**: spawn the `test-writer` subagent. Pass the baseline and current coverage, the diff of new code (`git diff "origin/$PIPE_TARGET_BRANCH"..HEAD` scoped to source files), and the exact commit subject `$PIPE_COMMIT_COVERAGE`.
 
 Tell the agent the commit subject must be exactly the value above, because the cap counter matches on it. Tell it not to run `git push`.
 

package/payload/skills/implement-issue/SKILL.md

@@ -22,7 +22,7 @@ The repository is already checked out on the feature branch. Git is local, no to
 
 ## Step 3: delegate to the coder
 
-Spawn the `coder` agent (Agent tool, `subagent_type: coder`) with the issue IID, title, and description from the context file, instructing it to implement the issue. The coder reads the config and the Documentation Map itself, explores existing patterns, implements, writes tests through the test-writer agent, runs the project verify command in a self-correcting loop, and commits. Do not restate its internal rules.
+Spawn the `coder` subagent with the issue IID, title, and description from the context file, instructing it to implement the issue. The coder reads the config and the Documentation Map itself, explores existing patterns, implements, writes tests through the test-writer agent, runs the project verify command in a self-correcting loop, and commits. Do not restate its internal rules.
 
 The coder must NOT push. Pushing is the runner's job. After the coder returns, confirm no push happened: the coder has no push step, but if the working tree or branch state shows an attempted push, note it in your output. The commits stay local for the runner to push.
 

package/payload/skills/init-pipeline-config/SKILL.md

@@ -37,7 +37,7 @@ Source paths: `<root>` below means the first candidate that actually contains `t
 
 Do not hand the user a homework list. Walk them through it:
 
-1. Start with one confirmation of the detected basics in a single question: "The pipeline will target branch `<detected>` on `<platform>`. Correct?" Detected values are proposals to confirm, never open questions.
+1. Start with one confirmation of the detected basics: "The pipeline will target branch `<detected>` on `<platform>`. Correct?" Detected values are proposals to confirm, never open questions. When the detected platform is GitLab, ask in the same message which harness to run: Claude Code (default, needs `ANTHROPIC_API_KEY`) or omp + OpenRouter (needs `OPENROUTER_API_KEY` and accepts any OpenRouter model). Record the answer as `PIPE_HARNESS` (`claude` or `omp`). When the detected platform is GitHub, record `PIPE_HARNESS=claude`, state that omp and OpenRouter support is not shipped for GitHub yet, and do not offer omp as an option.
 2. Split the remaining `TODO`s into two groups. **Defaultable:** the repo gives a defensible answer (coverage tooling absent means the policy is `not used`, Domain Check candidates read from the code, standard paths). Apply these without asking and keep them for the summary in step 4. **Genuinely open:** the repo gives no signal at all (a convention nobody wrote down, a check only a human knows about). Only these earn a question. Branch naming is not a question: with no repository convention use `<issue-iid>-<kebab-title>`, which is exactly what the runner accepts.
 3. Ask one scheduling question because frequency is a project policy, not a detectable technical fact: should the issue loop stay manual/disabled, run nightly on selected days, or use a custom cron? Recommend manual/disabled until both smoke tests pass. For a schedule, record days, local time, and time zone. Convert to UTC only for GitHub Actions; GitLab stores the chosen cron time zone. Then ask the other genuinely open items one concrete question at a time, in config order, each with a suggested default when possible. In a typical repo this is one to three questions total. Do not ask for the bot account username: the runner resolves it from the token at runtime (`platform_resolve_bot_user`); the account itself gets created with the token in phase 4. Apply each answer to the config immediately; the user never edits the file by hand during this phase.
 4. Close with one review summary of everything that was set: detected, defaulted, and answered, with the applied Domain Checks listed item by item. Invite the user to add, remove, or change anything; apply the edits. This summary is the safety net that lets steps 2-3 default aggressively.
@@ -50,7 +50,7 @@ Do this yourself; it is mechanical. The human only approves the diff. When the `
 **GitLab** (detected in phase 1):
 
 1. Create `.claude-pipeline/` and copy `<root>/ci-templates/claude-pipeline.gitlab-ci.yml` and `<root>/ci-templates/scripts/` into it.
-2. Edit the project `.gitlab-ci.yml`: ensure the stages the template needs (`orchestrate, code, test, review`), add the `include:` of the vendored template, and add the non-secret `PIPE_*` values from the config that differ from the template defaults (typically `PIPE_VERIFY_CMD`, `PIPE_TEST_REPORT_GLOB`) as top-level `variables:`. Always write `PIPE_TARGET_BRANCH` with the branch detected in phase 1, as a literal: a nested `$CI_DEFAULT_BRANCH` is not expanded inside `rules:` comparisons and would silently disable every MR job (E2E finding N-3). You know the values since phase 1; wiring them now keeps phase 4 free of commits. Do not touch the project's own jobs without asking.
+2. Edit the project `.gitlab-ci.yml`: ensure the stages the template needs (`orchestrate, code, test, review`), add the `include:` of the vendored template, and add the non-secret `PIPE_*` values from the config that differ from the template defaults (typically `PIPE_VERIFY_CMD`, `PIPE_TEST_REPORT_GLOB`) as top-level `variables:`. Always write `PIPE_TARGET_BRANCH` with the branch detected in phase 1, as a literal: a nested `$CI_DEFAULT_BRANCH` is not expanded inside `rules:` comparisons and would silently disable every MR job (E2E finding N-3). You know the values since phase 1; wiring them now keeps phase 4 free of commits. Do not touch the project's own jobs without asking. When phase 2 chose `omp`, add `PIPE_HARNESS: "omp"` to that same `variables:` block (the template default is `claude`).
 3. Check the project's own test job: when neither its `rules:` nor a `workflow:` block makes it run in `merge_request_event` pipelines, the template's `test-fix` job can never fire (its `needs: test` finds no test job in the MR pipeline, E2E finding N-4). Tell the user and offer a concrete diff that adds the missing rule. Apply it only after they agree.
 4. Copy `<root>/templates/spec-issue.template.md` to `.gitlab/issue_templates/Spec.md` (or the path the user chose in phase 2). When that file already exists, show the diff and ask before replacing it. An issue template is project-owned content, and the ground rule above covers the config and the CI file by name, so this one has to be said explicitly.
 
@@ -75,7 +75,7 @@ Never take the values. And never dump the whole checklist at once: this phase is
 
 The steps, in this order (GitLab has 7, GitHub 6, number the counter accordingly):
 
-1. `ANTHROPIC_API_KEY`: where to create it, set as a masked CI variable (GitLab: Settings > CI/CD > Variables, not protected when MR pipelines run from unprotected branches; GitHub: repository secret).
+1. The model credential for the platform and chosen harness. For GitHub, guide only `ANTHROPIC_API_KEY` (https://console.anthropic.com/settings/keys) as a repository secret. For GitLab with Claude Code, guide `ANTHROPIC_API_KEY` as a masked CI variable. For GitLab with omp, guide `OPENROUTER_API_KEY` (https://openrouter.ai/settings/keys) as a masked CI variable. GitLab model credentials must not be protected when MR pipelines run from unprotected branches.
 2. `PIPE_BOT_TOKEN`: GitLab project access token with `api` + `write_repository`, masked and hidden but not protected when ordinary unprotected feature branches need MR review/fix jobs; GitHub PAT with issues, contents, pull-requests and Actions write. Explain that protected GitLab variables work only when the project's protected-MR conditions are satisfied.
 3. GitLab only: `PIPE_TRIGGER_TOKEN` (Settings > CI/CD > Pipeline trigger tokens) for the orchestrate-to-code dispatch.
 4. The non-secret `PIPE_*` variables that differ from the defaults: these were already wired into the CI file in phase 3, so this step is normally a one-line "already wired, skipping". Only when something changed during phase 4 edit the CI file again (part of the walkthrough, no extra approval beyond showing the diff).
@@ -91,6 +91,6 @@ The smoke tests are the last step and the wizard drives them. The review smoke r
 
 1. Announce it in one line and prepare it: a branch named by the phase 2 convention, one small harmless change, an MR/PR against the target branch carrying the wip label. Then ask the one question of this phase: confirm the push plus MR/PR creation (ground rule: never push silently). One yes covers both. On GitLab without `glab`, create the MR with git push options (`git push -o merge_request.create -o merge_request.target=<target> -o merge_request.label=<wip label> origin <branch>`), no token or CLI needed. When no `merge_request_event` pipeline appears within about a minute of the MR existing, create it yourself with `POST /projects/:id/merge_requests/:iid/pipelines` (the bot token is set by phase 4). On GitHub without `gh`, push and print the compare URL for the user to open the PR.
 2. Check the run yourself with a single status query (`glab ci status` / `gh run list` for the run), or one short bounded wait, then report. Do not launch a blind polling loop that blocks for many minutes. If the jobs have not started or finished yet, say so and give the user the one command to re-check, rather than waiting them out. Scheduled pipelines and crons are best-effort and can lag by minutes, so an unstarted scheduled run is expected, not a failure. Expect, once it runs: the `review` job runs, a review comment from the bot account appears on the MR/PR, `review.env` and a metrics JSON land in `$PIPE_CONTEXT_DIR`. Report the result with a link to the MR/PR and the bot comment.
-3. On failure, read the job log yourself and say what is wrong and what to change. The common causes are a missing `ANTHROPIC_API_KEY`, a `PIPE_BOT_TOKEN` without comment/write scope, and an explicitly set `PIPE_BOT_USER` not matching the token's account (leave it unset; the runner resolves it from the token).
+3. On failure, read the job log yourself and say what is wrong and what to change. The common causes are a missing credential for the selected harness (`ANTHROPIC_API_KEY` or `OPENROUTER_API_KEY`), a `PIPE_BOT_TOKEN` without comment/write scope, and an explicitly set `PIPE_BOT_USER` not matching the token's account (leave it unset; the runner resolves it from the token).
 4. After the review smoke test passes, offer a separate end-to-end issue-loop smoke test. This is the only test that proves issue -> triage -> code -> MR/PR rather than only the review half, so it is worth running. Run it only after explicit approval, then watch it through MR/PR creation. Steps: create one small issue whose full spec sits in the issue DESCRIPTION following `spec-issue.template.md` (a spec pasted into a comment does not count, the pipeline reads the spec from the description), apply the ready label, then start orchestrate IMMEDIATELY with a manual run rather than a schedule. On GitLab that is Run pipeline on the target branch with variable `PIPE_ORCHESTRATE=1` (pipeline source `web`, which the orchestrate rule already allows), on GitHub the `workflow_dispatch` of the issue pipeline. Do not set up a cron schedule for this test. A cron is only for ongoing autonomy later and adds minutes of best-effort delay, while the manual run starts within seconds. It spends another triage plus coder run, pushes a feature branch, and opens an MR/PR.
 5. Close with the final recap, one table: every setting that matters (target branch, branch convention, labels, verify command, report path, image, caps, models, schedule), its value, and its origin (detected / default / answered). Under the table, state what was committed and pushed, both smoke-test results (or `not run`), and whether the issue schedule is active or manual. End with a clear "done": the user must never have to ask what state the repo is in.

package/payload/skills/postmortem-mr/SKILL.md

@@ -25,7 +25,7 @@ The changed-file list is available locally from `git diff --name-only "origin/$P
 
 ## Step 3: run the postmortem agent
 
-Spawn the `postmortem` agent (Agent tool, `subagent_type: postmortem`). Pass the MR/PR meta, the changed files, the fix-attempt git log, the original failure text, and the context label. The agent reads the config itself and produces the structured report, which includes the mandatory line:
+Spawn the `postmortem` subagent. Pass the MR/PR meta, the changed files, the fix-attempt git log, the original failure text, and the context label. The agent reads the config itself and produces the structured report, which includes the mandatory line:
 
 ```
 failure_category: <category>

package/payload/skills/review-mr/SKILL.md

@@ -33,7 +33,7 @@ When `$PIPE_IS_INCREMENTAL` is `true`, the diff is only what changed since the p
 
 ## Step 4: run the code-reviewer
 
-Spawn the `code-reviewer` agent (Agent tool, `subagent_type: code-reviewer`). Pass it:
+Spawn the `code-reviewer` subagent. Pass it:
 
 - the MR/PR intent (title, description, linked issues) from the context file,
 - the scope note (incremental or initial),

package/payload/skills/triage-issue/SKILL.md

@@ -22,7 +22,7 @@ Everything comes from CI variables and a context file the job prepared with the
 
 ## Step 3: run the orchestrator
 
-Spawn the `orchestrator` agent (Agent tool, `subagent_type: orchestrator`). Pass it the issue context (IID, title, description, comments) from the context file. The orchestrator reads the config, applies the spec-structure check and the capacity heuristic itself, and returns valid JSON, exactly one of:
+Spawn the `orchestrator` subagent. Pass it the issue context (IID, title, description, comments) from the context file. The orchestrator reads the config, applies the spec-structure check and the capacity heuristic itself, and returns valid JSON, exactly one of:
 
 - `{"actionable":true,"branch":"IID-kebab-title"}`: right-sized, ready to implement.
 - `{"actionable":true,"scope":"too_large","decomposition":"short paragraph"}`: clear but too big.
@@ -32,7 +32,7 @@ Do not restate the orchestrator's internal rules in the prompt.
 
 ## Step 4: decompose when too large
 
-Only when the orchestrator returned `scope:"too_large"`, spawn the `decomposer` agent (Agent tool, `subagent_type: decomposer`). Pass it the parent issue (IID, title, description, comments) and tell it the spec template path is `$PIPE_SPEC_TEMPLATE_PATH`. It reads the template and the config itself and returns JSON:
+Only when the orchestrator returned `scope:"too_large"`, spawn the `decomposer` subagent. Pass it the parent issue (IID, title, description, comments) and tell it the spec template path is `$PIPE_SPEC_TEMPLATE_PATH`. It reads the template and the config itself and returns JSON:
 
 ```
 {"confidence":"high|low","reason":"...","sub_issues":[{"key":"a","title":"...","spec_markdown":"...","depends_on":[]}]}

package/payload/templates/memory-index.template.md

@@ -0,0 +1,34 @@
+# Memory index
+
+<!-- Created by the ci-agent-platform install. This is tier 3 of a three-tier
+     information architecture:
+       CLAUDE.md          hardwired instructions, an index into the tiers below
+       docs/              long-term patterns, how-tos, architecture
+       .claude/memory/    active project state and cross-agent signals
+
+     Keep this file an index. Each entry is one line: the file, and what an
+     agent learns from it. Files here are project-owned. The installer never
+     rewrites them. -->
+
+## Feedback signals
+
+<!-- One file per lesson the pipeline taught the project, named
+     feedback_<topic>.md. Written after a postmortem or a repeated review
+     finding, read by the agents whose work it constrains. -->
+(none yet)
+
+## Project state
+
+<!-- One file per moving part whose current status agents need, named
+     project_<topic>.md. -->
+(none yet)
+
+## Reference
+
+<!-- Lookup tables that would otherwise be re-derived every run, named
+     reference_<topic>.md. -->
+(none yet)
+
+## Review suppressions
+
+- `review_suppressions.md` - patterns the reviewers must not flag, with the reason and the date. Read by every reviewer agent before it reports anything.