مهندسان میتوانند مستندات API را مستقیم از کد endpoint تولید کنند
Why this prompt matters
Engineering teams often ship endpoints faster than they document them, which leaves frontend developers, partners, QA, and new teammates relying on source code to understand basic usage. A strong prompt closes that gap by turning controllers, routes, schemas, and middleware into a consistent documentation draft. That speeds up integration, reduces support questions, and makes undocumented edge cases like auth rules or validation failures visible before they cause avoidable bugs.
What we use it for
Turning endpoint implementations into reusable API documentation with parameters, authentication requirements, validation rules, error cases, and copy-pasteable curl examples.
Prompt
Act as a senior API technical writer and backend engineer. I will paste endpoint code, controller logic, route definitions, request and response schemas, validators, auth middleware, error handling, comments, and sometimes tests. Your job is to convert that implementation detail into clean, developer-facing API documentation that another engineer could use without reading the source code. Return your answer in exactly these sections: 1. Endpoint Summary 2. HTTP Method and Path 3. What This Endpoint Does 4. Authentication Requirements 5. Request Headers 6. Path Parameters 7. Query Parameters 8. Request Body Schema 9. Validation Rules and Constraints 10. Success Response 11. Error Responses 12. Example cURL Request 13. Example Success Response JSON 14. Implementation Notes and Assumptions Rules: - Base the documentation only on the code and context provided. Do not invent fields, permissions, business rules, or status codes that are not supported by the source. - If something is implied but not fully certain, place it under Implementation Notes and Assumptions. - Normalize naming so the final documentation is easy to read, but preserve exact parameter names, enum values, header names, and route paths. - If auth middleware is present, explain the auth mechanism plainly, including required header format when visible in the code. - If validation logic exists, convert it into practical parameter constraints such as required, optional, type, format, min or max, allowed values, and defaults. - If the code shows multiple failure paths, list each distinct error with status code, trigger, and response shape when available. - If the endpoint interacts with pagination, filtering, sorting, idempotency, rate limits, or tenant scoping, include those details when explicitly present. - Write for engineers who need usable docs fast, not a marketing description. - Keep the output concise but implementation-ready. Source code and related context: [PASTE CODE HERE]
Result
مستندات API خیلی وقتها از کدی که واقعاً منتشر میشود عقب میماند. تیم بکاند یک route جدید اضافه میکند، اعتبارسنجی را تغییر میدهد، شرط احراز هویت را عوض میکند یا مسیر خطای تازهای اضافه میشود، اما مستندات ناقص یا قدیمی میماند. نتیجه این است که اعضای تیم برای پاسخ دادن به سادهترین سؤالهای یکپارچهسازی باید controller، schema و middleware را بخوانند.
این پرامپت برای حل همین مشکل طراحی شده است و جزئیات پیادهسازی را سریع به مستندات قابل استفاده تبدیل میکند. بهجای درخواست یک خلاصه مبهم، مدل را مجبور میکند در قالب مشخصی پاسخ دهد: خلاصه endpoint، متد و مسیر، احراز هویت، هدرها، پارامترها، schema درخواست، قوانین اعتبارسنجی، پاسخ موفق، خطاها و نمونه cURL. این ساختار مهم است چون دقیقاً با سؤالهایی همراستا است که فرانتاند، QA، مهندس شریک یا نویسنده فنی معمولاً میپرسند.
این پرامپت همچنین خطر هالوسینیشن را کمتر میکند چون به مدل میگوید فقط بر اساس کد ارائهشده بنویسد و موارد نامطمئن را به بخش فرضیات منتقل کند. در کار API این موضوع بسیار مهم است، چون اختراع یک فیلد یا status code خروجی را عملاً بیارزش میکند. با جدا کردن جزئیات تأییدشده از نکات استنباطی، نتیجه هم کاربردیتر میشود و هم امنتر.
دلیل دیگر موفقیت این پرامپت این است که الگوهای سطح پایین کد را به زبان مناسب توسعهدهنده تبدیل میکند. middleware به توضیح روشن احراز هویت تبدیل میشود. منطق validation به محدودیتهای خوانا برای پارامترها تبدیل میشود. شاخههای خطا به failure caseهای مستند با status code و علت احتمالی تبدیل میشوند. تستها و route definition هم شواهد کمکی برای مثالها و رفتار endpoint میشوند.
اگر درست استفاده شود، این پرامپت میتواند ساخت مستندات داخلی را سریعتر کند، handoff بین بکاند و فرانتاند را بهبود دهد و یک پیشنویس تمیز برای مستندات API خارجی بسازد، بدون اینکه تیم از صفحه خالی شروع کند.