Ponytail: Pinakatamad na Senior Dev Agent Skill

Ano ang Ponytail

Ang Ponytail ay isang set ng mga rule na nagtutulak sa AI coding agent na magsulat ng mas kaunting code. Inilalarawan ng project ang sarili nito sa isang linya: "Pinag-iisip nito ang iyong AI agent na gaya ng pinakatamad na senior dev sa team. Ang pinakamagandang code ay ang code na hindi mo kailanman isinulat." May MIT license ito. Wala itong sariling runtime, at walang anumang code rito ang ine-execute. Teksto lamang ito na inilalagay sa instructions ng agent, naka-package bilang skill para sa mga host na naglo-load ng skills, at bilang plain rule files para sa mga host na hindi naglo-load ng skills.

Ang repository ay DietrichGebert/ponytail. Nilikha ito noong 12 June 2026 at umabot sa 90,000 stars pagsapit ng 1 August 2026. Noong 1 August 2026, ang pinakabagong tagged release ay v4.8.4, na inilabas noong 29 June 2026, at naglista ang releases page ng sampung tag mula 14 hanggang 29 June lamang. Hindi bumagal ang development: noong 17 October 2026, ang pinakabagong release ay v5.3.2, na inilabas noong huling bahagi ng 16 October, ang ikatlong release noong araw na iyon pagkatapos ng v5.3.0 at v5.3.1. Bago nito, inilabas ang v5.2.0 noong 13 October, limang araw matapos parehong ilabas ang v5.0.0 at v5.1.0 noong 8 October, at ipinapakita ng repository na mayroon na itong mahigit 165,000 stars. Ang project na gumagalaw sa ganitong bilis ay maaaring nagbago na pagdating sa oras na mabasa mo ito, kaya mag-pin ng tag bago ka bumuo ng anuman batay rito.

Ang ideya bago ang tool: huminto sa unang baitang na sapat

Ang pangunahing ideya ng Ponytail ay isang decision ladder. Umaakyat dito ang agent bago magsulat ng anuman at humihinto sa unang baitang na sapat.

1. Kailangan ba talaga itong umiral? Ito ang YAGNI (hindi mo ito kakailanganin). Kung hindi, laktawan ito.
2. Umiiral na ba ito sa codebase na ito? Gamitin muli ang helper o pattern na naroon na.
3. Kaya ba ito ng standard library? Gamitin ito.
4. May native platform feature bang sumasaklaw dito? Gamitin ito.
5. May naka-install na dependency bang lumulutas dito? Gamitin ito.
6. Maaari ba itong maging isang line? Gawin itong isang line.
7. Saka lamang magsulat ng minimum na code na gumagana.

Iyan ang ladder ayon sa pagkakasulat sa v4.8.4, at sinusunod ng mga rung number sa natitirang bahagi ng artikulong ito ang pagkakasunod na iyon. Pinagsasama ng kasalukuyang main branch ang rung 3 at 4: "Standard library o platform feature? Gamitin ito, maliban kung may sarili ang project," at idinadagdag na "mas mainam ang house component kaysa native widget", kaya anim na rung na ito. Pareho pa rin ang pagkakasunod.

Ang pagkakasunod ang gumagawa ng trabaho, hindi ang alinmang isang rung. Kapag inutusan ang isang agent na gumawa ng date picker, gagawa ito ng date picker dahil iyon ang ipinagawa rito. Pinapatingnan muna ng ladder kung ano ang umiiral na bago ito bumuo ng anuman: itinatanong ng rung 2 kung mayroon nang component para rito ang repository, at sinasabi ng rung 4 na mayroon nang <input type="date"> ang browser. Eksaktong ganitong kaso ang nasa kasalukuyang benchmark notes ng project: ang date picker na umabot sa 335 lines nang walang rule ay naging 10 lines gamit ang Ponytail 5, dahil ginamit muli ng agent ang sariling Input component ng repository kasama ang type="date" at hinayaang browser ang magbigay ng calendar. Mas kaunti ang ibinaba ng colour picker, mula 135 lines tungo sa 26. Ang rung 2 ang tahimik na nabibigo, dahil ang agent na hindi nakikita ang helper na mayroon ka na ay basta na lamang magsusulat ng pangalawa, at ito ang puwang na nilalayong punan ng queryable map ng iyong codebase.

Hindi nangangahulugang pabaya ang pagiging mabagal dito, at malinaw itong sinasabi ng ruleset. Kasama sa listahan nitong "never lazy about" ang pag-unawa sa problema bago magpasya, input validation sa trust boundaries, error handling na pumipigil sa pagkawala ng data, security, accessibility, at anumang tahasang ipinagawa mo. Hinihingi rin nito ang isang maliit na runnable check para sa bawat piraso ng non-trivial logic. Binabawasan ng rule ang pag-iimbento. Hindi nito binabawasan ang correctness.

Ang aktuwal na nire-release ng repository

• AGENTS.md, ang palaging aktibong ruleset na naglalaman ng buong konsepto sa isang file na mababasa sa loob ng limang minuto.
• skills/ponytail/SKILL.md, ang skill definition, na may argument hint na lite, full, ultra o off.
• Mga rule file sa ilalim ng mga directory na partikular sa editor gaya ng .cursor/rules/ at .windsurf/rules/, para sa mga host na nagbabasa ng rules pero hindi naglo-load ng skills.
• hooks/, benchmarks/, examples/ at scripts/.

Binabago ng intensity argument kung gaano kalakas ipinatutupad ng rule ang mga requirement. Binubuo ng lite ang hiniling mo at tinutukoy nito sa isang linya ang mas kaunting trabaho na opsyon. Ang full ang default at ipinapatupad nito ang ladder. Ang ultra ang ekstremistang YAGNI setting: mas pinipili nito ang pagbura kaysa pagdaragdag at kinukuwestiyon pa nito mismo ang requirement.

May slash command din ang mga host na kayang gumamit ng skills. Itinatakda ng /ponytail ang level, sinusuri ng /ponytail-review ang diff para sa over-engineering, sinusuri ng /ponytail-audit ang buong repository, kinokolekta ng /ponytail-debt ang mga shortcut na ipinagpaliban mo, at ipinapakita ng /ponytail-gain ang benchmark scorecard. Ang mga host na rule file lamang ang binabasa ay nakakakuha ng ruleset pero walang commands. Mula nang ilabas ang v5.3.0 noong 16 October 2026, may band sa itaas ng prompt ang Claude Code na nagpapakita ng task cost, code reuse at test status. Kailangan nito ang Claude Code 2.1.290 o mas bago. Hindi ito lumalabas sa VS Code chat panel, cloud sessions o claude -p, at itinatago ito ng /ponytail band off. Mula nang ilabas ang v5.3.2, isang beses binabasa ng /ponytail band import ang mga nakaraang Claude Code session mo at idinaragdag ang mga ito sa board kasama ang cost, agent time at tokens ng mga ito, para maikumpara mo ang mga ito sa mga session na pinatakbo gamit ang rule.

Para mabasa ang source bago ito pagkatiwalaan, i-clone ang tag sa halip na ang branch. Ito ang tag na pinagmulan ng ladder sa itaas; palitan ito ng v5.3.2, ang pinakabago noong 17 October 2026, para mabasa ang kasalukuyang wording:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

Sa Claude Code, plugin install ang idodokumento ng project. Ang dalawang linyang ito ang dokumentado noong 17 October 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Sinusundan ng plugin path ang default branch sa halip na isang tag. Dahil dito, maaaring magbago ang mga instruction na gumagabay sa agent mo sa pagitan ng mga session. Ito ang kapalit na tinatanggap mo para sa kaginhawaan ng isang update command.

Bakit mas mura sa VPS ang agent na maingat

Hindi lumalabas sa conversation ang diff na ginagawa ng agent. Sa susunod na turn, bahagi ito ng context na muling binabasa ng model, kasama ang bawat file na binuksan nito para mabuo ang diff. Kaya ang 500 line na pagbabago ay may dagdag na gastos sa bawat kasunod na turn sa session hanggang palitan ng compaction ang mga naunang turn ng summary. Hindi lang ang turn na gumawa nito ang naaapektuhan. Ito ang dahilan kung bakit nagiging mas mabagal at mas hindi maaasahan ang agent habang tumatagal ang session kapag walang kontrol ang refactor: napupuno ang window ng sariling output ng agent, kaya lumiit ang espasyong natitira para sa aktuwal mong code. Ang pagkontrol dito ang pangunahing paksa ng pag-manage sa context window ng coding agent.

Sinisingil ang mga token sa input at output. Kaya ang diff na kalahati ang laki ay dalawang beses na mas mura: una kapag isinusulat ito, at muli sa bawat turn na muling nagbabasa nito. Kung mapupunta sa bill mo ang matitipid na ito ay depende sa paraan ng pagbabayad mo, dahil sinasagot ng Pro o Max subscription ang dagdag na token hanggang sa usage limits nito. Pagkatapos nito, hiwalay na sinisingil ang opt-in usage credits. Sa per-token API billing naman, sisingilin ka sa bawat token. Kung binabantayan mo ang bill sa self-hosted setup, ang instruction file ay isang kontrol na walang gastos gamitin. Nagsisimula ang pagkontrol sa gastos ng AI agent sa iyo sa dami ng output, at ipinapaliwanag ng kung paano ginagastos ng coding agent ang mga token nito kung bakit mas mahalaga kaysa inaasahan ang paulit-ulit na pagbasa.

Binabasa pa rin ng tao ang diff. Ang 400 line na pagbabago na dapat ay 20 lines lang ay kumakain sa atensiyon ng reviewer, at ang atensiyon ang unang nauubos. Walang sumusuri sa ikaapat na mahabang diff ng araw na may parehong pag-iingat na ibinigay niya sa una. Kaya ang sobrang lawak ng pagbabago ay hindi lang pag-aaksaya ng oras. Unti-unti rin nitong binabawasan ang kalidad ng review na dapat makatuklas sa mga error.

Sa server, nagbabago ang mga panganib dahil madalas tumatakbo ang agent nang walang nagbabantay. Ang agent na gumagana sa tmux session o sa timer ay maaaring magkaroon ng ilang oras para palalimin ang maling desisyon bago mo ito makita. Ito ang praktikal na panganib sa pagpapatakbo ng coding agent sa VPS, at ito ang dahilan kung bakit masusing inaayos ng mga gumagawa ng loop engineering ang mga persistent instruction kaysa sa mga indibidwal na prompt. Ang rule sa always-on file ay nalalapat sa turn 200. Ang rule na itina-type mo sa chat ay nalalapat sa turn 3. Nalalapat din ito sa ikalawang session na sinimulan mo sa parehong machine. Binabasa nito ang committed file, pero wala itong namamanang anumang itinype mo sa una, kahit maaaring magpadalhan ng mensahe ang dalawang session sa isa't isa.

Ang mga bagong dependency ang isa pang tahimik na gastos. Sinasabi ng Rung 5 na gamitin ang mga naka-install na. Ang bawat package na idinadagdag ng agent sa sarili nitong pasya ay kailangan mong i-patch sa hinaharap. Napapabilang din ito sa bawat container image na bina-build mo mula sa repositoryong iyon.

Ano ang sinasabi ng sariling benchmark numbers ng Ponytail

Dalawang uri ng resulta ang inilathala ng proyekto, at malaki ang agwat ng mga ito. Parehong sariling published figures ng proyekto ang mga ito. Wala sa mga ito ang independent test.

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

Ang chart ay kasalukuyang agentic benchmark ng proyekto, na may petsang 7 October 2026. Ang headless Claude Code 2.1.288 sessions sa Opus 5.5, gamit ang default effort, ay gumawa ng 39 na task, na may limang run bawat task at arm, o 585 session lahat para sa no skill, Ponytail v4.13.0, at Ponytail 5. Labindalawa sa mga task ay feature ticket sa tiangolo's full-stack-fastapi-template, isang aktuwal na FastAPI at React repository, na sinukat batay sa naiwan nitong git diff. Ang natitira ay 18 surgical task na may hidden check, anim na small app request, at tatlong request na "show me an example". Naka-disable ang Bash sa bawat arm. Bumaba ng 45 percent ang output token sa Ponytail 5.

Ihambing ito sa single shot figures na inilathala ng proyekto noong June 2026. Galing ang mga iyon sa bare model na sumagot sa limang pangkaraniwang prompt, mayroon at walang rule, at iniulat bilang median mula sa paulit-ulit na run. Nagpakita ang mga ito ng 80 hanggang 94 percent na mas kaunting code sa Haiku, Sonnet, at Opus, at sa cost verification na may petsang 17 June 2026, lumabas na 63 percent na mas mura ang Haiku. Sa kasalukuyang agentic result, ang Ponytail 5 ay may 53 percent na mas kaunting linya ng code, 26 percent na mas mababang cost, at 41 percent na mas maikling wall clock time. Mabilis na itinama ng proyekto ang single shot figure. Pagsapit ng v4.8.4, noong 29 June 2026, nakalagay na sa headline ng README ang agentic result, "~54% less code (up to 94%)", kasama ang paliwanag na ang naunang 80 hanggang 94 percent ay "the per-task ceiling, not the average", at inilipat na nito ang single shot numbers sa isang collapsed section na may pamagat na "Older single-shot numbers". Tapat nitong ipinaliwanag kung bakit may agwat: ang single shot baseline ay isang bare model na "pads its answer with prose and options", kaya madaling malampasan. Kapag inihambing sa isang aktuwal na agent na gumagawa ng aktuwal na trabaho, lumiit ang pakinabang. Totoo pa rin ito, at iyon ang mas kapaki-pakinabang na impormasyon. Ang June agentic run na iyon, na may labindalawang ticket sa Haiku 4.5 at apat na run bawat isa, ay halos kapareho ng resulta ngayon: 54 percent na mas kaunting linya. Hindi na kasama sa kasalukuyang README ang single shot numbers.

May isang caveat mula mismo sa proyekto, at ito ang magpapasya kung makatutulong ito sa iyo. Pinakamalaki ang natitipid kapag may tunay na panganib ng sobrang pagbuo, at halos zero kapag minimal na ang code mula pa noong una. Pinatutunayan ito ng October per-task table, kung saan ilang surgical task ang nagtapos sa parehong line count sa lahat ng tatlong arm. Hindi sapat na batayan para sa iyong repository ang 39 na task sa isang model at isang host, lalo na kung naka-off ang Bash. Kung mahalaga sa iyo ang number, patakbuhin ang comparison sa sarili mong ticket, mayroon at walang rule, at ikaw mismo ang magbilang ng mga linya.

Ang pattern na maaari mong kopyahin ngayon nang walang ini-install

Text ang ladder, kaya hindi mo kailangan ang plugin para gamitin ang ideya. Mag-paste ng block na gaya nito sa instruction file na binabasa na ng iyong agent, ito man ay AGENTS.md, CLAUDE.md, o rules file ng iyong editor.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

Mahalagang hiwalay na bigyang-pansin ang huling rule. Ang convention ng Ponytail sa mga kasalukuyang release nito ay isang comment na may tag na shortcut:, na nagsasaad ng limitasyon at kung kailan mag-upgrade (sa mga release noong June, kabilang ang v4.8.4, ponytail: ang ginamit na tag):

# shortcut: global lock, per-account locks if throughput matters

Dalawang linya lang ang comment, pero nilulutas nito ang isang tanong na kung hindi ay mangangailangan ng isang review cycle. Sinasabi nito sa susunod na reader na sinadyang desisyon ang simpleng version, at tinutukoy nito ang kondisyon kung kailan hindi na naaangkop ang desisyong iyon. Kung wala ito, hindi matutukoy ng reviewer kung pinag-isipang shortcut ang ginawa o may nakalimutan ang agent, kaya kailangan pa nilang magtanong.

Mahalaga ang lokasyon ng block, gaya ng kahalagahan ng nilalaman nito. Ang file na nilo-load ng agent sa bawat run ay gumagabay sa bawat run, kabilang ang mga run na hindi mo mino-monitor. Ito ang paksa ng pagsulat ng AGENTS.md na talagang sinusunod ng iyong agent, at ito ang dahilan kung bakit dapat ilagay ang pattern na ito sa isang committed file sa halip na sa shell history. Sa isang monorepo, dapat itong ilagay sa higit sa isang committed file, dahil pinananatiling maikli ng AGENTS.md bawat package ang mga rule nito sa halip na pilitin ang agent na basahin ang buong convention ng tree sa bawat run. Gayunman, hindi garantiya ang placement, kaya makatutulong na malaman kung bakit nilalampasan ng agent ang isang rule na na-load na nito bago mo ipagpalagay na kailangan ng ladder ng mas mahigpit na wording.

Kung Saan Hindi Na Tama ang Rule

Ang ladder ay nakatuon sa feature work sa isang codebase na mayroon na, kung saan karaniwang available at tama ang reuse. Hindi ito gaanong angkop sa greenfield project, dahil walang mare-reuse sa rung 2 at walang naka-install sa rung 5. Maaari pa ring huminto ang agent sa rung 1, sa standard library, sa platform feature, o sa isang one-liner, pero wala na ang dalawa sa pinakamurang paraan para matapos ang gawain. Dahil dito, mas maraming task ang nauuwi sa pagsusulat ng bagong code. Hindi rin ito angkop kapag talagang kailangan mo na ang abstraction. Kung magdadagdag ka na ng ikaapat na caller para sa parehong kinopyang block, bibigyan ka ng “shortest diff” ng ikalimang kopya.

Kukuwestiyunin ng ultra level ang iyong requirements. Iyan ang layunin ng level, at tunay na gastos ito kapag nakapagpasya ka na at gusto mo nang matapos ang gawain. Gamitin ang full para sa karaniwang trabaho, at gamitin ang ultra kapag pinaghihinalaan mong ang feature request mismo ang problema.

Walang instruction block na makapagliligtas sa iyo mula sa maling pag-unawa sa problema. Ang unang item mismo ng ruleset ay ang pag-unawa sa code bago magpasya. Iyon ang magastos na bahagi, at hindi iyon magagawa para sa iyo ng text. Ang minimal diff sa maling function ay mali pa rin na fix. Maliit lamang ito at madaling ma-approve.

Ang tapat na buod ay isang maingat na isinulat na prompt ang Ponytail, maayos na ipinamahagi, at may mga numerong kalakip. Walang bahagi nito ang nangangailangan sa plugin. Ang ibinibigay ng project ay ang maayos na pagkakasulat ng listahan, pagsubok dito sa isang tunay na repository, at paglalathala ng method kasabay ng resulta.

FAQ

Gumagana ba ang Ponytail sa mga agent maliban sa Claude Code?

Oo. Ipinapamahagi ito bilang skill para sa mga host na naglo-load ng skills. Kabilang sa mga ito ang Claude Code, Codex, OpenCode, Gemini, at ilang iba pa na nakalista sa README. Ang mga editor na nagbabasa ng rule files pero hindi naglo-load ng skills, gaya ng Cursor, Windsurf, Cline, at Copilot, ay kumukuha ng always-on ruleset mula sa katugmang rules directory at walang slash commands. Pareho ang text sa dalawang paraan. Ang tunay na kaibahan ay kung pinananatili ng host ang text na iyon sa context sa bawat turn o nilo-load lamang kapag na-trigger ang isang skill.

Lalaktawan ba ng lazy agent ang tests, validation, o security?

Hindi, at malinaw itong nakasaad sa ruleset. Binabanggit sa listahan nitong “never lazy about” ang input validation sa trust boundaries, error handling na pumipigil sa pagkawala ng data, security at accessibility. Hinihingi rin nito ang isang maliit na runnable check para sa bawat piraso ng non-trivial logic. Ang inaalis ng rule ay ang inimbentong structure: mga abstraction na hindi hiniling ng sinuman at mga dependency na hindi kailangan. Kung nagsimulang magtanggal ng tests ang agent mo matapos itong i-install, ang sanhi ay isa pang instruction sa sarili mong config na mas mataas ang priority kaysa rito. Basahin ang file na huling nilo-load ng agent.

Mapagkakatiwalaan ba ang mga inilathalang numero para sa speed at cost?

Sarili itong measurements ng project na inilathala kasama ang pamamaraan ng pagsukat. Dapat basahin ang mga ito sa ganoong konteksto. Ang single-shot figures mula June 2026 ay ikinumpara sa isang bare model na nilagyan ng dagdag na prose at options ang sagot nito. Tinukoy mismo ng README noong panahong iyon na mahina ang baseline na iyon. Ang kasalukuyang agentic figures ay mula sa headless Claude Code sessions gamit ang Opus 5.5. Kasama rito ang 39 tasks na may tig-limang run, at 12 sa mga iyon ay feature tickets sa isang FastAPI at React repository. Mapagkakatiwalaan ang mga numerong iyon para sa setup na iyon. Hindi ang mga ito forecast para sa codebase mo, dahil ipinapakita ng sariling per-task results ng project na halos nawawala ang natitipid sa code na minimal na bago pa magsimula.

Kailangan ko bang mag-install ng anuman para makuha ang pakinabang?

Hindi. Text ang ladder. Kung i-paste ang katumbas na block sa instruction file na binabasa na ng agent mo, makukuha mo ang karamihan ng epekto. Ibinibigay ng plugin ang pinapanatiling updated na wording, mga intensity level, review commands, at update path. Ang unang pagsubok sa kinopyang block ay sagot ng rung 1 sa tanong kung kailangan nga bang umiral ang install.

Paano ko pipigilan ang unattended agent na gumawa ng sobra habang magdamag?

Ilagay ang rule sa always-on instruction file sa halip na sa chat message. Sa ganitong paraan, gagana ito sa turn 200 ng mahabang run at hindi lamang sa turn 3. Pagkatapos, hiwalay na limitahan ang posibleng pinsala: bigyan ang agent ng checkout na maaari nitong sirain sa halip na ang nag-iisa mong kopya, at mangailangan ng human diff review bago magkaroon ng merge. Binabawasan ng minimal diff rule ang dami ng kailangan mong basahin. Hindi nito pinagpapasyahan kung ano ang ima-merge, at hindi rin dapat.