हर कार्ड पर parallel agents चलाने वाला open source Kanban desktop app

 (kanbots.dev)
1 पॉइंट द्वारा GN⁺ 8 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • KanBots एक desktop app है जो हर kanban कार्ड पर Claude Code और Codex को parallel में चलाता है, और progress, decisions और cost को board पर real time में दिखाता है
  • हर run, kanbots/issue-N branch की अलग git worktree में isolate होता है, और आप folder डालकर board बना सकते हैं तथा हर कार्ड को agent assign कर सकते हैं
  • Autopilot product, engineer, reviewer, tester जैसी personas को अधिकतम parallelism 4 के साथ round-robin में चलाकर काम बांटता है और backlog अपडेट करता है
  • agents निर्णय की ज़रूरत वाले बिंदु पर रुकते हैं और options दिखाते हैं; user number चुनकर, संशोधन के साथ दोबारा submit करके, या /spec, /review, /split से आगे बढ़ सकता है
  • desktop app free MIT license और local-first approach अपनाता है, जबकि Cloud $19 प्रति seat प्रति माह पर team sync, notifications और dashboards देता है

KanBots की बुनियादी अवधारणा

  • KanBots एक desktop app है जो Claude Code और Codex agents को kanban board के कार्ड-स्तर पर parallel में चलाता है
  • हर agent, kanbots/issue-N branch की अलग git worktree में चलता है, और board progress, decision requests और cost को real time में अपडेट करता है
  • folder डालते ही board बन जाता है, और कई कार्डों पर Claude Code या Codex agents assign किए जा सकते हैं
  • automatic execution mode में personas काम को बांटती हैं, parallel में चलाती हैं, और results की जांच करती हैं
  • desktop app free, MIT license, donation-based है और local-first तरीके से काम करता है

प्रोडक्ट संरचना और pricing

  • desktop OSS

    • Desktop local-first है, account की ज़रूरत नहीं, telemetry नहीं, हमेशा के लिए free है, और MIT license के तहत है
    • macOS, Linux, Windows को support करता है और सभी features शामिल हैं
    • मुख्य features में parallel agent execution, Autopilot, decision prompts, built-in और custom personas, real-time cost analytics, recipe library, kanbots-mcp-server, Sentry import, GitHub Issues mode, branch previews, PR draft creation, Claude Code और Codex support, और pre-push hooks शामिल हैं

  • teams के लिए Cloud

    • Cloud एक hosted multi-user product है, जबकि agents user hardware पर local रूप से चलते हैं
    • कीमत $19 प्रति seat प्रति माह है, और annual billing पर $190 है
    • OSS features के अलावा यह board real-time presence, teammate assignment notifications, device sync, Slack notifications, org-wide cost aggregation, real-time collaborative card editing, organization-level agent activity dashboards, और Managed GitHub App देता है
    • Enterprise features में audit logs, SSO / SCIM, REST API और PAT, outbound webhooks शामिल हैं
    • Cloud-only features को उन capabilities तक सीमित रखा गया है जिनका मतलब तभी है जब दूसरे लोग या दूसरी devices हों; एक व्यक्ति द्वारा एक machine पर इस्तेमाल होने वाले features OSS में शामिल हैं

supported tools और integrations

  • Claude Code और Codex CLI support करता है
  • GitHub Issues और PR workflows support करता है
  • Sentry error import support करता है
  • Cursor और Claude Desktop को MCP clients के रूप में integrate किया जा सकता है
  • local storage के लिए SQLite का उपयोग होता है
  • desktop shell Electron पर आधारित है

मुख्य features

  • parallel card execution

    • कई कार्डों पर agents को एक साथ चलाया जा सकता है, और हर run अपनी git worktree और kanbots/issue-N branch में आगे बढ़ता है
    • board execution progress, agent decision requests, और accumulated cost को real time में अपडेट करता है

  • automatic execution और personas

    • product, engineer, reviewer, tester जैसी personas को जोड़ा जा सकता है और parallelism को अधिकतम 4 तक सेट किया जा सकता है
    • orchestrator personas को round-robin में चलाता है, top-level issues को sub-tasks में बांटता है, और agents द्वारा खोजे गए काम से backlog अपडेट करता है
    • personas दूसरी personas भी बना सकती हैं

  • decision-centric execution

    • agents जब किसी ज़रूरी decision पर पहुंचते हैं तो रुक जाते हैं और options दिखाते हैं
    • user number selection, edits के बाद resubmit, या /spec, /review, /split जैसे slash commands के साथ execution जारी रख सकता है
    • quietly task tree बदलने के बजाय यह reviewable decision flow छोड़ता है

  • Claude Code और Codex integration

    • Claude Code या Codex को एक ही board, एक ही worktree, और एक ही decision UI में इस्तेमाल किया जा सकता है
    • KanBots एक single AgentCliAdapter के पीछे दोनों stream formats को handle करता है
    • मौजूदा claude /login या OPENAI_API_KEY का उपयोग किया जा सकता है

  • local-first storage

    • सारा data repository के बगल में .kanbots/ के अंदर रहता है
    • SQLite database, settings, और worktrees local रूप से store होते हैं
    • कोई cloud account, telemetry, या HTTP server नहीं है और code machine से बाहर नहीं जाता

  • cost analytics और budget limits

    • run-level, card-level, और project-level cost aggregation देता है
    • agent के काम करने के दौरान cost meter accumulate होता रहता है
    • per-run और per-session limits सेट की जा सकती हैं, और budget पहुँचने पर run रुक जाता है

  • GitHub workflow

    • personal PAT के साथ वास्तविक GitHub issues पर काम किया जा सकता है
    • worktree को commit में promote किया जा सकता है, या एक click में draft PR खोला जा सकता है
    • pre-push hook के जरिए agents को खुद से publish करने से रोका जाता है

  • MCP server

    • kanbots-mcp-server Model Context Protocol के जरिए board को expose करता है
    • Cursor, Claude Desktop, या MCP समझने वाले tools board को handle कर सकते हैं
    • board दूसरे agents के लिए इस्तेमाल होने वाला एक tool बन जाता है

app के अंदर workflow

  • Autopilot

    • एक या अधिक personas चुनें, parallelism सेट करें, फिर automatic execution शुरू करें
    • अधिकतम 4 parallel slots persona list को round-robin में चलाते हैं
    • हर slot अगले persona को atomically लेता है, और agent प्रगति के दौरान top-level issue को sub-tasks में बांटता है
    • completion या session budget तक पहुंचने पर रुक जाता है
    • example screen में Claude Opus 4.7, medium effort, parallelism 2, और Product Manager तथा Senior Engineer personas चुनी हुई दिखाई जाती हैं

  • Decisions

    • execution thread सभी tool_use और tool_result को real time में stream करता है
    • agent निर्णय की ज़रूरत वाले बिंदु पर run रोक देता है और numbered options दिखाता है
    • reply input /spec, /review, /split जैसे commands लेता है
    • password reset token implementation example में single-use JWT, DB-stored opaque token, magic link, या पहले trade-offs समझाने जैसे options दिखते हैं
    • execution screen में model, elapsed time, token count, cost, status, priority, folder, worktree, branch, base branch, और author दिखते हैं

  • Personas

    • persona नाम दिया गया system prompt fragment है
    • default personas app में शामिल हैं, और users नई personas लिखकर save व reuse कर सकते हैं
    • custom personas उसी machine पर local रूप से store होती हैं
    • default examples में Product Manager, Senior Engineer, UX Designer, Growth Lead, Reliability Engineer शामिल हैं

  • Providers

    • Claude Code और Codex को एक AgentCliAdapter के पीछे इस्तेमाल किया जा सकता है
    • मौजूदा claude /login या codex login को reuse किया जाता है, इसलिए अतिरिक्त account या extra key management की ज़रूरत नहीं है
    • हर run के लिए provider बदला जा सकता है
    • Codex CLI के लिए codex का PATH में होना ज़रूरी है, और issue draft creation तथा Sentry analysis अभी भी Claude पर चलते हैं
    • Codex login browser में auth.openai.com खोलकर या environment variable OPENAI_API_KEY से किया जा सकता है

  • Tasks

    • नए tasks bug fix, feature, refactor, review, और spike templates देते हैं
    • शुरू करने के तरीके हैं spec-first, create होते ही तुरंत run, या बाद में queue में डालना
    • title branch और PR title के रूप में इस्तेमाल होता है
    • spec-first /spec चलाकर acceptance criteria को refine करता है और उसे approval waiting state में रखता है
    • नया task fresh worktree बनाता है, और main के आधार पर .kanbots/worktrees/issue-N के नीचे branch बनाता है

  • Chat

    • workspace के बारे में सवाल पूछने के लिए एक general-purpose agent दिया गया है
    • agent repository, tests, और git state को जानता है और सवालों के जवाब देता है
    • बिना rate limiting वाले API routes ढूंढने, /api/login और /api/signup में rateLimit({ windowMs: 60_000, max: 10 }) जोड़ने, फिर tests लिखकर उन्हें pass कराने का example दिया गया है

Autopilot कैसे काम करता है

  • Autopilot एक mode है जो issues और budget लेकर backlog को खुद अपडेट करता है
  • orchestrator persona list को round-robin में चलाता है, और अधिकतम 4 slots को parallel में execute करता है
  • यह top-level issues को sub-tasks में बांटता है और काम के converge होने या cost limit तक पहुंचने तक cycle करता है
  • example में parallelism 4, model opus 4.7, session budget $25.00 में से $4.27 spent, और 14th cycle status दिखाया गया है

  • persona list selection

    • default personas इस्तेमाल की जा सकती हैं, या आप खुद system prompts define करके save और reuse कर सकते हैं
    • custom personas machine से बाहर नहीं जातीं

  • parallelism setting

    • parallelism 1 से 4 तक सेट किया जा सकता है
    • हर slot round-robin counter के जरिए अगले persona को atomically लेता है
    • चार agents चार perspectives और चार worktrees में एक साथ चल सकते हैं

  • task splitting

    • agent जब काम खोजता है तो board पर नया card बनाता है
    • बाद के cycles नए cards उठाते हैं, और backlog orchestrator के तहत बढ़ता-घटता रहता है

  • budget या completion पर stop

    • session-level cost budget कुल spending को सीमित करता है
    • stop button parent execution और सभी child executions को समाप्त कर देता है
    • in-progress runs अपनी current iteration साफ़ तरीके से पूरी करती हैं

QA mode

  • QA mode worktree के अंदर typecheck, tests, lint, build, और e2e चलाता है
  • ज़रूरत होने पर development server शुरू और monitor कर सकता है
  • हर failed check के लिए derived child issues में fix runs assign करता है
  • checks pass होने तक इसे दोहराता है

availability और निष्कर्ष

  • OSS desktop app free, MIT license, और no-account मॉडल में उपलब्ध है
  • यह इस workflow पर ज़ोर देता है जिसमें सभी agent runs को kanban पर visualise, decision-enabled, और isolate किया जाता है
  • जब team को board share करना हो, तब Cloud पर switch किया जा सकता है
  • download formats हैं macOS .dmg, Windows .exe, Linux .AppImage / .tar.xz

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

1 टिप्पणियां

 
GN⁺ 8 시간 전
Hacker News की टिप्पणियाँ

  • लोग रातभर एजेंट के काम के नतीजों को कैसे लेते हैं, इस पर मुझे लगातार हैरानी होती है
    निजी side project repo में भी 30 मिनट planning और 30 मिनट implementation का नतीजा review करने के लिए बहुत बड़ा लगता है। करीब 5 मिनट बाद, जब code बरस रहा होता है, तब भी कभी-कभी मैं AI से कह देता हूँ कि इसे फिर से करो

    • आजकल narrative इस पर केंद्रित है कि AI पूरा या ज़्यादातर code लिख रहा है, लेकिन हक़ीक़त में शायद इंसानों द्वारा review किए गए code का अनुपात लोगों के समझने या मानने से कहीं तेज़ी से 0 के करीब जा रहा है
    • ऐसे agent activity का बड़ा हिस्सा पहले से बने हुए काम को खंगालना और constraints को ज़बरदस्ती लगाकर review के समय मेज़ पर आने वाले output को कुछ हद तक predictable बनाना है
      मेरी राय में मज़बूत file structure भी मदद करता है। अभी-अभी generated 3,000-line file को review करना सबसे बुरा है, और मैं ऐसा output न किसी इंसान से लेना चाहूँगा न मशीन से। अगर चीज़ें सही जगह पर कई files में बंटी हों तो cognitive load कम हो जाता है
      कभी-कभी मैं agent से बात करते हुए साथ-साथ review भी करता हूँ। जैसे पहले पूछता हूँ कि review के लिए सबसे ज़रूरी file कौन-सी है
      मुझे changes को “LGTM” ढेर में stage करके रखना पसंद है। बाद में अगर fix चाहिए हो तो मैं agent से कहता हूँ, “unstaged changes review करो. यहाँ मैं चाहता था कि तुम इसे किसी और तरीके से करते”
    • कोई भी code review नहीं कर रहा। Managers भी नहीं चाहते कि हम code review करें, क्योंकि वही bottleneck है
      जब कुछ गड़बड़ होता है, यानी bug आता है, तब उसे उसी समय ठीक कर दिया जाता है। यह software engineering का बहुत दुखद दौर है। अगर हमारी industry में कभी engineering जैसी कोई चीज़ थी, तो अब उसका ज़्यादातर हिस्सा गायब हो चुका है, और हम “bug मत डालो” या “तुम tenant नहीं, owner हो” जैसी skills files लिखकर बस अंदाज़ा लगा रहे हैं
      effort level भी कम है और determinism भी बहुत कम है। GitHub जैसी बड़ी apps AI garbage की वजह से लगातार गिर रही हैं, और कम मशहूर systems में यह और ज़्यादा दिखता है। हमारी company या जिन दूसरे SaaS का हम इस्तेमाल करते हैं, वहाँ भी यही हाल है
      product managers को वैसे भी code में दिलचस्पी नहीं थी, engineering managers को भी अब code में उतनी दिलचस्पी नहीं है जितनी तब थी जब वे engineer थे। Directors को code की बिल्कुल परवाह नहीं, और CTO को अब शायद यह भी नहीं पता कि code दिखता कैसा है
      हम chain के आख़िरी छोर पर थे, और हमें भीतर तक पता था कि अच्छे systems अच्छे code पर बनते हैं, इसलिए हम usable और maintainable code पर गर्व करते थे। लेकिन अब हम ख़ुद को ख़तरे में डाल रहे हैं, और code की परवाह न करने वाले भी अब हम engineers ही हैं, जबकि AI इस समस्या को और बढ़ा रहा है
    • आम तौर पर मेरा लक्ष्य होता है कि Claude के रातभर काम करने के बाद आख़िर में लगभग 500 lines का code ही बचे
      ज़्यादातर समय अलग-अलग approaches आज़माने और उनका summary देने में जाता है, ताकि मुझे review और edit करने लायक़ काफ़ी छोटा diff मिले
    • मुझे भी यही सवाल परेशान करता है। जो लोग इसे सच में अच्छी तरह चलाते हैं, उनसे अक्सर यही सुनने को मिलता है कि वे code देखते ही नहीं, या कम से कम detail में नहीं देखते
      निजी तौर पर, agent के बनाए output में मैं हमेशा कुछ-न-कुछ छेड़छाड़ करता हूँ। समझ नहीं आता कि क्या मुझे वह control छोड़ देना चाहिए

  • इससे मुझे Vibe Kanban(https://vibekanban.com/) याद आता है, जिसे मैं ज़्यादातर projects में coding agents को manage करने के लिए इस्तेमाल करता हूँ
    दुर्भाग्य से Vibe Kanban के developers ने यह मानकर project में निवेश रोक दिया कि उन्हें monetization का रास्ता नज़र नहीं आ रहा। यह open source है, इसलिए आप इसे local पर चला सकते हैं या fork कर सकते हैं, लेकिन improvements रुक चुकी हैं और कुछ परेशान करने वाले bugs अब भी बचे हैं। मेरे पास इसे maintain करने का समय नहीं है
    अफ़सोस है, क्योंकि मैं Vibe Kanban के लिए पैसे देने को तैयार था। बस मुझे paid plan features की ज़रूरत नहीं थी। पीछे मुड़कर देखूँ तो शायद मुझे वैसे ही भुगतान कर देना चाहिए था
    मैं Kanbots भी आज़माऊँगा। इसे Vibe Kanban के features खुलकर copy करने चाहिए। ख़ासकर remote support और “Open in VS Code” button मेरे लिए बहुत ज़रूरी हैं। मेरे case में यह button local VSCode client खोलता है, जो remote VSCode server की तरफ़ point करता है

    • Vibe Kanban उपयोगी features के लिहाज़ से सचमुच खज़ाना है
      पिछले 1–2 हफ्तों से मैं एक नए tool को VK के feature parity स्तर तक लाने और उसमें कुछ अतिरिक्त improvements जोड़ने पर काम कर रहा हूँ। Vibe Kanban Discord में कुछ screenshots भी डाले हैं। उम्मीद है launch के लिए तैयार होने पर यह आपके use case में भी अच्छी तरह फ़िट बैठेगा
      मेरा tool Kanban board और agent workspace दोनों में VK से बेहतर features देने का लक्ष्य रखता है, और साथ ही desktop window management, plugins, browser में VSCode integration, और htmx-जैसी server-rendered UI जैसी अतिरिक्त systems भी जोड़ रहा है
      remote access का तरीका भी अलग है। laptop पर web server चलाकर remote coding agents तक पहुँचने के बजाय, OpenClaw की तरह सब कुछ host किया जाता है और browser में remote desktop UI तक access मिलता है

  • यह बात कि “local-first, serverless. सब कुछ repo के बगल में .kanbots/ में है: SQLite database, configs, worktrees. कोई cloud account नहीं, कोई telemetry नहीं, कोई HTTP server नहीं. यही open source desktop edition है” — ऐसे tool को अपनाने पर विचार करने के लिए बुनियादी शर्त है

    • मुझे समझ नहीं आ रहा कि “ऐसे tools” से आपका मतलब क्या है
      अगर AI agentic है, तो मैं उम्मीद करूँगा कि कोई भी product manager लगभग एक घंटे की बातचीत के बाद Jira को किसी agent loop के साथ integrate कर सके
      Jira, Trello, Linear, Basecamp — सबके पास API हैं, और शायद ऐसे CLI भी होंगे जिन्हें agent इस्तेमाल कर सके। एक developer या SaaS की ज़रूरत नहीं पड़नी चाहिए सिर्फ़ यह समझाने के लिए कि काम शुरू होने पर ticket checkout हो जाए, उसमें instructions हों, और खत्म होने पर वह DONE में चला जाए
    • page पर लिखा है कि local इस्तेमाल करने पर भी इस feature के लिए cloud account login चाहिए, इसलिए मैंने इसे आज़माने का विचार छोड़ दिया
      सच कहूँ तो यह cool दिखता है। लेकिन ऐसी cool दिखने वाली tools पहले से काफ़ी हैं

  • मूल रूप से “Kanban” शब्द Toyota ने card system का वर्णन करने के लिए इस्तेमाल किया था, और उस system ने कुछ अहम मक़सद पूरे किए थे, जैसे एक साथ बहुत ज़्यादा काम न करना और काम को visualize करना
    कुल मिलाकर Kanban का इस्तेमाल workflow को manage करने के लिए होता था ताकि defects आगे न निकल जाएँ
    लेकिन यह tool तो “जितना काम सोच सको, उसे जितना हो सके उतना parallel generate होने के लिए ठूंस दो” के ज़्यादा क़रीब लगता है। यह quality output के flow को manage नहीं करता, न ही काम को limit करता है। बस सब कुछ agents के हवाले कर दो और tokens को पागलों की तरह जलाओ
    इसे “Kanban” कहना मुझे सच में खटकता है। यह लगभग ईशनिंदा जैसा लगता है

  • जब मैंने agents को बिना supervision के चलाया, तो success से ज़्यादा frustration मिली
    मुझे यक़ीन है कि technology आख़िरकार वहाँ तक पहुँचेगी, लेकिन अभी हर agent के लिए एक IDE चाहिए और work merge करना भी झंझट है

  • यह हाल का open source project शेयर कर रहा हूँ। यह parallel agents वाला Kanban board है
    मैं इसमें और features जोड़कर सुधार करने की कोशिश कर रहा हूँ, और चाहे code contribution हो या ideas, repo में आपका योगदान स्वागतयोग्य है

    • बढ़िया काम है। मैंने पहले मौजूदा Jira projects में workflow के हिसाब से sort करके अपने agents से Kanban चलवाने की कोशिश की है, इसलिए आज HN पर यह project देखकर अच्छा लगा
      इसकी progress को follow करना मज़ेदार रहेगा
    • Stripe dev blog पर minions वाली post देखना अच्छा रहेगा। दिशा कुछ मिलती-जुलती लगती है

  • क्या यह मूल रूप से वही नहीं है जो Windsurf कर रहा है? आख़िर में ऐसी सारी UIs तो agents के ऊपर चढ़ी हुई सजावट भर हैं
    [0] https://windsurf.com/blog/windsurf-2-0

    • Kanban board से agents को handoff करने में मदद करने वाली कुछ apps हैं
      मुझे एक ज़्यादा human-in-the-loop flow चाहिए था। ऐसा तरीका जिसमें changesets को ठीक से देखा भी न जा सके और दिशा बदलने का मौका भी न मिले, मेरे लिए सही नहीं है
      https://www.agentkanban.io extension के ज़रिए task board को VS Code के GitHub Copilot Chat से जोड़ता है, ताकि task management के साथ chat से task तक आने वाले context capture का फ़ायदा भी मिले। इस तरह VS Code जैसे higher-level execution environment के फ़ायदे और task/project management दोनों एक साथ मिलते हैं
    • मुझे यहाँ कोई समस्या नहीं दिख रही। क्या कोई समस्या है?
      Linear भी सीधे इसी दिशा में काम कर रहा है
    • क्या Windsurf open source है?

  • ऐसे tools में जो बात मेरी समझ से बाहर है, वह है अलग-अलग worktrees में infrastructure boot-up को कैसे handle किया जाता है
    उदाहरण के लिए, अगर कोई web app है, तो हर worktree को अपना infra उठाना होगा, और हर एक अपने अलग local URL से accessible होना चाहिए। तभी आप हर worktree के changes को local पर देख सकते हैं, या agent-browser जैसी किसी चीज़ से agent को visual checks automate करने दे सकते हैं
    अभी मैं infra के लिए Docker इस्तेमाल करता हूँ, और हर service अपने container में चलती है। मेरे पास ./app worktree create worktreename script है, जो “worktreename” worktree बनाती है और फिर “WORKTREENAME” जैसे prefix के साथ पूरा Docker infra उठा देती है। इस तरह सारे URLs को worktreename.myapp.test से access किया जा सकता है, और main worktree बस myapp.test इस्तेमाल करती है
    अभी तो यह ठीक चल रहा है, लेकिन अच्छा होगा अगर इन apps में से कोई इस concept के साथ compatible हो, ताकि मैं उस तरफ़ move कर सकूँ

    • काम पर हमें भी यही समस्या थी, इसलिए मैंने CC से कहा कि worktrees बनाने, हटाने और list करने के लिए एक बहुत साधारण bun CLI tool बना दे
      वह CLI .env file में उस worktree के लिए URL और database भर देता है, और Vercel के open source package portless से unique ports पर dev server चलाता है। इस तरह हर worktree का अपना URL मिल जाता है
    • emdash.sh देखना चाहिए। हर task अपना worktree उठाता है, और उसमें predefined environment variables inject किए जाते हैं
      इसमें EMDASH_PORT भी शामिल है, जो 10-port range के भीतर एक unique port देता है। यह एक single monorepo में कई services चलाने के लिए बहुत उपयोगी है
    • मैं worktrees बनाने और हटाने के लिए shell scripts इस्तेमाल करता हूँ
      shell script सभी मौजूदा worktrees में ऐसा unique port ढूँढती है जो इस्तेमाल में न हो, और worktree बनाते समय उसे local .env में assign कर देती है। जब worktree merge होकर हट जाती है, तो port भी release हो जाता है
      जो secrets worktree-specific नहीं हैं, उन्हें मैं local .env में नहीं रखता, shell से inject करता हूँ
      सच कहूँ तो dev work automation के लिए ऐसी local scripts लिखना बहुत आसान था, और ये बाकी सभी CLI tools के साथ अच्छी तरह जुड़ जाती हैं। इसलिए मैंने अब तक कोई GUI app नहीं आज़माया। पता नहीं वह मेरी मनचाही तरह काम करने वाली custom local setup से टक्कर ले पाएगी या नहीं
    • क्या बस direnv इस्तेमाल नहीं किया जा सकता? local pages host करने वाले ports तो adjust करने होंगे, लेकिन worktree name based hash से N=mod(...) निकालकर port=default_port+N रखा जा सकता है
      Claude से कहो कि इसे configure कर दे। वह एक prompt में कर देगा

  • “‘kanbots’ damaged है और खोला नहीं जा सकता. इसे Trash में move करना होगा”
    vibe coding software के साथ पहली बार मिलने के लिए यह ग़लती कुछ ज़्यादा ही फ़िट बैठती है

  • क्या यह बस vibe-kanban ही नहीं है?
    https://github.com/BloopAI/vibe-kanban

    • competitors हो सकते हैं
    • यह सचमुच Bloop पर है। Bloop का ही original है