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

package/payload/ci-templates/scripts/lib/pipeline-common.sh

@@ -9,6 +9,8 @@ set -u
 SCRIPT_LIB_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 # shellcheck source=./usage-capture.sh
 source "$SCRIPT_LIB_DIR/usage-capture.sh"
+# shellcheck source=./usage-capture-omp.sh
+source "$SCRIPT_LIB_DIR/usage-capture-omp.sh"
 # shellcheck source=./platform.sh
 source "$SCRIPT_LIB_DIR/platform.sh"
 
@@ -27,9 +29,18 @@ pipe_defaults() {
   : "${PIPE_FIX_LOOP_CAP:=2}"
   : "${PIPE_CODER_CAP:=3}"
   : "${PIPE_ISSUE_SCAN:=20}"
-  : "${PIPE_MODEL_TRIAGE:=haiku}"
-  : "${PIPE_MODEL_CODE:=sonnet}"
-  : "${PIPE_MODEL_REVIEW:=sonnet}"
+  : "${PIPE_HARNESS:=claude}"
+  # Model defaults track the active harness. Each PIPE_MODEL_* variable remains
+  # explicitly overridable.
+  if [ "$PIPE_HARNESS" = "omp" ]; then
+    : "${PIPE_MODEL_TRIAGE:=openrouter/anthropic/claude-haiku-4-5}"
+    : "${PIPE_MODEL_CODE:=openrouter/anthropic/claude-sonnet-5-0}"
+    : "${PIPE_MODEL_REVIEW:=openrouter/anthropic/claude-sonnet-5-0}"
+  else
+    : "${PIPE_MODEL_TRIAGE:=haiku}"
+    : "${PIPE_MODEL_CODE:=claude-sonnet-5-0}"
+    : "${PIPE_MODEL_REVIEW:=claude-sonnet-5-0}"
+  fi
   : "${PIPE_COMMIT_TESTFIX:=Fix test errors}"
   : "${PIPE_COMMIT_REVIEWFIX:=Fix review findings}"
   : "${PIPE_COMMIT_COVERAGE:=Add coverage tests}"
@@ -64,7 +75,7 @@ pipe_defaults() {
     PIPE_LABEL_STUCK PIPE_LABEL_BLOCKER PIPE_LABEL_BLOCKED PIPE_LABEL_DECOMPOSED \
     PIPE_RESULT_REVIEW PIPE_RESULT_REVIEWFIX PIPE_VERIFY_CMD PIPE_COMPILE_CMD \
     PIPE_TEST_REPORT_GLOB PIPE_COVERAGE_SIGNAL PIPE_SPEC_TEMPLATE_PATH \
-    PIPE_MODEL_TRIAGE PIPE_MODEL_CODE PIPE_MODEL_REVIEW
+    PIPE_HARNESS PIPE_MODEL_TRIAGE PIPE_MODEL_CODE PIPE_MODEL_REVIEW
 }
 
 pipe_log() { echo "[pipeline] $*"; }
@@ -131,14 +142,22 @@ pipe_count_fix_commits() {
 
 pipe_agent_secret_var() {
   # Return success when an exported variable looks credential-bearing and is
-  # not explicitly required by the Claude API itself or allowlisted for a
-  # project verification command. The allowlist is comma/space separated.
+  # not explicitly required by the active harness's own auth or allowlisted
+  # for a project verification command. The allowlist is comma/space
+  # separated.
   local name="$1" allow=" ${PIPE_AGENT_ENV_ALLOWLIST:-} "
   allow=" ${allow//,/ } "
-  # The Claude process must keep its own credential regardless of which of the
-  # three supported auth variables the project uses.
-  case "$name" in
-    ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN|CLAUDE_CODE_OAUTH_TOKEN) return 1 ;;
+  # Preserve only the active harness's built-in model credentials. Credentials
+  # for the inactive harness fall through to the generic secret-name check.
+  case "${PIPE_HARNESS:-claude}" in
+    omp)
+      [ "$name" = "OPENROUTER_API_KEY" ] && return 1
+      ;;
+    *)
+      case "$name" in
+        ANTHROPIC_API_KEY|ANTHROPIC_AUTH_TOKEN|CLAUDE_CODE_OAUTH_TOKEN) return 1 ;;
+      esac
+      ;;
   esac
   [[ "$allow" == *" $name "* ]] && return 1
   case "$name" in
@@ -213,6 +232,115 @@ pipe_run_claude() {
   rm -f "$stdin_file"
 }
 
+# --- omp invocation -----------------------------------------------------
+# Runs `omp -p "/<skill>"` wrapped in usage-capture, the omp equivalent of
+# pipe_run_claude. Same non-root/su-user dance (unverified whether omp
+# tolerates root under --yolo; the same-user fallback Claude Code needs is
+# always safe, so it ships unconditionally either way).
+
+pipe_translate_tools_to_omp() {
+  # $1 = Claude Code-style comma-separated tool list, e.g.
+  # "Agent,Read,Write,Edit,Glob,Grep,Bash". Echoes the omp-equivalent
+  # comma-separated list, deduplicated and order-preserving. Tokens with no
+  # omp equivalent (LS, NotebookRead, Skill, KillShell, BashOutput) are
+  # dropped; mcp__* and any unrecognized token pass through unchanged. See
+  # the translation table in
+  # docs/superpowers/specs/2026-08-26-omp-openrouter-harness-design.md.
+  local tools="$1" tok mapped seen="," result=""
+  IFS=',' read -ra tokens <<< "$tools"
+  for tok in "${tokens[@]}"; do
+    case "$tok" in
+      Agent) mapped=task ;;
+      Bash) mapped=bash ;;
+      Edit|MultiEdit) mapped=edit ;;
+      Glob) mapped=glob ;;
+      Grep) mapped="grep" ;;
+      Read|WebFetch) mapped="read" ;;
+      Write) mapped="write" ;;
+      TodoWrite) mapped=todo ;;
+      WebSearch) mapped=web_search ;;
+      LS|NotebookRead|Skill|KillShell|BashOutput) continue ;;
+      *) mapped="$tok" ;;
+    esac
+    case "$seen" in *",$mapped,"*) continue ;; esac
+    seen="$seen$mapped,"
+    result="$result,$mapped"
+  done
+  echo "${result#,}"
+}
+
+pipe_run_omp() {
+  # $1 = agent label for metrics, $2 = skill invocation (e.g. "/review-mr"),
+  # $3 = allowed tools in Claude Code naming (optional, translated
+  # internally), $4 = model for the main loop (optional, e.g.
+  # $PIPE_MODEL_REVIEW; subagents keep the models from their own
+  # frontmatter), stdin = extra prompt (optional, usually empty).
+  local label="$1" skill="$2" tools="${3:-Agent,Read,Write,Edit,Glob,Grep,Bash}" model="${4:-}"
+  local omp_tools; omp_tools=$(pipe_translate_tools_to_omp "$tools")
+  local stdin_file; stdin_file=$(mktemp)
+  cat > "$stdin_file" || true
+
+  if [ "$(id -u)" -eq 0 ]; then
+    local runuser="pipelinebot"
+    id "$runuser" &>/dev/null || useradd -m -s /bin/bash "$runuser"
+    chown -R "$runuser:$runuser" "$PWD" "$PIPE_CONTEXT_DIR" "$stdin_file" 2>/dev/null || true
+    local runner; runner=$(mktemp)
+    {
+      printf '#!/bin/bash\nset -e\nexport HOME=/home/%s\n' "$runuser"
+      # Re-export the runtime environment the skill and usage-capture need.
+      local v
+      for v in $(compgen -v | grep -E '^(PIPE_|CI_|GH_|GITHUB_|OPENROUTER_)'); do
+        pipe_agent_secret_var "$v" && continue
+        printf 'export %s=%q\n' "$v" "${!v}"
+      done
+      # `su -m` preserves the parent environment, so explicitly remove every
+      # detected credential after exporting the safe runtime values above.
+      for v in $(compgen -e); do
+        pipe_agent_secret_var "$v" && printf 'unset %q\n' "$v"
+      done
+      printf 'cd %q\n' "$PWD"
+      printf 'source %q\n' "$SCRIPT_LIB_DIR/usage-capture-omp.sh"
+      printf 'export PIPE_CAPTURE_MODEL=%q\n' "$model"
+      if [ -n "$model" ]; then
+        printf 'capture_omp %q -- --yolo --no-session --no-title --model %q --tools %q -p %q < %q\n' \
+          "$label" "$model" "$omp_tools" "$skill" "$stdin_file"
+      else
+        printf 'capture_omp %q -- --yolo --no-session --no-title --tools %q -p %q < %q\n' \
+          "$label" "$omp_tools" "$skill" "$stdin_file"
+      fi
+    } > "$runner"
+    chmod +x "$runner"
+    chown "$runuser:$runuser" "$runner"
+    su -m "$runuser" -s /bin/bash "$runner" || true
+    chown -R root:root "$PWD" 2>/dev/null || true
+    rm -f "$runner"
+  else
+    (
+      pipe_scrub_agent_secrets
+      export PIPE_CAPTURE_MODEL="$model"
+      if [ -n "$model" ]; then
+        capture_omp "$label" -- --yolo --no-session --no-title --model "$model" --tools "$omp_tools" -p "$skill" < "$stdin_file"
+      else
+        capture_omp "$label" -- --yolo --no-session --no-title --tools "$omp_tools" -p "$skill" < "$stdin_file"
+      fi
+    ) || true
+  fi
+  rm -f "$stdin_file"
+}
+
+# --- Harness dispatch ---------------------------------------------------
+# Single entry point every job script calls. Same signature/contract as
+# pipe_run_claude/pipe_run_omp themselves: $1 label, $2 skill, $3 tools
+# (optional, Claude Code naming, translated internally when the target is
+# omp), $4 model (optional).
+
+pipe_run_agent() {
+  case "${PIPE_HARNESS:-claude}" in
+    omp) pipe_run_omp "$@" ;;
+    *) pipe_run_claude "$@" ;;
+  esac
+}
+
 # --- dotenv -----------------------------------------------------------------
 
 # Load KEY=VALUE lines from a marker file into the current shell.

package/payload/ci-templates/scripts/lib/usage-capture-omp.sh

@@ -0,0 +1,117 @@
+# shellcheck shell=bash
+# Source-only library. Wraps an `omp --mode json` invocation, sums usage/cost
+# from the agent_end event's message transcript, writes a metrics record, and
+# surfaces the assistant text on stdout — the omp equivalent of
+# usage-capture.sh's capture_claude. Same function contract, same metrics
+# record shape (bar the harness-specific exit-code key), different event
+# parsing because omp's schema differs from Claude's stream-json.
+#
+# Schema verified live against a real omp install (18.0.6): the final
+# "agent_end" line carries {"type":"agent_end","messages":[...],
+# "isTerminal":true}. Each assistant message in `messages[]` carries its own
+# `usage` object (per-message, not session-cumulative) and top-level
+# `model`/`provider`/`duration` fields. See
+# docs/superpowers/specs/2026-08-26-omp-openrouter-harness-design.md section 3
+# for the full verification record.
+#
+# Usage:   capture_omp <agent_name> -- <args to pass to `omp`...>
+# Stdin:   forwarded to `omp` stdin
+# Stdout:  concatenated text from assistant turns (drop-in for `omp -p`)
+# Side effect: writes one JSON record to $PIPE_METRICS_DIR
+
+set -u
+
+capture_omp() {
+  local agent="$1"; shift
+  [ "${1:-}" = "--" ] && shift
+
+  local metrics_dir="${PIPE_METRICS_DIR:-${PIPE_CONTEXT_DIR:-build/pipeline}/metrics}"
+  mkdir -p "$metrics_dir"
+
+  local job_name="${PIPE_JOB_NAME:-${CI_JOB_NAME:-job}}"
+  local job_id="${PIPE_JOB_ID:-${CI_JOB_ID:-$$}}"
+  local pipeline_id="${PIPE_PIPELINE_ID:-${CI_PIPELINE_ID:-}}"
+  local mr_iid="${PIPE_MR_IID:-${CI_MERGE_REQUEST_IID:-null}}"
+  local issue_iid="${PIPE_ISSUE_IID:-${CODER_ISSUE:-null}}"
+
+  local stream_file stderr_file
+  stream_file=$(mktemp)
+  stderr_file=$(mktemp)
+  local start_ns end_ns
+  start_ns=$(date +%s%N)
+  local exit_code=0
+
+  # Force JSON mode so we always get an agent_end event with the full
+  # message transcript.
+  omp --mode json "$@" \
+    >"$stream_file" 2>"$stderr_file" || exit_code=$?
+
+  end_ns=$(date +%s%N)
+  local wall_ms=$(( (end_ns - start_ns) / 1000000 ))
+
+  # Extract the final agent_end event (last line that begins with
+  # {"type":"agent_end"). Its usage is per-message (one API call each), not
+  # pre-aggregated like Claude's single "result" event, so sum it ourselves.
+  local result_line
+  result_line=$(grep '^{"type":"agent_end"' "$stream_file" | tail -1 || true)
+
+  local model input output cache_c cache_r cost duration
+  if [ -n "$result_line" ]; then
+    model=$(echo "$result_line" | jq -r '[.messages[]? | select(.role=="assistant") | ((.provider // "") + "/" + (.model // ""))] | last // ""')
+    input=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.input // 0] | add // 0')
+    output=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.output // 0] | add // 0')
+    cache_c=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.cacheWrite // 0] | add // 0')
+    cache_r=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.cacheRead // 0] | add // 0')
+    cost=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .usage.cost.total // 0] | add // 0')
+    duration=$(echo "$result_line" | jq '[.messages[]? | select(.role=="assistant") | .duration // 0] | add // 0')
+  else
+    model=""; input=0; output=0; cache_c=0; cache_r=0; cost=0; duration=$wall_ms
+  fi
+  [ -n "${PIPE_CAPTURE_MODEL:-}" ] && [ -z "$model" ] && model="$PIPE_CAPTURE_MODEL"
+
+  # Recover the user-facing text (concatenate all assistant text blocks) so
+  # downstream consumers that read `omp -p`'s stdout still work.
+  grep '^{"type":"message_end"' "$stream_file" \
+    | jq -r 'select(.message.role=="assistant") | .message.content[]? | select(.type=="text") | .text' \
+    || true
+
+  # Write metrics record. Same field names as capture_claude's record; only
+  # the harness-specific exit-code key differs (omp_exit_code vs
+  # claude_exit_code), by the same convention the two capture_* files
+  # already use for their own harness-labelled fields.
+  local record_stamp record_file
+  record_stamp=$(date +%s%N)
+  record_file="$metrics_dir/${job_name}-${job_id}-${record_stamp}.json"
+  jq -n \
+    --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
+    --arg agent "$agent" \
+    --arg event "omp_invocation" \
+    --arg model "$model" \
+    --arg pipeline_id "$pipeline_id" \
+    --arg job_id "$job_id" \
+    --arg job_name "$job_name" \
+    --argjson mr_iid "$mr_iid" \
+    --argjson issue_iid "$issue_iid" \
+    --argjson input "$input" \
+    --argjson output "$output" \
+    --argjson cache_c "$cache_c" \
+    --argjson cache_r "$cache_r" \
+    --argjson cost "$cost" \
+    --argjson duration "$duration" \
+    --argjson wall_ms "$wall_ms" \
+    --argjson exit_code "$exit_code" \
+    '{
+      ts: $ts, agent: $agent, event: $event, model: $model,
+      pipeline_id: $pipeline_id, job_id: $job_id, job_name: $job_name,
+      mr_iid: $mr_iid, issue_iid: $issue_iid,
+      input_tokens: $input, output_tokens: $output,
+      cache_creation_tokens: $cache_c, cache_read_tokens: $cache_r,
+      total_cost_usd: $cost, duration_ms: $duration, wall_ms: $wall_ms,
+      omp_exit_code: $exit_code
+    }' > "$record_file"
+
+  # If omp failed, forward stderr so debugging still works.
+  [ "$exit_code" -ne 0 ] && cat "$stderr_file" >&2
+  rm -f "$stream_file" "$stderr_file"
+  return "$exit_code"
+}

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

@@ -119,7 +119,7 @@ while IFS= read -r ISSUE; do
 
   export PIPE_ISSUE_IID="$IID"
   rm -f "$PIPE_CONTEXT_DIR/triage.env" "$PIPE_CONTEXT_DIR/triage.json"
-  pipe_run_claude orchestrator "/triage-issue" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_TRIAGE" < /dev/null
+  pipe_run_agent orchestrator "/triage-issue" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_TRIAGE" < /dev/null
 
   TRIAGE_ENV="$PIPE_CONTEXT_DIR/triage.env"
   TRIAGE_JSON="$PIPE_CONTEXT_DIR/triage.json"

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

@@ -38,7 +38,7 @@ fi
 
 # Run the postmortem skill unless a prior inline flow already produced the marker.
 if [ ! -f "$PIPE_CONTEXT_DIR/postmortem.env" ]; then
-  pipe_run_claude postmortem "/postmortem-mr" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_TRIAGE" < /dev/null
+  pipe_run_agent postmortem "/postmortem-mr" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_TRIAGE" < /dev/null
 fi
 
 # Apply the runner side: labels, comment, metric.

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

@@ -40,7 +40,7 @@ echo "$NOTES" | jq -r --arg u "${PIPE_BOT_USER:-}" --arg m "$REVIEW_MARKER" \
 # 5. Run the fix skill. It caps, gathers prior fix diffs, delegates to the coder,
 #    verifies, writes the result JSON, and the review-fix.env marker. On cap it
 #    runs the shared postmortem flow (writing postmortem.md + postmortem.env).
-pipe_run_claude coder "/fix-review-findings" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_CODE" < /dev/null
+pipe_run_agent coder "/fix-review-findings" "Agent,Read,Write,Edit,Glob,Grep,Bash" "$PIPE_MODEL_CODE" < /dev/null
 
 # 6. Read the marker the skill wrote.
 RF_ENV="$PIPE_CONTEXT_DIR/review-fix.env"

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,

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"

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

@@ -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

@@ -44,8 +44,8 @@ Stop counting at the first subject that does not match. If the count is at or ab
 
 ## 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":[]}]}