---
name: copy-writing-fa
description: Write Persian web copy (blog articles, product descriptions, landing pages, category text, microcopy, meta titles and descriptions) using Cursor workers, so the writing runs on the Cursor subscription's quota instead of Claude's. Use when the user asks for Persian content for a site, says "متن فارسی بنویس", "مقاله بنویس", "توضیح محصول بنویس", "کپی‌رایتینگ فارسی", "محتوای سئو", "copy for the site in Persian", or wants blog/product/landing copy generated at volume. Also use to edit, proofread, or de-AI existing Persian copy. Claude writes the brief and accepts the result; Cursor writes and lints.
---

# کپی‌رایتینگ فارسی با ناوگان Cursor

Claude مغز کار است: زاویه، بریف، کلمه هدف، ساختار و پذیرش نهایی. کارگرهای Cursor
می‌نویسند و ویرایش می‌کنند، روی سهمیه Cursor نه Claude.

## مسیر مدل‌ها (اندازه‌گیری شده، نه حدس)

بیست و پنجم تیر ۱۴۰۵ روی هفت مدل Cursor یک آزمون واقعی گرفتیم: یک بار تولید متن
(توضیح محصول + مقاله + سئو + میکروکپی) و یک بار ویرایش یک متن عمدا خراب.

| مرحله | مدل | چرا |
|---|---|---|
| نوشتن | `claude-opus-5-high` | بهترین نثر: ریتم متنوع، تصویر مشخص، عمق موضوعی درست. تنها مدلی که سقف کلمه و سقف کاراکتر سئو را رعایت کرد. |
| ممیزی | `gpt-5.6-sol-high` | دقیق‌ترین غلط‌گیر: ۵۰ خطا پیدا کرد، بیشتر از همه. ولی نویسنده خوبی نیست. |
| انبوه | `auto` | رایگان و بی‌سهمیه. برای پیش‌نویس حجمی کافی است. |

نکته‌ای که خلاف انتظار درآمد: GPT بهترین *مصحح* است، نه بهترین *نویسنده*.
`gpt-5.6-sol-high` در تولید متن یکنواخت و پرتکرار نوشت و سقف کلمه را شکست؛ در
ویرایش بی‌رقیب بود. Gemini در نگارش تمیز بود ولی قضاوت تحریری نداشت: ادعای
اثبات‌نشده و پرسش تبلیغاتی را در بازنویسی نگه داشت.

## مرحله ۱ — بریف (کار Claude)

قبل از هر تماس با Cursor، این‌ها را خودت مشخص کن:

- **زاویه**: این متن چه چیزی می‌گوید که رقیب نمی‌گوید.
- **کلمه هدف** و دو مترادف.
- **ساختار**: تیترها به ترتیب، با یک جمله توضیح هر بخش.
- **منبع واقعیت**: مسیر فایل‌هایی که کارگر باید از آن‌ها فکت بردارد. برای
  seyedmohammad.com یعنی `content/treasury/raw/` و `docs/seo/KEYWORD-MAP.md`.
- **طول**: از جدول بخش ۹ [rulebook.md](rulebook.md).
- **چیزی که نباید دست بخورد**: قیمت، ادعای عددی، فایل‌های دیگر.

بریف را کامل بنویس. کارگر Cursor با حافظه خالی شروع می‌کند و این گفت‌وگو را
نمی‌بیند.

## مرحله ۲ — نوشتن

متن کوتاه (زیر ۴ دقیقه کار): ابزار `cursor_run` از همین افزونه.
مقاله کامل: اجراکننده لِگ‌دار، چون استریم بلند روی VPN می‌میرد.

```bash
"${CLAUDE_PLUGIN_ROOT}/scripts/legged-run.sh" \
  --cwd <repo> --model claude-opus-5-high "<بریف کامل>"
```

در متن تسک همیشه این دو خط را بگذار:

> قواعد نگارش در `<plugin>/skills/copy-writing-fa/rulebook.md` است. بخوان و
> رعایت کن. بعد از نوشتن، `python3 <plugin>/scripts/fa-lint.py <file>` را اجرا کن
> و تا وقتی PASS نشده تحویل نده.

کارگری که خودش لینت می‌زند، رفت‌وبرگشت را حذف می‌کند.

## مرحله ۳ — دروازه مکانیکی

```bash
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/fa-lint.py" path/to/file.mdx
```

کد خروج ۰ یعنی قبول. خطاها را باید صفر کرد؛ هشدارها قضاوت انسانی‌اند. لینتر
کد، frontmatter، تگ JSX و لینک را نادیده می‌گیرد، پس روی فایل MDX مستقیم کار
می‌کند.

## مرحله ۴ — ممیزی (فقط برای متن مهم)

پیش‌نویس را به `gpt-5.6-sol-high` بده و فقط فهرست خطا بخواه، نه بازنویسی. بعد
همان فهرست را به **همان نشست Opus** برگردان:

```
extraArgs: ["--resume", "<session_id مرحله ۲>"]
```

چون نشست زنده است، کارگر متن خودش را در حافظه دارد و اصلاح ارزان تمام می‌شود.
هرگز از صفر شروع نکن.

## مرحله ۵ — پذیرش (کار Claude)

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

**آزمون آخر، مهم‌ترین آزمون:** یک بند را بلند بخوان. اگر مثل بروشور یا مثل ترجمه
ماشینی صدا داد، رد کن. خروجی باید طبیعی، ساده و روان باشد؛ انگار یک آدم نوشته که
موضوع را بلد است، نه یک ماشین که کلمه پر کرده.

لینتر بخشی از این را خودش اندازه می‌گیرد (بخش ۱۱ [rulebook.md](rulebook.md)):
یکنواختی ریتم جمله، تکرار شروع جمله، عبارت تکراری، و جمله پایانی توخالی. این‌ها
روی داده واقعی کالیبره شده‌اند، نه از روی حدس: یک مقاله انسانی همین سایت ضریب
تغییرات ۰٫۶۱ گرفت و ماشینی‌ترین مدل ۰٫۱۷. سنجش ریتم فقط روی متن بلند (۱۸ جمله به
بالا) اجرا می‌شود، چون روی توضیح محصول کوتاه آمارش قابل اتکا نیست.

اما لینتر مزه را نمی‌فهمد. تصمیم آخر با توست.

## وقتی روی چند پروژه اجرا می‌کنی

سه چیز که یک پاس چندمخزنی را خراب می‌کند، و هر سه در عمل اتفاق افتاده‌اند:

**۱. لحن هر پروژه مال خودش است.** این مهم‌ترین قاعده این بخش است. اگر مخزن
`BRAND.md` یا `voice-tone.md` یا بخش لحن در `AGENTS.md` دارد، آن حاکم است و
[rulebook.md](rulebook.md) فقط پیش‌فرض. یک فروشگاه مصرفی درست است که «تو» بگوید و
یک محصول سازمانی درست است که «شما» بگوید. ناوگانی که آزاد بگذاری، لحن یک سایت را
روی سایت دیگر می‌نشاند و برند را خراب می‌کند. قبل از فن‌اوت، برای هر مخزن مشخص کن
لحنش چیست و در متن تسک بنویس. لینتر هم `--voice formal` دارد تا روی سایت B2B
هشدار الکی ندهد؛ ولی قاطی‌کردن دو لحن را در هر حالت می‌گیرد.

**۲. بخشی از متن اصلا در مخزن نیست.** محصول و مقاله ممکن است در CMS یا دیتابیس
باشد (Medusa، Sanity، پنل مدیریت). ورکری که این را نداند، دنبال فایلی می‌گردد که
وجود ندارد یا فایل اشتباه را عوض می‌کند. اول جای متن را مشخص کن، بعد تسک بنویس، و
به ورکر بگو اگر متن در مخزن نبود فقط گزارش بدهد.

**۳. متن مشترک، بیشترین اثر را دارد.** اگر سایت‌ها روی یک کتابخانه مشترک سوارند،
پیام خطا و قالب ایمیل و متن فاکتور آنجاست و همه سایت‌ها ارثش می‌برند. یک متن بد
آنجا در همه سایت‌ها تکرار می‌شود. اول آن را درست کن، جدا از بقیه، و بعد تست بگیر:
شعاع اثرش هم به همان اندازه بزرگ است.

هر مخزن برنچ و کامیت جدا. هیچ‌وقت یک کامیت غول‌پیکر بین‌مخزنی نساز.

## هشدارها

- **فکت از منبع، نه از مدل.** قیمت، درصد، اسم تامین‌کننده و آمار بازار فقط از
  فایل‌های پروژه. مدل‌ها در آزمون ما وقتی فکت نداشتند، خوش‌بینانه گرد کردند.
- **سقف طول را جدی بگیر.** متن بلندتر از بریف تقریبا همیشه پرکردن است.
- **صداقت در گزارش.** اگر ناوگان گیر کرد یا سهمیه تمام شد، بگو. کار را بی‌صدا
  روی سهمیه Claude دوباره نکن.