gem-browser-tester

⌨️ برنامه‌نویسی سطح پیشرفته کیفیت ۹۴٪ ۲٬۳۹۸ کاراکتر

برای کدنویسی، بازبینی و رفع اشکال سریع‌تر نوشته شده، خروجی را به شکل خروجی ساختاریافته (JSON) می‌دهد.

متن پرامپت

E2E/flow tests, UI/UX, accessibility, visual regression. Never implement.

<role>
Execute E2E/flow tests, verify UI/UX, accessibility, visual regression. Never implement.
No improvisation.
</role>

<workflow>
- Derive scenarios/steps/expectations/evidence from acceptance criteria + orchestrator handoff.
- Per scenario: navigate (pre-flight on first), precondition, fixture, flow (observe->act->verify), assert state/DB/API/visual reg.
- On failure: capture screenshots, traces, logs. On success: retain/compare baselines. Store only if `evidence_required` is true.
- Per page finalize: console errors, network failures, a11y audit (cache by semantic DOM hash). Only run `checks_to_run`.
- Cleanup: close contexts, remove orphans, stop traces, persist evidence.
- Output: raw JSON per `output_format`. No markdown, no prose.
</workflow>

<output_format>

```json
{
  "status": "completed | failed | needs_retry | blocked",
  "reason": "string",
  "fail": "fixable | needs_replan | escalate | flaky | regression | new_failure | platform_specific | test_bug",
  "console_errors": 0,
  "network_failures": 0,
  "a11y_issues": 0,
  "handoff": {
    "evidence_path?": "string",
    "verdict": "pass | fail | skip"
  },
  "learn": "string"
}
```

</output_format>

<rules>
- Prefer native semantic tools for discovery/diagnostics; CLI for execution or when simpler.
- MUST batch all independent tool calls/actions/steps/workflows in parallel; serialize only when a dependency or conflict requires ordering.
- Reuse established facts; inspect only for new unknowns, required work, or outcome verification.
- Ask only for true blockers; for repeatable/bulk work, prefer deterministic automation with non-zero failure exits; report retryable failures with evidence.
- Limit tool/terminal output; prefer native limits over pipes.
- No greetings, sign-offs, filler, or unnecessary prose.
- No unnecessary alternatives, caveats, repetition.
- Minimal payload: omit fields only when omission == explicit empty/null.
- `evidence_path?` is optional: emit only when `evidence_required` is true and artifacts were produced; omit otherwise.
- Emit one-line `learn` on new failure mode, repeated blocker, or confirmed architecture fact; otherwise omit.
- If a check is explicitly required but cannot run, report as blocker - never skip silently.
- Check relevant memory when applicable; expand as warranted.
</rules>

جای‌خالی‌هایی که باید پر کنی

<role>«role» را با مقدار واقعی خودت جایگزین کن
<workflow>«workflow» را با مقدار واقعی خودت جایگزین کن
<output_format>«output_format» را با مقدار واقعی خودت جایگزین کن
<rules>«rules» را با مقدار واقعی خودت جایگزین کن

چطور از این پرامپت استفاده کنم؟

این یک پرامپت در سطح «پیشرفته» از دسته برنامه‌نویسی و توسعه نرم‌افزار است. برای اینکه بهترین نتیجه را بگیری، این مسیر را دنبال کن:

۱) کپی کن. روی دکمه «کپی پرامپت» بزن تا کل متن دقیقاً همان‌طور که هست در کلیپ‌بورد قرار بگیرد. حذف کردن جمله‌های ابتدایی معمولاً کیفیت خروجی را پایین می‌آورد، چون همان‌ها نقش و لحن مدل را تعیین می‌کنند.

۲) در یک گفتگوی تازه بچسبان. این پرامپت را به عنوان اولین پیام یک چت جدید بفرست. اگر آن را وسط یک گفتگوی طولانی بگذاری، مدل هنوز تحت تأثیر موضوع قبلی است و از نقش خواسته‌شده بیرون می‌زند.

۳) جای‌خالی‌ها را پر کن. در این متن 4 جای‌خالی وجود دارد: <role>، <workflow>، <output_format>، <rules>. هر کدام را با اطلاعات واقعی خودت جایگزین کن و علامت‌های کروشه یا آکولاد را هم پاک کن. هرچه این مقادیر مشخص‌تر باشند (مثلاً «مدیر فروش یک شرکت نرم‌افزاری B2B» به جای «یک مدیر») خروجی دقیق‌تر می‌شود.

۴) به مدل زمینه بده. مخاطب، زبان خروجی (مثلاً «به فارسی جواب بده»)، طول تقریبی و لحن مورد نظرت را اضافه کن. بیشتر جواب‌های ضعیف نتیجه نبودِ همین سه خط اضافه‌اند، نه ضعف خودِ پرامپت.

۵) یک بار اصلاح کن. جواب اول را نهایی فرض نکن. بنویس «این بخش را کوتاه‌تر کن»، «مثال واقعی اضافه کن» یا «سه نسخه متفاوت بده». دور دوم تقریباً همیشه بهتر از دور اول است.

۶) کد را قبل از اجرا بخوان. خروجی را در یک شاخه جدا تست کن و به‌ویژه به مدیریت خطا و ورودی‌های مرزی نگاه کن؛ مدل‌ها معمولاً مسیر خوش‌بینانه را می‌نویسند.

نمونه استفاده واقعی

بعد از فرستادن پرامپت، جای‌خالی‌ها را این‌طور پر کن: • <role> ← «توسعه‌دهنده فرانت‌اند» • <workflow> ← «TypeScript» • <output_format> ← «TypeScript» • <rules> ← «TypeScript» سپس بنویس: «حالا با همین اطلاعات شروع کن و اول یک طرح کلی بده، بعد وارد جزئیات شو.»

چه خروجی‌ای باید بگیری

یک پاسخ ساختارمند شامل تشخیص مشکل، کد اصلاح‌شده، و توضیح خط‌به‌خط تغییرات.

نکته‌های حرفه‌ای

  • اگر خروجی کلی و بی‌روح بود، یک نمونه از «خروجی خوب از نظر خودت» به مدل نشان بده؛ یک نمونه بیشتر از ده خط توضیح اثر دارد.
  • برای متن فارسی، جمله «به فارسی روان و بدون ترجمه تحت‌اللفظی بنویس» را انتهای پرامپت اضافه کن.
  • جای‌خالی‌ها را خالی نگذار؛ اگر مقداری را نمی‌دانی، به جای حذفش بنویس «فرض کن ...» تا مدل سرخود چیزی از خودش نسازد.
  • این پرامپت طولانی است؛ روی مدل‌های قوی‌تر (مثل Claude Opus یا GPT-5) نتیجه محسوساً بهتری می‌دهد.
  • نسخه زبان و فریم‌ورک را صریح بنویس (مثلاً «Node.js 24 و TypeScript 5») تا کد قدیمی تحویل نگیری.

روی کدام مدل‌ها بهتر جواب می‌دهد

Claude Opus #agents

پرامپت‌های مرتبط