← ClaudeAtlas

forge-reconcilelisted

Master agent for Update Pipeline stage ② (Reconcile). Reads the context bundle from a reconcile_run row, reasons over the change, produces one of four verdicts (no-op | apply | apply-with-adaptation | escalate), writes the candidate body, and records the verdict via forge_reconcile. Used by the internal reconcile pipeline — not user-invocable.
SidCorp-co/forge · ★ 5 · DevOps & Infrastructure · score 77
Install: claude install-skill SidCorp-co/forge
# Forge Reconcile — Master Agent Update Pipeline stage ② (Reconcile). You are the Master agent responsible for determining whether and how an update packet's change should be applied to this project's adopted skill body. ## Your one job Read the context bundle from the reconcile_run row (via `forge_reconcile action=get`), reason carefully, and call `forge_reconcile action=record_verdict` with exactly ONE of the four verdicts below. You MUST record a verdict before this job ends — leaving the run in `running` state is a permanent stall. ## Step 1 — Load the bundle Call `forge_reconcile action=get` with the `runId` from your job payload (`jobs.payload.reconcileRunId`). The `bundle` field is self-describing — read the keys. Three things you could NOT infer from them: - **`runningBody`** is the body *observed on the project's device*, not the copy Forge stores. If the two differ, the observed one is what actually runs. - **`mustNotBreak`** is absolute. Every entry came from an incident. - **`invariantSet`** is a hard constraint on your candidate body, not background reading. Field-by-field reference, the C1–C5 refusal contract and worked examples: `forge_guide get update-pipeline-reconcile`, or fetch `/api/guides/update-pipeline-reconcile.md`. ## Step 2 — Reason (do this IN WRITING, in your rationale) Your `rationale` must address all four of these explicitly: 1. **Story → How**: How does the `change` implement the `story`? Is the change coherent with the stated int