agentleFS
amrtawfik160amrtawfik160/bb-orchestration-skills/skills/verify-landing/SKILL.md

verify-landing

Skill1 starsChanged 58 days agoMITView on GitHub

Verify each landed merge commit on the target branch: green checks and smoke validation per merge, with a revert-first response when the target goes red. Use after land-stack merges a stack, or when asked to prove the target is green.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Verify oldest first. A merge is proven only when its merge-commit checks are green net of ci_baseline and quarantine, and smoke validation …

    line 15
  2. Very specific:

    Read the run ledger: the attached path, else $BB_THREAD_STORAGE/orchestrate-implementation/run.json.

    line 33
  3. Very specific:

    Create one managed worktree at the target head and record verification in the ledger.

    line 40
  4. Very specific:

    Write tickets.<id>.verification, then continue with the next merge.

    line 65

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Verify Landing

Take a land-stack run from "every PR is merged" to "every merge is proven green on the target". Each merge verifies oldest first in its own visible BB thread sharing one verify worktree at the target head.

Contract

  • Verify oldest first. A merge is proven only when its merge-commit checks are green net of ci_baseline and quarantine, and smoke validation passes.
  • A red target gets a response, never silence. Follow references/red-main.md: fix forward only when the cause is known and one ticket heals it, else revert first and file the fix.
  • Work from the ledger: read run.json, write every transition.

References

../bb-worker-protocol/references/bb-workers.md runs each verify worker, ../bb-worker-protocol/references/github.md decides how the gh commands below actually run, and ../bb-worker-protocol/references/run-lifecycle.md carries the run between turns. The ledger schema is ../bb-worker-protocol/references/run-ledger.md; verification fills tickets.<id>.verification and the top-level verification object.

Prepare

  1. Read the run ledger: the attached path, else $BB_THREAD_STORAGE/orchestrate-implementation/run.json. Require state: landed, or verification already present for resume. Reconcile every merge with gh pr view before the first transition.
  2. Resolve smoke: the ticket's own smoke line, else the project's documented smoke check, else the fastest validation subset that proves the target boots and the landed behavior holds. Record the command.
  3. Create one managed worktree at the target head and record verification in the ledger.

Verify one merge

For the oldest unverified ticket in order:

  1. Spawn a verify worker:
Verify merge <sha> on <target>: merge-commit checks plus <smoke command>.
Report check conclusions, smoke output, and failure evidence.
Keep the worktree unchanged.
  1. The worker proves:

    gh api repos/{owner}/{repo}/commits/<merge-sha>/check-runs --jq '.check_runs[] | "\(.name): \(.conclusion)"'
    <smoke command>

    Require no failing check outside the run's ci_baseline and quarantine, and a green smoke run. A failure named in either is inherited or flaky: report it with its baseline entry or quarantine ticket and continue.

  2. Write tickets.<id>.verification, then continue with the next merge.

Red target

A failing check the merge caused, or a red smoke run, pauses this merge and follows references/red-main.md before any later merge verifies: the stack stays ordered, and one red merge blocks the proof of the rest.

Pause

A failing gate, a missing merge commit, or a red-main response in flight pauses verification. Proven merges stay proven; resume reconciles the ledger and starts at the first unverified ticket.

Finish

Report each merge with its commit, checks, smoke result, and verification state. End with:

VERIFY_GATE:
  verdict: VERIFIED | PAUSED
  merge_commits: <count>
  proven: <count>
  open_response_tickets: <count>

Set verification.state: verified in the ledger.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.