Ponytail: AI coding agent-এর ছোট পরিবর্তনের rule

Ponytail কী

Ponytail হলো এমন একটি rule set, যা AI coding agent-কে কম code লিখতে সাহায্য করে। Project-টি নিজেকে এক লাইনে এভাবে বর্ণনা করে: "Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote." এটি MIT licensed। এর নিজস্ব কোনো runtime নেই, এবং এর মধ্যে কিছুই execute হয় না। এটি agent-এর instructions-এ যোগ করার জন্য লেখা text। যে host-গুলো skills load করে, সেগুলোর জন্য এটি skill হিসেবে packaged। আর যে host-গুলো skills load করে না, সেগুলোর জন্য এটি plain rule file হিসেবে দেওয়া হয়।

Repository-টি হলো DietrichGebert/ponytail। এটি 12 June 2026-এ তৈরি হয় এবং 1 August 2026-এর মধ্যে 90,000 stars অতিক্রম করে। 1 August 2026-এ সর্বশেষ tagged release ছিল v4.8.4, যা 29 June 2026-এ published হয়। Releases page-এ শুধু 14 থেকে 29 June-এর মধ্যে দশটি tag তালিকাভুক্ত ছিল। Project-টির গতি কমেনি: 17 October 2026-এ সর্বশেষ release হলো v5.3.2, যা 16 October-এর শেষ দিকে published হয়। ওই দিন এটি v5.3.0 এবং v5.3.1-এর পরে তৃতীয় release ছিল। এর আগে 13 October-এ v5.2.0 প্রকাশিত হয়। তার 5 দিন আগে, 8 October-এ v5.0.0 এবং v5.1.0 দুটিই প্রকাশিত হয়। Repository-তে 165,000-এর বেশি stars দেখা যাচ্ছে। এই গতিতে চলা কোনো project আপনি এটি পড়ার সময় বদলে যেতে পারে। তাই এর ওপর কিছু build করার আগে একটি tag pin করুন।

টুলের আগে ধারণাটি: যে প্রথম ধাপটি কার্যকর, সেখানেই থামুন

Ponytail-এর মূল ধারণা হলো একটি সিদ্ধান্তের সিঁড়ি। Agent কোনো কোড লেখার আগে এই সিঁড়ি অনুসরণ করে এবং যে প্রথম ধাপটি কার্যকর, সেখানেই থামে।

1. এটি আদৌ থাকা দরকার কি? এটি YAGNI (you are not going to need it)। উত্তর না হলে এটি বাদ দিন।
2. এটি কি এই codebase-এ ইতিমধ্যে আছে? আগে থাকা helper বা pattern পুনর্ব্যবহার করুন।
3. Standard library কি এটি করতে পারে? সেটি ব্যবহার করুন।
4. Native platform feature কি এটি সামলাতে পারে? সেটি ব্যবহার করুন।
5. ইতিমধ্যে installed কোনো dependency কি সমস্যাটি সমাধান করে? সেটি ব্যবহার করুন।
6. এটি কি এক লাইনে করা যায়? এক লাইনেই করুন।
7. এরপরই কেবল কাজ করে এমন ন্যূনতম code লিখুন।

v4.8.4-এ সিঁড়িটি এভাবেই লেখা আছে, এবং এই article-এর বাকি অংশে ধাপের নম্বরগুলোও একই ক্রম অনুসরণ করে। বর্তমান main branch 3 এবং 4 নম্বর ধাপ একত্র করে বলছে, "Standard library অথবা platform feature? ব্যবহার করুন, যদি না project-এর নিজস্ব কিছু থাকে", এবং আরও যোগ করছে যে "house component native widget-এর চেয়ে ভালো"; ফলে এতে ছয়টি ধাপ আছে। ক্রমটি একই রয়েছে।

কাজটি করে ক্রম, কোনো একক ধাপ নয়। কোনো agent-কে date picker তৈরি করতে বলা হলে সে date picker তৈরি করবে, কারণ তাকে সেটিই করতে বলা হয়েছে। সিঁড়িটি তাকে কিছু তৈরি করার আগে বিদ্যমান জিনিস পরীক্ষা করতে বাধ্য করে: 2 নম্বর ধাপে জিজ্ঞেস করা হয় repository-তে এর জন্য কোনো component ইতিমধ্যে আছে কি না, এবং 4 নম্বর ধাপে বলা হয় যে browser-এ ইতিমধ্যে <input type="date"> আছে। Project-এর বর্তমান benchmark notes-এ ঠিক এই ঘটনাটিই দেখানো হয়েছে: নিয়ম ছাড়া যে date picker 335 lines-এ তৈরি হয়েছিল, Ponytail 5 ব্যবহার করলে সেটি 10 lines-এ নেমে আসে, কারণ agent repository-এর নিজস্ব Input component-কে type="date"-এর সঙ্গে পুনর্ব্যবহার করেছে এবং calendar-এর কাজ browser-কে করতে দিয়েছে। Colour picker-এর ক্ষেত্রে কমলেও পরিবর্তনটি তুলনামূলকভাবে কম ছিল: 135 lines থেকে 26 lines। 2 নম্বর ধাপটি নীরবে ব্যর্থ হয়, কারণ আপনি আগে থেকেই যে helper রেখেছেন agent সেটি দেখতে না পেলে আনন্দের সঙ্গে দ্বিতীয় একটি helper লিখে ফেলবে। এই ফাঁকটি বন্ধ করার জন্যই আপনার codebase-এর queryable map দরকার।

এখানে lazy বলতে অসতর্ক বোঝায় না, এবং ruleset-এ এটি সরাসরি বলা আছে। এর "never lazy about" তালিকায় সিদ্ধান্ত নেওয়ার আগে সমস্যা বোঝা, trust boundary-তে input validation, data loss প্রতিরোধ করে এমন error handling, security, accessibility এবং নাম ধরে অনুরোধ করা যেকোনো বিষয় অন্তর্ভুক্ত। এটি non-trivial logic-এর প্রতিটি অংশের জন্য একটি ছোট runnable check রাখতেও বলে। এই নিয়ম অপ্রয়োজনীয় উদ্ভাবন কমায়। Correctness কমায় না।

রিপোজিটরিতে আসলে যা প্রকাশিত হয়

• AGENTS.md, সব সময় সক্রিয় ruleset; পাঁচ মিনিটে পড়ে বোঝা যায় এমন একটি ফাইলেই পুরো ধারণাটি রয়েছে।
• skills/ponytail/SKILL.md, skill definition; এর argument hint হলো lite, full, ultra অথবা off।
• .cursor/rules/ এবং .windsurf/rules/-এর মতো editor-specific directory-এর অধীনে থাকা rule file, এমন host-এর জন্য যেগুলো rule পড়ে কিন্তু skill load করে না।
• hooks/, benchmarks/, examples/ এবং scripts/।

intensity argument নিয়মটি কতটা কঠোরভাবে প্রয়োগ হবে তা পরিবর্তন করে। lite আপনার চাওয়া জিনিস তৈরি করে এবং এক লাইনে আরও কম কাজের একটি বিকল্পের নাম দেয়। full হলো default; এটি ladder বাধ্যতামূলক করে। ultra হলো YAGNI-এর চরম setting: এটি সংযোজনের বদলে মুছে ফেলা পছন্দ করে এবং requirement নিজেকেও প্রশ্ন করবে।

skill-capable host-গুলো slash command-ও পায়। /ponytail level নির্ধারণ করে, /ponytail-review over-engineering আছে কি না তা diff-এ পরীক্ষা করে, /ponytail-audit পুরো repository পরীক্ষা করে, /ponytail-debt পরে করার জন্য রেখে দেওয়া shortcut সংগ্রহ করে, এবং /ponytail-gain benchmark scorecard দেখায়। যেসব host শুধু rule file পড়ে, সেগুলো কোনো command ছাড়াই ruleset পায়। v5.3.0 থেকে, যা 16 October 2026-এ প্রকাশিত হয়েছে, Claude Code prompt-এর ওপরে এমন একটি band-ও দেখায় যেখানে task cost, code reuse এবং test status দেখা যায়। এর জন্য Claude Code 2.1.290 বা পরবর্তী version প্রয়োজন। এটি VS Code chat panel, cloud session অথবা claude -p-এ দেখা যায় না, এবং /ponytail band off এটি আড়াল করে। v5.3.2 থেকে /ponytail band import আপনার আগের Claude Code session একবার পড়ে এবং সেগুলোর cost, agent time ও token-সহ board-এ যোগ করে। ফলে আপনি সেগুলোকে এই rule-এর অধীনে চালানো session-এর সঙ্গে তুলনা করতে পারেন।

বিশ্বাস করার আগে source পড়তে চাইলে branch নয়, tag clone করুন। উপরের ladder যেই tag থেকে এসেছে এটি সেটিই। বর্তমান wording পড়তে 17 October 2026-এ latest থাকা v5.3.2 বসান:

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

Claude Code-এ project-টি এর পরিবর্তে plugin install নথিবদ্ধ করেছে। 17 October 2026-এ নথিতে থাকা এই দুইটি line হলো:

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

plugin path tag-এর বদলে default branch অনুসরণ করে। তাই session-এর মধ্যে আপনার agent-কে নির্দেশ দেওয়া instruction পরিবর্তিত হতে পারে। update command ব্যবহারের সুবিধার বিনিময়ে আপনি এই trade-off গ্রহণ করছেন।

VPS-এ অলস agent কেন কম খরচের

Agent যে diff লেখে, সেটি conversation-এর বাইরে যায় না। পরের turn-এ model সেটি আবার পড়ে, পাশাপাশি সেটি তৈরি করতে খোলা প্রতিটি file-ও পড়ে। তাই 500 line-এর একটি পরিবর্তন compaction পুরোনো turn-গুলোকে summary দিয়ে প্রতিস্থাপন না করা পর্যন্ত session-এর পরবর্তী প্রতিটি turn-এর ওপর অতিরিক্ত চাপ ফেলে; শুধু যে turn-এ পরিবর্তনটি তৈরি হয়েছে, তার ওপর নয়। এ কারণেই runaway refactor চলতে থাকলে session যত এগোয়, agent তত ধীর এবং কম কার্যকর মনে হয়: window agent-এর নিজের output-এ ভরে যায়, ফলে আপনার প্রকৃত code-এর জন্য অবশিষ্ট জায়গা কমে যায়। coding agent-এর context window পরিচালনা করা-ই মূলত এই বিষয়টি নিয়ন্ত্রণ করার কাজ।

Token input এবং output—দুই দিকের জন্যই bill হয়। তাই অর্ধেক আকারের একটি diff দুইবার সাশ্রয় করে: একবার লেখার সময়, এবং পরে প্রতিটি turn-এ সেটি আবার পড়ার সময়। এই সাশ্রয় আপনার bill-এ প্রতিফলিত হবে কি না, তা নির্ভর করে আপনি কীভাবে অর্থ পরিশোধ করেন। Pro বা Max subscription usage limit পর্যন্ত অতিরিক্ত token-এর খরচ বহন করে; এর পরে opt-in usage credit আলাদাভাবে bill হয়। অন্যদিকে, per-token API billing প্রতিটি token-এর জন্য আপনাকে charge করে। self-hosted setup-এ bill-এর দিকে নজর রাখলে instruction file হলো এমন একটি lever, যা ব্যবহার করতে কোনো খরচ নেই। AI agent-এর খরচ নিয়ন্ত্রণ output volume থেকে শুরু হয়, আর coding agent কীভাবে তার token ব্যবহার করে তা ব্যাখ্যা করে কেন পুনরায় পড়ার খরচ মানুষের প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ।

মানুষকে এখনও diff পড়তে হয়। 20 line হওয়া উচিত ছিল এমন 400 line-এর একটি পরিবর্তন reviewer-এর মনোযোগ খরচ করে, আর সবার আগে যে resource শেষ হয়ে যায়, তা হলো মনোযোগ। দিনের চতুর্থ দীর্ঘ diff কেউ প্রথমটির মতো যত্ন নিয়ে review করে না। তাই অতিরিক্তভাবে code তৈরি করা শুধু সময় নষ্ট করে না। যে review-এর মাধ্যমে ভুল ধরা পড়ার কথা, তার quality-ও এটি নীরবে কমিয়ে দেয়।

Server-এ ঝুঁকির মাত্রা বদলে যায়, কারণ agent প্রায়ই কারও তদারকি ছাড়াই চলে। tmux session-এ বা timer-এর মাধ্যমে চলা agent আপনার দেখার আগেই কোনো ভুল সিদ্ধান্তের ওপর কয়েক ঘণ্টা ধরে কাজ করতে পারে। এটাই VPS-এ coding agent চালানোর বাস্তব ঝুঁকি। তাই loop engineering করা ব্যক্তিরা individual prompt-এর চেয়ে standing instruction নিয়ে বেশি যত্নশীল থাকেন। always-on file-এর একটি rule turn 200-তেও প্রযোজ্য হয়। Chat-এ লেখা একটি rule শুধু turn 3-এ প্রযোজ্য হয়। একই server-এ শুরু করা দ্বিতীয় session-এর ক্ষেত্রেও প্রথম rule প্রযোজ্য হয়, কারণ সেটি committed file পড়ে; তবে প্রথম session-এ chat-এ লেখা কোনো কিছু সেটি পায় না, এমনকি দুটি session একে অপরকে message পাঠাতে পারলেও।

নতুন dependency আরেকটি নীরব খরচ। Rung 5-এ বলা আছে, যা installed আছে সেটিই ব্যবহার করতে হবে। Agent নিজের উদ্যোগে যে package যোগ করে, পরে আপনাকেই সেটি patch করতে হয়। সেই package repository থেকে তৈরি করা প্রতিটি container image-এও যুক্ত হয়ে যায়।

Ponytail-এর নিজস্ব benchmark সংখ্যাগুলো কী বলছে

প্রকল্পটি দুই ধরনের ফলাফল প্রকাশ করেছে, এবং সেগুলো একে অপরের সঙ্গে বড় ব্যবধানে অসঙ্গত। উভয়ই প্রকল্পের নিজস্ব প্রকাশিত পরিসংখ্যান। কোনোটিই স্বাধীন পরীক্ষা নয়।

[
  {
    "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
  }
]

চার্টটি প্রকল্পের বর্তমান agentic benchmark, যার তারিখ 7 October 2026। Default effort-এ Opus 5.5 ব্যবহার করে Headless Claude Code 2.1.288 session মোট 39টি task সম্পন্ন করেছে; প্রতিটি task ও arm-এর জন্য পাঁচটি run, সব মিলিয়ে 585টি session। পরীক্ষায় no skill, Ponytail v4.13.0 এবং Ponytail 5 ব্যবহার করা হয়েছে। Task-এর 12টি tiangolo-এর full-stack-fastapi-template-এর feature ticket, যা একটি বাস্তব FastAPI ও React repository; রেখে যাওয়া git diff-এর ভিত্তিতে সেগুলোর score করা হয়েছে। বাকি task-এর মধ্যে hidden check-সহ 18টি surgical task, ছয়টি ছোট app request এবং তিনটি "show me an example" request রয়েছে। প্রতিটি arm-এ Bash disabled ছিল। Ponytail 5 ব্যবহার করলে output token 45 percent কমেছে।

এটিকে প্রকল্পের June 2026-এ প্রকাশিত single shot পরিসংখ্যানের সঙ্গে তুলনা করুন। সেগুলোতে rule ছাড়া এবং rule-সহ পাঁচটি দৈনন্দিন prompt-এর উত্তর দেওয়া bare model-এর ফল repeated run-এর median হিসেবে দেখানো হয়েছিল। Haiku, Sonnet এবং Opus জুড়ে সেখানে 80 থেকে 94 percent কম code দেখা গিয়েছিল, এবং 17 June 2026 তারিখের cost verification-এ Haiku-এর খরচ 63 percent কম দেখানো হয়েছিল। Ponytail 5-এর বর্তমান agentic ফলাফলে code-এর line 53 percent কম, cost 26 percent কম এবং wall clock time 41 percent কম। প্রকল্পটি single shot সংখ্যাটি দ্রুত সংশোধন করেছে। v4.8.4 অনুযায়ী, 29 June 2026-এর মধ্যে README-তে agentic ফলাফল "~54% less code (up to 94%)" শিরোনামে দেখানো হয়েছিল। সেখানে উল্লেখ ছিল যে আগের 80 থেকে 94 percent ছিল "the per-task ceiling, not the average", এবং single shot সংখ্যাগুলো "Older single-shot numbers" নামের collapsed section-এ সরিয়ে নেওয়া হয়েছিল। ওই section-এ ব্যবধানের কারণ স্পষ্টভাবে বলা হয়েছিল: single shot baseline হলো এমন একটি bare model, যা "pads its answer with prose and options"—এটি অতিক্রম করা সহজ। বাস্তব কাজ করা একটি বাস্তব agent-এর সঙ্গে তুলনা করলে উন্নতির ব্যবধান কমে যায়। তবে উন্নতিটি বাস্তবই থাকে, এবং ব্যবহারিক দিক থেকে এটিই বেশি গুরুত্বপূর্ণ তথ্য। June-এর ওই agentic run-এ Haiku 4.5 ব্যবহার করে 12টি ticket-এ প্রতিটির জন্য চারটি করে run চালানো হয়েছিল; সেখানে code-এর line 54 percent কমেছিল, যা আজকের ফলাফলের কাছাকাছি। বর্তমান README-তে আর single shot সংখ্যাগুলো নেই।

একটি caveat প্রকল্পটি নিজেই উল্লেখ করেছে, এবং এই সুবিধা আপনার কাজে লাগবে কি না তা মূলত সেটিই নির্ধারণ করে। যেখানে code অতিরিক্তভাবে বড় করে লেখার প্রকৃত ঝুঁকি থাকে, সেখানে সাশ্রয় সবচেয়ে বেশি। Code আগে থেকেই minimal হলে সাশ্রয় প্রায় শূন্য। October-এর per-task table-এও এর প্রমাণ আছে; কয়েকটি surgical task-এ তিনটি arm-এই line count একই ছিল। একটি model ও একটি host-এ Bash disabled রেখে চালানো 39টি task আপনার repository-এর ফলাফল অনুমান করার জন্য যথেষ্ট নয়। সংখ্যাটি আপনার কাছে গুরুত্বপূর্ণ হলে, নিজের ticket-এ rule ছাড়া এবং rule-সহ তুলনা চালান এবং line নিজেই গুনুন।

আজই কোনো কিছু ইনস্টল না করে যে প্যাটার্নটি কপি করতে পারেন

ল্যাডারটি লেখা আকারে আছে, তাই ধারণাটি ব্যবহার করতে আপনার plugin-এর প্রয়োজন নেই। আপনার agent ইতিমধ্যে যে instruction file পড়ে, সেখানে এই ধরনের একটি block paste করুন। সেটি AGENTS.md, CLAUDE.md বা আপনার editor-এর rules file হতে পারে।

## 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.

শেষ নিয়মটি আলাদাভাবে গ্রহণ করার মতো। Ponytail-এর বর্তমান releases-এ প্রচলিত নিয়ম হলো shortcut: দিয়ে tagged একটি comment লেখা, যেখানে limit এবং কখন upgrade করতে হবে তা উল্লেখ থাকে। June releases-এ, v4.8.4-সহ, এর পরিবর্তে ponytail: tag ব্যবহার করা হয়েছিল:

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

এই comment লিখতে দুই লাইন লাগে, কিন্তু এতে এমন একটি প্রশ্নের সমাধান হয়, যার জন্য অন্যথায় একটি review cycle ব্যয় হতো। এটি পরবর্তী reader-কে জানায় যে simple version ব্যবহার করা একটি সিদ্ধান্ত ছিল। একই সঙ্গে এটি উল্লেখ করে, কোন শর্তে সেই সিদ্ধান্ত আর প্রযোজ্য থাকবে না। এই comment না থাকলে reviewer বুঝতে পারেন না যে এটি বিবেচনা করে নেওয়া shortcut, নাকি agent বিষয়টি ভুলে গেছে। তাই তাঁকে প্রশ্ন করতে হয়।

আপনি block-টি কোথায় রাখছেন, তা এর বক্তব্যের মতোই গুরুত্বপূর্ণ। Agent যে file প্রতিবার run-এর সময় load করে, সেটি প্রতিটি run-এর আচরণ নিয়ন্ত্রণ করে। আপনি যেসব run পর্যবেক্ষণ করছেন না, সেগুলিও এর অন্তর্ভুক্ত। এই পার্থক্যটি এমন একটি AGENTS.md লেখা যা আপনার agent সত্যিই মেনে চলে বিষয়টির মূল কথা। এ কারণেই এই pattern shell history-তে না রেখে committed file-এ রাখা উচিত। একটি monorepo-তে এটি একাধিক committed file-এ রাখা উচিত, কারণ প্রতিটি package-এর জন্য একটি AGENTS.md রাখলে প্রতিটি directory-র নিয়ম সংক্ষিপ্ত থাকে। এতে agent-কে প্রতিবার পুরো tree-এর convention পড়তে হয় না। তবে placement কোনো নিশ্চয়তা নয়। তাই ladder-এর ভাষা আরও কঠোর করা দরকার কি না সিদ্ধান্ত নেওয়ার আগে কেন কোনো agent ইতিমধ্যে load করা নিয়ম অতিক্রম করে চলে যায় তা জানা ভালো।

যেখানে এই নিয়ম আর প্রযোজ্য নয়

এই ধাপভিত্তিক পদ্ধতিটি এমন বিদ্যমান codebase-এ feature work-এর জন্য তৈরি, যেখানে সাধারণত পুনর্ব্যবহারযোগ্য উপাদান থাকে এবং সেগুলো সাধারণত সঠিক পছন্দ। এটি greenfield project-এ তুলনামূলকভাবে কম কার্যকর, কারণ rung 2-এ পুনর্ব্যবহার করার মতো কিছু থাকে না এবং rung 5-এ ইনস্টল করা কোনো উপাদান থাকে না। Agent তবু rung 1, standard library, platform feature বা one-liner-এ থামতে পারে। কিন্তু সবচেয়ে কম খরচের দুটি বিকল্প না থাকায় বেশি কাজেই নতুন code লিখতে হয়। আপনি যখন সত্যিই abstraction যোগ করতে চান, তখনও এটি ভালোভাবে প্রযোজ্য নয়। একই copied block-এর চতুর্থ caller যোগ করতে যাচ্ছেন, এমন সময় "shortest diff" আপনাকে পঞ্চম copy তৈরি করতে বাধ্য করে।

ultra level আপনার requirements নিয়ে প্রশ্ন তুলবে। এই level-এর উদ্দেশ্যই তা, এবং সিদ্ধান্ত ইতিমধ্যে নেওয়া হয়ে গেলে ও কাজটি সম্পন্ন করাতে চাইলে এটি একটি বাস্তব খরচ। সাধারণ কাজের জন্য full ব্যবহার করুন। কোনো feature request-ই সমস্যার মূল কারণ বলে সন্দেহ হলে ultra ব্যবহার করুন।

সমস্যাটি ভুলভাবে বোঝা থেকে কোনো instruction block আপনাকে রক্ষা করতে পারে না। সিদ্ধান্ত নেওয়ার আগে code বোঝাই ruleset-এর প্রথম নির্দেশনা। এটিই সবচেয়ে ব্যয়বহুল অংশ, এবং text আপনার হয়ে এটি করতে পারে না। ভুল function-এ minimal diff করলেও সেটি ভুল fix-ই থাকে। এখন সেটি এমন একটি ছোট ভুল fix, যা সহজে অনুমোদন করা যায়।

সৎভাবে বললে, Ponytail হলো যত্নসহকারে লেখা একটি prompt, যা ভালোভাবে বিতরণ করা হয়েছে এবং যার সঙ্গে কিছু সংখ্যা যুক্ত করা হয়েছে। এতে plugin ব্যবহারের কোনো বাধ্যবাধকতা নেই। Project আপনাকে যা দেয়, তা হলো কেউ তালিকাটি সঠিকভাবে লিখেছে, একটি বাস্তব repository-তে পরীক্ষা করেছে এবং ফলাফলের পাশে পদ্ধতিটি প্রকাশ করেছে।

FAQ

Ponytail কি Claude Code ছাড়া অন্য agent-এর সঙ্গে কাজ করে?

হ্যাঁ। এটি এমন host-এর জন্য skill হিসেবে প্রকাশ করা হয়েছে, যেগুলো skill load করে। এই তালিকায় Claude Code, Codex, OpenCode, Gemini এবং README-তে উল্লেখ করা আরও কয়েকটি host রয়েছে। Cursor, Windsurf, Cline এবং Copilot-এর মতো যেসব editor rule file পড়ে কিন্তু skill load করে না, সেগুলো সংশ্লিষ্ট rules directory থেকে always-on ruleset নেয় এবং কোনো slash command পায় না। দুই ক্ষেত্রেই text একই থাকে। প্রকৃত পার্থক্য হলো, আপনার host প্রতিটি turn-এ ওই text context-এ রাখে কি না, নাকি শুধু skill trigger হলে রাখে।

Lazy agent কি test, validation বা security বাদ দেবে?

না, এবং ruleset-এ এটি সরাসরি বলা আছে। এর "never lazy about" তালিকায় trust boundary-তে input validation, data loss প্রতিরোধকারী error handling, security এবং accessibility রয়েছে। প্রতিটি non-trivial logic-এর অংশের জন্য একটি ছোট runnable check রাখতেও এতে বলা হয়েছে। এই rule যে বিষয়টি বাদ দেয়, তা হলো বানানো structure: কেউ না চাওয়া abstraction এবং কারও প্রয়োজন না থাকা dependency। এটি install করার পরে আপনার agent test বাদ দিতে শুরু করলে, কারণটি হলো আপনার নিজস্ব config-এর অন্য কোনো instruction এই rule-এর চেয়ে বেশি অগ্রাধিকার পাচ্ছে। তাই agent সর্বশেষ যে file load করে, সেটি পড়ুন।

প্রকাশিত speed এবং cost-এর সংখ্যা কি নির্ভরযোগ্য?

এগুলো project-এর নিজস্ব measurement, এবং project তার method-সহ এগুলো প্রকাশ করেছে। তাই সেই প্রেক্ষিতেই এগুলো পড়া উচিত। June 2026-এর single shot figure-গুলো এমন একটি bare model-এর সঙ্গে তুলনা করা হয়েছিল, যেটি prose এবং option যোগ করে তার উত্তর অপ্রয়োজনীয়ভাবে দীর্ঘ করেছিল। README-তে তখন ওই baseline-কে নিজেই দুর্বল বলা হয়েছিল। বর্তমান agentic figure-গুলো Opus 5.5-এ headless Claude Code session থেকে নেওয়া। এতে 39টি task ছিল, প্রতিটিতে পাঁচটি করে run, এবং এর মধ্যে 12টি ছিল একটি FastAPI ও React repository-র feature ticket। ওই setup-এর জন্য এগুলো সৎ পরিমাপ। আপনার codebase-এর জন্য এগুলো পূর্বাভাস নয়, কারণ project-এর নিজস্ব per-task result দেখায় যে code আগে থেকেই minimal হলে সাশ্রয় প্রায় শূন্যে নেমে আসে।

এই সুবিধা পেতে কি কিছু install করতে হবে?

না। ladder-টি text-ভিত্তিক। আপনার agent যে instruction file আগে থেকেই পড়ে, সেখানে সমতুল্য একটি block paste করলেই অধিকাংশ সুবিধা পাওয়া যায়। Plugin-টি maintained wording, intensity level, review command এবং update path দেয়। আগে copied block ব্যবহার করে দেখা হলো rung 1-এর উত্তর: আদৌ install করতে হবে কি না, তা যাচাই করার জন্য এটিই যথেষ্ট।

Unattended agent-কে রাতভর অতিরিক্ত কাজ করা থেকে কীভাবে থামাব?

Rule-টি chat message-এর বদলে always-on instruction file-এ রাখুন। তাহলে এটি দীর্ঘ run-এর turn 200-তেও প্রযোজ্য হবে, শুধু turn 3-এ নয়। এরপর ক্ষতির সীমা আলাদাভাবে নির্ধারণ করুন। আপনার একমাত্র copy-এর বদলে agent-কে এমন একটি checkout দিন, যেটি নষ্ট করার অনুমতি তার আছে। Merge করার আগে human diff review বাধ্যতামূলক করুন। Minimal diff rule আপনাকে কতটা পড়তে হবে তা কমায়। তবে কোন পরিবর্তন merge হবে, তা এটি নির্ধারণ করে না এবং করা উচিতও নয়।