CLAUDE SPEC-DRIVEN WORKFLOW
यह वही तीन-चरण वाली workflow है जो मैं हर Claude-assisted build पर चलाता हूँ। Brainstorm से spec से implementation तक, साथ ही वे gates जो failures को जल्दी पकड़ते हैं।
Spec-driven क्यों मायने रखता है
Claude के साथ code generation इतना तेज़ है कि bottleneck अब typing नहीं है। Bottleneck यह है कि आप exactly जानते हैं कि आप क्या चाहते हैं इससे पहले Claude इसे लिखे। Spec-driven workflow thinking को front-load करता है ताकि implementation phase execution बन जाए, न कि exploration।
जो teams Claude के साथ अच्छी तरह ship करती हैं वे वह हैं जिन्होंने AI tools के आने से पहले spec discipline बनाई थी। जो teams struggle करती हैं वे हैं जो spec को skip करने की कोशिश करती हैं Claude से पूछकर कि वह figure it out करे।
Stage 1: structured brainstorm
मैं Claude को problem describe करता हूँ तीन या चार sentences में। फिर मैं Claude से पूछता हूँ कि पाँच questions surface करो जिनके answers design को बदल दें। मैं उन्हें answer करता हूँ। फिर मैं Claude से पूछता हूँ कि resulting product spec को 200 words में summarise करो।
यह चरण 30 से 60 मिनट में पूरा होता है और एक लिखित spec तैयार करता है जिससे बाकी का सारा काम आगे बढ़ता है। ये पाँच सवाल आमतौर पर वही होते हैं जिन्हें मैं अगर सीधे कोड लिखने चला जाता तो छोड़ देता; इन्हें brainstorm चरण के माध्यम से सामने लाना ही इसका पूरा मूल्य है।
चरण 2: तकनीकी फैसले
spec के साथ, मैं Claude को उन architecture विकल्पों की पहचान करने के लिए कहता हूँ जिनका downstream सबसे ज़्यादा प्रभाव होता है। Database shape, API surface, rendering strategy, deployment model। हर एक के लिए Claude दो या तीन विकल्पें propose करता है और उनके trade-offs बताता है।
मैं चुनता हूँ। फैसले उसी दस्तावेज़ में चले जाते हैं ताकि build phase के पास सच्चाई का एक ही स्रोत हो। इस चरण में लिए गए फैसलों को ठीक करना implementation के दौरान खोजे गए फैसलों की तुलना में 10 गुना सस्ता होता है।
चरण 3: spec-संचालित कार्यान्वयन
Code generation आखिरी चरण है और सबसे तेज़ होता है क्योंकि spec पहले से ही पूरी होती है। Claude schema लिखता है, queries लिखता है, components लिखता है, routes लिखता है, tests लिखता है, मोटे तौर पर इसी क्रम में। मैं हर commit की समीक्षा करता हूँ।
ज़्यादातर reviews एक छोटे refactor या एक missing edge case को सामने लाते हैं; जब spec clear हो तो पूरे rewrites दुर्लभ होते हैं। रफ़्तार unaided engineering की तुलना में greenfield काम पर दो से पाँच गुना तेज़ होती है।
वह gates जो failures को पकड़ते हैं
Brainstorm और shipped code के बीच तीन review gates हैं:
Spec gate: कोई भी code लिखने से पहले, 200-शब्दों का spec शुरू से अंत तक पढ़ा जाता है। कोई भी अस्पष्ट बात clarify की जाती है। कोई भी aspirational चीज़ काट दी जाती है।
आर्किटेक्चर गेट: किसी भी डेटाबेस माइग्रेशन से पहले, आर्किटेक्चर निर्णयों की स्पेक के विरुद्ध समीक्षा की जाती है। जो कुछ भी स्पेक को पूरा नहीं करता उसे फिर से विचार किया जाता है।
कमिट गेट: Claude द्वारा लिखा गया हर कमिट मर्ज करने से पहले मानवीय समीक्षा से गुजरता है। यह समीक्षा कोड खुद लिखने से तेजी से होती है लेकिन इसे छोड़ा नहीं जा सकता। Claude अपनी खुद की पुल रिक्वेस्ट को मंजूरी नहीं देता।
जब स्पेक-ड्रिवन काम नहीं करता
खोजी या शोध-आकार का काम जहाँ लक्ष्य यह सीखना है कि क्या संभव है बजाय किसी ज्ञात चीज को बनाने के। इनके लिए, स्पेक स्टेज अस्पष्ट स्पेक तैयार करता है जो Claude को अनुपयोगी तरीके से सीमित करता है। ठोस आर्टिफैक्ट्स के साथ पुनरावृत्तिमूलक चैट सही पैटर्न है।
बग फिक्स जहाँ कारण अज्ञात है। स्पेक स्टेज यह मानता है कि आप गंतव्य जानते हैं; डिबगिंग यह पता लगाना है कि आप कहाँ हैं। डिबगिंग के लिए, सीधे व्यवस्थित डिबगिंग पैटर्न (पुनरुत्पादित करें, अलग करें, निदान करें, ठीक करें) पर जाएँ और स्पेक को छोड़ दें।
यूआई पॉलिश जहाँ हर पुनरावृत्ति छोटी है और दृश्य प्रतिक्रिया सिग्नल है। इनके लिए, Cursor में Claude के साथ हॉट रीलोड और साइड-बाय-साइड डिफ सही उपकरण है, लिखित स्पेक नहीं।