Ponytail: AI coding agent తక్కువ code రాయేలా చేసే rules

Ponytail అంటే ఏమిటి

Ponytail అనేది AI coding agent తక్కువ code రాసేలా చేసే rules సమాహారం. ఈ project తనను ఒకే వాక్యంలో ఇలా వివరిస్తుంది: "మీ AI agent గదిలో ఉన్న అత్యంత సోమరి senior developer లా ఆలోచించేలా చేస్తుంది. మీరు ఎప్పుడూ రాయకపోయిన code నే అత్యుత్తమ code." ఇది MIT license కింద విడుదలైంది. దీనికి స్వంత runtime లేదు, ఇందులో ఏదీ execute కాదు. ఇది agent instructions లోకి చేర్చే text. Skills load చేసే hosts కోసం దీన్ని skill గా, skills load చేయని hosts కోసం plain rule files గా package చేశారు.

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 మధ్యనే పది tags ఉన్నాయి. ఇంత వేగంగా మారుతున్న project మీరు దీన్ని చదివే సమయానికి మారి ఉండవచ్చు. అందువల్ల దాని ఆధారంగా ఏదైనా build చేయడానికి ముందు ఒక tag ను pin చేయండి.

పనిముట్టు ముందు ఆలోచన: సరైన మొదటి మెట్టుపైనే ఆగండి

Ponytail యొక్క ప్రధాన భావన నిర్ణయాల మెట్టు. ఏదైనా రాయడానికి ముందు agent ఈ మెట్లను పరిశీలించి, సరిపోయే మొదటి మెట్టుపైనే ఆగుతుంది.

1. ఇది అసలు ఉండాల్సిన అవసరం ఉందా? ఇది YAGNI (మీకు ఇది అవసరం ఉండదు) సూత్రం. సమాధానం లేదు అయితే దాన్ని వదిలేయండి.
2. ఇది ఇప్పటికే ఈ codebase లో ఉందా? ఇప్పటికే ఉన్న helper లేదా pattern ను మళ్లీ ఉపయోగించండి.
3. standard library దీన్ని చేయగలదా? దానినే ఉపయోగించండి.
4. native platform feature దీన్ని అందిస్తుందా? దానినే ఉపయోగించండి.
5. ఇప్పటికే install చేసిన dependency దీనికి పరిష్కారం ఇస్తుందా? దానినే ఉపయోగించండి.
6. దీన్ని ఒక line లో రాయగలరా? ఒక line గానే రాయండి.
7. ఆ తరువాత మాత్రమే, పనిచేసే కనిష్ఠ code ను రాయండి.

పనిని చేసేది ఏకైక మెట్టు కాదు; వాటి క్రమమే పనిని చేస్తుంది. date picker అడిగితే agent date picker రాస్తుంది, ఎందుకంటే అదే రాయమని దానికి చెప్పారు. ఈ ladder ముందుగా మెట్టు 4 ను పరిశీలించేలా చేస్తుంది. మెట్టు 4 ప్రకారం browser లో ఇప్పటికే <input type="date"> ఉంది. ఈ project's benchmark notes లో ఇదే విషయం స్పష్టంగా ఉంది: ఈ నియమం లేకుండా date picker 404 lines కు చేరింది; నియమంతో 23 lines కు తగ్గింది. కారణం, agent component నిర్మించకుండా native input ను ఉపయోగించింది. colour picker కూడా ఇదే కారణంతో 287 lines నుంచి 23 lines కు తగ్గింది. మెట్టు 2 నిశ్శబ్దంగా విఫలమయ్యే మెట్టు. మీ వద్ద ఇప్పటికే ఉన్న helper ను agent చూడలేకపోతే, అది రెండవ helper ను సంతోషంగా రాస్తుంది. ఈ అంతరాన్ని మీ codebase యొక్క query చేయగల map పూడ్చడానికి ఉద్దేశించబడింది.

ఇక్కడ lazy అంటే నిర్లక్ష్యంగా ఉండటం కాదు. ruleset ఇదే విషయాన్ని నేరుగా చెబుతుంది. దాని "ఎప్పుడూ lazy గా ఉండకూడని" జాబితాలో నిర్ణయం తీసుకునే ముందు సమస్యను అర్థం చేసుకోవడం, trust boundaries వద్ద input validation, data loss ను నివారించే error handling, security, accessibility, అలాగే మీరు పేరు పెట్టి అడిగిన ప్రతి అంశం ఉన్నాయి. అదనంగా, non-trivial logic ఉన్న ప్రతి భాగానికి ఒక చిన్న runnable check ఉండాలని అది అడుగుతుంది. ఈ నియమం అనవసరమైన కొత్త నిర్మాణాన్ని తగ్గిస్తుంది. correctness ను కాదు.

రిపాజిటరీ వాస్తవంగా విడుదల చేసేవి

• AGENTS.md, ఎల్లప్పుడూ అమలులో ఉండే ruleset. ఐదు నిమిషాల్లో చదవగలిగే ఒకే ఫైల్‌లో మొత్తం భావన ఉంటుంది.
• skills/ponytail/SKILL.md, skill definition. దీనికి lite, full లేదా ultra అనే argument hint ఉంటుంది.
• .cursor/rules/ మరియు .windsurf/rules/ వంటి editor-specific directories లోని rule files. rules ను చదివి skills ను load చేయని hosts కోసం ఇవి ఉంటాయి.
• hooks/, benchmarks/, examples/ మరియు scripts/.

Intensity argument నియమం ఎంత కఠినంగా అమలవుతుందో మార్చుతుంది. lite మీరు అడిగినదాన్ని నిర్మించి, ఒకే పంక్తిలో మరింత సులభమైన option ను సూచిస్తుంది. full default విలువ. ఇది ladder ను తప్పనిసరిగా అమలు చేస్తుంది. ultra అనేది YAGNI యొక్క అత్యంత కఠినమైన setting. ఇది జోడించడంకంటే తొలగింపును ప్రాధాన్యంగా తీసుకుంటుంది మరియు requirement పైనే అభ్యంతరం చెబుతుంది.

Skills కు మద్దతు ఉన్న hosts కు slash commands కూడా లభిస్తాయి. /ponytail స్థాయిని సెట్ చేస్తుంది, /ponytail-review over-engineering కోసం diff ను పరిశీలిస్తుంది, /ponytail-audit మొత్తం repository ను పరిశీలిస్తుంది, /ponytail-debt మీరు వాయిదా వేసిన shortcuts ను సేకరిస్తుంది, /ponytail-gain benchmark scorecard ను ప్రింట్ చేస్తుంది. Rule files మాత్రమే చదివే hosts కు commands లేకుండా ruleset మాత్రమే లభిస్తుంది.

Source ను నమ్మేముందు చదవాలంటే branch ను కాకుండా tag ను clone చేయండి:

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

Claude Code లో project బదులుగా plugin install ను document చేస్తుంది. 1 August 2026 నాటికి ఈ రెండు పంక్తులు documentation లో ఉన్న విధంగానే ఉన్నాయి:

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

Plugin path tag ను కాకుండా default branch ను అనుసరిస్తుంది. అందువల్ల మీ agent కు మార్గనిర్దేశం చేసే instructions sessions మధ్యలో మీ నియంత్రణ లేకుండానే మారవచ్చు. Update command అందించే సౌలభ్యం కోసం మీరు అంగీకరించే trade-off ఇదే.

VPSలో lazy agent ఎందుకు తక్కువ ఖర్చుతో ఉంటుంది

Agent రాసిన diff conversation బయటకు వెళ్లదు. తదుపరి turnలో model దాన్ని, అలాగే దాన్ని రూపొందించడానికి తెరిచిన ప్రతి fileను మళ్లీ చదువుతుంది. అందువల్ల 500 line changeను రూపొందించిన turnకు మాత్రమే కాదు, sessionలోని ప్రతి తరువాతి turnకు కూడా అదనపు భారంగా మారుతుంది. అందుకే runaway refactor వల్ల session కొనసాగుతున్న కొద్దీ agent నెమ్మదిగా, తక్కువ సామర్థ్యంతో పనిచేస్తున్నట్లు అనిపిస్తుంది. Window agent స్వంత outputతో నిండిపోతుంది. దాంతో మీ అసలు codeకు మిగిలే స్థలం తగ్గుతుంది. దీన్ని నియంత్రించడం అంటే coding agent యొక్క context windowను నిర్వహించడం.

Tokens inputగా వెళ్లినప్పటికీ, outputగా వచ్చినప్పటికీ billingలో లెక్కించబడతాయి. అందువల్ల సగం పరిమాణం ఉన్న diff రెండు సార్లు తక్కువ ఖర్చు చేస్తుంది: ఒకసారి అది రాయబడినప్పుడు, మళ్లీ దాన్ని ప్రతి turnలో తిరిగి చదివినప్పుడు. ఆ ఆదా మీ billలో కనిపిస్తుందా లేదా అనేది మీరు చెల్లించే విధానంపై ఆధారపడి ఉంటుంది. ఎందుకంటే flat Pro లేదా Max subscription అదనపు tokens ఖర్చును కలుపుకుంటుంది. Per-token API billing మాత్రం ప్రతి tokenకు మీకు charge చేస్తుంది. Self-hosted setupలో billను గమనిస్తుంటే, instruction fileను మార్చడానికి అదనపు ఖర్చు ఉండదు. AI agent మీకు ఎంత ఖర్చు చేస్తుందో నియంత్రించడం output volumeతో ప్రారంభమవుతుంది. coding agent తన tokensను ఎలా ఖర్చు చేస్తుందో తెలుసుకుంటే, re-reading ఎందుకు ఊహించినదానికంటే ఎక్కువ ప్రభావం చూపుతుందో అర్థమవుతుంది.

Diffను మనిషి కూడా చదవాలి. 20 lines ఉండాల్సిన మార్పు 400 linesగా ఉంటే, reviewer దృష్టి దానిపై ఖర్చవుతుంది. ముందుగా తరిగిపోయేది ఆ దృష్టే. రోజులో నాలుగో long diffను, మొదటి diffను పరిశీలించినంత జాగ్రత్తగా ఎవరూ పరిశీలించరు. అందువల్ల అవసరానికి మించి code రాయడం సమయాన్ని మాత్రమే వృథా చేయదు. తప్పులను గుర్తించాల్సిన review నాణ్యతను కూడా నెమ్మదిగా తగ్గిస్తుంది.

Serverపై పరిస్థితి మరింత ప్రమాదకరంగా ఉంటుంది. ఎందుకంటే agent తరచుగా ఎవరూ పర్యవేక్షించకుండా నడుస్తుంది. tmux sessionలో లేదా timer ద్వారా పనిచేసే agent, మీరు గమనించేలోపు ఒక తప్పు నిర్ణయంపై గంటల పాటు మరిన్ని మార్పులు చేయగలదు. VPSపై coding agentను నడపడంలో ఇదే ప్రధాన ప్రాయోగిక ప్రమాదం. loop engineering చేసే వారు individual prompts కంటే standing instructionsపై ఎక్కువ శ్రద్ధ పెట్టడానికి ఇదే కారణం. ఎల్లప్పుడూ అమలులో ఉండే fileలోని rule turn 200కూ వర్తిస్తుంది. Chatలో మీరు టైప్ చేసిన rule turn 3కు మాత్రమే వర్తిస్తుంది. అదే boxపై మీరు ప్రారంభించే రెండవ sessionకూ ఆ file వర్తిస్తుంది. ఆ session committed fileను చదువుతుంది, కానీ మొదటి sessionలో మీరు chatలో టైప్ చేసినదేమీ దానికి అందదు. ఇది రెండు sessions పరస్పరం message చేయగలిగినప్పటికీ అలాగే ఉంటుంది.

కొత్త dependencies మరో నిశ్శబ్ద ఖర్చు. Rung 5లో install అయి ఉన్నదానినే ఉపయోగించాలని చెబుతుంది. Agent తన నిర్ణయంతో జోడించే ప్రతి packageను తరువాత మీరు patch చేయాలి. ఆ package repository నుంచి build చేసే ప్రతి container imageలో కూడా చేరుతుంది.

Ponytail స్వయంగా ప్రచురించిన benchmark సంఖ్యలు ఏమి చెబుతున్నాయి

ఈ project రెండు ఫలితాల సముదాయాలను ప్రచురిస్తుంది. అవి పరస్పరం చాలా తేడాతో ఉన్నాయి. రెండూ project స్వయంగా ప్రచురించిన గణాంకాలే. ఏదీ 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
  }
]

single shot column లోని సంఖ్యలు, ఆ rule తో మరియు అది లేకుండా, కొద్దిపాటి prompts కు సమాధానం ఇచ్చిన bare model నుంచి వచ్చాయి. ఇవి 13 మరియు 17 June 2026 తేదీల్లో చేసిన పునరావృత runs యొక్క medians. agentic column లోని సంఖ్యలు, tiangolo యొక్క full-stack-fastapi-template అనే నిజమైన FastAPI మరియు React repository ని headless Claude Code session సవరించినప్పుడు వచ్చినవి. Haiku 4.5 పై పన్నెండు feature tickets కు ఒక్కో ticket కు నాలుగు runs చేశారు. మిగిలిన git diff ఆధారంగా వాటికి score ఇచ్చారు.

రెండవ column ను చూడండి. agentic ఫలితంలో code lines 54 percent తక్కువగా ఉన్నాయి, cost 20 percent తక్కువగా ఉంది, wall clock time 27 percent తక్కువగా ఉంది. అదే కొలతలకు single shot setup లో ఈ సంఖ్యలు వరుసగా 93 percent మరియు 74 percent. README కారణాన్ని స్పష్టంగా చెబుతుంది: single shot baseline అనేది "several options plus commentary తో సమాధానం ఇచ్చే" bare model. దాన్ని అధిగమించడం సులభం. నిజమైన పని చేస్తున్న నిజమైన agent తో పోలిస్తే ప్రయోజనం తగ్గుతుంది. అయినప్పటికీ ఈ ఫలితం వాస్తవ పరిస్థితులకు దగ్గరగా ఉంటుంది. అందువల్ల ఇది మరింత ఉపయోగకరమైన విషయం.

ఒక ముఖ్యమైన పరిమితిని project స్వయంగా చెబుతుంది. మీకు ఇది ఉపయోగపడుతుందా లేదా అనేది దానిపైనే ఆధారపడి ఉంటుంది. నిజంగా అవసరానికి మించి నిర్మించే ప్రమాదం ఉన్న చోట saving ఎక్కువగా ఉంటుంది. ఇప్పటికే minimal గా ఉన్న code పై saving దాదాపు శూన్యం. ఒకే Python మరియు TypeScript repository లోని పన్నెండు tickets మీ repository ఫలితాలను ముందుగా చెప్పలేవు. ఈ సంఖ్య మీకు ముఖ్యమైతే, మీ స్వంత tickets పై rule తో మరియు అది లేకుండా comparison run చేయండి. Lines ను మీరే లెక్కించండి.

ఈ రోజే ఏదీ ఇన్‌స్టాల్ చేయకుండా మీరు అనుసరించగల నమూనా

ఈ ladder టెక్స్ట్ రూపంలో ఉంటుంది. అందువల్ల ఈ ఆలోచనను ఉపయోగించడానికి 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.

చివరి rule ను ప్రత్యేకంగా పరిగణించాలి. Ponytail యొక్క convention ప్రకారం, comment కు tool పేరు tag గా ఉంటుంది:

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

ఈ comment రెండు పనులు చేస్తుంది. లేకపోతే review cycle అవసరమయ్యే ఒక ప్రశ్నను ఇది పరిష్కరిస్తుంది. సరళమైన version ఉద్దేశపూర్వక decision అని, ఆ decision వర్తించని పరిస్థితి ఏమిటో తదుపరి reader కు తెలియజేస్తుంది. ఇది లేకపోతే, reviewer ఆలోచించి తీసుకున్న shortcut ను agent మర్చిపోయిన విషయంగా గుర్తించలేరు. అందువల్ల వారు ప్రశ్నించాల్సి వస్తుంది.

Block ను ఎక్కడ ఉంచారనేది, అందులో ఏమి రాశారన్నదితో సమానంగా ముఖ్యం. ప్రతి run లో agent load చేసే file, మీరు గమనించని run లతో సహా ప్రతి run ను ప్రభావితం చేస్తుంది. ఈ తేడా మీ agent నిజంగా అనుసరించే AGENTS.md రాయడం అనే విషయానికి సంబంధించినది. అందుకే ఈ pattern ను shell history లో కాకుండా committed file లో ఉంచాలి. Monorepo లో దీనిని ఒకటి కంటే ఎక్కువ committed file లలో ఉంచాలి. ఎందుకంటే ప్రతి package కు ఒక AGENTS.md ఉంచితే, ప్రతి directory యొక్క rules చిన్నగా ఉంటాయి. ప్రతి run లో agent మొత్తం tree యొక్క conventions చదవాల్సిన అవసరం ఉండదు. అయితే placement హామీ కాదు. Ladder కు మరింత కఠినమైన wording అవసరమని నిర్ణయించే ముందు, agent ఇప్పటికే load చేసిన rule ను దాటి ఎందుకు వెళ్తుందో తెలుసుకోవాలి.

ఈ నియమం వర్తించని సందర్భాలు

ఈ క్రమం ఇప్పటికే ఉన్న codebaseలో feature work కోసం రూపొందించబడింది. అలాంటి codebaseలో పునర్వినియోగం సాధారణంగా అందుబాటులో ఉండటమే కాకుండా, సాధారణంగా సరైనదిగా కూడా ఉంటుంది. ఇది greenfield projectకు సరిగ్గా సరిపోదు. ఎందుకంటే rung 2లో పునర్వినియోగం చేయడానికి ఏదీ ఉండదు, rung 5లో install చేసినది ఏదీ ఉండదు. అందువల్ల agent ప్రతిసారీ rung 7కు వెళ్తుంది. మీరు నిజంగా abstractionను జోడించాలనుకునే సమయంలో కూడా ఇది సరిగ్గా సరిపోదు. అదే copied blockను ఉపయోగించే నాల్గవ callerను జోడించబోతున్నప్పుడు, "shortest diff" మీకు ఐదవ copyని ఇస్తుంది.

ultra స్థాయి మీ requirementsను ప్రశ్నిస్తుంది. ఆ స్థాయి ఉద్దేశం అదే. అయితే మీరు ఇప్పటికే నిర్ణయం తీసుకుని, పని పూర్తిచేయాలని కోరుకున్నప్పుడు ఇది నిజమైన వ్యయం. సాధారణ పనికి full ఉపయోగించండి. Feature requestనే సమస్యగా అనుమానించినప్పుడు ultraను ఉపయోగించండి.

ఏ instruction block అయినా సమస్యను తప్పుగా అర్థం చేసుకోకుండా మిమ్మల్ని రక్షించదు. నిర్ణయం తీసుకునే ముందు codeను అర్థం చేసుకోవాలని rulesetలోని మొదటి అంశమే చెబుతుంది. అదే ఖరీదైన భాగం. ఆ భాగాన్ని text మీ తరఫున చేయలదు. తప్పు functionలో చేసిన minimal diff కూడా తప్పు fixగానే ఉంటుంది. ఇప్పుడు అది approve చేయడం సులభమైన చిన్న తప్పు fixగా మారుతుంది.

నిజాయితీగా చెప్పాలంటే, Ponytail అనేది జాగ్రత్తగా రాసిన prompt. ఇది బాగా పంపిణీ చేయబడింది. దీనికి numbers జోడించబడ్డాయి. దీనికి plugin అవసరమని చెప్పే అంశం ఏదీ లేదు. ఈ project మీకు ఇచ్చేది ఏమిటంటే, ఎవరో ఆ listను సక్రమంగా రాశారు, దాన్ని నిజమైన repositoryపై పరీక్షించారు, మరియు result పక్కనే methodను ప్రచురించారు.

FAQ

Ponytail, Claude Code కాకుండా ఇతర agents తో కూడా పనిచేస్తుందా?

అవును. skills ను లోడ్ చేసే hosts కోసం ఇది ఒక skill గా విడుదల చేయబడుతుంది. ఆ జాబితాలో Claude Code, Codex, OpenCode, Gemini ఉన్నాయి. README లో మరికొన్ని hosts కూడా పేర్కొనబడ్డాయి. Cursor, Windsurf, Cline, Copilot వంటి rule files ను చదివినా skills ను లోడ్ చేయని editors, సరిపోలే rules directory నుంచి always-on ruleset ను తీసుకుంటాయి. వాటికి slash commands అందుబాటులో ఉండవు. రెండు సందర్భాల్లోనూ text ఒకటే ఉంటుంది. వాస్తవ తేడా ఏమిటంటే, ప్రతి turn లో మీ host ఆ text ను context లో ఉంచుతుందా, లేక skill trigger అయినప్పుడు మాత్రమే లోడ్ చేస్తుందా అన్నది.

lazy agent tests, validation లేదా security ను వదిలేస్తుందా?

లేదు. Ruleset దీనిని నేరుగా పేర్కొంటుంది. దాని "never lazy about" జాబితాలో trust boundaries వద్ద input validation, data loss ను నిరోధించే error handling, security, accessibility ఉన్నాయి. ప్రతి non-trivial logic భాగానికి ఒక చిన్నగా run చేయగల check ఉండాలని కూడా ఇది కోరుతుంది. Rule తొలగించేది కల్పిత structure మాత్రమే: ఎవరూ కోరని abstractions, ఎవరికీ అవసరం లేని dependencies. దీన్ని install చేసిన తర్వాత మీ agent tests ను వదిలేస్తే, మీ స్వంత config లోని మరొక instruction దీనికంటే ఎక్కువ ప్రాధాన్యత పొందడం కారణం. అందువల్ల agent చివరిగా లోడ్ చేసే file ను చదవండి.

ప్రచురించిన speed మరియు cost సంఖ్యలను నమ్మవచ్చా?

అవి project స్వయంగా చేసిన measurements. వాటి విధానంతో పాటు ప్రచురించబడ్డాయి. కాబట్టి వాటిని ఆ సందర్భంలోనే అర్థం చేసుకోవాలి. Single shot గణాంకాలు options మరియు commentary తో సమాధానం ఇచ్చే bare model తో పోలుస్తాయి. README కూడా ఆ baseline బలహీనమైనదని పేర్కొంటుంది. Agentic గణాంకాలు ఒక FastAPI మరియు React repository పై headless Claude Code session నుంచి వచ్చాయి. ఇందులో twelve tickets ఉన్నాయి. Haiku 4.5 పై ప్రతి ticket కు four runs నిర్వహించారు. ఆ setup కు అవి విశ్వసనీయమైన సంఖ్యలు. కానీ అవి మీ codebase కోసం forecast కావు. ఇప్పటికే minimal గా ఉన్న code పై saving near zero కు పడిపోతుందని project కూడా చెబుతుంది.

ప్రయోజనం పొందడానికి ఏదైనా install చేయాలా?

లేదు. Ladder అనేది text మాత్రమే. మీ agent ఇప్పటికే చదివే instruction file లో సమానమైన block ను paste చేస్తే, ప్రభావంలో ఎక్కువ భాగం పొందవచ్చు. Plugin నిర్వహించబడే wording, intensity levels, review commands, update path ను అందిస్తుంది. Install నిజంగా అవసరమా అనే ప్రశ్నకు copied block తో ముందుగా ప్రయత్నించడం rung 1 సమాధానం.

unattended agent రాత్రంతా అవసరానికి మించి నిర్మాణం చేయకుండా ఎలా ఆపాలి?

Rule ను chat message లో కాకుండా always-on instruction file లో ఉంచండి. అప్పుడు అది దీర్ఘ run లోని turn 3 వద్ద మాత్రమే కాకుండా turn 200 వద్ద కూడా వర్తిస్తుంది. తరువాత నష్టాన్ని విడిగా పరిమితం చేయండి. మీరు మాత్రమే కలిగి ఉన్న ఏకైక copy కి బదులుగా, పాడుచేయడానికి అనుమతించబడిన checkout ను agent కు ఇవ్వండి. ఏదైనా merge చేయడానికి ముందు human diff review తప్పనిసరి చేయండి. Minimal diff rule మీరు చదవాల్సిన పరిమాణాన్ని తగ్గిస్తుంది. ఏ మార్పు చేర్చాలో అది నిర్ణయించదు. నిర్ణయించకూడదు కూడా.