memoryJedna statická binárka – nad vaším coding CLI

mcptask runner – AI vývojář na vašem stroji. Dotahuje úkoly až do zmergovaného PR.

mcptask runner promění vaše coding CLI – Claude Code, Codex CLI nebo OpenCode – v samostatného člena týmu. Funguje s Claude, Kimi, DeepSeekem, lokální Ollamou nebo s jakýmkoli modelem – bez vazby na jednoho dodavatele. Vybere úkol, napíše kód i testy a otevře PR. V režimech auto-squash ho po zeleném CI zmerguje, v manuálních režimech nechá PR otevřené k vaší kontrole. Zadáte dobře specifikovanou práci, dostanete zelené PR.

mcptask runner nenahrazuje váš tým – násobí ho.

Úkoly si runner bere z mcptask.online – to je jeho jediný zdroj. Jira, Linear ani GitHub Issues přímo nečte.

Instalace jedním příkazem:

curl -fsSL https://github.com/jchsoft/mcptask-releases/releases/latest/download/install.sh | sh

Na macOS také přes Homebrew:brew install jchsoft/tap/mcptask_runner

Mac během úkolu usíná? Nechte ho vzhůru jen po dobu běhu programovacího CLI: nastavtelauncher.command: [caffeinate, -i, claude]v config/mcptask_runner.yml.Jak se nastavuje naplánovaná úloha

Vyzkoušet 30 dní zdarma – bez karty terminalNainstalovat Runner v projektu

verified_user30 dní zdarma. Bez kreditní karty. Kdykoli zrušíte.

terminal

mcptask_runnermcptask_runner run today_auto_squash

→ Triage: difficulty=13, model=opus, complexity=high

→ Picking next task#142 (Export faktur do CSV)

→ Snapshotstarting → triage → processing

→ Branchfeature/142-invoice-csv-export

→ CI✓ green

→ PR auto-merged✓

→ Quota: 18% of daily budget used

1 příkazna start

payments

Runner platíte jako každého dalšího uživatele

mcptask runner je v účtu uživatel a tarif ho počítá úplně stejně jako kohokoli z týmu – žádná zvláštní položka, žádná sleva ani přirážka.

Tokeny modelu platíte ze svého vlastního předplatného Claude, Codex nebo OpenCode. mcptask.online za ně nic neúčtuje.

Ceník a tarifyarrow_forward

storageVaše reálné prostředí

Na vašem stroji, proti realitě

Agenti v cloudu běží ve sterilních sandboxech. Runner běží ve vašem reálném projektu.

storage

Reálná databáze

Pracuje s databází, kterou váš projekt už používá – se schématem, seed daty i migrační historií, které ji zformovaly. (PostgreSQL je jeden konkrétní příklad; runner řídí to, co běží ve vašem projektu.)

fact_check

Reálné systémové testy

Spouští vstupní body testů vašeho projektu, od začátku do konce – Capybara a Selenium proti vaší reálné aplikaci jako jeden konkrétní příklad, se screenshoty a kontrolami v prohlížeči, které dokazují, že se změna opravdu projevila v aplikaci.

code

Reálné commity a PR

Větve, commity a pull requesty žijí ve vašem repozitáři, s vaším CI a ve vaší historii gitu – na GitHubu, na Bitbucket Cloudu, nebo na GitLabu, a na všech je otevírá `mcptask_runner pr`. Runner spouští to, co spouští váš `bin/ci`.

infoCo to je

Plný autonomní harness nad vaším coding CLI

mcptask runner je jedna statická binárka bez runtime závislostí – řídí coding CLI na vašem stroji a projde celý agentní cyklus: najde úkol → posoudí složitost → zvolí model → spustí coding CLI → hlídá běh watchdogem → dodrží denní kvótu → (volitelně) po zeleném CI zmerguje PR. Funguje s jakýmkoli projektem, který používá git, na GitHubu, na Bitbucket Cloudu, nebo na GitLabu – za běhu nikde nepotřebuje Ruby, bundler ani Gemfile, metadata projektu se berou z CLAUDE.md a `bin/ci` je konvence (když `bin/ci` chybí, krok se přeskočí). Žádný prompt, který runner skládá, už nejmenuje příkaz konkrétního frameworku: projekt, který se před browser testy potřebuje připravit, si to řekne sám – ve svém CLAUDE.md, nebo v příkazu, který předá `/test-runner`.

Šest buildů na vydání – macOS, Linux a Windows, každý pro amd64 i arm64. Nainstalujete ho instalačním skriptem, přes Homebrew (macOS), scoop (Windows) nebo npm (npx @mcptask/cli); gem mcptask-rails-runner je jen další kanál pro Rails projekty, ne podmínka.

auto_awesome

Není to jen „tupý spouštěč“ coding CLI. Přidává orchestraci, dohled, zotavení a řízení kvality, které holé CLI nemá.

tuneVaše coding CLI

Vyberte CLI, které bude řídit váš projekt

Harness je coding CLI, které runner řídí. V binárce jsou tři profily – Claude Code, Codex CLI a OpenCode – a vlastní profil žije buď pro celý stroj v ~/.mcptask/harnesses/, nebo pro jeden projekt v config/harnesses/. Volba se dělá jednou pro každý stroj a projekt, udělá ji init a zapíše harness: do config/mcptask_runner.yml. Ten soubor patří jednomu stroji, je v .gitignore, takže dva vývojáři nad stejným repozitářem mohou řídit různá CLI.

terminalJeden příkaz

mcptask_runner init --cli codex

layersTři přibalené profily

auto_awesome

Claude Code

mcptask_runner init --cli claude

Skills: 12 v .claude/skills
MCP konfigurace: .mcp.json
Instrukce: CLAUDE.md
Modely: aliasy opus / sonnet / haiku
Oprávnění: .claude/settings.local.json

terminal

Codex CLI

mcptask_runner init --cli codex

Skills: 9 v .agents/skills
MCP konfigurace: .codex/config.toml
Instrukce: ukazatel v AGENTS.md
Modely: gpt-6-astra, gpt-5.6-terra, gpt-5.6-luna
Preflight: codex login status musí projít

code

OpenCode

mcptask_runner init --cli opencode

Skills: 9 v .claude/skills
MCP konfigurace: opencode.json
Instrukce: CLAUDE.md
Modely: provider/model
Oprávnění: permission mapu vloží runner

loginPřihlášeno jednou, vámi

CLI musí být nainstalované a už přihlášené tím, komu stroj patří. Runner nikdy nic nepřihlašuje – credential, který by si vymyslel, by autentizoval jako někdo jiný – a každé CLI má vlastní jednorázové přihlášení.

Claude Code: vlastní login Claude CodeNedeklaruje žádnou sondu – žádnou nepotřebuje.
Codex CLI: codex logincodex login status musí skončit nulou, než běh začne; preflight běh raději odmítne, než aby ho spustil.
OpenCode: opencode auth loginPreflight ověří jen to, že binárka odpoví na --version; chybějící přihlášení selže při prvním spuštění a řekne to.

Kde profil deklaruje sondu, runner ji ověří při startu a bez ní odmítne běžet, takže nepřihlášené CLI odmítne jménem, místo aby ho nechal spadnout při prvním volání.

report_problemŽádný default neexistuje

Projekt, který CLI nikdy nepojmenoval, runner odmítne jménem – nepředpokládá tiše Claude Code. launcher.command zůstává override samotného argv a je křížově kontrolován proti harness: – nemůže protlačit jiné CLI, než jaké projekt deklaroval.

hubCo je na všech třech stejné

Profil drží binárku, argv, resume flag, literály selhání, jména nástrojů a skillů a to, co zapisuje init. Všechno, co dělá runner runnerem, je nad profilem a s volbou CLI se nemění: karta na dashboardu, záznam effortů, run log i bug úkol vypadají stejně, ať běží kterýkoli harness.

enginewatchdogpracovní smyčkakarta na dashboarduzáznam effortůbug úkolrun log

ruleLimity, řečené naplno

call_split

Fork skills jsou jen na Claude Code

discover, memory-search a mcptask-read forkují levného subagenta, aby se surový výstup nikdy nedostal do rodičovského kontextu. To umí jen Claude Code, takže profily Codex a OpenCode mají devět skillů místo dvanácti. Devět helper skriptů je na všech třech stejných.

Codex potřebuje funkční login

codex login status musí projít, než běh začne. Preflight raději odmítne, než aby spotřeboval kvótu na CLI, které spadne při prvním volání.

lock_open

OpenCode nemá read-only flag

Není co předat, takže runner místo toho vloží permission mapu. Read-only garance je stejná; mechanismus ne.

verifiedOvěřeno, nejen tvrzeno

Conformance a chaos suity běží v CI proti všem třem dialektům a profily nejsou funkce na papíře: reálný běh na Codexu dokončil úkol 9. 9. 2026 a OpenCode má za sebou vlastní reálné běhy.

merge_typePull requesty

Pull requesty na GitHubu, na Bitbucketu nebo na GitLabu

Runner pracuje s repozitářem na GitHubu, na Bitbucket Cloudu nebo na GitLabu (gitlab.com i self-managed) a pull request na všech otevírá jeden příkaz: mcptask_runner pr. Žádný prompt ani přibalený skill už nejmenuje CLI konkrétního hostitele – binárka se hostitele zeptá sama, takže stejné instrukce fungují bez ohledu na to, kde váš repozitář žije.

terminalPR neotevře nic jiného než mcptask_runner pr

Je to pátý veřejný subcommand. Každý subcommand vypíše na stdout jeden JSON objekt, chyby jdou na stderr s nenulovým exit kódem a --git-host přepíše hostitele pro jedno zavolání. Samotné git_host: je nepovinné – runner ho odvodí z git remote get-url origin a init --git-host bitbucket|gitlab je tu pro aliasy, zrcadla a self-managed instance.

list_altŠest subcommandů

pr create

Otevře pull request pro aktuální větev.

pr list

Vypíše pull requesty, filtrované přes --task, --branch, --open nebo --state.

pr view

Přečte jeden pull request jako JSON.

pr reviews

Přečte review, která na pull requestu zůstala.

pr merge

Zmerguje ho – --squash a --delete-branch jsou default, protože právě to auto-squash znamená.

pr checks

Zeptá se hostitele, co jeho checky říkají o head commitu.

keyTři hostitelé, tři způsoby přihlášení

hub

GitHub

Autentizace přes gh a jeho vlastní login. Šablona pull requestu se čte z .github/pull_request_template.md, což je cesta, kterou zná jen GitHub.

cloud

Bitbucket Cloud

REST API 2.0, s jedním ze dvou přihlášení a nikdy s oběma: BITBUCKET_ACCESS_TOKEN pro stroj (Bearer), nebo BITBUCKET_EMAIL a BITBUCKET_API_TOKEN pro člověka (Basic). App passwords jsou odmítnuté – Atlassian je 9. 6. 2026 ukončil. init zapíše ~/.mcptask_env.d/bitbucket_credentials s právy 0600 (kontrola práv se na Windows přeskakuje), nikdy nepřepíše existující hodnotu ničím a nikdy přihlašovací údaj nevypíše. Mimo GitHub se šablona deklaruje jako pr_template: path:.

account_tree

GitLab

Řídí ho CLI glab, které si drží vlastní přihlášení – glab auth login, a runner si žádný GitLab credential neukládá. Funguje gitlab.com i self-managed instance: self-managed projekt deklaruje git_host: gitlab (mcptask_runner init --git-host gitlab), protože jeho origin URL není gitlab.com, a runner po vás URL instance nikdy nechce – glab už ví, kam je přihlášený. To, co tam pr create otevře, je merge request.

fact_checkAuto-squash se před mergem zeptá hostitele

Merge není naděje, že CI bylo zelené. Runner si nejdřív přečte checky hostitele pro head commit: FAILED ukončí běh jako ci_failed a PR nechá otevřené, IN_PROGRESS zkusí desetkrát po dvou minutách a NONE – repozitář, který u hostitele žádné checky nemá – spadne na lokální gate: zelené bin/ci merge pustí a projekt bez bin/ci skončí jako merge_skipped_no_ci, s PR otevřeným, aby ho zmergoval člověk. GitLab hlásí jeden stav pipeline na merge request, takže výpis checků je tam jeden řádek, ne seznam.

report_problemGitHub Enterprise není github.com – pokud to sami neřeknete

Když se hostitel odvozuje z URL originu, pozná se podle přesného hostname, takže instanci GitHub Enterprise runner odmítne se zprávou, která to říká, místo aby ji považoval za github.com. Explicitní git_host: github toto odvození přeskočí a runner vám uvěří. PR otevřené proti špatnému API hostitele je horší než běh, který odmítne začít.

info

Kde končí runner a začíná mcptask.online

Tady jde o runner pracující s repozitářem na Bitbucket Cloudu – ne o Bitbucket integraci na úrovni mcptask.online. Párování commitů a pull requestů zpět na úkoly jede na webhoocích a ty zůstávají GitHub a GitLab.

loopSmyčka + cíl

Smyčka bere úkoly, cíl je dotahuje

mcptask runner spojuje pracovní smyčku (bere úkol za úkolem z fronty) s cílem (dotahuje každý úkol až do zeleného PR, nejen k „nějakým úpravám“). Zvolte režim podle toho, jak dlouho má běžet:

Tvar smyčky	Režim	Auto-squash vs. ruční	Povinný přepínač
play_circleSpustí jednoho vykonavatele a skončí	`once`	ruční	–
	`once_dry`	ruční	–
	`once_auto_squash`	auto-squash	–
	`review`	ruční	–
repeatIteruje, dokud nenastane stop-status	`today`	ruční	–
	`today_auto_squash`	auto-squash	–
	`queue_manual` aliasy: queue	ruční	–
	`queue_auto_squash`	auto-squash	–
	`workflow`	ruční	–
	`reviews`	ruční	–
account_treeProjde podúkoly story	`story_manual` aliasy: story	ruční	`--story-id`
	`story_auto_squash`	auto-squash	`--story-id`
	`task_manual` aliasy: task	ruční	`--task-id`
	`task_auto_squash`	auto-squash	`--task-id`
todayDělá to celý den, každý den	`daily`	ruční	–

infoNěkteré režimy se chovají jinak, než napovídá tvar, do kterého jsou zařazené

boltonce_dry, review a reviews úplně přeskočí triage. once_dry jen ukáže další úkol a skončí; oba revizní režimy jdou rovnou na pull requesty, které revizi potřebují.
layersworkflow má dvě fáze: nejdřív revize (PR, která blokují člověka), potom dnešní úkoly.
scheduledaily nekončí s koncem dne – smyčku ukončí jen pád, signál, nepovedené předání, požadavek na zastavení, odmítnutí ze strany účtu nebo odmítnuté hlášení chyby. Cestou do noční pauzy se navíc může předat novější binárce, kterou už má na disku (viz samoaktualizace níže); smyčka, která se zítra probudí, je stále ta samá smyčka, jen běží na novějším kódu.
all_inclusivequeue_manual a queue_auto_squash nejsou nijak časově omezené; běží, dokud přicházejí úkoly.

menu_book

Kompletní seznam funkcí a přehled změn

Všechny funkce, co se změnilo v každé verzi, úplná reference příkazové řádky a technické podrobnosti o kvótě, logech a samoaktualizaci na samostatné stránce.

Otevřít dokumentaci runneruarrow_forward

Technické FAQ

Krátké odpovědi na otázky, které stránka otevírá, ale na které přímo neodpovídá. Každá odpověď odkazuje na sekci, které otázka patří, a neopakuje ji.

help_outline

Potřebuje runner Ruby, bundler nebo Gemfile?

Ne. Metadata projektu čte z CLAUDE.md a konfiguraci z config/mcptask_runner.yml – ani jedno z toho neprochází přes Ruby. Žádný prompt nejmenuje ani příkaz konkrétního frameworku: projekt, který před browser testy potřebuje build krok, si ho deklaruje ve vlastním CLAUDE.md.

Viz Plný autonomní harness nad vaším coding CLI

help_outline

Funguje na projektu mimo Rails?

Ano – na libovolném projektu pod gitem, na GitHubu, na Bitbucket Cloudu, nebo na GitLabu (gitlab.com i self-managed), s jedním ze tří podporovaných coding CLI nainstalovaným a přihlášeným na hostiteli a s CLAUDE.md, který deklaruje account_code a project_relative_id. Žádné výchozí CLI neexistuje: vybírá ho init --cli claude|codex|opencode, launcher.command přepisuje jen argv a je křížově kontrolován proti harness:.

Viz Vyberte CLI, které bude řídit váš projekt

help_outline

Mohou dva runnery sdílet jeden checkout?

Ne. Druhý runner odmítne nastartovat; lock.go (AcquireInstanceLock) vynucuje jeden runner na checkout.

Viz Proč to není kouzlo

help_outline

Co se stane, když denní kvóta dojde uprostřed úkolu?

Runner zabije potomka, pokus skončí se statusem quota_exceeded_mid_task bez retry (bug úkol se nezakládá) a smyčka končí. Sám se vrátí jen režim daily: počká do dalšího dne a začne znovu triáží. Ostatní režimy pokračují až dalším naplánovaným spuštěním.

Viz Jedno číslo, tři místa, kde se ověřuje

help_outline

Co po pádu zůstane a kdo se to dozví?

Tvrdý pád (status error, status crash nebo status anomaly – vlastní pojistka runneru, která v běhu neplatila, a běh přesto pokračoval) založí vlastní bug úkol s připojeným run logem a otiskem; stejný pád se nahlásí nejvýš jednou za šest hodin. Reportér nemůže nahlásit bug, který říká, že chybí jeho vlastní token – ten se projeví exit kódem a logem.

Viz Co je vidět za běhu, Když nastane tvrdý pád, bug úkol se založí sám

help_outline

Aktualizuje se sám bez dozoru?

Ne, záměrně. `update` se ve výchozím stavu dotýká jen skillů a helperů; `update --self` aktualizuje binárku v terminálu uživatele, ne v běhu na pozadí.

Viz update --self a záměrně chybějící automatika

help_outline

Na kterých OS běží a co nepokryje zelený lokální běh testů?

macOS (launchd), Linux (systemd user timer) a Windows (Task Scheduler) mají každý vlastní naplánovanou úlohu. Zelený lokální běh testů pokryje unit a systémové testy na té verzi Go, kterou má hostitel; nepokryje matici tří OS × dvou verzí Go ani čtrnáct konformančních scénářů, které hlídají vydání.

Viz Konformanční scénáře a matice CI

rocket_launch

Ráno zapněte stroj

Jeden statický binární soubor, jeden instalační řádek, a runner začne brát úkoly z vaší fronty.

Vyzkoušet 30 dní zdarma – bez karty Nainstalovat Runner v projektu

codePošlete stránku svému vývojáři

verified_user30 dní zdarma. Bez kreditní karty. Kdykoli zrušíte.