GitHub का Spec Kit - उच्च-गुणवत्ता वाला सॉफ़्टवेयर तेज़ी से विकसित करना

• Spec-Driven Development: पारंपरिक development में सहायक साधन मानी जाने वाली spec को executable spec तक उन्नत करके, spec से सीधे काम करने वाला implementation बनाने का दृष्टिकोण
  • code-केंद्रित प्रथाओं को बदलकर पहले क्या और क्यों को परिभाषित करना, और बाद में कैसे को ठोस बनाना — इस intent-driven development पर ज़ोर
  • मुख्य विचार यह है कि spec के माध्यम से सुसंगत outputs बनाए जाएँ, और दोहराए जाने वाले काम को automate करके developers को product problems पर ध्यान केंद्रित करने में मदद दी जाए
• Spec Kit ऐसे spec को executable artifacts में बदलकर implementation को automate करने में मदद करने वाले tools का संग्रह है
• install करने के बाद /specify से क्या/क्यों लिखा जाता है, /plan से stack/architecture घोषित की जाती है, और /tasks से work units बनाए जाते हैं
• लक्ष्य यह है कि organization अलग पहचान न रखने वाले common code लिखने से बाहर निकलकर product scenarios पर ध्यान दे सके; यह spec-driven तरीके से quality और speed दोनों बढ़ाने के लिए एक प्रयोगात्मक framework है

मुख्य दर्शन: Core philosophy

• intent-driven development के तहत क्या को प्राथमिकता देना और कैसे को बाद में विस्तार देना — एक spec-first सोच
• guardrails और organizational principles से युक्त समृद्ध spec लिखना, और one-off code generation के बजाय multi-stage refinement प्रक्रिया से गुजरना
• उन्नत AI models की व्याख्यात्मक क्षमता पर सक्रिय रूप से निर्भर रहते हुए spec को executable परिणामों में बदलने के उपयोग पर ज़ोर

Spec Kit के साथ spec-driven process

• Spec Kit spec को engineering process के केंद्र में रखता है, जिससे implementation, checklist, और task breakdown संचालित होते हैं; developer मुख्य रूप से निर्देशन की भूमिका निभाता है
  • coding agent अधिकांश लिखने का काम संभालता है
• process 4 चरणों से बना है, प्रत्येक चरण में स्पष्ट checkpoints होते हैं, और जब तक वर्तमान काम पूरी तरह validate न हो जाए, अगले चरण में नहीं बढ़ा जाता
• Specify चरण: उच्च-स्तरीय विवरण देने पर coding agent विस्तृत spec बनाता है, जो technical stack के बजाय user journey, experience, और success metrics पर केंद्रित होता है
  • इसमें यह map किया जाता है कि user कौन है, कौन-सी समस्या हल की जा रही है, interaction कैसे होगा, और कौन-से परिणाम महत्वपूर्ण हैं
  • यह user learning के साथ विकसित होने वाला एक living artifact होता है
• Plan चरण: इच्छित stack, architecture, और constraints देने पर coding agent एक व्यापक technical plan बनाता है
  • इसमें company-standard technologies, legacy system integration, compliance, performance goals आदि शामिल हो सकते हैं
  • तुलना के लिए कई plan variants माँगे जा सकते हैं, और internal documents देने पर architecture patterns को सीधे शामिल किया जा सकता है
• Tasks चरण: spec और plan के आधार पर coding agent काम को छोटे, review किए जा सकने वाले chunks में तोड़ता है
  • हर task को स्वतंत्र रूप से implement और test किया जा सकता है, और इसे इस तरह design किया जाता है कि AI task को validate और track कर सके
  • उदाहरण के लिए, "authentication बनाना" की जगह "email format validation करने वाला user registration endpoint बनाना" जैसा अधिक ठोस task
• Implement चरण: coding agent tasks को एक-एक करके या parallel में संभालता है, और developer focused changes की review करता है
  • spec बताता है कि क्या बनाना है, plan बताता है कि कैसे बनाना है, और tasks बताते हैं कि किस काम पर काम करना है
• हर चरण में developer reflection और refinement करता है, और यह validation role निभाता है कि spec इरादे को सही पकड़ रहा है या नहीं, plan वास्तविक constraints को ध्यान में रखता है या नहीं, और कहीं कुछ छूटा हुआ या edge cases तो नहीं हैं

Agentic workflow में Spec Kit का उपयोग कैसे करें

• Spec Kit GitHub Copilot, Claude Code, Gemini CLI जैसे coding agents के साथ काम करता है, और साधारण commands की एक श्रृंखला के जरिए agent को निर्देश देकर artifacts तैयार करता है
  • इससे अस्पष्ट prompts को स्पष्ट intent में बदलकर भरोसेमंद execution संभव होता है
• project initialize करने के बाद /specify command से high-level prompt देने पर coding agent पूरा spec बनाता है, जो project के "क्या" और "क्यों" पर केंद्रित होता है
• /plan command से high-level technical direction देने पर coding agent architecture और constraints का सम्मान करने वाला विस्तृत plan बनाता है
• /tasks command से spec और plan को executable task list में तोड़ा जाता है, जिसके आधार पर coding agent project requirements implement करता है

विकास चरण: Development phases

• 0-to-1 (greenfield) चरण: high-level requirements के आधार पर spec generation → planning → production-grade app बनाने के flow को support करता है
• creative exploration चरण: विभिन्न stack/architecture और UX patterns को parallel implementation के साथ आज़माने की प्रक्रिया पर ज़ोर
• incremental improvement (brownfield) चरण: feature addition, legacy modernization, और process adaptation को दोहराने वाला evolutionary development

3 परिदृश्य जहाँ यह दृष्टिकोण अच्छी तरह काम करता है

• greenfield (zero-to-one): नया project शुरू करते समय सीधे coding शुरू करने के बजाय पहले spec और plan बनाकर यह सुनिश्चित करना कि AI वही बनाए जो वास्तव में इरादा है; सामान्य pattern-आधारित generic solutions की जगह tailored results मिलते हैं
• मौजूदा सिस्टम में feature work (N-to-N+1): जटिल codebase में feature जोड़ते समय spec के ज़रिए नए feature की मौजूदा system interactions को स्पष्ट करना, और plan के माध्यम से architectural constraints को encode करना, ताकि native जैसा महसूस होने वाला code तैयार हो
  • इससे निरंतर development तेज़ और सुरक्षित होता है, हालांकि इसके लिए उन्नत context engineering techniques की आवश्यकता पड़ सकती है
• legacy modernization: legacy system को फिर से बनाते समय जब मूल intent खो गया हो, तब Spec Kit process आवश्यक business logic को आधुनिक spec में कैप्चर करके नई architecture की योजना बनाता है, ताकि AI technical debt के बिना पुनर्निर्माण कर सके

Prerequisites

• Linux/macOS या Windows पर WSL2 आवश्यक
• AI agent के रूप में Claude Code, GitHub Copilot, Gemini CLI, Cursor में से कोई एक चुनें

[edunga1]

मुझे Copilot Workspace की याद आ रही है।

[cocofather]

लगता है कि यह natural language-आधारित AI programming की नींव बनेगा।

[tested]

GitHub के Spec Kit का फ़ायदा यह है कि इसे GitHub Copilot में भी इस्तेमाल किया जा सकता है.
चूंकि यह GitHub ने बनाया है, इसलिए यह तो स्वाभाविक ही है? लेकिन कई दूसरे टूल्स Claude-आधारित थे.

[skageektp]

मुझे Kiro IDE याद आ रहा है

[kandk]

दिलचस्प है। बात समझ में भी आती है

[xguru]

लेख के बीच में SDD के विस्तृत परिचय का लिंक अच्छा है। नीचे उसका AI से किया गया सारांश है।

स्पेसिफिकेशन-ड्रिवन डेवलपमेंट (Specification-Driven Development, SDD)

The Power Inversion

• उस प्रवाह को उलट देता है जिसमें code केंद्र में होता था और PRD·design documents सहायक भूमिका में होते थे; यहाँ specification मूल स्रोत है और code एक अभिव्यक्ति है, जिसे किसी खास language·framework में implement किया जाता है
  • यह निदान पेश करता है कि specification और implementation के बीच का स्थायी अंतर केवल documents बढ़ाकर या process कड़ा करके दूर करना कठिन था
  • अगर executable specification और implementation plan code generate करें, तो यह अंतर गायब हो जाता है और केवल transformation बचता है
• AI जटिल specifications की व्याख्या और implementation plan बनाने में सक्षम बनाता है, लेकिन बिना संरचना के generation अव्यवस्था पैदा करता है; इसलिए SDD सटीक structure और guardrails के जरिए quality सुनिश्चित करता है
• maintenance specification के विकास का कार्य है, और development intent को natural language·design assets·core principles में व्यक्त किया जाता है; code की भूमिका last mile की होती है
• debugging में गलत code को सीधे ठीक करने से पहले specification·implementation plan को सुधारने को प्राथमिकता दी जाती है, और refactoring को clarity के पुनर्गठन के अर्थ में फिर से परिभाषित किया जाता है

The SDD Workflow in Practice

• ideas को AI के साथ conversational interaction के जरिए PRD में refine किया जाता है, और AI questions·edge cases·acceptance criteria को ठोस बनाता है
  • requirements और design को continuous activity में बदलकर team-स्तर पर branch-based specification work तथा review·versioning का समर्थन किया जाता है
• research agent library compatibility, performance, security, और organizational constraints (DB standards·authentication·deployment policies) की जांच करके उन्हें specification में अपने-आप शामिल करता है
• PRD से implementation plan बनाकर requirements और technical decisions को traceable तरीके से map किया जाता है, और AI contradictions·ambiguity·omissions की लगातार जांच करता है
• जब specification और plan पर्याप्त रूप से स्थिर हो जाते हैं, तब code generation शुरू किया जाता है; शुरुआत में exploratory generation से feasibility को validate किया जाता है
  • domain concepts को data models, user stories को API endpoints, और acceptance scenarios को tests में बदला जाता है
• operational चरण के metrics·incidents specification को update करते हैं ताकि अगली regeneration में वे परिलक्षित हों; performance bottlenecks को non-functional requirements और vulnerabilities को global constraints के रूप में उन्नत किया जाता है

Why SDD Matters Now

• AI capability threshold: अब natural language specifications से working code को भरोसेमंद ढंग से generate करना संभव है, और implementation translation के mechanical हिस्सों के automation से exploration और creativity amplification को समर्थन मिलता है
• complexity explosion: बहुत-सी services·frameworks·dependencies के कारण intent-implementation alignment बनाए रखना कठिन हो गया है, इसलिए SDD की specification-driven alignment की ज़रूरत है
• accelerating change: बार-बार pivot की स्थितियों में SDD बदलावों को documents-design-code में manual propagation की बजाय systematic regeneration से संभालता है
  • उदाहरण के तौर पर, यह what-if simulation और parallel implementation को संभव बनाकर decision-making agility देता है

Core Principles

• specification = common language: specification first-class output है, code किसी खास stack की expression है, और maintenance specification evolution की क्रिया है
• executable specification: सटीक·पूर्ण·अस्पष्टतारहित स्तर की specification से working system generate किया जाता है
• continuous refinement: one-time gate के बजाय लगातार consistency validation किया जाता है
• research-based context: performance·security·organizational constraints को निरंतर एकत्र करके specification में डाला जाता है
• bidirectional feedback: operational reality specification update input बनती है
• branching for exploration: एक ही specification से performance·maintainability·UX·cost जैसे optimization goals के अनुसार multiple implementations generate करने का समर्थन

Implementation Approaches

• आज के व्यवहारिक प्रयोग में मौजूदा tools के संयोजन और discipline बनाए रखना मुख्य है, और इसे निम्न तत्वों से लागू किया जा सकता है
  • specification की iterative refinement के लिए AI assistant
  • technical context इकट्ठा करने के लिए research agent
  • specification→implementation transformation के लिए code generation tools
  • specification-first workflow के अनुरूप version control
  • specification documents की AI consistency analysis आधारित checking
• साझा सिद्धांत यह है कि specification को single source of truth रखा जाए और code को specification द्वारा मांगा गया output माना जाए

Streamlining SDD with Commands

• /specify: feature description को structured specification में बदलता है और automatic numbering, branch creation, तथा template-based directory setup को automate करता है
• /plan: specification analysis → constitution compliance review → technical translation → data model·API contracts·test scenarios documentation → quickstart validation तैयार करता है
• /tasks: plan.md और संबंधित design को पढ़कर actionable task list बनाता है, और parallelizable tasks की पहचान तथा सुरक्षित parallel grouping देता है
• उदाहरण: chat feature
  • पारंपरिक approach में लगभग 12 घंटे के document work को specification·plan·tasks automation से लगभग 15 मिनट की setup तक घटाने वाला flow दिखाया गया है
  • outputs में specification, implementation plan और rationale, API contracts·data model, quickstart scenario, और tasks.md को branch में version control किया जाता है

The Power of Structured Automation

• missing items की रोकथाम: templates non-functional requirements·error handling तक को cover करते हैं
• decision traceability: हर technical choice specific requirement से जुड़ी होती है
• living documents: specification code generate करती है, इसलिए synchronization बनाए रखना आसान होता है
• rapid iteration: requirement बदलने पर plan regeneration से मिनटों या घंटों के स्तर पर प्रतिक्रिया संभव होती है

Template-Driven Quality

• implementation details के जल्दबाज़ी में घुस आने की रोकथाम: WHAT/WHY पर फोकस और HOW को बाहर रखने का नियम abstraction level बनाए रखने में मदद करता है
• uncertainty markers को अनिवार्य करना: [NEEDS CLARIFICATION] marker के जरिए guesswork पर रोक और स्पष्ट सवाल पूछने को बढ़ावा दिया जाता है
• checklist-based self-review: completeness·clarity·measurable acceptance criteria की जांच से quality gate लागू होता है
• constitution gate: simplicity gate (≤3 projects), anti-abstraction gate (frameworks का direct use), integration-first gate (contracts·contract tests पहले) जैसे pre-phase (-1) checks लागू किए जाते हैं
• layered detail management: अत्यधिक code और details को implementation-details/ में अलग रखकर readability बनाए रखी जाती है
• test prioritization: contract→integration→E2E→unit क्रम में file creation·test-first नियमों से verifiability सुनिश्चित की जाती है
• assumptions और speculative features पर नियंत्रण: speculative features पर रोक और phase-wise prerequisites की स्पष्टता से scope management मजबूत होता है

The Constitutional Foundation

• memory/constitution.md के immutable principles के आधार पर सभी implementations को consistent·simple·high-quality बनाए रखने वाली development constitution अपनाई जाती है
  • Article I: Library-First — हर feature independent library के रूप में शुरू होता है ताकि modularity सुनिश्चित हो
  • Article II: CLI Mandate — हर library text I/O·JSON को support करने वाला CLI interface expose करती है, जिससे observability और testing ease सुनिश्चित होती है
  • Article III: Test-First — test approval और failure (red) की पुष्टि से पहले implementation नहीं, तथा behavior definition first सिद्धांत लागू होता है
  • Articles VII & VIII: simplicity·anti-abstraction — project count को न्यूनतम रखना और frameworks पर direct भरोसा करना, ताकि over-engineering रोका जा सके
  • Article IX: integration-first testing — real-environment-जैसी testing को प्राथमिकता दी जाती है और contract testing को implementation से पहले अनिवार्य किया जाता है
• templates के Phase -1 gate के जरिए constitution compliance को checklist में बदला जाता है, और exceptions के लिए Complexity Tracking में स्पष्ट rationale दर्ज किया जाता है
• amendment procedure के जरिए principles के लागू करने के तरीके विकसित हो सकते हैं, लेकिन core philosophy बनी रहती है

The Transformation

• लक्ष्य developers को replace करना नहीं, बल्कि mechanical translation के automation से human capability amplification और intent-implementation alignment बनाए रखना है
• SDD specification से code को generate कराता है, जिससे specification·research·code एक tight feedback loop में साथ-साथ विकसित होने वाले continuous transformation का अभ्यास करते हैं

[amoplan]

आपने इसे किस AI से संक्षेपित किया?

[xguru]

मैंने यह GPT-5 से किया, और सारांश के लिए अपने हिसाब से तैयार किया हुआ काफ़ी लंबा प्रॉम्प्ट इस्तेमाल करता हूँ.

[heycalmdown]

मैं इस कॉन्सेप्ट से काफ़ी सहमत था, इसलिए वीकेंड पर एक नए प्रोजेक्ट में इसका थोड़ा परीक्षण करके देखा, लेकिन यह उम्मीद के मुताबिक़ उतना अच्छा काम नहीं कर पाया। लगता है कि अभी इसमें काफ़ी सुधार की ज़रूरत है। फ़िलहाल इसकी मोटे तौर पर काम करने की प्रक्रिया, जैसा कि कई बार बताया जा चुका है, इस प्रकार है:
संविधान लिखना → स्पेक लिखना → टास्क लिखना → इम्प्लीमेंटेशन

समस्या यह है कि

• constitution.md फ़ाइल "कैसे डेवलप करना है" के बारे में मुख्य गाइड है, लेकिन इसमें "यह ऐप आखिरकार क्या बनेगा" शामिल नहीं है
• spec.md किसी एक फीचर को समझाने वाला दस्तावेज़ है
• "यह ऐप क्या है" इस बारे में कोई मास्टर दस्तावेज़ नहीं है
• GitHub पर चल रही चर्चाएँ पढ़कर लगा कि specs की chain ही अंततः source of truth बन जाएगी — ऐसा लगता है। थोड़ा अजीब लगा, लेकिन मोटे तौर पर समझा जा सकता है।
• /specify और /tasaks कमांड के ज़रिए बहुत सारे दस्तावेज़ output के रूप में बनते हैं (जो मैं चाहता था), लेकिन शायद इसी वजह से context बहुत जल्दी ख़र्च होता है (मैं Claude Code इस्तेमाल कर रहा हूँ)
• एक बार इम्प्लीमेंटेशन शुरू हो जाए तो Spec Kit से थोड़ी दूरी बन जाती है, और फिर सामान्य तौर पर Claude Code के साथ बातचीत करते हुए इम्प्लीमेंटेशन पूरा होता है
• context पूरी तरह ख़त्म हो जाए और compaction हो जाए या नया session शुरू किया जाए, तो Spec Kit द्वारा बनाए गए दस्तावेज़ों का अस्तित्व ही भूल जाता है
• tasks.md में परिभाषित कामों को करते-करते पहले ठीक से बनाई गई चीज़ें भी overwrite हो जाती हैं, और बग ठीक करते समय नए फीचर भी बन जाते हैं, जिससे tasks.md से दूरी बढ़ती जाती है। मुझे समझ नहीं आता कि tasks.md को स्थायी रूप से सहेजकर रखने का क्या मतलब है।

फ़िलहाल मैंने जो निष्कर्ष निकाला है, वह इस प्रकार है:

• अगर शुरुआती सोच से अलग नतीजा आए तब भी पहले स्पेक को पूरा करना चाहिए, और फिर नया स्पेक बनाकर उसे धीरे-धीरे सुधारना चाहिए
• शुरुआती स्पेक का बड़ा होना लगभग तय है, इसलिए ऐप के फीचर्स को बिल्कुल समझाने के बजाय सिर्फ़ boilerplate बनाना बेहतर होगा
• PoC स्तर पर बनाते समय Spec Kit का इस्तेमाल न करना ही बेहतर होगा