🧠 plan · 🔨 implement · 🔍 review · ✅ QA gate · 🚢 merge
Thirty-five agent skills that run a full PR pipeline. Install them into any repo, with any coding agent.
These skills wrote and shipped a real product. Inside the Open Mercato project, this workflow produced ~800k lines of code with zero hand-written lines, 1700+ merged PRs, 4000 unit tests, 730 integration tests, and weekly releases, with 100+ contributors working through it. This repository extracts the pipeline itself, stripped of everything product-specific, so any team with a GitHub repo can run it.
npx skills add open-mercato/skills --skill '*'Install all thirty-six — the pipeline composes, and every skill is small until invoked. Drop --skill '*' to cherry-pick interactively. Skills install for 22+ coding agents (Claude Code, Cursor, Codex, and others) via skills.sh.
Then, once per repository:
/om-setup-agent-pipeline
It inspects your repo (default branch, validation scripts, GitHub labels), asks a few questions, writes .ai/agentic.config.json, and generates SDLC.md — your team's ticket-flow doc. Every other skill reads the config.
Then ship something:
/om-auto-create-pr "add rate limiting to the login endpoint"
The agent drafts an execution plan, implements it phase by phase in an isolated worktree, runs your validation commands, reviews its own diff, and opens a labeled, reviewed PR.
Update project-installed skills from the project directory:
npx skills update -pFor skills installed globally, update the global installation instead:
npx skills update -gThis refreshes the installed skill files to their latest versions. It does not overwrite artifacts that the setup skill previously generated inside your repository, including .ai/trackers/<tracker>.md and .ai/browsers/<provider>.md. After updating, run:
/om-apply-upgrade-notes
That skill applies the relevant UPGRADE_NOTES.md migrations while preserving local edits.
ℹ️ A few skills drive a real browser through the configured browser provider — om-prepare-test-env, om-integration-tests, and om-auto-qa-pr. Because of that, skills.sh validation may flag them as Medium or High risk. We of course recommend reading any skill before you run it — but we use these exactly as shipped at Open Mercato, with no issues so far.
Working on the skills themselves? Skip the npx skills add round-trip and symlink this checkout straight into your agents' skill directories:
npm run install-skillsThis links every skill in skills/ into ~/.claude/skills (Claude Code) and ~/.codex/skills (Codex). Because they are symlinks, any edit you make in this repo is live on the next skill invocation — no reinstall needed.
Options:
npm run install-skills -- --agent claude # only one agent (claude or codex)
npm run install-skills -- --force # replace existing non-symlink installs
npm run uninstall-skills # remove only the links owned by this repoThe installer never touches skills it does not own: an existing real directory (e.g. installed earlier via npx skills add) is skipped with a warning unless you pass --force, and uninstall removes only symlinks that point into this checkout.
Three entry paths: hand the agent a task brief (om-auto-create-pr), a spec (om-auto-write-spec to author one, om-auto-implement-spec to build one), or a GitHub issue (om-auto-fix-issue). The issue path classifies first — a bug drives the autofix chain, a feature request gets its spec resolved (or autonomously written) and implemented on the same PR. All paths converge on the same review loop and the same QA gate. And when there is no artifact yet — just an idea or a question — om-brainstorm runs the conversation first and hands the pipeline a routing decision plus a brief.
The skills chain: every PR-producing skill ends with a PR: #<number> (link: <url>) reference line the next skill consumes, and every skill checks for a PR a previous skill already opened and continues on it instead of opening a duplicate. A completed autonomous run always leaves a ready, fully labeled PR (pipeline + category + priority + risk + QA meta) with a run-summary comment — and screenshots from the working app when the change is user-facing. Skills claim PRs and issues with an in-progress label, so concurrent agents back off instead of colliding.
flowchart LR
brainstorm["om-brainstorm<br/>(conversation)"] -. "small task" .-> createPR
brainstorm -. "feature" .-> writeSpec
subgraph brief ["From a task brief"]
createPR["om-auto-create-pr"] --> reviewPR["om-auto-review-pr"]
reviewPR -- "changes requested" --> continuePR["om-auto-continue-pr"]
continuePR --> reviewPR
reviewPR -- "approved" --> qaGate{"QA gate"}
qaGate -- "skip-qa" --> mergePR["om-merge-buddy /<br/>om-approve-merge-pr"]
qaGate -- "needs-qa" --> manualQA["manual QA"]
manualQA -- "qa-approved" --> mergePR
end
subgraph issue ["From a GitHub issue: om-auto-fix-issue classifies, then routes"]
classify{"bug or FR?"}
classify -- "bug" --> verifyStep["om-verify-in-repo"]
verifyStep --> rootCause["om-root-cause"]
rootCause --> applyFix["om-fix"]
applyFix --> openPR["om-open-pr"]
classify -- "feature request" --> specExists{"spec exists?"}
specExists -- "no spec" --> writeSpec["om-auto-write-spec<br/>(spec PR + mockups)"]
writeSpec --> implementSpec["om-auto-implement-spec"]
specExists -- "spec exists" --> implementSpec
end
openPR --> reviewPR
implementSpec --> reviewPR
📇 Per-skill cards with parameters: docs/skills/
Naming convention: the om-auto-* prefix means autonomous and non-interactive — hand these a brief, an issue, or nothing at all and they run end-to-end without supervision: they claim their work with the in-progress lock so concurrent agents back off, work in isolated worktrees so your checkout stays untouched, run the validation gate, self-review, make the recommended most-reversible call themselves (documented for override) instead of stopping to ask, and finish with a PR, a review verdict, or a reconciled tracker. Safe to run on a schedule or in CI. Every skill without the auto prefix is interactive: it acts once, may ask you questions, reports, and hands control back.
| Skill | What it does autonomously |
|---|---|
om-auto-create-pr |
Takes a free-form task brief end-to-end: execution plan, isolated worktree, phase-by-phase commits, validation gate, self-review, labeled PR, then an autofix review loop until clean. Resumable. Hands runs whose plan exceeds the configured step threshold to om-auto-create-pr-loop automatically. |
om-auto-create-pr-loop |
Advanced om-auto-create-pr for long spec implementations: run folder with PLAN/HANDOFF/NOTIFY, one commit per step, checkpoint verification every ~5 steps, plan-driven executor dispatch (per-step placement + model-tier hints in the plan), full gate at completion. |
om-auto-fix-issue |
The single issue-to-PR entry point: classifies the issue first, then routes. A bug drives the autofix chain — triage gate, root-cause analysis, minimal fix with regression tests, a ready labeled PR, autofix review loop. A feature request takes the feature route — claims the issue, resolves its spec (autonomously written via om-auto-write-spec when none exists, implemented via om-auto-implement-spec), and verifies the contract on the same PR — reviewed, UI-verified, fully labeled. For a spec without implementation, run om-auto-write-spec directly. Stops cleanly when the issue is already solved or claimed. |
om-auto-write-spec |
Turns a brief or FR issue into a finished spec on a ready PR: autonomous Open-Questions defaults posted for override, UI mockups + current-app screenshots attached as PR evidence, full SDLC labels, chain markers for om-auto-implement-spec. |
om-auto-implement-spec |
Implements an existing spec (by path, name, issue, or spec-PR number; clean stop when not found): reuses the spec PR's branch or runs om-auto-create-pr, then the review autofix loop and UI verification with screenshots on the PR. |
om-auto-continue-pr |
Resumes an in-progress PR from the first unchecked step in its tracking plan and carries it to completion — implementation, validation, review loop, summary comment. A PR with no plan (a human's, another tool's, a crashed run's) is adopted: the goal is reconstructed from its description, comments, review feedback, linked issues and diff, landed as a real plan, then executed. |
om-auto-continue-pr-loop |
Resumes runs started by om-auto-create-pr-loop: orients from HANDOFF.md, picks up at the first non-done Tasks-table row, keeps the per-step commit and checkpoint discipline to completion. |
om-auto-review-pr |
Reviews a PR by number in an isolated worktree, approves or requests changes, manages labels. On changes-requested, its autofix loop iterates fixes and re-review until merge-ready. A spec-only design PR gets a specification review instead of the code checklist: what can go wrong, backward compatibility, what's missing, how the spec can be improved, and whether it is the simplest possible solution — same severity scale and verdict rule, and the autofix loop amends the spec document (never adds implementation). |
om-auto-fix-pr |
Drives one PR to merge-ready: merges the latest base in first, then loops review-autofix (om-auto-review-pr), its own CI-stabilization step (classify each failing check as real bug / test bug / flake / infra, fix the real ones with tests, never fake green), and UI QA (om-auto-qa-pr), re-merging base whenever it advances. Files follow-up issues for non-blocking nits via om-followup-issue-from-pr, keeps the fork carry-forward supersede/credit rules, normalizes labels, and hands off to om-approve-merge-pr — it never merges itself. A --ci-only [--branch <name>] mode drives a plain branch or no-PR change to green CI without the rest of the loop. |
om-pr-autopilot |
The single "just finish this PR" entry point: diagnoses what state one open PR is actually in — unfinished plan steps, missing review, unresolved conversations, red CI, base conflicts, missing labels or QA evidence, merge-ready — then maps that onto an ordered chain of the skills above and runs it, re-diagnosing between steps. Dispatch only: om-auto-continue-pr, om-auto-fix-pr, om-auto-qa-pr, om-followup-issue-from-pr and om-approve-merge-pr do the work. Never merges without --allow-merge; --dry-run diagnoses and mutates nothing. |
om-review-prs |
Sweeps all unreviewed open PRs, newest first, through om-auto-review-pr, respecting claim locks. |
om-close-fixed-issues |
Post-merge housekeeping sweep: closes issues that merged PRs fix, comments on issues whose PRs were closed without merging. |
Interactive helpers (no auto in the name — the other half of the naming convention): they act once, may ask you questions along the way, report, and hand control back to you.
| Skill | What it does |
|---|---|
om-setup-agent-pipeline |
One-per-repo configurator. Inspects the repository, asks a few questions, writes .ai/agentic.config.json, installs tracker and browser-provider descriptors, generates SDLC.md and an AGENTS.md starter when missing. Verifies cross-skill coverage: if an installed skill references one that isn't installed, it prints the exact npx skills add command to fix it. |
om-apply-upgrade-notes |
Post-upgrade migrator. Applies UPGRADE_NOTES.md to the repo: re-syncs installed tracker/browser descriptors while preserving local edits, reports custom-provider gaps, and checks the config against notable upgrades. |
om-merge-buddy |
Scans open PRs and reports which can merge now and which are close but blocked, based on labels, reviews, CI, and mergeability. |
om-pipeline-retro |
Classifies runs the pipeline already finished — clean single pass, hard recovery, loop checkpoints, or a second pass with no recorded cause — and ranks the causes by the wall-clock hours they cost. Read-only; hands the top cause to om-prepare-issue. |
om-approve-merge-pr |
Approves and squash-merges a PR given only its number. Can file a follow-up issue at the same time. |
om-check-and-commit |
Runs the configured validation gate on the current branch, fixes obvious drift, then commits and pushes when green. |
om-followup-issue-from-pr |
Turns a PR or a PR comment into a tracked follow-up issue, assigned to the right person. |
om-brainstorm |
The conversation before any artifact exists: open questions one at a time, alternatives weighed (including building nothing), a challenger subagent attacks the conclusion, then the user confirms a routing decision — a machine-parsed Next: line plus a handoff brief that feeds om-prepare-issue, om-auto-write-spec, om-spec-writing, or om-auto-create-pr. |
om-spec-writing |
Writes and reviews feature specs to staff-engineer standards: skeleton-first with a hard Open Questions gate, phased implementation breakdown that feeds om-auto-create-pr, severity-ranked architectural reviews. |
om-prepare-issue |
Files a single well-formed tracker issue for deferred work: dedupes against existing issues and PRs, links (or authors) a covering spec, otherwise embeds step-by-step guidance, and applies the SDLC labels on creation. |
om-auto-manage-issues |
Brings existing issues up to standard, single or in bulk: applies missing SDLC labels, and for a laconic issue (one line + a screenshot) analyzes the screenshot with the terse text, clarifies the wording non-destructively, and posts the agent's understanding as a comment. Checks spec coverage for feature issues: when one lacks a covering spec it posts a spec-required comment to the issue author (fill up the spec before implementation), or authors the spec itself via om-auto-write-spec with --write-missing-specs (default off). Batch defaults to the last ~25 open, worst-described first, narrowable by state/label/author/limit. Idempotent and claim-aware. |
om-integration-tests |
Creates and runs integration/E2E tests by exploring the running app first — real locators, runtime fixtures, no hardcoded IDs — and reports failures with artifact-based per-test diagnosis. Reuses the shared om-prepare-test-env instance so QA and tests hit the same booted app. |
om-auto-qa-pr |
QAs a change's UI in a real browser without merging. Checks the PR's review state first and runs om-auto-review-pr when the PR is still unreviewed, then boots the app via om-prepare-test-env, derives a scenario from the diff, drives the configured browser provider with screenshots, and produces a pass/fail report. Posts evidence as a PR comment when a tracker is configured; otherwise saves screenshots + JSON/Markdown reports. |
om-auto-update-changelog |
Drafts a CHANGELOG.md release entry for every PR merged since the last release — emoji categories, contributor credits resolved by the Supersede Credit Rule and verified against commit authorship so carry-forwards and umbrella merges credit the author, not the merger — then delegates to om-auto-create-pr to ship it as a docs PR. |
The building blocks behind the autofix chain and the review loop. You can call them directly, but they mainly exist for the other skills to compose.
| Skill | What it does |
|---|---|
om-verify-in-repo |
Read-only triage gate: decides whether a GitHub issue is a real, still-unfixed defect, and stops the chain cleanly when there is nothing to do. |
om-root-cause |
Read-only analysis: locates the bug and the minimal change surface so the fix step never re-explores the repo. |
om-fix |
Implements the minimal change, adds regression tests, runs the validation gate. Does not commit or push. |
om-open-pr |
The shared PR opener: commits, pushes, opens (or reuses) a ready PR with the unified body template, applies the full SDLC label set, posts the run summary, releases the claim lock, and emits the chain markers. |
om-code-review |
The review checklist behind om-auto-review-pr: correctness, security, contract surfaces, plus your repo-local checklist when configured. |
om-prepare-test-env |
Boots the app for QA and tests, any stack: reuses the repo's own environment or generates portable bring-up scripts, then caches builds and validates warm reuse. It autonomously provisions the configured browser provider (agent-browser by default; Playwright supported), writes a shared environment descriptor, and works on macOS, Linux, WSL2, and Windows. |
Same pipeline, different entry points. Each role runs one or two commands; the skills chain the rest automatically. Deeper guides live under docs/roles/.
Turn ideas into well-formed, labeled work — and review the plan before any code is written.
| ⚙️ Runs automatically inside | 🎁 You get | |
|---|---|---|
/om-brainstorm "should we build bulk-archive?" |
read-only repo reading and tracker checks, a challenger subagent | a routing decision with its reasoning, and a brief file the pipeline can run with |
/om-prepare-issue "Bulk-archive orders from the grid" |
dedupe search, om-spec-writing (when a feature needs a spec) |
one well-formed issue with SDLC labels, a linked spec or step-by-step guidance |
/om-auto-manage-issues |
claim-aware label sync, screenshot analysis, implementation-prep comment, spec-coverage check | the backlog triaged: missing labels added, laconic issues clarified, feature issues without a spec get a spec-required comment to their author (or a spec via --write-missing-specs) |
/om-auto-write-spec 123 |
om-spec-writing --autonomous, om-open-pr |
a spec-first PR to review before implementation starts |
More: docs/roles/product-manager.md
Get a written spec with visuals attached — mockups of the new layout next to screenshots of the current app.
| ⚙️ Runs automatically inside | 🎁 You get | |
|---|---|---|
/om-auto-write-spec "Redesign the checkout summary panel" |
om-spec-writing --autonomous, om-open-pr, om-prepare-test-env + browser provider |
a ready spec PR with UI mockups, current-app screenshots, and an assumptions comment |
/om-auto-implement-spec 2026-07-18-checkout-redesign |
om-auto-create-pr, om-auto-review-pr, om-auto-qa-pr |
the built change with before/after screenshots from the working app |
/om-auto-qa-pr 123 |
om-prepare-test-env, browser provider |
fresh screenshots of a PR's UI to design-review, no source touched |
/om-ux-setup once, then /om-ux-review-pr 123 |
om-ux-setup extracts the repo's design contract; om-ux-review-pr walks the PR in a real browser |
a design review judged against your own design system: evidence-tagged findings with done-when criteria |
/om-ux-shape "Quick-add flow for the people list" |
om-ux-shape |
a decided direction before anything is drawn: scope, states, riskiest-assumption test |
💡 Tip — ask for visuals explicitly to force mockups: /om-auto-write-spec "Redesign the checkout summary panel — include mockups of the new layout and screenshots of the current one".
More: docs/roles/designer.md
Hand off a brief, a spec, or an issue number; get back a reviewed, labeled PR.
| ⚙️ Runs automatically inside | 🎁 You get | |
|---|---|---|
/om-auto-write-spec "CSV export for the orders grid" |
om-spec-writing --autonomous, om-open-pr, browser provider for mockups |
a ready spec PR with mockups + assumptions comment |
/om-auto-implement-spec 2026-07-18-csv-export |
om-auto-create-pr / om-auto-continue-pr, om-auto-review-pr, om-auto-qa-pr |
an implemented, reviewed PR with screenshots from the working app |
/om-auto-fix-issue 123 |
classifies then routes: bugs to the autofix chain, features to om-auto-write-spec + om-auto-implement-spec |
a finished, fully-labeled PR from an issue number |
/om-auto-fix-issue 456 |
om-verify-in-repo, om-root-cause, om-fix, om-open-pr, om-auto-review-pr |
a bug-fix PR with regression tests and a clean review |
🔁 /om-auto-create-pr-loop "Implement the multi-tenant billing spec" |
run folder (PLAN/HANDOFF/NOTIFY), per-step commits, checkpoint verification | a resumable, step-tracked PR for a large spec (continue with om-auto-continue-pr-loop; plain runs escalate here on their own past the step threshold) |
More: docs/roles/developer.md
Boot the app once, verify UI changes in a real browser, and add integration coverage — without touching source.
| ⚙️ Runs automatically inside | 🎁 You get | |
|---|---|---|
/om-prepare-test-env |
app discovery, launch-script generation, browser-provider provisioning | a reusable booted app + shared test-env descriptor the other QA skills reuse |
/om-auto-qa-pr 123 |
om-prepare-test-env, browser provider |
screenshots + a pass/fail report posted on the PR (evidence only, no labels changed) |
/om-auto-qa-pr 123 --self-qa-signoff |
same, plus label guards | qa-approved + qa-self-verified — only on a fully-green run with screenshots on a needs-qa PR |
/om-integration-tests |
om-prepare-test-env, browser provider |
integration/E2E tests written against the live app, with artifact-based failure diagnosis |
More: docs/roles/qa.md
Sweep open PRs, drive them to merge-ready, and ship — the QA gate stays a human decision.
| ⚙️ Runs automatically inside | 🎁 You get | |
|---|---|---|
/om-merge-buddy |
tracker scan of labels, reviews, CI, mergeability | a report of which PRs can merge now and which are close but blocked |
/om-review-prs |
om-auto-review-pr per PR, claim-lock aware |
every unreviewed open PR reviewed, newest first |
/om-auto-fix-pr 123 |
om-auto-review-pr, its CI-stabilization step, om-auto-qa-pr, om-followup-issue-from-pr |
one PR driven to approvable, green, QA-evidenced — handed to om-approve-merge-pr, never self-merged |
/om-auto-fix-pr 123 --ci-only |
tracker check status + failed-step logs | green CI from real fixes with tests, never by weakening checks |
/om-pr-autopilot 123 |
diagnosis of the PR's real state, then the matching chain of the skills above | one PR driven from wherever it is to merge-ready, with a summary comment covering every step — never merged unless --allow-merge |
/om-auto-update-changelog |
om-auto-create-pr |
a CHANGELOG release entry landed as a docs PR, with Supersede Credit |
/om-approve-merge-pr 123 |
approving review + squash-merge, QA-gate guard | the PR merged — refused when needs-qa lacks qa-approved or a blocking label is set |
More: docs/roles/release-manager.md
Nothing here assumes JavaScript, or any particular product. The base branch, the validation commands, the label taxonomy, and the working paths all come from one committed file, .ai/agentic.config.json, written by om-setup-agent-pipeline:
{
"version": 1,
"baseBranch": "auto",
"tracker": "github",
"browser": { "provider": "agent-browser" },
"validation": {
"commands": ["pnpm typecheck", "pnpm test", "pnpm build"]
},
"labels": {
"enabled": true,
"pipeline": ["review", "changes-requested", "qa", "qa-failed", "merge-queue", "blocked", "do-not-merge"],
"category": ["bug", "feature", "refactor", "security", "dependencies", "documentation"],
"meta": ["needs-qa", "skip-qa", "qa-approved", "qa-self-verified", "in-progress"],
"priority": ["priority-low", "priority-medium", "priority-high", "priority-extreme"],
"risk": ["risk-low", "risk-medium", "risk-high"]
},
"qaGate": true,
"paths": {
"runs": ".ai/runs",
"analysis": ".ai/analysis",
"specs": ".ai/specs",
"scripts": ".ai/scripts",
"qa": ".ai/qa"
},
"reviewChecklist": null,
"closeKeywords": []
}A Rust repo puts cargo test and cargo clippy in validation.commands; a Go repo puts go test ./.... Skills run whatever you configure and treat any non-zero exit as a gate failure. A skill invoked in a repo without the config runs om-setup-agent-pipeline first — interactively when you're there to answer its questions, with --defaults when running unattended — then continues with the freshly written config.
GitHub is the default tracker, but nothing in the skills is hard-wired to it — see the tracker providers section below.
Agent-browser is the default browser automation provider for fresh setups. It installs itself and Chrome for Testing when needed; existing repositories remain on Playwright until their config makes a provider explicit.
Four layers of project fit, no forking:
- Agent instructions — skills read your
AGENTS.md/CLAUDE.mdbefore working, so project conventions apply from the first run. No such file?om-setup-agent-pipelineoffers a starter. - Generated project docs —
SDLC.md(the process doc),CODE_REVIEW.md(review rules, auto-applied byom-code-review),BACKWARD_COMPATIBILITY.md(protected contract surfaces — reviews flag violations, implementations warn you), and anAGENTS.mdstarter with a task-routing table.om-setup-agent-pipelinederives each from your repository and only when the file is missing; existing docs are honored as-is. - Repo-local skills — drop a skill with the same name into your repo at
.ai/skills/<skill-name>/SKILL.mdand it takes precedence over the installed one (details below). - Tracker descriptor — every issue/PR/label command the skills run lives in one committed file,
.ai/trackers/<tracker>.md, that you can edit or replace (details below).
Each skill keeps its numbered main algorithm in SKILL.md and factors its repeatable procedures into per-skill references/<step>.md files under standard names — agentic-setup.md, worktree-setup.md, claim-pr.md, pr-finalize.md, review-report.md, rules.md. These standard step files are deliberately duplicated inside every skill that uses them rather than shared through cross-skill pointers, so each skill installs and runs standalone (om-auto-create-pr holds the canonical copy). The trade-off is intentional: standalone installability over DRY. When you edit a standard step file in one skill, sync the same change into the other skills that carry it — the collection's own contributor rule is to ask whether to propagate before doing so.
Every installed skill checks, right after loading the config, for a repo-local skill of the same name at .ai/skills/<skill-name>/SKILL.md. When present, the local skill wins — the installed one follows it instead of its own instructions. To extend rather than replace, the local skill just @-imports or references the installed skill and adds rules on top:
<!-- .ai/skills/om-auto-review-pr/SKILL.md -->
Follow the installed `om-auto-review-pr` skill, plus:
- Also run `pnpm test:e2e` before approving PRs that touch `apps/web`.
- Our PR body template additionally requires a "Screenshots" section for UI changes.Local rules win, but a local skill can never relax the installed skill's safety rules (no skipping tests, no --no-verify, no force-pushes). This convention is also what makes the collection a drop-in for repos that already keep specialized om-* skills under .ai/skills/: the installed skills defer to them automatically.
No skill calls gh — or any tracker CLI — directly. Skills name tracker operations (get-issue, create-pr, comment-pr, merge-pr, …) and one committed descriptor file, .ai/trackers/<tracker>.md, defines how each operation is executed. om-setup-agent-pipeline asks which tracker you use, sets the config's tracker field, and installs the matching descriptor into your repo.
That file is yours, which makes three things easy:
- Extend or override GitHub behavior — edit
.ai/trackers/github.md: add flags, change the merge strategy, adjust comment conventions, extend the label taxonomy commands. Every skill picks it up on its next run. - Bring your own tracker (Linear, Jira, …) — write
.ai/trackers/<name>.mdfrom the shippedTEMPLATE.md(inom-setup-agent-pipeline/references/trackers/), implementing each operation with your tracker's CLI, MCP tools, or API, and set"tracker": "<name>"in the config. No skill changes needed — the descriptor is the whole integration surface. - Split setups — issues in Linear, PRs on GitHub: implement the issue operations against Linear and delegate the PR sections to the GitHub descriptor. The template documents this pattern, including how identifiers cross-link (a
ENG-123ticket referenced from a GitHub PR).
The claim protocol (assignee + in-progress + 🤖 comment), the label guards (missing label ⇒ logged skip, labels.enabled: false ⇒ no label ops), and the QA gate semantics are part of the contract — a provider must express them, in whatever way its tracker allows.
QA and integration-test skills select browser.provider from
.ai/agentic.config.json and execute the committed descriptor at
.ai/browsers/<provider>.md. Fresh setups use agent-browser; Playwright remains
available for existing repositories and teams that prefer it. The agent-browser
descriptor downloads its native release binary and Chrome for Testing itself,
then verifies a live headless launch — no Node runtime, project dependency, or
cloud-browser subscription is required.
Custom providers implement the operations in
skills/om-setup-agent-pipeline/references/browsers/TEMPLATE.md. Repository E2E
suites remain authoritative; the provider controls agent-driven exploration,
assertions, and screenshots.
Every PR carries at most one pipeline label (review, changes-requested, merge-queue, ...) plus additive category, meta, priority, and risk labels; priority says how urgent the work is, risk says how dangerous the change is to ship. The full taxonomy, and whether to use labels at all, lives in the config; om-setup-agent-pipeline documents every group and creates missing labels for you.
The QA gate is the one hard rule: a PR labeled needs-qa cannot merge until a human adds qa-approved, no matter how green the checks are. Automated skills request QA; they never grant it.
Real production case studies are being added here.
Built by the Open Mercato team, where these skills ship the product every week. We teach this way of working at aitechleaders.pl (an AI engineering course, in Polish).