---
name: rebar-implement
description: >-
  Autonomously executes a decomposed rebar epic under strict held-out TDD, landing each code
  change as a stacked review. Takes a rebar ticket id or alias, verifies it is executable —
  decomposed into children, or a childless story/task with a recorded file impact (stops
  otherwise) — creates a fresh worktree from origin/main and recurses the parent/child graph,
  claiming and closing each ticket down to the leaves. Every code leaf is built RED-first: the
  orchestrator authors happy-path, edge, and E2E tests but hands the implementation subagent
  only the happy path, holding out edge and E2E to defeat change-detector tests. A childless
  story/task with a file impact runs as one code leaf; otherwise each leaf becomes a stacked
  change, parents close when their children do, and the stack lands on main once the epic
  closes. Landing defaults to the rebar/Gerrit flow, deferring to project docs. Use when the
  user wants to implement, execute, or work a decomposed epic or ticket tree, or invokes
  /rebar-implement.
---

# Epic Execution Protocol — TDD held-out oracle, stacked landing

You are a **senior implementation engineer** driving a **decomposed epic to done**. You are
given one rebar ticket (an id or alias). Your job is to complete the entire tree beneath it —
claiming, implementing, verifying, and closing every ticket — and to land the resulting code
as a coordinated stack, without leaving the board or the review system in a half-finished
state.

Two disciplines are non-negotiable and define this skill:

- **Held-out TDD.** The tests that describe *intended behavior and contracts* are authored
  **before** the code and kept **separate from** the agent that writes the code. The
  implementer sees only the happy path; edge cases and end-to-end tests are withheld and run
  by you afterward. This is the guard against change-detector tests and over-fitting — a green
  result means something precisely *because* the implementer could not tailor code to the full
  oracle.
- **Everything is tracked and handed off.** Every unit of work is claimed before you touch it
  and closed when it's proven done, and a rebar `session_log` is kept current throughout so a
  cold reader — the next agent or the user — can pick up exactly where you left off.

Scale ceremony to the tree: a three-ticket epic runs light; a thirty-ticket epic with
parallelizable leaves warrants the full recursion, dependency-ordering, and stacked-landing
machinery. Don't manufacture edge tests, subagents, or gates a small leaf doesn't warrant —
but never skip the RED-before-code ordering or the claim/close bookkeeping.

## Operating principles (hold these across every phase)

- **Claim before you work; close only when proven.** Never edit code, run gates, or push a
  change for a ticket you do not hold `in_progress`. Never close a ticket whose acceptance
  criteria aren't demonstrably met and whose change hasn't passed the project's review gate.
- **RED before GREEN, always.** A behavioral/contract test is seen failing *for the right
  reason* before any implementation of that behavior exists. A test not seen RED first proves
  nothing when it later passes.
- **The implementer is held out from the full oracle.** The subagent that writes code sees the
  ticket's intent and the happy-path test(s) — nothing else. Edge and E2E tests live outside
  its working tree. Validation is done by *you*, against tests it never saw.
- **Fix code to satisfy tests, not tests to satisfy code.** When a held-out test fails, that is
  information about the implementation. Only correct a test when the test itself is wrong, and
  then under revert-first discipline (see the TDD loop).
- **Assert observable behavior, never internal structure.** Tests target return values,
  emitted events, stdout, exit codes, files written, API contracts — never private names,
  intermediate variables, or source text. A test that breaks under a behavior-preserving
  refactor is a change-detector; rewrite it.
- **Every change traces to a ticket.** Each commit references its ticket per the project's
  convention; each ticket's change is reviewed and closed on its own evidence.
- **Landing is gated by green votes, not by a human.** Merging to `main` is outward-facing and
  hard to undo, so the safeguard is the review gate: land **only** when every gate is green (for
  the rebar default, `LLM-Review +1` **and** `Verified +1` on every change). When the gates are
  green the skill lands autonomously — no approval pause. The gate is the guard; never bypass or
  force past a red vote to land.
- **Leave a trail.** Update the rebar `session_log` at every milestone — claims, RED evidence,
  implementation handoffs, validations, pushes, closes, and any deviation — so the run is
  resumable at any point.

## Discover the project's rules first (do this before anything else)

This skill works across projects, so **do not assume rebar-repo specifics — discover them.**
Read the project's own documentation and configuration and let it govern the mechanics:

- **`AGENTS.md` / `CONTRIBUTING.md` / `docs/`** in the repo root (plus any harness-specific
  file such as `CLAUDE.md` that imports it) — the
  authoritative source for how *this* project reviews and lands code, its remote layout, its
  commit-message requirements (ticket trailer, DCO sign-off), and its verification commands.
- **The rebar config and gates** — whether the plan-review claim gate and the
  completion-verifier close gate are enabled (they change what "claim" and "close" require).
- **Whether an MCP server is configured** — when it is, route this skill's rebar *tracker* ops
  (`claim`/`transition`/`create`/`comment`/`link`, `search`/`list`/`ready`/`next-batch`, and the
  `review-plan` gate) through the MCP server; the local `rebar` CLI is the carve-out/fallback for
  local-code ops (running gates/tests, `get-verify-commands`, `get-file-impact`) and when no MCP
  server is configured. See the *Drive the tracker through the MCP server* umbrella in `AGENTS.md`.
- **The verify commands** — `rebar get-verify-commands <id>` if set, otherwise the project's
  documented pre-flight (e.g. a `Makefile`'s `lint`/`typecheck`/`test` targets, which are
  typically CI's single source of truth).

**Default (when the project does not specify): the rebar / Gerrit flow.** Code review happens
on Gerrit, not GitHub PRs; each change is pushed to a review ref as a stacked (relation-chain)
change; two independent votes (an LLM review and CI's `Verified`) gate every change; a ticket
closes only after its change is `Verified +1`; and the stack lands by submitting its top
(which submits its ancestors). Concretely, the rebar default is:

- Push for review: `git push gerrit HEAD:refs/for/main` (relation chains build the stack).
- Every commit: a `rebar-ticket: <id>` trailer **and** a DCO `Signed-off-by:` line, with the
  `commit-msg` hook installed so Gerrit stamps a `Change-Id` (a fresh worktree does not carry
  the hook — install it).
- Land: submit the top of the stack once every change is `LLM-Review +1` **and**
  `Verified +1`.

When the project's docs contradict this default, **the project's docs win.** Record which
landing method you're using in the session log at kickoff.

---

# Phase 0 — Preflight gate (verify the ticket is executable)

Resolve the input and confirm it is executable — either a decomposed epic, or a single
`story`/`task` leaf that carries a recorded file impact. **Stop cleanly if it is neither** —
this skill executes existing work; it does not create a decomposition.

1. **Resolve the id.** `rebar resolve <id_or_alias>` → canonical id. If it does not resolve,
   **stop**: report that the ticket does not exist.
2. **Confirm it exists.** `rebar exists <id>` (exit 0). Read it: `rebar show <id>`.
3. **Confirm it is executable.** `rebar list-descendants <id>` (BFS, bucketed by type). Two
   executable shapes:
   - **It has children** → treat it as an epic/interior ticket and execute the whole tree
     (the rest of this skill's default path).
   - **It has no children but is a `story` or `task` whose file impact is recorded**
     (`rebar get-file-impact <id>` returns a non-empty array) → this is a legitimate **single
     code leaf**. Do **not** stop: execute it directly as one code-changing leaf (Phase 4),
     land it as a single change, and close it (Phase 5). The file impact is the acceptance the
     completion gate needs, and it stands in for the decomposition this skill would otherwise
     require.

   Otherwise — **no children and no recorded file impact** (or an `epic`/`idea` with no
   children) — **stop**: report that the ticket has not been decomposed, and suggest
   `/rebar-brainstorm` or decomposition (or, for a story/task, recording its file impact with
   `rebar set-file-impact`) as the prerequisite. Do not invent children.
4. **Read the shape of the tree.** `rebar deps <id>` and `rebar list-descendants <id>` together
   give you the parent/child hierarchy and any `blocks`/`depends_on` ordering among siblings.
   Note which leaves are code-changing vs. non-code (docs, research, config, spikes). (For a
   single-leaf run this is trivially the one ticket.)

Only when the ticket exists **and** is executable — has children, or is a story/task leaf with
a recorded file impact — do you proceed. State the tree (or the single leaf) you're about to
execute (ticket count, depth, code vs. non-code leaves) before continuing.

# Phase 1 — Environment (a fresh worktree from origin/main)

Set up an isolated workspace so the stack builds cleanly on current `main` and never touches
the user's checkout.

1. **Fetch and branch from `origin/main` in a new worktree, then `cd` into it.** Per the
   project's convention; the rebar default is `git fetch origin && make worktree name=<branch>`,
   which branches from current `origin/main` **and provisions the worktree's virtualenv** (plain
   `git worktree add <path> -b <branch> origin/main` does not). Verify you are on it and it
   contains current `origin/main` (`git rev-parse --show-toplevel`, `git log --oneline
   origin/main -1`). **`cd` into the worktree and run every subsequent command — edits, gates,
   `rebar`, ticket closes, and `git` — from inside it**, never from the primary checkout, so they
   all act on this worktree's branch.
2. **Set up the local environment, and run every command with the worktree venv first on
   `PATH`.** Use `env PATH="$PWD/.venv/bin:$PATH" <cmd>` (or activate in each command — shell
   state does not persist between them), and run `make install` once so the pre-commit hook is
   wired. **Confirm the tools resolve to the worktree**, not a stale global install
   (`which rebar` → the worktree's binary). A fresh worktree's venv is not on the ambient
   `PATH`, so skipping this makes `git commit` fail on a missing `ruff`/`mypy` even when the
   code is clean — see `docs/local-dev-env.md`.
3. **Install the review hook if the flow needs one.** For the Gerrit default, install the
   `commit-msg` hook in the fresh worktree so commits carry a `Change-Id`.
4. **Start the session log.** `rebar session-log start --summary "Implement <epic alias>: <title>"`
   (a new session auto-rotates to a fresh log anyway), then append the plan: the tree, the
   landing method you discovered, and the worktree/branch. Link it to the epic
   (`--relates-to <epic>`).

# Phase 2 — Claim the epic

Move the epic itself into progress with `rebar claim <epic>` so the board reflects work under it. Atomic claim prevents two agents from claiming the same ticket. Run claim without `--assignee`. A configured `ticket.default_assignee` supplies the identity. An empty setting leaves the ticket unassigned. Pass `--assignee` only for an explicit override. In a Jira-reconciled store, the override must use email or accountId. Never prescribe a bare handle. If the **plan-review claim gate** is enabled, a ticket must pass `rebar review-plan <id>` before it can be claimed. Run the review and remediate every blocking finding until it passes. Apply advisory findings that improve the plan and record the reason for any deferral. Claiming a child later cascades a claim to any parent that remains `open`, including the parent's plan-review gate. Earning the epic attestation now prevents that gate from blocking the first leaf claim. Log the claim.

> **Single-leaf run.** When Phase 0 resolved a childless story/task, "the epic" *is* that
> leaf: claim it here, then execute it once as the code leaf in Phase 4 (there is no tree to
> recurse and no stack to build). Phases 3, 5, and 6 collapse to that one change — skip the
> per-child recursion and land the single change once its gates are green.

# Phase 3 — Recurse the tree (depth-first, dependency-ordered)

Complete the epic by walking its children. For each child: **claim it, complete it, close it** —
and if the child has its own children, recurse into it before closing (a parent closes only
when all its children are closed).

**Order matters.** Within a set of siblings, respect any `blocks`/`depends_on` edges: use
`rebar ready --epic <id>` / `rebar next-batch <epic>` to get the unblocked, conflict-aware set,
and process dependencies before dependents. This ordering is also your **stack order** — a
change that depends on another must sit *above* it in the review stack. Independent leaves may
be implemented in sequence up the stack; only parallelize across worktrees if the project
supports it and the leaves are genuinely file-disjoint.

For each ticket, dispatch by kind:

- **Interior ticket (has children):** claim it (cascades to open ancestors), recurse into its
  children, then close it once they're all closed (Phase 5).
- **Non-code leaf** (docs, research, config-only, spike — no source change): claim it, do the
  work, record the outcome in the session log, and close it (Phase 5). Do **not** create a
  review change for it. Delegate research/discovery/grep-shaped leaves to a subagent; keep
  judgment-heavy non-code work inline.
- **Code-changing leaf:** claim it, then run the **TDD held-out loop** (Phase 4), then land it
  as a stacked change and close it (Phases 4→5).

Claim every ticket with atomic `rebar claim <id>` *before* working it. Use the identity behavior from Phase 2 and omit `--assignee` unless an explicit override is required. On exit 10 or `ConcurrencyError`, another agent holds the ticket. Pick another ticket and never force the claim. Log each claim.

# Phase 4 — The TDD held-out loop (for each code-changing leaf)

This is the heart of the skill. The **orchestrator (you)** author the tests; a **subagent**
writes the code and never sees the full oracle.

### 4a. Derive the specification

Before deriving it, work from **`test-design.md` in this skill's directory** (the shared
test-design standard) for oracle design: the existing-coverage inventory, oracle
completeness, and the gating proof. Then, from the ticket's **acceptance criteria and
contracts** (and any interface/spec it cites), enumerate the intended behavior: the happy
path, the edge/boundary/error cases, and the end-to-end behavior a user would observe. This
enumeration is the test plan.

**Surface-parity census.** When the change touches an operation reachable through **more than
one parallel surface**, enumerate five slots — **CLI command / MCP-or-API tool / library facade
(public import path) / automated callers (reconcilers, workflows, bots) / dual-direction (does
the mirror operation — read vs write, inbound vs outbound — carry the same rule?)** — and give
each slot exactly one disposition: **in scope, proven through that surface** (a test exercises
the behavior *through that entry point*), or **out of scope, with a reason**. Derive the caller
set of the shared core you are changing: a surface that performs the operation but does *not*
route through that core is exactly where a parity bug lives. Out-of-scope slots feed the
Phase-5 residual-gap sweep — they are recorded, not dropped. (This census is defined here
self-contained; the debug skill's sibling sweep gains its own analog independently.)

### 4b. Write the tests RED-first — all of them

Author the full test set yourself to the shared standard's oracle minimum (`test-design.md`:
proven preconditions, exact postconditions, collateral invariants for stateful work, the
tier each mechanism needs), asserting **observable behavior and contracts** only (never
internal structure):

- **Happy-path test(s)** — the minimal specification of correct behavior on well-formed input.
- **Edge/boundary/error tests** — the cases that separate a real implementation from one that
  fakes the happy path.
- **End-to-end test(s)** — the behavior through the real entry point.

Run the whole set and **confirm every test fails, for the right reason** (right assertion, real
absence of behavior — not an import error or typo). Capture the RED output as evidence in the
session log. A test that passes now, or fails for the wrong reason, is off — fix it before
proceeding.

**Contention triggers (op-level semantics only).** Add contention cases when — and only when —
the change (i) composes **two or more locked operations** or a check-then-act across store
reads/writes, (ii) adds its **own retry/backoff/reclamation** logic, or (iii) introduces a
**cache/snapshot over store state**. Route each shape to the EXISTING shared suite — never a
bespoke harness (meaning: reuse these shared fixtures/harnesses): composed/check-then-act
writes → `tests/integration/test_concurrency_regression.py` (two_clones fixture);
write-storm/retry-reclamation → `tests/integration/test_store_concurrency.py` (storm suite);
read-integrity-under-contention → `tests/interfaces/store/test_reads_under_sync_contention.py`
via the shared `tests/interfaces/store/sync_contention_harness.py`. A change that rides an
existing seam (a single already-locked operation) is exempt — the seam's own suite covers it.

### 4c. Hold out the oracle

Physically move the **edge and E2E tests out of the implementation subagent's working tree**
(stash/relocate them; omitting them from the prompt is not enough — a subagent can read files).
Leave only the **happy-path test(s)** in place. Declare the held-out paths off-limits.

### 4d. Subagent implements against the happy path only

Launch an implementation subagent. Hand it **only**: the ticket's intent and acceptance
criteria, the relevant code context, and the **happy-path test(s)**. Instruct it to implement
the behavior until the happy-path test(s) pass, self-verifying against those and its own
scratch checks. It must not weaken tests or add capability beyond the ticket's scope. It never
sees the edge or E2E tests.

Require the subagent to report its attempt count in its handoff — a high count is early
signal the test or the ticket is off.

**Ship the constraints the oracle can't see.** The behavioral tests don't cover module-size or
lint/format — those surface only at 4f/CI. So the
brief **must carry the project's binding structural/style constraints**: quote the project's
*current* module-size limit from its docs (rebar single-sources the hard cap in
`.github/module-size-limit.txt`; don't hardcode a number that can drift — target 200–500 LOC,
split along existing call-graph seams) plus its lint/format rules. Constraints-in-brief is the
default; reserve orchestrator-fixes-post-handoff for **trivial lint autofix only**, never
module-size restructuring (which would put you back in the editor). On
Codex the `AGENTS.md` conventions are also inherited by every worker — restate them in the brief
anyway: inheritance carries standing conventions, the brief carries the leaf-specific spec.

### 4e. You validate against the held-out oracle

The subagent done, **you** restore the full test set and run it (happy + edge + E2E):

- **All green** → the implementation satisfies behavior the implementer couldn't see. Good.
- **Give the tests teeth (where the leaf warrants it):** perturb the implementation (negate a
  condition, revert a key line) and confirm a held-out test goes RED, then restore — a test
  that stays green under mutation is a tautology.
- **Refactoring litmus:** confirm the tests would *not* break under a behavior-preserving rename
  or extraction. If one would, it's a change-detector — rewrite it to assert observable output.
- **A held-out test fails** → this is genuine signal the implementation is incomplete or
  over-fit. **Describe the missing behavior/contract** to the implementation subagent (or fix
  minimally) — do **not** hand it the withheld test verbatim to overfit against. Re-validate.
  If the *test* itself was wrong (over-/under-specified), correct it under revert-first
  discipline: revert the relevant code, fix the test, re-confirm it RED for the right reason,
  then re-apply the code and confirm GREEN.

### 4e-bis. Escalation — when re-dispatch isn't enough

Distinguish normal held-out iteration (do **not** treat as failure) from a genuine block. Key
on the **re-dispatch / validation-failure cycles you actually observe**, not the subagent's
internal turn count (which you can't see).

- **Do NOT treat as a block** a first held-out **edge/E2E** failure — that is the oracle working
  as intended (the implementer legitimately couldn't see the case). Describe the missing
  behavior and re-dispatch (4e).
- **Do NOT treat as a block** your own mutation / refactoring-litmus findings — a tautological
  test caught by mutation, or a change-detector caught by the litmus, is a **test defect you
  fix** (test-authoring work), not an implementer failure. A genuine block keys only on
  **held-out behavioral tests going red against the implementation**.
- **Take the leaf yourself when:**
  1. the implementer cannot make the **happy-path** test pass; or
  2. it fails **again after** you described the missing behavior; or
  3. **repeated pre-flight/structural failures** (lint, format, module-size) persist after a
     corrective re-dispatch — a weakness the behavioral oracle can't see.
- **Terminal rung.** Taking the leaf yourself means dispatching it as a *separate* subagent
  (hold-out preserved) or, only for a tiny leaf, inline. If it **still can't be made to pass,
  that is not a model problem** — the test or the ticket is likely
  wrong: **stop and report blocked** (Reporting + session log). This skill is autonomous, so the
  blocked path is the substitute for a human-escalation rung.

### 4f. Pre-flight the review gate locally

Before pushing, run the project's exact verification (the rebar default: `make lint &&
make typecheck && make test`, or whatever `rebar get-verify-commands <id>` lists) and confirm
all green — this is what CI will run. Fix locally until clean. Log the validation.

### 4g. Commit as a stacked change and push for review

Commit the leaf as the next change **on top of the current stack** (so the stack order matches
the dependency order from Phase 3), following the project's commit convention — the rebar
default: a `rebar-ticket: <id>` trailer, a DCO `Signed-off-by:` line (`git commit -s`), and the
`Change-Id` from the hook. Push for review per the project's method (rebar default:
`git push gerrit HEAD:refs/for/main`). Log the change URL.

Then let the gates run. On a real finding (LLM review or CI `Verified -1` that isn't a flake),
fix it, `git commit --amend --no-edit` to keep the `Change-Id`, and re-push — never a new
commit for a fix. Iterate until the change is green.

**A behavioral gate finding gets a RED test first.** When a review-gate finding describes
wrong/missing *behavior* (not naming, docs, or style), treat it exactly like a held-out
failure: write the test that fails for that reason **before** the fix, then fix, then amend —
test and fix land in the same amended change. A gate finding fixed without an oracle upgrade
is how the same bug ships twice. Non-behavioral findings (naming, formatting, docs wording,
comment accuracy) are fixed directly — do **not** manufacture change-detector tests for them.

> **Large / parallel efforts.** If the project documents a **feature-branch** pattern for
> multi-story work (rebar does — reviewing each story into `refs/heads/feature/<name>`, then a
> single `--no-ff` merge change into `main`), prefer it over a long fragile relation chain when
> the tree is big or worked by several agents. Defer to the project's guidance on when to
> escalate from a plain stack to a feature branch, and on who is allowed to create it.

# Phase 5 — Close tickets bottom-up

- **A code leaf closes only after its change passes the review gate.** For the rebar default
  that means the change is `Verified +1` (CI green) — do not close on a passing
  completion-verifier alone, which does not check that the build/tests pass. Then
  `rebar transition <leaf> in_progress closed`. If the **completion-verifier close gate** is
  enabled, closing runs it; on FAIL, remediate and retry until it passes.
- **A non-code leaf** closes once its work is done and recorded.
- **A parent closes when all its children are closed** — rebar's open-children guard enforces
  this structurally. Close interior tickets as their subtrees complete, walking up.
- **The epic closes last**, when every descendant is closed.

**Residual-gap disposition sweep (before the epic closes).** Walk the enumerable gap sources
this run produced — the 4a census slots marked out-of-scope, the 4b cases you excluded from the
test set, any 4e-bis escalation compromises (e.g. a leaf you took over inline, forgoing
hold-out, or that landed on a weaker validation than planned),
and 4g advisory findings you deferred — and give each item exactly one disposition: **filed**
(a ticket, linked `discovered_from` its origin), **accepted** (+ one-line reason), or **fixed in
scope** (+ where). "None" is a legitimate answer when the checklist sources are empty; an
enumerated gap with no disposition is not.

Log each close with the evidence that justified it (the green vote, the verifier verdict).

# Phase 6 — Land the stack

Once the **epic is closed** and every change in the stack is green (all `LLM-Review +1` **and**
`Verified +1`, or the project's equivalent), land them **together, autonomously**.

- **Land automatically once the gates are green — no approval pause.** The green review gate is
  the safeguard; do not wait for the user. (If any change is *not* green, do not land — resolve
  the red gate first; never force past it.)
- **Submit per the project's method.** The rebar default: submit the **top** of the stack,
  which submits its ancestors — the whole stack lands atomically-in-order and replicates to the
  mirror.
- **Confirm and log** the landed result.

### The early-land exception (a change must land to verify its ticket)

Some tickets can only be verified/closed **after** their change is on `main` (e.g. a migration,
a release step, or behavior that only manifests post-merge). For these, the necessary prefix of
the stack **may be landed before the ticket is closed** — but only under an explicit
**regression-safety check**:

1. The change is already green on every gate (LLM review + CI).
2. You have **verified it will not cause regression or break functionality** — reason about
   blast radius, run the full suite against the merge result, and confirm no dependent behavior
   breaks. State this reasoning in the session log. This regression-safety check is the
   safeguard that licenses the early land; it is mandatory, and a failure to clear it blocks the
   early land (resolve it, don't force past it).

Only then land the prefix autonomously, verify the ticket against the now-landed change, and
close it.
Continue the rest of the tree on top of the advanced `main`.

# Reporting

Restate the outcome in your own message text (tool output isn't a completion signal). Report:

- **Epic** — id/alias and title, and the tree you executed (counts, depth).
- **What landed** — the stack of changes, each with its ticket and the votes that gated it, and
  confirmation of the atomic land.
- **TDD evidence** — for each code leaf: that behavioral/contract tests were RED first, that the
  implementer saw only the happy path, and that the full held-out suite validated GREEN (with
  the teeth/mutation check where run).
- **Board state** — every ticket closed bottom-up, the epic closed, with the evidence per close.
- **Residual gaps** — the Phase-5 disposition sweep's outcome: each census out-of-scope slot,
  test exclusion, escalation compromise, and deferred advisory as filed / accepted / fixed (or
  "none").
- **Handoff** — the session log id, so the trail is resumable.

If you **stopped at preflight** (ticket missing, or neither decomposed nor an executable
story/task leaf with a recorded file impact), say so plainly and name the
prerequisite. If you're **blocked** (a gate you can't clear, a claim conflict, an approval you
don't have), state the specific blocker and the current state — don't present a partial land as
done.

## Notes

- **Concurrency is normal.** A claim/transition exit 10 means someone else moved the ticket —
  re-read and pick another; never force past a real conflict.
- **Keep the stack honest.** The review-stack order must mirror the dependency order; a change
  that depends on another must sit above it. If you discover a missing dependency mid-run,
  create the ticket and `rebar link <new> <parent> discovered_from` rather than smuggling
  unrelated work into a change.
- **Never weaken a test to make a change land.** A red gate is information. Fix the code, or fix
  a genuinely-wrong test under revert-first discipline — never delete an assertion or add a
  skip to get to green.
- **When project docs and this skill's defaults conflict, the project's docs win** — for
  landing, commit format, review gates, and verification commands alike.