Ano ang Ponytail: Ang AI Agent Skill para sa Tamad na Dev

Ano ang Ponytail

Ang Ponytail ay isang rule set na nag-uutos sa isang AI coding agent na magsulat ng mas kaunting code. Inilalarawan ng proyekto ang sarili nito sa isang linya: "Ginagawa nitong mag-isip ang iyong AI agent na parang ang pinakatamad na senior dev sa loob ng kwarto. Ang pinakamagandang code ay ang code na hindi mo naisulat." Ito ay may lisensyang MIT. Wala itong sariling runtime, at walang anumang bahagi nito ang nag-e-execute. Ito ay text na inilalagay sa mga instruction ng agent, na naka-package bilang isang skill para sa mga host na naglo-load ng mga skill, at bilang mga plain rule file para sa mga host na hindi gumagamit nito.

Ang repository ay DietrichGebert/ponytail. Nilikha ito noong 12 June 2026 at lumampas sa 90,000 stars noong 1 August 2026. Ang pinakabagong tagged release noong 1 August 2026 ay v4.8.4, na inilathala noong 29 June 2026, at ang releases page ay naglilista ng sampung tag sa pagitan ng 14 at 29 June pa lamang. Ang isang proyektong mabilis ang pagbabago ay tiyak na mag-iiba na pagdating ng oras na mabasa mo ito, kaya mag-pin ng isang tag bago ka bumuo ng anumang bagay sa ibabaw nito.

Ang konsepto bago ang tool: huminto sa unang baitang na matibay

Ang core ng Ponytail ay isang decision ladder. Inaakyat ito ng agent bago magsulat ng kahit ano at humihinto sa unang baitang na matibay.

1. Kailangan ba talaga itong umiral? Ito ang YAGNI (you are not going to need it). Kung hindi, laktawan ito.
2. Umiiral na ba ito sa codebase na ito? Gamitin muli ang helper o pattern na naroon na.
3. Ginagawa ba ito ng standard library? Gamitin ito.
4. Sinasaklaw ba ito ng native platform feature? Gamitin ito.
5. Nasosolusyunan ba ito ng dependency na naka-install na? Gamitin ito.
6. Kaya ba itong gawing isang linya? Gawin itong isang linya.
7. Saka lamang magsulat ng pinakakaunting code na gagana.

Ang pagkakasunod-sunod ang gumagawa ng trabaho, hindi ang anumang solong baitang. Ang isang agent na inutusang gumawa ng date picker ay magsusulat ng date picker, dahil iyon ang iniutos sa kanya. Pinipilit siya ng ladder na suriin muna ang baitang 4, at sinasabi ng baitang 4 na mayroon na ang browser ng <input type="date">. Ang sariling benchmark ng project ay nagtatala ng eksaktong kasong ito: ang isang date picker na umabot sa 404 lines nang walang rule ay naging 23 lines na lamang dahil dito, dahil gumamit ang agent ng native input sa halip na bumuo ng component. Ang isang colour picker ay naging 23 lines mula sa 287 lines dahil sa parehong dahilan. Ang baitang 2 ang tahimik na nabibigo, dahil ang agent na hindi nakakakita sa helper na mayroon ka na ay masayang magsusulat ng pangalawa, na siyang puwang na nilalayong punan ng a queryable map of your codebase.

Ang pagiging "lazy" dito ay hindi nangangahulugang pabaya, at direktang sinasabi ito ng ruleset. Ang listahan nito ng "never lazy about" ay sumasaklaw sa pag-unawa sa problema bago magdesisyon, input validation sa trust boundaries, error handling na pumipigil sa data loss, security, accessibility, at anumang hiniling mo ayon sa pangalan. Humihingi rin ito ng isang maliit at runnable na check para sa bawat piraso ng non-trivial logic. Pinipigilan ng rule ang pag-imbento. Hindi nito pinipigilan ang pagiging tama.

Ang aktwal na nilalaman ng repository

• AGENTS.md, ang always-on ruleset, na siyang buong konsepto sa loob ng isang file na mababasa mo sa loob ng limang minuto.
• skills/ponytail/SKILL.md, ang skill definition, na may argument hint na lite, full o ultra.
• 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 kahigpit ang pagpapatupad ng rule. Ang lite ay bumubuo ng hiningi mo at nagmumungkahi ng mas tamad na opsyon sa isang linya. Ang full ang default at nagpapatupad ng ladder. Ang ultra ang YAGNI extremist setting: mas gusto nito ang pagbura kaysa pagdagdag at makikipagtalo pa ito sa mismong requirement.

Ang mga host na may kakayahang mag-skill ay nakakakuha rin ng mga slash command. Ang /ponytail ang nagtatakda ng level, ang /ponytail-review ang sumusuri ng diff para sa over-engineering, ang /ponytail-audit ang sumusuri ng buong repository, ang /ponytail-debt ang nagtitipon ng mga shortcut na ipinagpaliban mo, at ang /ponytail-gain ang nagpi-print ng benchmark scorecard. Ang mga host na nagbabasa lang ng rule files ay makakakuha ng ruleset nang walang mga command.

Para basahin ang source bago mo ito pagkatiwalaan, i-clone ang tag sa halip na ang branch:

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

Sa Claude Code, ang proyekto ay nagdodokumento ng plugin install sa halip nito, at ang dalawang linyang ito ay ayon sa dokumentasyon noong 1 August 2026:

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

Ang plugin path ay sumusunod sa default branch sa halip na sa isang tag, kaya ang mga instruction na nagpapatakbo sa iyong agent ay maaaring magbago nang hindi mo namamalayan sa pagitan ng mga session. Iyan ang kapalit na tinatanggap mo para sa convenience ng isang update command.

Bakit mas mura ang lazy agent sa isang VPS

Ang diff na isinusulat ng isang agent ay hindi nawawala sa usapan. Sa susunod na turn, ito ay bahagi na ng context na binabasa muli ng model, kasama ang bawat file na binuksan nito para magawa ang output. Dahil dito, ang 500-line change ay nagpapabigat sa bawat susunod na turn sa session, hindi lang sa turn kung kailan ito ginawa. Ito ang dahilan kung bakit ang isang runaway refactor ay nagpapabagal at nagpapabobo sa agent habang tumatagal ang session: napupuno ang window ng sariling output ng agent, kaya kumakaunti ang espasyong natitira para sa iyong mismong code. Ang pagkontrol dito ang buong paksa ng pamamahala sa context window ng isang coding agent.

Ang mga token ay binabayaran base sa dami ng pumapasok at lumalabas, kaya ang diff na kalahati lang ang laki ay mas mura nang dalawang beses—isang beses kapag isinulat ito, at muli sa bawat turn na binabasa itong muli. Kung ang matitipid na ito ay mararamdaman sa iyong bill ay depende sa kung paano ka magbayad, dahil ang isang flat Pro o Max subscription ay sumasalo sa mga extra token, habang ang per-token API billing ay naniningil para sa bawat isa sa mga ito. Kung binabantayan mo ang bill sa isang self-hosted setup, ang instruction file ay isang lever na walang gastos gamitin. Ang pagkontrol sa gastos ng isang AI agent ay nagsisimula sa dami ng output, at ang kung paano gumagastos ng token ang isang coding agent ay nagpapaliwanag kung bakit mas mahalaga ang re-reading kaysa sa inaakala ng marami.

Binabasa pa rin ng tao ang diff. Ang 400-line change na dapat ay 20 lines lang ay kumakain ng atensyon ng reviewer, at ang atensyon ang resource na unang nauubos. Walang sinuman ang nagre-review ng ikaapat na mahabang diff sa isang araw nang may parehong pag-iingat gaya ng una, kaya ang over-building ay hindi lang nagsasayang ng oras. Tahimik nitong ibinababa ang kalidad ng review na dapat sana ay nakakahuli ng mga pagkakamali.

Sa isang server, nagbabago ang stakes dahil madalas tumatakbo ang agent nang walang nakabantay. Ang isang agent na gumagana sa loob ng isang tmux session o naka-timer ay may oras para magpatuloy sa isang maling desisyon bago mo pa ito makita. Iyan ang praktikal na panganib sa pagpapatakbo ng isang coding agent sa isang VPS, at ito ang dahilan kung bakit ang mga taong gumagawa ng loop engineering ay mas nagtutuon ng pansin sa mga standing instruction kaysa sa mga indibidwal na prompt. Ang isang rule sa always-on file ay apply sa turn 200. Ang rule na tinipa mo sa chat ay apply lang sa turn 3. Apply din ito sa pangalawang session na sisimulan mo sa parehong box, na nagbabasa ng committed file pero walang namamanang kahit ano mula sa tinipa mo sa una, kahit pa ang dalawang session ay kayang mag-message sa isa't isa.

Ang mga bagong dependency ang isa pang tahimik na gastos. Sinasabi ng Rung 5 na gamitin lang ang kung ano ang naka-install. Ang bawat package na idinaragdag ng agent sa sarili nitong inisyatibo ay isang bagay na kailangan mong i-patch sa hinaharap at isang bagay na mapupunta sa bawat container image na gagawin mo mula sa repository na iyon.

Ano ang sinasabi ng sariling benchmark numbers ng Ponytail

Naglalathala ang proyekto ng dalawang set ng resulta, at malaki ang pagkakaiba ng mga ito sa isa't isa. Parehong sariling datos ito ng proyekto. Wala sa mga ito ang independent test.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

Ang column para sa single shot ay nagmula sa isang bare model na sumasagot sa maliit na set ng mga prompt nang mayroon at walang rule, na kinuha bilang median sa mga paulit-ulit na run noong 13 at 17 June 2026. Ang agentic column naman ay mula sa isang headless Claude Code session na nag-e-edit ng full-stack-fastapi-template ni tiangolo, isang totoong FastAPI at React repository, sa loob ng labindalawang feature ticket na may apat na run bawat isa sa Haiku 4.5, na minarkahan batay sa naiwang git diff.

Basahin ang ikalawang column. Ang agentic result ay 54 percent na mas kakaunting linya ng code, 20 percent na mas mababang gastos, at 27 percent na mas maikling wall clock time, kumpara sa 93 percent at 74 percent para sa parehong sukatan sa single shot setup. Tapat ang README tungkol sa dahilan: ang single shot baseline ay isang bare model na "sumasagot gamit ang ilang opsyon at komentaryo," na madaling talunin. Ipagkumpara ito sa isang totoong agent na gumagawa ng totoong trabaho at liliit ang lamang. Nananatili rin itong totoo, na siyang mas kapaki-pakinabang na impormasyon.

Isang caveat ang galing mismo sa proyekto, at ito ang magdedesisyon kung makakatulong ito sa iyo. Ang matitipid ay pinakamalaki kung saan may tunay na over-build trap at halos zero sa code na minimal na. Ang labindalawang ticket sa isang Python at TypeScript repository ay hindi garantiya para sa iyong repository. Kung mahalaga sa iyo ang numero, patakbuhin ang paghahambing sa sarili mong mga ticket, nang mayroon at walang rule, at bilangin mo mismo ang mga linya.

Ang pattern na maaari mong kopyahin ngayon nang hindi nag-i-install ng anuman

Ang ladder ay text, kaya hindi mo kailangan ng plugin para magamit ang ideyang ito. I-paste ang block na gaya nito sa instruction file na binabasa na ng iyong agent, maging ito man ay AGENTS.md, CLAUDE.md, o ang 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.

Ang huling rule na iyon ay sulit gamitin nang mag-isa. Ang convention ng Ponytail ay isang comment na may tag ng pangalan ng tool:

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

Ang comment ay binubuo ng dalawang linya ng trabaho at tinatapos nito ang isang tanong na kung hindi ay magdudulot ng review cycle. Sinasabi nito sa susunod na magbabasa na ang simpleng bersyon ay isang desisyon, at pinapangalanan nito ang kondisyon kung kailan hindi na magiging wasto ang desisyong iyon. Kung wala ito, hindi malalaman ng reviewer kung ang shortcut ay pinag-isipan o nakalimutan lang ng agent, kaya mapipilitan silang magtanong.

Ang lokasyon kung saan mo ilalagay ang block ay kasinghalaga ng nilalaman nito. Ang file na binabasa ng agent sa bawat run ay nagdidikta sa bawat run, kabilang ang mga hindi mo binabantayan. Ang pagkakaibang iyon ang paksa ng pagsulat ng AGENTS.md na sinusunod talaga ng iyong agent, at ito ang dahilan kung bakit ang pattern na ito ay dapat nasa isang committed file sa halip na sa iyong shell history. Sa isang monorepo, dapat itong nasa higit sa isang committed file, dahil ang isang AGENTS.md bawat package ay pinapanatiling maikli ang mga rule ng bawat directory sa halip na pabasahin ang agent ng mga convention ng buong tree sa bawat run. Gayunpaman, ang paglalagay ay hindi garantiya, at sulit na malaman ang kung bakit nilalagpasan ng agent ang isang rule na na-load na nito bago mo konklusyonin na kailangan ng mas matapang na pananalita ang ladder.

Kung saan hindi na tama ang rule

Ang ladder ay naka-tune para sa feature work sa isang codebase na umiiral na, kung saan ang reuse ay karaniwang available at tama. Hindi ito angkop sa greenfield project dahil ang rung 2 ay walang mare-reuse at ang rung 5 ay walang naka-install, kaya ang agent ay laging bumabagsak sa rung 7. Hindi rin ito angkop sa sandaling kailangan mo na talaga ng abstraction. Kung magdadagdag ka na ng ikaapat na caller ng parehong copied block, ang "shortest diff" ay magbibigay sa iyo ng ikalimang kopya.

Ang ultra level ay hahamon sa iyong mga requirement. Iyan ang layunin ng level na iyan, at isa itong tunay na gastos kapag nakapagdesisyon ka na at gusto mo na lang matapos ang trabaho. Gamitin ang full para sa ordinaryong trabaho at gamitin ang ultra kapag hinala mong ang feature request mismo ang problema.

Walang instruction block ang makapagliligtas sa iyo mula sa maling pag-intindi sa problema. Ang unang item sa ruleset ay ang pag-unawa sa code bago magdesisyon, na siyang mahirap na bahagi at ang bahaging hindi magagawa ng text para sa iyo. Ang minimal diff sa maling function ay maling fix pa rin, at isa na itong maliit na maling fix na madaling i-approve.

Ang tapat na buod ay ang Ponytail ay isang maingat na isinulat na prompt, na naipamahagi nang maayos, at may mga numerong nakalakip. Walang anuman dito ang nangangailangan ng plugin. Ang ibinibigay sa iyo ng project ay ang katotohanang may sumulat ng listahan nang tama, sinubukan ito sa isang totoong repository, at inilathala ang method kasabay ng resulta.

FAQ

Gumagana ba ang Ponytail sa ibang agents bukod sa Claude Code?

Oo. Ito ay inilalabas bilang isang skill para sa mga host na naglo-load ng skills, isang listahan na kinabibilangan ng Claude Code, Codex, OpenCode, Gemini, at marami pang iba 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 kaukulang rules directory at walang slash commands. Pareho lang ang text sa dalawang paraan, kaya ang tunay na pagkakaiba ay kung pinapanatili ba ng iyong host ang text na iyon sa context sa bawat turn o kapag na-trigger lang ang isang skill.

Lalaktawan ba ng isang lazy agent ang mga test, validation, o security?

Hindi, at direktang nakasaad ito sa ruleset. Ang listahan nito ng "never lazy about" ay tumutukoy sa input validation sa mga trust boundary, error handling na pumipigil sa data loss, security, at accessibility, at humihingi ito ng isang maliit na runnable check para sa bawat piraso ng non-trivial logic. Ang inaalis ng rule ay ang mga imbentong structure: mga abstraction na walang humiling at mga dependency na hindi kailangan. Kung nagsimulang magbawas ng tests ang iyong agent matapos mo itong i-install, ang sanhi nito ay isa pang instruction sa sarili mong config na mas mataas ang priority kaysa dito, kaya basahin ang file na huling nilo-load ng agent.

Mapagkakatiwalaan ba ang mga inilathalang numero para sa bilis at gastos?

Ang mga ito ay sariling sukat ng proyekto, inilathala kasama ang kanilang method, at dapat basahin bilang ganoon. Ang mga single shot figure ay ikinukumpara sa isang bare model na sumasagot nang may mga opsyon at komento, na tinukoy mismo ng README bilang isang mahinang baseline. Ang mga agentic figure ay nagmula sa isang headless Claude Code session sa isang FastAPI at React repository, labindalawang ticket, apat na run bawat isa, gamit ang Haiku 4.5. Ang mga iyon ay tapat na numero para sa setup na iyon. Hindi ito forecast para sa iyong codebase, dahil sinasabi rin ng proyekto na ang matitipid ay halos maging zero sa code na minimal na dati pa.

Kailangan ko bang mag-install ng kahit ano para makuha ang benepisyo?

Hindi. Ang ladder ay text, at ang katumbas na block na i-paste mo sa instruction file na binabasa na ng iyong agent ay magbibigay sa iyo ng halos lahat ng epekto. Ang plugin ang nagbibigay sa iyo ng maintained wording, intensity levels, review commands, at update path. Ang pagsubok sa kinopyang block muna ang rung 1 na sagot sa tanong kung kailangan ba talaga ng install.

Paano ko pipigilan ang isang unattended agent na mag-over-build sa magdamag?

Ilagay ang rule sa always-on instruction file sa halip na sa isang chat message, para mailapat ito sa turn 200 ng isang mahabang run at hindi lang sa turn 3. Pagkatapos, limitahan ang pinsala nang hiwalay: bigyan ang agent ng checkout na maaari nitong sirain sa halip na ang iyong tanging kopya, at mangailangan ng human diff review bago mag-merge ang kahit ano. Ang isang minimal diff rule ay nagpapababa sa dami ng kailangan mong basahin. Hindi ito ang nagpapasya kung ano ang mamerge, at hindi dapat ito ang gumawa noon.