Get Shit Done - मेटा प्रॉम्प्ट और स्पेसिफिकेशन-आधारित डेवलपमेंट सिस्टम

 (github.com/gsd-build)
12 पॉइंट द्वारा GN⁺ 2026-03-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code आदि में स्पेसिफिकेशन-आधारित डेवलपमेंट (SDD) को ऑटोमेट करने वाला एक हल्का सिस्टम, जो जटिल workflow के बिना प्रोजेक्ट पूरा करने में मदद करता है
  • context engineering, XML-आधारित prompt structuring, और multi-agent orchestration के जरिए AI code quality degradation (context rot) को रोकता है
  • /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase जैसे commands से idea definition → planning → execution → verification की पूरी development lifecycle को ऑटोमेट करता है
  • हर task unit के लिए atomic Git commit और parallel execution (wave execution) के जरिए traceability और efficiency सुनिश्चित करता है
  • Amazon, Google, Shopify, Webflow के engineers द्वारा इस्तेमाल किया जाने वाला टूल, जो AI-आधारित development की reliability और productivity बढ़ाता है

अवलोकन

  • Get Shit Done(GSD) एक हल्का meta prompt और context management system है, जो Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity जैसे विभिन्न AI development environments में काम करता है
  • यह code लिखते समय AI में होने वाली context rot की समस्या को हल करता है और specification-आधारित तरीके से consistent results देता है
  • यह Mac, Windows, Linux सभी पर काम करता है, और npx get-shit-done-cc@latest command से install किया जा सकता है

बनाने की पृष्ठभूमि (Why I Built This)

  • बड़े संगठनों के लिए बने tools द्वारा अनावश्यक रूप से जटिल प्रक्रियाएँ थोपे जाने की समस्या को हल करने के लिए बनाया गया
  • GSD को complexity system के अंदर, workflow सरल रखने के सिद्धांत पर डिज़ाइन किया गया है
  • यह अंदरूनी तौर पर context engineering, XML prompt formatting, sub-agent orchestration, state management संभालता है
  • उपयोगकर्ता केवल सरल commands से प्रोजेक्ट पूरा कर सकते हैं

मुख्य फीचर्स और workflow (How It Works)

  • पूरा development process 6 चरणों में बना है

    1. प्रोजेक्ट initialization: idea, constraints, tech stack आदि पूछकर PROJECT.md, ROADMAP.md आदि बनाता है
    2. discuss चरण: implementation details को परिभाषित कर CONTEXT.md बनाता है
    3. plan चरण: parallel research और planning, साथ ही XML structure वाले task units बनाता है
    4. execution चरण: dependency-आधारित wave parallel execution, हर task पर commit और verification
    5. verification चरण: automated tests और user confirmation, failure होने पर auto-fix plan तैयार
    6. iteration और milestone completion: हर चरण को दोहराने के बाद release tagging

  • Quick Mode एक single task को तेज़ी से संभालता है, और --discuss, --research, --full flags से विस्तृत नियंत्रण संभव है

मुख्य तकनीक (Why It Works)

  • context engineering: पूरे प्रोजेक्ट के context को file level पर manage करता है (PROJECT.md, REQUIREMENTS.md, STATE.md आदि)
  • XML prompt formatting: हर task को स्पष्ट रूप से परिभाषित करता है और verification procedure शामिल करता है
  • multi-agent orchestration: research, planning, execution, verification चरणों के लिए विशेषज्ञ agents को parallel में चलाता है
  • atomic Git commit: हर task unit पर commit के जरिए traceability और आसान recovery सुनिश्चित करता है
  • modular design: चरण जोड़ना, बीच में डालना, या बदलना आसान है, जिससे flexible project management संभव है

command system (Commands)

  • मुख्य workflow: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • UI design support: /gsd:ui-phase, /gsd:ui-review
  • codebase analysis: /gsd:map-codebase
  • project management: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • utility: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note आदि

settings और configuration

  • .planning/config.json config file में mode, phase granularity, model profiles, workflow agents, parallelization, Git branching strategy आदि नियंत्रित किए जा सकते हैं
  • model profile में quality, balanced, budget, inherit में से चुना जा सकता है
  • workflow.research, workflow.plan_check, workflow.verifier जैसे toggles से quality और speed को adjust किया जा सकता है

सुरक्षा और समस्या निवारण (Security & Troubleshooting)

  • .env, secrets/, *.pem, *.key जैसी sensitive files को Claude Code की deny list में जोड़कर access रोका जा सकता है
  • install के बाद command recognition error आए तो runtime restart या reinstall करने की सलाह दी जाती है
  • Docker environment में CLAUDE_CONFIG_DIR setting से path issues हल किए जा सकते हैं
  • --uninstall option से सभी components हटाए जा सकते हैं

community और license

  • OpenCode, Gemini CLI, Codex के लिए community ports उपलब्ध हैं
  • MIT license के तहत जारी
  • “Claude Code is powerful. GSD makes it reliable.” — Claude Code की reliability बढ़ाने वाला टूल

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-19
Hacker News की राय

  • मैंने पहले Plan mode और Superpowers को साथ में इस्तेमाल किया था, लेकिन आखिर में लगा कि सिर्फ Plan mode ही काफ़ी है
    ऐसे फ्रेमवर्क fire-and-forget कामों के लिए अच्छे हैं जहाँ research चाहिए, लेकिन लगा कि ये 10 गुना से ज़्यादा token खर्च कर देते हैं
    नतीजों की quality में भी बहुत बड़ा फ़र्क नहीं था, इसलिए Max plan limit बार-बार hit हो जाती थी

    • मैंने Superpowers की brainstorm·design·implementation planning क्षमता ली और उसे Ralph-आधारित implementation layer से जोड़ दिया
      implementation plan ख़त्म होते ही यह मेरे input के बिना अपने-आप आगे बढ़ता है, लेकिन इसे Docker sandbox के अंदर चलना चाहिए
      वजह जोखिमभरी permission settings हैं, लेकिन वैसे भी मुझे लगता है कि वही ज़्यादा सुरक्षित है
      अभी यह अच्छे से काम कर रहा है और productivity भी बढ़ी है, लेकिन यह यात्रा का बीच वाला चरण लगता है
    • मैंने उल्टा Plan mode से Superpowers पर switch किया
      latest version announcement देखकर फिर से इस्तेमाल किया, और cross-check और self-review की कई layers होने की वजह से नतीजे ज़्यादा stable थे
      यह manually भी किया जा सकता है, लेकिन Superpowers उस process को automate कर देता है, इसलिए काफ़ी आसान था
    • मैंने वही काम GSD और Plan Mode में test किया, Plan Mode ने 20 मिनट में basic implementation तक पूरा कर दिया, जबकि GSD को कई घंटे लगे
      GSD का code पूरे project context को ध्यान में रखकर था, जबकि Plan Mode ने MVP स्तर पर सिर्फ़ ज़रूरी चीज़ें implement कीं
      workflow या काम के scale के हिसाब से दोनों के फ़ायदे-नुकसान साफ़ दिखते हैं
    • GitHub Copilot का Plan mode हाल में plan memory जुड़ने के बाद अजीब हो गया है
      output ज़्यादा verbose हो गया है और details उल्टा और धुंधली हो गई हैं
      “design”, “figure out” जैसे चरण ही बढ़ गए हैं, और follow-up सवाल किए बिना सीधे implementation पर चला जाता है
    • मेरा भी ऐसा ही अनुभव रहा
      मैंने एक हफ़्ते की Claude subscription और API credits सब जला दिए और बदले में लगभग 500 lines code ही मिला
      यह tests में हेरफेर भी करता था या बिल्कुल अजीब results देता था
      आख़िर में मैंने खुद manually guide करते हुए MVP पूरा किया, और वही कहीं ज़्यादा efficient था

  • आजकल ऐसे meta frameworks बहुत ज़्यादा हैं, लेकिन असल productivity साबित करते हुए मैंने बहुत कम देखे हैं
    ज़्यादातर बस token waste हैं और context window pollution पैदा करते हैं
    आखिर में सबसे अच्छा यही लगा कि चीज़ों को simple रखो, सिर्फ़ ज़रूरी जानकारी दो, और Plan → Code → Verify क्रम में दोहराते रहो

    • Apenwarr की पोस्ट “The AI Developer’s Descent Into Madness” में “agent अपना ही framework बना रहा है” वाली स्थिति का व्यंग्यात्मक चित्रण है
    • मैंने Claude और Codex को जोड़कर एक mini framework खुद बनाया
      Claude की अकेले की गई गलतियों को Codex पकड़ लेता है, इससे लगा कि किसी एक agent पर पूरी तरह भरोसा नहीं किया जा सकता
    • मैं visual spec design तरीका इस्तेमाल करता हूँ
      app की screen flow को images में design करके, उसे structured markdown में export कर दो तो LLM screen unit के हिसाब से context समझ लेता है
      text-आधारित specs की तुलना में missing states या error flows पहले ही पकड़ में आ जाते हैं
    • ऐसे meta frameworks आखिरकार .vimrc या .emacs.d जैसे personal tooling ही हैं
      बनाने वाले के लिए उपयोगी, लेकिन दूसरों को अक्सर बेकार लगते हैं

  • मुझे लगता है Spec-Driven systems का असफल होना तय है
    अंग्रेज़ी में लिखे specs असली code और behavior को जोड़ नहीं पाते
    यह समस्या पहले ही automated tests से हल की जा चुकी है
    system के behavior को executable tests के रूप में encode करना चाहिए
    LLM जब implementation बनाए, तब भी पहले tests लिखने चाहिए और mutation testing से consistency verify करनी चाहिए
    इससे जुड़ी बातें मैंने इस लेख और GitHub example में समेटी हैं

    • natural language specs scalable नहीं होते, लेकिन इन्हीं के आधार पर formal spec बनाया जाए तो संभावना हो सकती है
      आखिर में उसे code के रूप में व्यक्त होना ही होगा
    • “A sufficiently detailed spec is code” जैसा एक लेख भी था, लेकिन मैं OpenAI के results reproduce नहीं कर पाया
      लिंक देखें
    • Spec Driven Development नाम से TDD जैसा लगता है, लेकिन दिशा बिल्कुल उलटी है
    • tests को सिर्फ़ spec का output मानना गलत तर्क है
      spec, tests की तुलना में कहीं बड़ा दायरा कवर करता है
      कई बार LLM tests को ignore कर देता है या मनमाने ढंग से बदल देता है

  • मैं एक personal AI system इस्तेमाल कर रहा हूँ, लेकिन उसे public करूँ या नहीं, इस पर सोच रहा हूँ
    यह मेरे काम के हिसाब से customize है, इसलिए इसका public version अलग से maintain करना बोझ जैसा लगता है
    लोगों को सीधे इस्तेमाल करने के लिए देने के बजाय, मैं अपने system को reference की तरह रखकर patterns ही share करना चाहता हूँ

    • maintenance करना ज़रूरी नहीं है
      AI युग में सिर्फ़ inspiration और ideas share करना भी काफ़ी value रखता है

  • मैंने team hackathon में GSD इस्तेमाल किया, लेकिन codebase समझने में बहुत समय लग गया और token usage भी बहुत ज़्यादा था
    agent transcript बनाते समय errors भी बार-बार आए
    कुछ छोटे features बनाने के लिए यह tool हद से ज़्यादा भारी था
    सीख यही मिली — अच्छे specs लिखना + Plan mode को दोहराना कहीं ज़्यादा efficient था

  • Beads की design constraints मुझे घुटनभरी लगीं, इसलिए मैंने वैसा ही एक tool खुद बना लिया
    मेरा version SQLite-आधारित है, और मैंने GitHub के साथ two-way sync भी जोड़ दिया है
    असली बात है पहले model से बात करके स्पष्ट spec files बनाना
    file होने पर model भूलता नहीं है, और details जितनी ज़्यादा हों, output quality उतनी बेहतर होती है
    मैंने Claude की मदद से एक लंबे समय से सोचा हुआ idea prototype के रूप में बनाया, और वह उम्मीद से बेहतर निकला

    • इसे “secret sauce” कहना ठीक नहीं, क्योंकि RPI(research-plan-implement) पहले से official docs में मौजूद concept है
      model अब भी probabilistic system है, इसलिए perfect memory असंभव है
      इसे जैसे कोई नई गुप्त तकनीक खोज ली हो, उस तरह पेश करना बढ़ा-चढ़ाकर कहना है

  • मैंने Superpowers इस्तेमाल किया है, और यह GSD भी उससे मिलता-जुलता लग रहा था, इसलिए comparison जानना चाहता था

    • मैंने दोनों इस्तेमाल किए हैं, और GSD ज़रूरत से ज़्यादा complex और slow है
      Quick mode अपने मूल उद्देश्य से भटका देता है, और Superpowers बीच का संतुलित विकल्प लगा
    • structured prompts वाक़ई मदद करते हैं
      ऐसे frameworks को repository में रखकर, AI से framework को ही improve करवाओ तो creative कामों में भी फ़ायदा हो सकता है
      लेकिन यह structure शायद बस temporary hack है; models पर्याप्त train हो जाएँगे तो यह स्वाभाविक रूप से ग़ायब हो जाएगा
    • Superpowers planning stage में सारा code पहले ही लिख देता है, और sub-agents उसे ज्यों का त्यों copy करते हैं, इसलिए यह inefficient था
      GSD इस समस्या को हल करता है, लेकिन steps बहुत ज़्यादा होने की वजह से यह slow है
    • मैंने अपना blog Hugo से Astro में migrate करते समय Superpowers test किया
      Superpowers द्वारा बनाया गया spec काफ़ी detailed था, लेकिन कुछ features (जैसे RSS, analytics) छूट गए, और parallel migration सुझाने वाला collaboration spec ज़्यादा flexible था
      आख़िर में मैंने Claude से दोनों specs की तुलना और integration करवाकर final version तैयार किया
      विस्तृत तुलना देखें
    • पता नहीं CLI wrapper की सच में ज़रूरत भी है या नहीं
      सिर्फ़ Claude skills से भी यह काफ़ी हद तक implement हो सकता है

  • मैंने 3 महीने तक GSD को गहराई से इस्तेमाल किया, और यह पहले इस्तेमाल किए गए speckit से कहीं ज़्यादा polished लगा
    यह complex tasks का भी 95% तक काम अपने-आप कर देता है
    बाकी 5% मैं manual testing से पूरा करता हूँ
    इससे मैंने SaaS product(whiteboar.it) तक launch कर दिया
    model के अपने improvements भी रहे होंगे, लेकिन productivity gain साफ़ था

    • मेरा भी लगभग ऐसा ही अनुभव रहा
      FreshBooks subscription पर पैसे बर्बाद न हों, इसलिए मैंने GSD से macOS Swift app खुद बना लिया
      receipt auto-extraction और category classification तक Anthropic API से implement किया
      शुरुआत web app से हुई थी, लेकिन camera integration जैसी features जोड़ते-जोड़ते यह पूरी desktop app बन गई
      GSD की वजह से मैं अपना personal accounting app पूरा कर पाया

  • आखिर में असली ज़रूरत tokens बचाने वाले tools की है
    लेकिन अभी ऐसे tools हैं नहीं
    बड़े projects में Claude Code भी बहुत ज़्यादा tokens खाता है

  • “Markdown files के इस bundle” का नाम बहुत cringe है

    • अगर इसे “Languages” folder के नीचे रखते तो शायद बेहतर लगता
    • फिर भी “gstack” जितना बुरा तो नहीं है, है ना?