Claude Code उपयोगी prompt brief: शुरुआत में कौन सी जानकारी दें

यह workflow क्यों ज़रूरी है

नए उपयोगकर्ता अक्सर इसलिए असफल नहीं होते कि prompt सुंदर नहीं है। असली कमी goal, protected files, revenue links और done criteria की होती है। छोटा task brief Claude Code की guessing घटाता है और पहला patch छोटा रखता है।

इसे इन लेखों के साथ पढ़ें: first task runbook, prompt library maintenance, CLAUDE.md template.

काम में इस्तेमाल करने की प्रक्रिया

goal एक sentence में लिखें। फिर target file, reader और business reason जोड़ें। उसके बाद क्या नहीं छूना है, कौन से Gumroad links बचाने हैं, और proof command क्या है, यह लिखें।

कॉपी-पेस्ट करने योग्य छोटा सेट

# Claude Code task brief

## Goal
Change one clear thing:

## Context
- user or reader:
- current file/page:
- business reason:

## Constraints
- do not touch:
- keep these links working:
- proof command:

## Definition of done
- small diff
- public URL checked
- CTA path still works
- handoff note written

Use this brief before editing.
Ask up to three clarifying questions only if the goal, protected files, or proof command is missing.
Then propose the smallest safe patch and the verification receipt.

rg --files | Select-Object -First 80
git diff --name-only
cd site
npm.cmd run build

अच्छे request brief का उदाहरण

अच्छा brief Claude Code को सिर्फ बदलाव नहीं बताता, बल्कि सीमा भी बताता है। Article edit के लिए आप ऐसे लिख सकते हैं:

site/src/content/blog-hi/claude-code-productive-prompt-brief.mdx में सिर्फ introduction और CTA के आसपास का हिस्सा सुधारें। Reader वह solo developer है जो Claude Code पहली बार गंभीरता से इस्तेमाल कर रहा है। मकसद यह है कि वह free PDF से शुरू करे और फिर समझे कि Prompt Templates, Setup Guide या consultation कब उपयोगी हैं। frontmatter, slug, मौजूदा Gumroad links, internal links और code blocks न बदलें। अंत में node scripts/check-updated-article-quality.mjs चलाएँ और बताएं कि इस slug की errors खत्म हुईं या नहीं।

यह अच्छा है क्योंकि scope छोटा है। “सिर्फ introduction और CTA” लिखने से पूरा article rewrite नहीं होता। Reader और business goal लिखने से Claude Code वाक्य सजाने के बजाय सही next step पर ध्यान देता है।

Protected चीजें भी साफ हैं। frontmatter page metadata संभालता है। Gumroad links revenue path हैं। Internal links readers को दूसरे articles तक ले जाते हैं। Code blocks copy-paste material हैं। इन्हें पहले लिख देने से review में छिपी हुई टूट-फूट जल्दी पकड़ी जाती है।

खराब request का उदाहरण

खराब request अक्सर ऐसी होती है:

इस article को SEO और conversion के लिए बेहतर कर दो।

यह सुनने में ठीक है, पर इसमें सीमा नहीं है। SEO का मतलब title बदलना, keywords जोड़ना, internal links बढ़ाना या body लंबी करना हो सकता है। Conversion का मतलब CTA बदलना, Gumroad links बढ़ाना या लेखक का अनुभव जोड़ना हो सकता है। Claude Code अंदाजा लगाकर बड़ा diff बना सकता है।

एक और कमजोर request है:

इसे beginners के लिए आसान बना दो और हो जाए तो बता देना।

Intention सही है, लेकिन done criteria नहीं है। बेहतर request में अच्छे brief का उदाहरण, खराब request का उदाहरण, beginner template और free PDF, Gumroad material, consultation की natural path मांगें। साथ में कौन सा quality command चलाना है, यह भी लिखें।

शुरुआती लोगों के लिए पहला template

Perfect prompt लिखने की जरूरत नहीं है। पहले ये पाँच बातें भरें:

Change: एक ही मुख्य बदलाव
Target: file, URL, command या screen
Reader: किसके लिए यह बेहतर होना चाहिए
Protect: कौन से files, links, behavior या rules नहीं बदलने
Proof: कौन सा command या result check करना है

अगर product page का CTA सुधारना है, तो change को CTA text और placement तक रखें। Target product page की MDX file है। Reader वह व्यक्ति है जिसने free PDF पढ़ा है लेकिन templates या setup help को लेकर unsure है। Protect में free PDF, Prompt Templates और Setup Guide links आते हैं। Proof में build, public URL और links का check आता है।

सामग्री और consultation की natural path

Brief reader को अगला सही step चुनने में भी मदद करता है। Basic commands में डर है तो free PDF काफी है। Similar requests बार-बार लिखनी पड़ती हैं तो Prompt Templates काम आते हैं। Team rollout, permissions, review rules या revenue links जुड़ते हैं तो consultation ज्यादा सुरक्षित है।

Article में क्रम यह रखें: पहले आज काम आने वाला free resource, फिर repeat work के लिए reusable templates, और अंत में high-risk setup के लिए consultation. इससे reader को sale push नहीं लगता, बल्कि अपने stage के हिसाब से रास्ता दिखता है।

तीन वास्तविक उपयोग

सिर्फ article CTA बदलना हो तो full rewrite रोकें और public URL check को done बनाएँ।
CLAUDE.md बदलना हो तो forbidden commands और build command पहले दें।
product page बदलना हो तो free PDF, Prompt Templates और Setup Guide links protect करें।

गलतियाँ और बचाव

सिर्फ ‘इसे बेहतर करो’ कहना। diff बहुत बड़ा हो जाता है।
protected links न लिखना। revenue path गायब हो सकता है।
done criteria न देना। Claude Code research पर रुक सकता है।

मुफ़्त PDF, Gumroad और consultation का रास्ता

brief लिखने से पहले free cheatsheet से commands देखें। बार-बार उपयोग होने वाले अनुरोध चाहिए तो Prompt Templates लें। project assumptions, CLAUDE.md और hooks स्थिर करने हों तो Setup Guide सही है।

पहले मुफ़्त PDF से commands और सुरक्षित आदतें पक्की करें। जब workflow दोहराने लगे तो Gumroad guide लें, और जब team rollout या revenue path गलत होने का जोखिम हो तो consultation लें।

इस लेख के लिए मैंने क्या जाँचा

मैंने Markdown brief, Claude Code instruction और proof command अलग किए। लक्ष्य है एक बदलाव, एक proof और एक revenue path check।