چطور با /doctor prompt-audit دستورهای کهنه‌ی CLAUDE.md را پیدا کنیم

کلاد کد از نسخه‌ی 2.1.283 دستور /doctor prompt-audit را اضافه کرد که فایل‌های دستورالعمل شما را می‌خواند و دستورهای نوشته‌شده برای مدل‌های قدیمی را نشان می‌دهد. در این پست راهنمایی را که خود کلاد کد همراه نصبش می‌آورد از داخل نصب بیرون می‌کشیم، سپس همان سیگنال‌های grep را روی یک پروژه‌ی واقعی اجرا می‌کنیم و با git blame منشأ هر خط را جدا می‌کنیم.

دستورهای شما هم پیر می‌شوند

پیکربندی هر پروژه‌ای به مرور پوس می‌خورد: در یک نشست پاسخ کوتاه است و یک سطر اضافه می‌کنید؛ شش ماه بعد آن سطر مانده، در حالی که مدل عوض شده. راهنمای رسمی می‌گوید این دستورها فقط توکن تلف نمی‌کنند، بلکه رفتار را خراب می‌کنند.

همان راهنما می‌گوید مدل‌های امروزی دستورها را دقیق‌تر و تحت‌اللفظی‌تر دنبال می‌کنند. نتیجه دو سویه است: زبان فشاری مثل CRITICAL که برای مدل کم‌جسارت لازم بود، حالا بیش‌فعالی می‌سازد؛ و «اگر ممکن است» به‌صورت literal خوانده می‌شود و مجوز کم‌کاری می‌دهد.

نکته‌ای که در توضیح رسمی دستور کمتر دیده می‌شود این است که هدف ممیزی، کوتاه کردن نیست: آسیب از دستورهای مشخصِ کهنه می‌آید، نه از حجم متن. و یک فهرست یازده‌تایی به نام keep list می‌گوید چه چیزی اصلا حذف نشود.

این جدول از خود راهنمای داخل نصب نقل شده، نه از خلاصه‌های ثالث. همان راهنما هشدار می‌دهد مثال‌های تقویت فراخوانی ابزار در توضیح ابزار جای درستی ندارند.

راهنمای ممیزی داخل نصب کلاد کد است

مهم‌ترین کشف این بود که راهنمای ممیزی فایل روی دیسک نیست؛ در فایل اجرایی کلاد کد فشرده شده و همراه نصب می‌آید. یعنی معیار سنجش، متن رسمی همان شرکتی است که مدل را می‌سازد.

# نسخه‌ی نصب‌شده را ببین و نام فایل راهنما را داخل نصب پیدا کن
claude --version
strings -a $(readlink -f $(which claude)) | grep -m1 "prompt-audit-.*\.md\.zst"

# 2.1.283 (Claude Code)
# /$bunfs/root/prompt-audit-8fe29508.md.zst

خروجی نشان می‌دهد فایل zstd فشرده و با هش نام‌گذاری شده، پس نام ثابتی ندارد. راه درست، خارج کردن فایل است.

# -*- coding: utf-8 -*-
import re, zstandard as zstd

BIN = "/root/.hermes/tools/node-26.7.0-linux-x64/lib/node_modules/@anthropic-ai/claude-code/node_modules/@anthropic-ai/claude-code-linux-x64/claude"
data = open(BIN, "rb").read()
MAGIC = b"\x28\xb5\x2f\xfd"          # سرآیند zstd
dctx = zstd.ZstdDecompressor()

# فایل را با محتوای «prompt-audit» پیدا کن
for m in re.finditer(re.escape(MAGIC), data):
    try:
        out = dctx.decompress(data[m.start():m.start() + 300000])
    except Exception:
        continue
    if out[:2000].startswith(b"# Prompt Audit"):
        open("prompt-audit.md", "wb").write(out)
        print("extracted", len(out), "bytes")
        break
# extracted 47257 bytes

چهل‌وهفت هزار و دویست‌وسیله بایت متن راهنما از این مسیر بیرون آمد. روش به شماره‌ی نسخه وابسته نیست: دنبال محتوا می‌گردد، نه نام فایل.

ساختار راهنما اندازه‌گیری‌پذیر است و این اعداد را روی فایل استخراج‌شده شمرده‌ام: هشت گام، چهار گروه الگو، شش الگو در گروه یک، یازده بند keep list و شش سطر Signals.

بند نخست keep list می‌گوید زمینه هرگز اضافی نیست: مخاطب، محصول، محیط و دلیل پشت محدودیت‌ها. بند سوم استثنای مهمی است: عملیات شکننده باید دستور دقیق بمانند.

سیگنال‌های راهنما را روی یک پروژه اجرا کن

راهنما در گام ۴ می‌گوید سطرهای Signals قابل grep هستند و باید روی فایل‌ها اجرا شوند، نه با چشم. این اسکریپت همان الگوها را می‌زند و مسیرهای نام‌برده را در برابر مخزن می‌سنجد.

F=./CLAUDE.md
echo "== 1a signals: MUST|NEVER|ALWAYS|CRITICAL|IMPORTANT =="
grep -nE 'MUST|NEVER|ALWAYS|CRITICAL|IMPORTANT' "$F" || echo "(no match)"
echo "== 1b signals: think step by step|take a deep breath =="
grep -nEi 'think step by step|take a deep breath' "$F" || echo "(no match)"
echo "== 2b: آیا مسیرهای نام‌برده هنوز وجود دارند؟ =="
grep -oE '[A-Za-z0-9_./-]+\.(sh|md|py|json)' "$F" | sort -u | while read -r f; do
  if [ -e "$f" ]; then echo "exists   $f"; else echo "MISSING  $f"; fi
done

خروجی واقعی روی یک فایل دستورالعمل کهنه، دو خط فشاری و یک مسیر مرده را نشان می‌دهد. نکته مهم این است که هر سه بخش باید خروجی بدهند؛ سکوت grep لزوما تمیزی نیست.

$ bash audit.sh .
== 1a signals: MUST|NEVER|ALWAYS|CRITICAL|IMPORTANT ==
5:IMPORTANT: Always think step by step before answering.
9:You MUST carefully consider all possibilities before responding.
== 1b signals: think step by step|take a deep breath ==
5:IMPORTANT: Always think step by step before answering.
== 1d signals: ^You are (a|an) (helpful|expert) ==
3:You are an expert software engineer with 20 years of experience.
== 2b: آیا مسیرهای نام‌برده هنوز وجود دارند؟ ==
MISSING  CONTRIBUTING.md
MISSING  docs/style-guide.md
MISSING  scripts/old-deploy.sh

سه مسیر گمشده یافته‌ایم. راهنما این را یافته‌ی اطمینان‌بالا می‌نامد، چون خود مخزن آن را رد می‌کند؛ غیاب چیزی به‌تنهایی تناقض نیست، اما مسیری که نام برده شده و نیست، هست.

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

$ bash audit.sh .
== 1a signals: MUST|NEVER|ALWAYS|CRITICAL|IMPORTANT ==
(no match)
== 1d signals: ^You are (a|an) (helpful|expert) ==
(no match)
== 2b: آیا مسیرهای نام‌برده هنوز وجود دارند؟ ==
exists   services/auth.py
exists   services/db.py

تفاوت این دو اجرا همان چیزی است که یک دروازه‌ی خوب را از اسکریپت تزئینی جدا می‌کند. با فقط نسخه‌ی اول، نمی‌دانستید ابزار شما توان تشخیص دارد یا همیشه ساکت است.

منشأ هر خط را با git blame جدا کن

گام ۲ راهنما از هر سطر تاکیدی یک سوال می‌کند: این سطر جلوی کدام خطا، روی کدام مدل را می‌گرفت و آیا آن خطا هنوز روی مدل هدف تکرار می‌شود؟ بدون تاریخچه، حدس است.

سناریویی دو مرحله‌ای ساختم تا blame واقعا کار کند: کامیت اول از چند ماه قبل با boilerplate، کامیت دوم بعد از مهاجرت با زمینه‌ی واقعی پروژه.

$ git --no-pager blame --date=short -s CLAUDE.md
^c02eed3  3) You are an expert software engineer with 20 years of experience.
^c02eed3  5) IMPORTANT: Always think step by step before answering.
^c02eed3  7) Please note that you should be very careful and thorough.
^c02eed3  9) You MUST carefully consider all possibilities before responding.
^c02eed3 11) Use the legacy helper at scripts/old-deploy.sh for every deploy.
MISSING  scripts/old-deploy.sh  (مسیر نام‌برده وجود ندارد)
MISSING  CONTRIBUTING.md
MISSING  docs/style-guide.md

حالا تفکیک روشن است: سطرهای برگشتی به کامیت اول boilerplate هستند و سطر اسکریپت حذف‌شده یک یافته‌ی قطعی است. اما دو بند از کامیت دوم باید بمانند.

دلیلشان روشن است: مهاجرت را ویرایش نکنید یک عملیات شکننده است و بند ۳ keep list همین را نگه می‌دارد. سقف بازپرداخت هم محدودیت کسب‌وکاری با دلیل است، نه سبک خروجی، و بند ۱ حفظش می‌کند.

$ git diff --stat
 CLAUDE.md | 17 ++++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

$ git --no-pager diff
-You are an expert software engineer with 20 years of experience.
-IMPORTANT: Always think step by step before answering.
-Please note that you should be very careful and thorough.
-You MUST carefully consider all possibilities before responding.
-Use the legacy helper at scripts/old-deploy.sh for every deploy.
-Follow the coding guidelines described in CONTRIBUTING.md and the rules in docs/style-guide.md.
+Deploy with `make deploy-staging`; `make migrate` runs the migrations first.
+
+Never edit a migration once it is under `migrations/` — add a new one instead.

خود دستور را چطور اجرا کنیم

دستور یک اسلش‌کامند تعاملی است و نام مستعار /checkup prompt-audit هم دارد. برای اجرای غیرتعاملی، پرچم -p:

$ claude --version
2.1.283 (Claude Code)

# درون یک نشست تعاملی:
/doctor prompt-audit

# معادل غیرتعاملی (نیازمند احراز هویت)
claude -p "/doctor prompt-audit"

در محیطی که این پست نوشته شد، نسخه‌ی نصب‌شده ۲.1.283 است: همان نسخه‌ای که این دستور را معرفی کرد. نسخه‌ی پایین‌تر آن را ندارد.

راهنما دو خروجی می‌سازد و در گام ۵ و ۶ هر دو را الزامی می‌داند: گزارش ممیزی و diff پیشنهادی. هر یافته در گزارش شش فیلد دارد، از مکان و شاهد تا سطح اطمینان و اقدام.

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

گام ۷ نکته‌ای دارد که با پیکربندی هم فرقی نمی‌کند: راستی‌آزمایی باید روی رفتار باشد، نه گزارش خودمدل.

مرزهایی که راهنما اعلام می‌کند

چهار نکته را باید کنار دستور نگه داشت، چون خود راهنما صریح بیانشان می‌کند.

نخست، ممیزی که چیزی پیدا نکند باید هیچ چیز را تغییر ندهد؛ راهنما این را نتیجه‌ی معتبر می‌داند و diff خالی را بر diff ساختگی ترجیح می‌دهد.

دوم، تطبیق الگو کافی نیست. یافته‌ای که نتوانید به یک سطر جدول‌ها و یک دلیل مستند وصل کنید، یافته نیست.

سوم، معیار سنجش با هر انتشار مدل جابه‌جا می‌شود: سطری که روی یک نسل بارگذار بود روی نسل بعدی اضافه است.

در آخر، ملاحظه‌ای که در توضیح رسمی نمی‌آید: آداپت فایل‌ها به کلود یعنی دور شدن تدریجی از بقیه. راهنما خودش می‌پذیرد و می‌گوید تصمیم با شماست.

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

منابع

1. تاریخچه‌ی رسمی Claude Code — سطر مربوط به /doctor prompt-audit
2. انتشار v2.1.283 در ۲۵ سپتامبر — سند تصویب‌شده‌ی همه‌ی سطرهای این پست
3. مستند حافظه و فایل‌های دستورالعمل CLAUDE.md
4. مستند settings — دامنه‌ی فایل‌های پیکربندی
5. مستند اسکیل‌ها و ساختار SKILL.md
6. مستند زیر‌ایجنت‌ها — تعریف‌هایی که ممیزی می‌خواند
7. مستند پیکربندی مدل
8. مستند هزینه‌ها و شمارش توکن
9. مستند افزونه‌ها
10. مرجع خط فرمان — پرچم‌های -p و --version
11. خروجی ساختاریافته — جایگزین اسکلت‌های پیام‌ساز