English | 简体中文 | 日本語 | 한국어 | Tiếng Việt | Português | Español | Deutsch | Français | हिंदी

विश्वस्तरीय इंजीनियरों द्वारा निर्मित, vibecoders के लिए
flowser.ai — GTM के लिए कंप्यूटर वाले AI Agents

vibecode-pro-max-kit

"पूर्ण एकाग्रता — Spec श्वास, दसवाँ रूप: Vibe Flow कभी नहीं टूटता।"
— तंजिरो कामादो

इसे किसी भी project में डालें। आपके AI agent को एक पूरी plan-first development process मिल जाती है — 7 gated phases, self-healing check loops, और autopilot जो शुरू से अंत तक बिना अपनी जगह खोए चलता है।

📦 एक command में install एक curl line इसे किसी भी project में डाल देती है। यह नए और पुराने दोनों users को detect करती है और आपकी files कभी overwrite नहीं करती।	🌐 हर जगह काम करता है कोई भी tech stack, कोई भी language, और कोई भी AI coding agent — Claude Code, Codex, Cursor, Windsurf, Copilot, और अन्य।
🧭 RIPER-5 plan-first workflow 7 gated phases (Research → Spec → Innovate → Plan → Validate → Execute → Update-Process) agent को सीधे code लिखने से रोकते हैं।	🚀 Autopilot mode (quick / fast / full) किसी भी phase पर एक ही phrase से hands-free run शुरू करें। तीन lanes जोखिम के अनुसार ceremony को adjust करती हैं।
🎯 /goal — run-until-done token एक copy-pasteable block agent को phase दर phase बिना रुके चलाता है — और fresh session में run फिर से शुरू कर देता है।	🔁 PVL + EVL self-healing loops Plan-check-fix और test-check-fix loops खुद gaps ढूंढते हैं, ठीक करते हैं, और दोबारा जांचते हैं — हर एक 10 cycles तक।
🔍 vc-autoresearch एक reusable find-gaps → fix → repeat loop जिसे आप plans, tests, specs, docs, या evals पर लगा सकते हैं।	🧪 Feasibility probes किसी भी design approach पर commit करने से पहले test-before-you-build verdicts (VIABLE / NOT-VIABLE)।
🎛️ Smart strategy picker हर phase से पहले यह तय करता है — एक agent, कई agents, या एक coordinated team — cost estimates के साथ — और सबसे सस्ता सही option चुनता है।	🧮 Smart model use महंगा model सिर्फ code लिखता है; सस्ता model बाकी सब करता है। कम लागत, वही quality।
🤔 Intent clarification जब request अस्पष्ट हो, agent अंदाज़ा लगाने और गलत चीज़ बनाने की बजाय पहले कुछ सटीक सवाल पूछता है।	🛡️ 36 validators Mechanical correctness checks — opinions नहीं — kit की अपनी structure की रक्षा करते हैं और ship होने से पहले drift को पकड़ते हैं।
🏗️ Phase programs बड़े projects को independent phases में बांटा जाता है जिनके बीच quality gates होते हैं, ताकि बड़ा काम बिखरे नहीं।	🔀 Programs जो खुद को reshape करते हैं सीखने के साथ-साथ agent नए phases insert करता है, काम को reorder करता है, और blocked steps skip करता है — plan उड़ान में adapt होती है।
🧠 कभी अपनी जगह नहीं खोता Progress notes हर phase पर disk पर लिखी जाती हैं, इसलिए run memory reset के बाद भी बचता है और ठीक वहीं से शुरू होता है जहाँ छोड़ा था।	📚 Self-improving project memory यह setup पर आपका codebase सीखता है और हर feature ship होने के बाद अपनी shared notes खुद update करता है, ताकि docs कभी stale न हों।
⚡ Quick Fix + Fast Mode छोटे बदलावों के लिए light lanes भारी ceremony skip करती हैं, ताकि एक-line fix एक-line fix ही रहे।	🧱 Layered, auto-discovered skills Skills स्पष्ट layers में organized हैं और automatically discover होती हैं — agent हमेशा हर step के लिए सही tool ढूंढ लेता है।
🤖 15 agents · 33 skills · 10 hooks Specialized agents, reusable skills, और safety hooks की पूरी team — box से बाहर सब कुछ एक-दूसरे से जुड़ा हुआ।	🔄 Full kit lifecycle Install, setup, update, और publish — हर एक एक ही command — हर project को safely latest kit पर रखते हैं।
📝 SPEC — आपकी plain-language sign-off किसी भी design से पहले, आप simple user stories में बताते हैं क्या बनाना है — गलतफहमी पकड़ने की सबसे सस्ती जगह।	🎯 हमेशा आपका intent जांचता है हर बाद का phase आपके SPEC से measure करता है: क्या हम वही बना रहे हैं जो आपने मांगा था?

सबसे सरल, सबसे flexible, team-friendly coding kit

     
   

किसी भी tech stack, किसी भी language, किसी भी project पर काम करता है

यह केवल दिखावे के लिए नहीं है। जब आप vc-setup चलाते हैं, तो agents आपका codebase scan करते हैं,
आपका stack detect करते हैं, और project-specific knowledge groups बनाते हैं जिन्हें हर skill काम करने से पहले पढ़ती है।
दूसरे harnesses agents को एक language तक lock कर देते हैं — rust-review-agent, python-linter — जो कहीं और बेकार हैं।
यह ऊपर दिए किसी भी combination के अनुसार adapt होता है और ship करने के साथ-साथ knowledge बढ़ाता जाता है।

⚡ शुरू करें — एक Command, 30 सेकंड

Prerequisites: Node.js ≥ 22, git, bash (macOS / Linux / WSL; Alpine पर: apk add bash)।

सिर्फ एक command है, और यह सबके लिए काम करती है। इसे अपने project folder के अंदर चलाएं। यह detect करती है कि आप नए user हैं या पुराने, आपकी files overwrite किए बिना safely install होती है, और फिर बिल्कुल सटीक अगला कदम बताती है।

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

जब यह पूरी हो जाए, तो दो में से एक message print होता है — output के नीचे पढ़ें और ठीक वही करें जो लिखा है:

💡 Command कभी guess नहीं करनी। install.sh आपको route करता है: fresh → vc-setup, upgrade → vc-update। Install दोबारा चलाना हमेशा safe है — यह कुछ तोड़ता नहीं। Codex users: chat में कहने की बजाय /vc-setup (या /vc-update) run करें।

your-project/
├── .claude/
│   ├── agents/              # 🤖 15 agent definitions (.md)
│   ├── skills/              # ⚡ 33 skills (each a dir with SKILL.md)
│   └── hooks/               # 🪝 10 lifecycle hooks (.cjs / .mjs)
├── .codex/agents/           # 🔄 Codex के लिए mirrored agents
├── .agents/skills →         # 🔗 Symlink to .claude/skills (Codex discovery)
├── CLAUDE.md                # 📋 Orchestrator + routing rules
├── AGENTS.md                # 📖 Agent + skill registry (cross-tool)
└── process/
    └── development-protocols/  # 📜 22 shared workflow docs (install द्वारा seed किए)
                                #    context/, plans, features → vc-setup द्वारा बनाए जाते हैं

First, install the vibecode-pro-max-kit agent harness by running this command:

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

After install completes, run vc-setup and follow the full interactive flow:

1. DETECT — Read package.json (or go.mod, Cargo.toml, pyproject.toml, etc.), detect my
   stack: framework, package manager, monorepo structure, test framework, database, auth.
   Also check for any existing .claude/, process/, or context files.
2. SHOW ME WHAT YOU FOUND — Summarize detection and wait for me to confirm. If this is an
   existing project, tell me what looks good vs what could be improved.
3. ASK ME ABOUT THE PROJECT — Have a real conversation. Ask follow-ups, probe anything
   vague, keep going until you genuinely understand it. Summarize back and confirm.
4. SCAFFOLD — Create the process/ directory. If process/ already exists, show me the plan
   and wait for approval. Never silently move or delete my files.
5. STUDY — Deep-scan and populate process/context/all-context.md with REAL content: repo
   structure, stack + versions, patterns, import aliases, env vars, routes, schema, tests.
   No placeholder text.
6. VALIDATE — Run all validation checks to confirm everything is wired correctly.

Rules: read and preserve good existing context; show me a summary before each major change
and wait for my OK; never create empty placeholder files; ask before reorganizing.

🎁 एक नज़र में

🔥 समस्या

आप Claude से कहते हैं "webhook support add करो।" वह तुरंत code लिखने लगता है। आपके architecture के बारे में कोई सवाल नहीं। Existing patterns की कोई जांच नहीं। कोई plan नहीं। आपको 400 lines मिलती हैं जो codebase में fit नहीं होतीं, और आप उन्हें ठीक करने में एक घंटा बिताते हैं।

लेकिन यह तो बस ऊपरी परत है। असली गहरी समस्याएं और ज़्यादा तकलीफ देती हैं:

आपके agent के पास intelligence है लेकिन कोई process नहीं, कोई memory नहीं, और आपकी team के साथ collaborate करने का कोई तरीका नहीं। चाहे आप developer हों, PM हों, या CEO जिसने अभी vibe coding शुरू की हो — यह सबको एक जैसे लगता है, और fix भी एक ही है: अपने agent को एक असली development process दें।

🛠️ समाधान

यह kit आपके project में एक पूरा development system install करता है — सिर्फ एक CLAUDE.md नहीं, बल्कि 15 specialized agents, 33 skills, 10 hooks, और 22 protocols — एक step-locked workflow के साथ जो आपके agent को build करने से पहले समझने और ship करने से पहले prove करने पर मजबूर करता है।

पूरा RIPER-5 flow — 7 phases, हर step gated

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    R["RESEARCH\nread-only facts"]
    S["SPEC\nrequirements doc"]
    I["INNOVATE\n2-3 approaches"]
    P["PLAN\ndetailed checklist"]
    V["VALIDATE\nplan → contract\n(PVL loop)"]
    E["EXECUTE\nimplement\n(EVL loop)"]
    U["UPDATE PROCESS\ncapture + archive"]

    R -->|"go"| S
    S -->|"go"| I
    I -->|"go"| P
    P -->|"ENTER VALIDATE"| V
    V -->|"Gate: PASS"| E
    E -->|"gates green"| U

    style R fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style S fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style I fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style P fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style V fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style U fill:#00695C,stroke:#004D40,color:#FFFFFF

Interactive mode में, हर phase आगे बढ़ने से पहले आपके "go" का इंतज़ार करती है — आप हर step पर loop में रहते हैं। Autopilot या /goal mode में, आप एक बार पहले approval देते हैं, फिर system खुद को done तक drive करता है। यह सिर्फ नीचे listed तीन specific hard stops पर रुकता है। VALIDATE और post-EXECUTE re-test optional नहीं हैं — ये hard gates हैं जो खराब काम को ship होने से रोकते हैं — और दोनों modes में automatically चलते हैं।

The Vibe Coding Revolution

Vibe coding ने बदल दिया कि software कौन बना सकता है। Plan-first development बदलता है कि वे क्या ship कर सकते हैं।

ज़्यादातर tools आपको project शुरू करने में मदद करते हैं। यह kit आपको उसे finish करने में मदद करता है — ऐसे plans के साथ जिन्हें आपकी team review कर सके, knowledge जो कभी stale न हो, और safety checks जो गलतियों को ship होने से पहले पकड़ें।

यह किसके लिए है?

तुलना

Runtime breadth के बारे में: GSD 14 runtimes support करता है। हम 7 को गहराई से support करते हैं — full agent harnesses, skill discovery, और हर platform पर lifecycle hooks के साथ। Breadth बनाम depth: आपकी पसंद।

⚡ यह अलग क्यों है

🧭 यह कैसे काम करता है — Coordinator

आपका main session एक coordinator (orchestrator कहलाता है) है, worker नहीं। यह चार काम करता है और कुछ नहीं:

आपका request
  → Step 0: Skill Discovery (33 skills scan करें, keywords match करें, candidates attach करें)
  → Intent detect करें (feature / bug / question / refactor / UI) + ambiguity score करें
  → सही agent को fresh context window में route करें
  → Monitor: step compliance, status codes, loop driving

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    REQ["User request"]
    SD["Step 0: Skill Discovery\nscan 33 skills, match keywords"]
    INT{"Detect intent\n+ score ambiguity"}
    RES["vc-research-agent\n(feature / question)"]
    PLN["vc-plan-agent\n(after INNOVATE)"]
    VAL["vc-validate-agent\n(PVL loop)"]
    EXE["vc-execute-agent\n(EXECUTE)"]
    TST["vc-tester\n(EVL loop)"]
    UPD["vc-update-process-agent\n(closeout)"]
    MON["Monitor\nstatus codes · loop driving\nno inline execution ever"]

    REQ --> SD --> INT
    INT -->|"feature / research"| RES
    INT -->|"plan phase"| PLN
    INT -->|"validate phase"| VAL
    INT -->|"execute phase"| EXE
    EXE -.->|"EVL"| TST
    INT -->|"update phase"| UPD
    RES --> MON
    PLN --> MON
    VAL --> MON
    TST --> MON
    UPD --> MON

    style REQ fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style SD fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style INT fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style RES fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PLN fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style VAL fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style EXE fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style TST fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style UPD fill:#00695C,stroke:#004D40,color:#FFFFFF
    style MON fill:#37474F,stroke:#263238,color:#FFFFFF

यह क्यों मायने रखता है: एक agent जो decide भी कर सकता है और चुपचाप edit भी, plan skip करने के तरीके ढूंढ लेगा। Coordinator को workers (sub-agents) से अलग करके, process structurally honest बन जाता है — code लिखने का एकमात्र तरीका required steps से गुज़रना है।

📊 RIPER-5 जीवनचक्र

📝 SPEC अपना अलग चरण क्यों है: अधिकांश प्रणालियाँ "समझना" से सीधे "डिज़ाइन करना" पर कूद जाती हैं। एक उत्पाद-खोज SPEC चरण जोड़ने से आप (या आपके उत्पाद प्रबंधक) यह तय करते हैं कि क्या बनाया जा रहा है — सरल उपयोगकर्ता कहानियों और स्वीकृति मापदंडों में — एजेंट कैसे करें यह बहस करने से पहले। किसी गलतफहमी को पकड़ने का यह सबसे सस्ता मौका है। (किसी चरण कार्यक्रम के आंतरिक लूप में SPEC छोड़ दिया जाता है — छाता SPEC सभी चरणों पर लागू होता है।)

SPEC मापने की छड़ी है। यह अपेक्षित व्यवहार को सरल शब्दों में बताता है जिसे आप एक मिनट में देख सकते हैं। इसके बाद का हर चरण — Innovate, Plan, Validate, Execute — इसके विरुद्ध जाँचता है और वही सवाल पूछता है: क्या हम जो बना रहे हैं वह वास्तव में वही है जो आपने माँगा था? जब काम भटकने लगता है, SPEC ही उसे पकड़ता है।

flowchart TD
    U["आप: जो मैं वास्तव में चाहता हूँ<br>(सरल शब्दों में)"] --> S["📝 SPEC<br>अपेक्षित व्यवहार + स्वीकृति<br>मापदंड — आप अनुमोदित करते हैं"]
    S --> I["💡 INNOVATE"]
    S --> P["📋 PLAN"]
    S --> V["✅ VALIDATE"]
    S --> E["⚡ EXECUTE"]
    I -.->|"check back"| Q{"क्या यही है जो<br>आपने माँगा था?"}
    P -.->|"check back"| Q
    V -.->|"check back"| Q
    E -.->|"check back"| Q
    Q -->|yes| GO["keep building"]
    Q -->|no| S

💻 उदाहरण सत्र

# 🆕 Feature request
You: "add webhook support to the API"
→ Skill discovery surfaces: vc-scenario, vc-security
→ research-agent gathers context (read-only, can't touch code)
→ "go" → spec-agent writes requirements doc → you approve
→ "go" → innovate-agent compares approaches → decision summary
→ "go" → plan-agent writes the plan, listing which files it will touch
→ "ENTER VALIDATE MODE" → validate-agent gates the plan (PVL loop) → Gate: PASS
→ "ENTER EXECUTE MODE" → execute-agent implements → tester re-runs gates (EVL) → reviewer → git-manager
→ Closeout packet: what changed, what's verified, recommended next step

# 🐛 Bug fix
You: "login redirect is broken"
→ Routes to vc-debugger → gathers evidence FIRST → 2-3 competing hypotheses
→ Systematically eliminates each → root cause with proof chain
→ execute-agent implements the fix → EVL re-test → quality pipeline

# ⏩ Fast mode
You: "ENTER FAST MODE - add rate limiting middleware"
→ Compressed RESEARCH + SPEC + INNOVATE + PLAN + VALIDATE in one pass
→ Mandatory safety pause after VALIDATE → you review → "ENTER EXECUTE MODE"

# 🤖 Autopilot (hands-free)
You: "autopilot full: build a notifications system"
→ ONE consolidated clarification round → provisional /goal block (standing consent)
→ Drives the full RIPER-5 sequence autonomously, pausing only on hard stops

# 🏗️ Large program
You: "build a full testing platform"
→ Umbrella plan + phase plans in a feature folder
→ Each phase inner loop: research → innovate → plan → PVL → execute → EVL → update
→ Progress survives context compaction — durable reports on disk

🎯 इरादे का स्पष्टीकरण

रूटिंग से पहले, मुख्य एजेंट आपके अनुरोध की अस्पष्टता को 4 द्विआधारी संकेतों (0–4) पर मापता है और एक स्तर चुनता है। यह सवाल केवल तभी पूछता है जब वे वास्तव में इसकी कार्रवाई बदल देंगे।

🧠 अधिकतम दो दौर। यदि Tier 2 के बाद भी अस्पष्ट रहे, तो एक अंतिम सरल प्रश्न पूछता है, फिर सबसे संकीर्ण उचित दायरे के साथ रिसर्च पर डिफ़ॉल्ट करता है। यह स्पष्टीकरण को कभी अनंत लूप में नहीं डालता। RESEARCH के बाद, इरादे की फिर से जाँच होती है — यदि रिसर्च दिखाती है कि अनुरोध जो माना गया था उससे अलग था, तो वह फिर प्रस्तुत करता है; यदि पुष्टि हो, तो दोबारा पूछे बिना आगे बढ़ता है।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    REQ["User request"]
    SCORE{"ambiguity score\n0–4 binary signals"}
    AUTO["Auto-skip conditions\n(go / continue / mid-phase\n/ trivial / explicit mode\n/ resuming plan / pure info)"]
    T0["Tier 0\nsilent auto-route\n(score 0–1 OR auto-skip)"]
    T1["Tier 1\ninline summary\n(score 2)"]
    T2["Tier 2\nask focused questions\n(score 3+)"]
    ROUTE["Route to matching agent\n(research / plan / execute / …)"]
    STILL{"still unclear\nafter Tier 2?"}
    FINAL["One final plain question\n(max 2 clarification rounds)"]
    NARROW["Default: vc-research-agent\nnarrowest reasonable scope"]

    REQ --> AUTO
    AUTO -->|"auto-skip matches"| T0
    AUTO -->|"no auto-skip"| SCORE
    SCORE -->|"0–1"| T0
    SCORE -->|"2"| T1
    SCORE -->|"3+"| T2
    T0 --> ROUTE
    T1 --> ROUTE
    T2 --> STILL
    STILL -->|"resolved"| ROUTE
    STILL -->|"still unclear"| FINAL --> NARROW

    style REQ fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style AUTO fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style SCORE fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style T0 fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style T1 fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style T2 fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style ROUTE fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style STILL fill:#F57F17,stroke:#F9A825,color:#000000
    style FINAL fill:#AD1457,stroke:#880E4F,color:#FFFFFF
    style NARROW fill:#00695C,stroke:#004D40,color:#FFFFFF

✅ दो गुणवत्ता लूप — PVL + EVL

अधिकांश प्रणालियाँ एक बार जाँचती हैं, यदि बिल्कुल करती हैं। यह प्रणाली EXECUTE को दो स्वतंत्र लूप में लपेटती है — एक कोड लिखे जाने से पहले, एक बाद में।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '15px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    PLAN["📋 PLAN written"]
    PVL{"✅ PVL\nValidate the plan\nV1–V7 gates"}
    PASS["Gate: PASS"]
    SUPP["📝 plan-agent supplements\n(addresses gaps)"]
    EXEC["⚡ EXECUTE\nimplement the plan"]
    EVL{"🧪 EVL\ntester re-runs the\nvalidate-contract gates"}
    FIX["⚡ execute-agent\nsupplement (fix gate)"]
    DONE["🧠 UPDATE PROCESS"]

    PLAN --> PVL
    PVL -->|"CONDITIONAL / BLOCKED"| SUPP
    SUPP -->|"re-run from V1"| PVL
    PVL -->|"PASS"| PASS
    PASS -->|"ENTER EXECUTE"| EXEC
    EXEC --> EVL
    EVL -->|"gate fails"| FIX
    FIX -->|"re-run"| EVL
    EVL -->|"all gates green"| DONE

    style PLAN fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PVL fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style PASS fill:#00695C,stroke:#004D40,color:#FFFFFF
    style SUPP fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style EXEC fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style EVL fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style FIX fill:#AD1457,stroke:#880E4F,color:#FFFFFF
    style DONE fill:#00695C,stroke:#004D40,color:#FFFFFF

💎 निर्णय की सीढ़ी: PASS → आगे बढ़ें · CONDITIONAL → ठीक करने योग्य खामियाँ; लूप चलता है (या आप उन्हें रिकॉर्ड में स्वीकार करते हैं) · BLOCKED → गहरी समस्या; PLAN पर वापस जाता है (ऑटोपायलट के तहत: खामी बैकलॉग में जाती है और रन जारी रहता है)।

🔁 vc-autoresearch — साझा लूप इंजन

PVL और EVL दोनों एक ही ट्रैकिंग परत का उपयोग करते हैं: vc-autoresearch — एक खामियाँ ढूँढो → ठीक करो → दोहराओ लूप। मुख्य एजेंट लूप चलाता है — यह राउंड काउंटर, प्रति-राउंड रिपोर्ट, TSV लॉग, और पठार/सीमा/प्रतिगमन जाँच का मालिक है। कार्यकर्ता एजेंट एकमुश्त होते हैं: वे परिणाम लौटाते हैं और रुक जाते हैं। कोई भी एजेंट स्वयं को या किसी अन्य चरण एजेंट को दोबारा नहीं बुलाता।

वही इंजन अपने आप भी चल सकता है: "इस स्पेक को मज़बूत करो", "सभी lint ठीक करो", "परीक्षण कवरेज सुधारो", "ये दस्तावेज़ सुधारो" — 6 डोमेन (spec · tests · ux · docs · plan · errors) में कोई भी बार-बार खामियाँ ढूँढो-और-ठीक करो कार्य।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    START["Start loop\n(orchestrator init results.tsv\nheader + baseline row)"]
    FIND["Find gaps\n(validate-agent / tester\nreturns gap list)"]
    RPT["Write iteration report\n{slug}-iteration-{NNN}_REPORT_{dd-mm-yy}.md"]
    TSV["Append results.tsv row\n(cycle N, gap count)"]
    FIX["Fix gaps\n(plan-agent supplement\nOR execute-agent supplement)"]
    CHK["Guard checks\nplateau? cap hit? regression?"]
    RECHECK["Re-check\n(re-run validate / tester)"]
    SUCC["SUCCESS\nall-clear 2 consecutive rounds"]
    HALT["HALT\nplateau / 10-cycle cap / regression"]

    START --> FIND --> RPT --> TSV --> FIX --> CHK
    CHK -->|"safe to continue"| RECHECK
    RECHECK --> FIND
    CHK -->|"plateau / cap / regression"| HALT
    FIND -->|"no gaps found (×2)"| SUCC

    style START fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style FIND fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style RPT fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style TSV fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style FIX fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style CHK fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style RECHECK fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style SUCC fill:#00695C,stroke:#004D40,color:#FFFFFF
    style HALT fill:#B71C1C,stroke:#7F0000,color:#FFFFFF

रुकने की स्थितियाँ: SUCCESS (लगातार दो राउंड सब साफ) · HALT_PLATEAU (3 राउंड तक कोई प्रगति नहीं) · HALT_CAP (10-राउंड की सख्त सीमा) · HALT_REGRESSION (जो जाँच पास हो रही थी अब विफल होती है)।

👥 रणनीति तुलना + मॉडल नीति

हर चरण के बदलाव पर, मुख्य एजेंट vc-agent-strategy-compare को अगले चरण को कैसे चलाएं — लागत अनुमान के साथ — इसकी सिफारिश करने के लिए बुलाता है।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    SS["vc-agent-strategy-compare\n(every phase transition)"]
    SC{"signal score\n0–7"}
    SEQ["Sequential\none agent at a time\n(output feeds next)"]
    PAR["Parallel subagents\nfire-and-forget\n(independent dimensions)"]
    WF["Workflow\nscripted steps\nacross a list"]
    TEAM["Agent team\nTeamCreate + TaskCreate\n+ SendMessage\n(must coordinate mid-run)"]
    MC{"which phase?"}
    OPUS["🔴 opus\n(EXECUTE only)"]
    SONNET["🔵 sonnet\n(every other phase)"]

    SS --> SC
    SC -->|"low / dependent"| SEQ
    SC -->|"mid / independent"| PAR
    SC -->|"predictable split"| WF
    SC -->|"high / must coordinate\nor 3+ phase plans"| TEAM
    SS --> MC
    MC -->|"EXECUTE / fast-mode\nquick-fix (real code)"| OPUS
    MC -->|"Research / Spec\nInnovate / Plan\nValidate / Update\nall reviewers"| SONNET

    style SS fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style SC fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style SEQ fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PAR fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style WF fill:#00695C,stroke:#004D40,color:#FFFFFF
    style TEAM fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style MC fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style OPUS fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style SONNET fill:#37474F,stroke:#263238,color:#FFFFFF

⚠️ "Agent team" का मतलब असली मशीनरी है — नामित साथी, एक साझा कार्य सूची, और इंटर-एजेंट संदेशन — न कि केवल समानांतर एजेंट जिन्हें "टीम" कहा जाए। यह 3+ चरण योजनाएं बनाने और बहु-फ़ाइल संपादन के लिए आवश्यक है (वैकल्पिक नहीं) जहाँ एजेंटों को प्रत्येक अपनी फ़ाइलों में रहना होता है। केवल एक सच्ची टीम ही चलते समय संवाद कर सकती है।

🧮 मॉडल चयन नीति

जब काम कई एजेंटों में विभाजित हो, केवल कोडिंग एजेंट opus का उपयोग करता है। हर समीक्षक, शोधकर्ता, सत्यापनकर्ता, और योजनाकार sonnet का उपयोग करता है। मुख्य एजेंट हर बार कार्यकर्ता बुलाते समय मॉडल का नाम बताता है।

🤖 ऑटोपायलट मोड — हैंड्स-फ्री RIPER-5

autopilot [task] कहें (या run autopilot, autonomous mode, ENTER AUTOPILOT MODE) और एजेंट शुरुआत में एक स्पष्टीकरण दौर के साथ पूरी शेष RIPER-5 अनुक्रम चलाता है — फिर पूरा होने तक कोई रुकावट नहीं।

कहीं से भी ट्रिगर करें: ऑटोपायलट सत्र की शुरुआत में या किसी भी बिंदु पर बीच में शुरू हो सकता है। ट्रिगर पर, मुख्य एजेंट डिस्क पर सहेजी गई फ़ाइलें पढ़ता है यह जानने के लिए कि आप पहले से किस RIPER-5 चरण में हैं, फिर वहीं से उठाता है और बाकी खुद चलाता है।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    TRG["autopilot trigger phrase\n(anywhere in session)"]
    DISK["Read saved files on disk\ndetect current phase"]
    CLR["ONE consolidated\nclarification round"]
    GOAL["Emit provisional /goal block\n(≤4000 chars, copy-pasteable\nstanding EXECUTE consent)"]
    ACT["AUTOPILOT_ACTIVATED\nautonomous run begins"]
    PHASES["Drive remaining phases\nRESEARCH → … → UPDATE PROCESS\n(no user pauses)"]
    HS1["🛑 Irreversible / outward action\nnot pre-approved"]
    HS2["⛔ Cascade BLOCKED\n(several phases stuck)"]
    HS3["💸 Live-provider billed probe\n(double opt-in required)"]
    DONE["Run complete\nautopilot deactivates"]

    TRG --> DISK --> CLR --> GOAL --> ACT --> PHASES
    PHASES -->|"hard stop 1"| HS1
    PHASES -->|"hard stop 2"| HS2
    PHASES -->|"hard stop 3"| HS3
    PHASES -->|"all phases done"| DONE

    style TRG fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style DISK fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style CLR fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style GOAL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style ACT fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style PHASES fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style HS1 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
    style HS2 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
    style HS3 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
    style DONE fill:#00695C,stroke:#004D40,color:#FFFFFF

You: "autopilot full: add team invitations with email + role management"
→ Reads saved files → detects current phase → enters there
→ ONE consolidated clarification round (scope, hard stops, autonomy boundaries, first-phase strategy)
→ Provisional /goal block emitted (≤4000 chars, copy-pasteable, standing EXECUTE consent)
→ AUTOPILOT_ACTIVATED → drives remaining phases on its own
→ Stops ONLY for hard stops

तीन लेन — जोखिम के अनुसार प्रक्रिया चुनें

🌙 हैंड्स-फ्री: एक वाक्य, सोते समय काम

autopilot full: [task] कहें — या /goal ब्लॉक पेस्ट करें — और निम्नलिखित सब बिना किसी मानवीय इनपुट के होता है:

• योजना-जाँच-और-सुधार लूप — योजना में खामियाँ ढूँढता है, उन्हें ठीक करता है, और फिर से जाँचता है। अपने आप 10 राउंड तक।
• बनाओ-परीक्षण करो-और-ठीक करो लूप — कोड लिखता है, परीक्षण चलाता है, विफलताओं को ठीक करता है, फिर से चलाता है। अपने आप 10 राउंड तक। यह कभी अपने "सब हरा" पर भरोसा नहीं करता — एक अलग जाँचकर्ता (vc-tester) पुष्टि के लिए स्वतंत्र रूप से हर परीक्षण फिर से चलाता है।
• चरण-से-चरण प्रगति — रिसर्च से योजना से कोड से पूरा तक बिना आपका इंतज़ार किए आगे बढ़ता है।
• मेमोरी रीसेट के बाद उठाता है — योजनाएं, रिपोर्ट, और प्रगति सभी डिस्क पर फ़ाइलों के रूप में हैं। संकुचन (जब AI की अल्पकालिक मेमोरी साफ होती है) के बाद, अगला सत्र उन फ़ाइलों को पढ़ता है और ठीक वहीं से जारी रहता है।
• अटकी हुई सुविधा? अलग रखें, आगे बढ़ते रहें — यदि एक चरण हल नहीं हो सकता, तो एजेंट एक बैकलॉग नोट लिखता है और अगली सुविधा पर आगे बढ़ता है। आप एक ब्लॉकर से सब कुछ रोके बिना कई सुविधाएं समानांतर में चला सकते हैं।
• समानांतर सुविधाओं के लिए एजेंटों की टीम — कई एजेंट एक ही समय में अलग-अलग सुविधाएं बना सकते हैं, प्रत्येक अपनी फ़ाइलों तक सीमित ताकि वे कभी टकराएं नहीं। अटकी सुविधा रोक दी जाती है, बाकी के लिए ब्लॉकर नहीं।

हार्ड स्टॉप हमेशा सामने आते हैं (ऑटोपायलट पर भी)

ये केवल तीन बार हैं जब यह रुककर आपसे पूछता है:

• 🛑 कुछ भी जो वापस न किया जा सके, या जो बाहरी दुनिया तक पहुँचे और पहले से अनुमोदित न हो (लाइव जाना, असली संदेश भेजना, पैसे चार्ज करना)
• ⛔ लगातार कई चरण बिना किसी प्रगति के अटक जाते हैं — एक वास्तविक गतिरोध जो आपकी नज़र का हकदार है
• 💸 एक परीक्षण जो किसी भुगतान वाली बाहरी सेवा पर असली पैसे खर्च करेगा — चलाने से पहले पूछता है

🎯 /goal — स्वायत्त रन टोकन

आवश्यक, सजावट नहीं: हर VALIDATE चरण पूरा होने के बाद, मुख्य एजेंट को EXECUTE शुरू होने से पहले एक कॉपी-करने योग्य /goal ब्लॉक देना होगा। यह एक आवश्यक हैंडऑफ़ फ़ाइल है — वैकल्पिक टिप्पणी नहीं।

प्रारूप बाधाएं:

/goal कमांड 4000 अक्षरों से लंबे ब्लॉक अस्वीकार करता है। इसे संक्षिप्त रखें — आवश्यक फ़ील्ड को संरचना के रूप में उपयोग करें, गद्य निबंध नहीं।

स्वतंत्र /goal मोड: एक /goal ब्लॉक को नए सत्र में पेस्ट करें और रन START में नामित चरण से उठाता है। स्पष्टीकरण और निर्णय नियम पहले से निर्धारित हैं — कोई नया स्पष्टीकरण दौर नहीं। एक स्थायी /goal के तहत, एजेंट हर प्रतिवर्ती चरण पर स्वयं निर्णय लेता है, BLOCKED आइटम बैकलॉग में भेजता है, और अपनी रिपोर्ट लिखता है — लेकिन कार्यकर्ता एजेंट प्रतिनिधित्व अनिवार्य रहता है। ऑटोपायलट केवल अनुमोदन विराम हटाता है, no-inline-execution नियम कभी नहीं।

validate-autopilot-goal-block.mjs द्वारा सत्यापित।

🔬 व्यवहार्यता जाँच + सत्यापनकर्ता सुरक्षा जाल

🔬 व्यवहार्यता जाँच — बनाने से पहले धारणा का परीक्षण करें

जब SPEC, INNOVATE, या VALIDATE किसी मुख्य धारणा से टकराती है जिसे वह केवल पढ़कर पुष्टि नहीं कर सकती, तो वह VC-FEASIBILITY-PROBE-NEEDED भेजती है और रुक जाती है। मुख्य एजेंट vc-debugger को एक वास्तविक परीक्षण चलाने और एक VERDICT लिखने के लिए बुलाता है:

प्रत्येक निर्णय के साथ 3-भाग का डिज़ाइन नोट आता है: परिणाम क्या अनुमति देता है · क्या नकारता है · क्या अभी भी अनिश्चित है — शब्द-दर-शब्द रुके हुए चरण में वापस डाला जाता है। जाँच लागत-वर्गीकृत हैं (cheap-local / needs-container / needs-live-provider → दोहरी सहमति / needs-browser / needs-cf) ताकि कोई भुगतान या साझा-संसाधन जाँच चुपचाप न चले।

🛡️ 36 सत्यापनकर्ता — यांत्रिक सटीकता, राय नहीं

किट 36 सत्यापनकर्ता स्क्रिप्ट के साथ आती है जो "क्या एजेंट ने नियमों का पालन किया?" को स्पष्ट पास/फेल परिणाम में बदलती है। ये किसी भी चरण के बाद चलती हैं जो हार्नेस फ़ाइलें छूता है, और UPDATE PROCESS में आवश्यक जाँच बिंदुओं के रूप में:

🛡️ अंतर्निहित सुरक्षा प्रणालियाँ

ये दिशानिर्देश नहीं हैं — ये सख्त नियम हैं जो हर एजेंट में बने हुए हैं।

🔍 कार्यान्वयन-पूर्व बुद्धिमत्ता

कोड की एक भी पंक्ति लिखे जाने से पहले, तीन विशेषज्ञ कौशल समस्याएं पकड़ सकते हैं:

✅ गुणवत्ता पाइपलाइन — निष्पादन में अंतर्निहित

पहले परीक्षण, फिर कोड। सहमत चेकलिस्ट (किसी कोड को छूने से पहले लिखी गई) सटीक परीक्षण परिभाषित करती है जो पास होने चाहिए। execute-agent तब तक कोड लिखता है जब तक वे परीक्षण हरे न हों। फिर एक अलग जाँचकर्ता — vc-tester — पुष्टि के लिए अपने आप हर परीक्षण फिर से चलाता है। execute-agent का अपना "सब हरा" कभी सच नहीं माना जाता। अंत में, समीक्षक जाँचता है कि पूरा प्रोजेक्ट अभी भी एक साथ काम करता है, न केवल नया टुकड़ा।

execute-agent केवल कोड नहीं लिखता और पूरा नहीं बोलता। यह स्वतः एक गुणवत्ता पाइपलाइन से गुज़रता है:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '16px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    E["⚡ Execute-Agent\nImplements the plan"]
    SR["🔎 Self-Review\nLine-by-line check\nagainst plan"]
    T["🧪 Tester (EVL)\nDiff-aware — re-runs\nthe contract gates"]
    CR["🔍 Code Reviewer\nEdge case scout\n+ adversarial review"]
    CS["✨ Code Simplifier\nClarity refactoring"]
    GM["📦 Git Manager\nLogical commit splitting\nfrom touched_files"]

    E --> SR --> T --> CR --> CS --> GM

    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style SR fill:#AD1457,stroke:#880E4F,color:#FFFFFF
    style T fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style CR fill:#283593,stroke:#1A237E,color:#FFFFFF
    style CS fill:#00695C,stroke:#004D40,color:#FFFFFF
    style GM fill:#37474F,stroke:#263238,color:#FFFFFF

📋 योजना का जीवन-चक्र

हर महत्वपूर्ण फ़ीचर एक योजना-जीवन-चक्र से गुज़रता है — एक लिखित विनिर्देशन जो बनाई जाती है, समीक्षा की जाती है, उसके अनुसार काम किया जाता है, और फिर स्थायी परियोजना इतिहास के रूप में संग्रहीत की जाती है।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '16px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    A["🆕 Feature Request"]
    B["📝 Plan Created\nin active/{slug}_{date}/"]
    C{"👀 User Reviews\nthe Plan"}
    D["✅ VALIDATE\n(PVL gates)"]
    E["⚡ Execute + EVL"]
    F["📦 Plan Archived\nto completed/"]
    G["🧠 Learnings →\nall-context.md"]
    H["🔄 Next Feature\nStarts Smarter"]

    A --> B --> C
    C -->|"✏️ Needs Changes"| B
    C -->|"✅ Approved"| D --> E --> F --> G --> H
    H -.->|"context compounds"| A

    style A fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style B fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style C fill:#F57F17,stroke:#F9A825,color:#000000
    style D fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style F fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style G fill:#00695C,stroke:#004D40,color:#FFFFFF
    style H fill:#1565C0,stroke:#0D47A1,color:#FFFFFF

💡 छह महीने बाद, जब कोई पूछे "हमने auth इस तरह क्यों बनाया?" — जवाब completed/ में मिलेगा। Slack के किसी पुराने धागे में खोना नहीं पड़ेगा।

योजनाएँ कहाँ रहती हैं — टास्क-फ़ोल्डर नियम:

process/
├── general-plans/
│   ├── active/
│   │   └── webhooks_28-05-26/          # 📋 Task folder: plan + colocated reports/refs
│   │       └── webhooks_PLAN_28-05-26.md
│   ├── completed/                       # ✅ Archived (searchable history)
│   └── backlog/                         # 📌 Deferred work
└── features/
    └── billing/                         # 🏷️ Feature-scoped (5+ artifacts)
        ├── active/{slug}_{date}/
        ├── completed/
        └── backlog/

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    PC["vc-plan-agent creates task folder\nprocess/general-plans/active/{slug}_{date}/\nOR features/{feature}/active/{slug}_{date}/"]
    PLAN["{slug}_PLAN_{dd-mm-yy}.md\n— plan file\n— Validate Contract appended here"]
    REF["{slug}_REF_{dd-mm-yy}.md\n— optional references"]
    RPT["{slug}-iteration-{NNN}_REPORT_{dd-mm-yy}.md\n— per PVL/EVL cycle report"]
    TSV["results.tsv\n— rolling loop log\n(header + baseline + cycle rows)"]
    PP["PHASE PROGRAM extras"]
    UMB["umbrella_PLAN_{dd-mm-yy}.md\n— Program Goal Charter\n— /goal block"]
    PHN["phase-N_PLAN_{dd-mm-yy}.md\n— one file per phase"]
    REG["phase-blast-radius-registry.md\n— per-phase file ownership"]

    PC --> PLAN
    PC --> REF
    PC --> RPT
    PC --> TSV
    PC --> PP
    PP --> UMB
    PP --> PHN
    PP --> REG

    style PC fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style PLAN fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style REF fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style RPT fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style TSV fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style PP fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style UMB fill:#00695C,stroke:#004D40,color:#FFFFFF
    style PHN fill:#00695C,stroke:#004D40,color:#FFFFFF
    style REG fill:#37474F,stroke:#263238,color:#FFFFFF

हर योजना में होता है: 📍 संपर्क-बिंदु (बनाई/बदली गई फ़ाइलें) · 📜 सार्वजनिक अनुबंध · 💥 कौन-सी फ़ाइलें छू सकती है (क्या टूट सकता है, क्या परखना है) · ✅ सत्यापन प्रमाण · 🔄 कार्य-पुनः-शुरू करने की जानकारी। vc-plan-discovery सही योजना खोजता है; post-write-plan-check हर योजना-लेखन पर संरचना जाँचता है।

🏗️ फ़ेज़ प्रोग्राम — बड़े प्रोजेक्ट जो बिखरते नहीं

सामान्य फ़ीचर के लिए एक योजना काफ़ी है। बड़े बहु-चरण प्रोजेक्ट के लिए एक फ़ेज़ प्रोग्राम होता है — एक छाता-योजना और प्रति-चरण अलग योजनाएँ, जिनमें से हर एक पूरे 7-चरणीय आंतरिक लूप से गुज़रती है — अपने स्वयं के चेकपॉइंट और सहेजी गई रिपोर्ट के साथ।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    UP["🎯 Umbrella Plan\nProgram Goal Charter\n(north star · done · scope tiers)"]
    P1["📋 Phase 1"]
    P2["📋 Phase 2 ..."]

    subgraph LOOP["🔁 Per-phase inner loop (skips SPEC)"]
        direction TB
        R["🔍 Research"]
        I["💡 Innovate"]
        PL["📋 Plan-supplement"]
        PVL["✅ PVL"]
        EX["⚡ Execute"]
        EVL["🧪 EVL"]
        UPD["🧠 Update"]
        R --> I --> PL --> PVL --> EX --> EVL --> UPD
    end

    UP --> P1 --> LOOP
    LOOP -.->|"learnings feed\nnext phase"| P2

    style UP fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style P1 fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style P2 fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style R fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style I fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style PL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style PVL fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style EX fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style EVL fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style UPD fill:#00695C,stroke:#004D40,color:#FFFFFF

🔀 प्रोग्राम खुद को सीखते हुए बदलता है

शुरुआत में लिखी योजना एक मोटा नक्शा है, पक्का अनुबंध नहीं। जैसे-जैसे प्रोग्राम चलता है, वह खुद को समायोजित करता है — ताकि आपको हर कदम पहले से न सोचना पड़े।

यह काम के बीच में नया चरण जोड़ सकता है। काम करते समय एजेंट एक ज़रूरी कदम खोज सकता है — कुछ ऐसा जो अगले चरण से पहले होना ज़रूरी है। ऐसे में वह वहीं एक नया चरण जोड़ता है, बाकी को पुनः क्रमांकित करता है, और आगे बढ़ता है। किसी इंसान की ज़रूरत नहीं। (आंतरिक संकेत: MID_PROGRAM_PLAN_CREATED — नई योजना डिस्क पर लिखी जाती है और रजिस्ट्री में स्वतः जोड़ी जाती है।)

यह चरणों का क्रम बदल सकता है। रिसर्च कभी-कभी दिखाती है कि योजना का क्रम गलत है — जैसे Phase 3 को कुछ ऐसी चीज़ चाहिए जो Phase 4 बनाएगा। एजेंट बचे हुए चरणों को पुनः व्यवस्थित करता है और कारण दर्ज करता है। (आंतरिक संकेत: PHASE_RESTRUCTURE_NOTICE — फ़ेज़ रिपोर्ट में ऑडिट ट्रेल के रूप में सहेजा जाता है, रुकावट नहीं।)

यह कोडिंग से ठीक पहले हर चरण की अपनी योजना अपडेट करता है। किसी भी चरण की कोडिंग शुरू होने से पहले, एक त्वरित रिसर्च पास यह देखता है कि प्रोग्राम ने अब तक क्या सीखा है। फिर उस चरण की जाँच-सूची में नई जानकारी जोड़ता है। इसे plan-supplement चरण कहते हैं। योजनाएँ कभी जमी नहीं रहतीं — वे पहले के चरणों से नई बातें सोखती हैं।

यह वह काम छोड़ देता है जो अभी शुरू नहीं हो सकता। अगर कोई चरण किसी ऐसी चीज़ पर निर्भर है जो अभी तैयार नहीं — कोई सेवा जो बनी नहीं, कोई निर्णय जो हुआ नहीं — तो एजेंट उस चरण को dependency-blocked चिह्नित करता है, अलग रखता है, और अगले पर बढ़ता है। एक चरण के इंतज़ार में पूरा प्रोग्राम नहीं रुकता।

यह जानता है कब रुककर पूछना है। एक अटका चरण बस बैकलॉग में चला जाता है और प्रोग्राम जारी रहता है। लेकिन अगर कई चरण लगातार बिना प्रगति के दीवार से टकराते हैं, तो एजेंट इसे असली गतिरोध मानता है — एक cascade stop — और रुककर आपको बताता है क्या हुआ। एक अटका चरण सामान्य है। कई लगातार अटके चरण बताते हैं कि कुछ मूलभूत गलत है।

यह एक लाइव स्कोरबोर्ड रखता है। हर प्रोग्राम की छाता-योजना में एक-पेज की स्थिति-अनुभाग होती है — कौन-सा चरण चल रहा है, पूरा हुआ या नहीं, रिपोर्ट कहाँ है। कोई भी — या एजेंट खुद मेमोरी रीसेट के बाद — इसे पढ़ सकता है और ठीक-ठीक जान सकता है कहाँ चीज़ें खड़ी हैं। यह एक सरल फ़ाइल रजिस्ट्री भी रखता है ताकि एक ही समय काम करने वाले दो चरण कभी एक ही फ़ाइल न बदलें।

एक बड़ी अंतिम जाँच। पूरे प्रोग्राम के अंत में, एजेंट एक end-to-end परीक्षण चलाता है कि पूरा प्रोजेक्ट अभी भी मिलकर काम करता है — न सिर्फ़ हर टुकड़ा अपने आप। प्रति-चरण चेकपॉइंट हर हिस्से को सिद्ध करते हैं; यह अंतिम जाँच सिद्ध करती है कि हिस्से एक साथ काम करते हैं।

🧠 यह अपनी जगह कभी नहीं भूलता (मेमोरी रीसेट से बचता है)

लंबे काम सही तरीके से पूरे होते हैं — भले ही AI की मेमोरी बीच में रीसेट हो जाए। योजना, प्रगति, और प्रमाण — सब डिस्क पर फ़ाइलों में रहते हैं, सिर्फ़ एजेंट के दिमाग में नहीं।

AI एजेंट की कार्यशील मेमोरी सीमित होती है। किसी लंबे काम में वह भर जाती है और सिकुड़ जाती है — जानकारी धुंधली हो सकती है। जब नया सत्र शुरू होता है (या मेमोरी साफ होती है), एजेंट अंदाज़ा नहीं लगाता कि वह कहाँ था। वह फ़ाइलें पढ़ता है।

यह ठीक इस तरह काम करता है:

1. हर चरण के बाद एक छोटी रिपोर्ट लिखता है। जब कोई चरण पूरा होता है, एक रिपोर्ट फ़ाइल डिस्क पर लिखी जाती है। प्रगति आपके प्रोजेक्ट फ़ोल्डर में रहती है, सिर्फ़ एजेंट के दिमाग में नहीं। मेमोरी सिकुड़ने से फ़ाइल नहीं मिटती।

2. किन कदमों का काम हुआ, इसकी जाँच-सूची रखता है। हर चरण-योजना में एक Phase Loop Progress सूची होती है — हर कदम के लिए टिक-बॉक्स (रिसर्च, योजना-जाँच, निर्माण, परीक्षण, सीख दर्ज करना)। रीसेट के बाद एजेंट वे बॉक्स पढ़ता है और ठीक अगला कदम जानता है। उसे अपडेट करने की ज़रूरत नहीं।

3. हर चरण की शुरुआत में एक संक्षिप्त "लिफ़ाफ़ा"। हर वर्कर एजेंट (एक केंद्रित सहायक जो काम का एक चरण करता है) शुरू में एक Context Envelope उत्सर्जित करता है — 10 क्षेत्रों की एक नोट: कौन-सा फ़ीचर, कौन-सा चरण, कौन-सी शाखा, कौन-सी योजना-फ़ाइल, कौन-से परीक्षण चलाने हैं। पढ़ने में कुछ सेकंड लगते हैं। कुछ भी करने से पहले एजेंट तैयार हो जाता है।

4. यह फ़ाइलों पर अपनी मेमोरी से ज़्यादा भरोसा करता है। पुनः-शुरू होने पर एजेंट जाँचता है कि कोड और git इतिहास में वास्तव में क्या है बनाम योजना क्या कहती है। असली स्थिति जीतती है। पुरानी पड़ी योजना एजेंट को काम दोहराने या कदम छोड़ने के लिए भ्रमित नहीं कर सकती।

5. एक चलता स्कोरबोर्ड और प्रति-दौर रिपोर्टें। हर फ़िक्स-लूप (योजना-जाँच लूप और निर्माण-परीक्षण लूप) एक results.tsv स्कोरबोर्ड फ़ाइल रखता है — प्रति दौर एक पंक्ति, यह ट्रैक करते हुए कि कितने मुद्दे बचे हैं। जब कोई सत्र लूप के बीच में समाप्त होता है, अगला सत्र गिनती पढ़ता है, सही दौर पर उठाता है, और जारी रखता है। कोई दौर नहीं खोता।

6. पुनः-शुरू होने पर एक अनुस्मारक स्वतः डाला जाता है। जब मेमोरी सिकुड़ती है, सिस्टम स्वतः नवीनतम स्थिति-नोट नए सत्र में फिर से लोड करता है। अगर कोई स्वीकृति लंबित थी — जैसे एक चेकपॉइंट जिसे आगे बढ़ने के लिए "हाँ" चाहिए था — तो अनुस्मारक उसे चिह्नित करता है। कुछ भी चुपके से नहीं छूटता।

💡 संक्षेप में: आप एक autopilot रन शुरू कर सकते हैं, लैपटॉप बंद कर सकते हैं, और घंटों बाद वापस आ सकते हैं। एजेंट ठीक वहाँ होगा जहाँ होना चाहिए — या आखिरी सहेजे चेकपॉइंट से शुरू करेगा, डिस्क पर सबूत के साथ।

🧠 संदर्भ समूह

परियोजना की जानकारी संदर्भ समूहों में व्यवस्थित है — स्थिर ज्ञान-क्षेत्र, जिनमें से प्रत्येक के पास एक all-{group}.md राउटर फ़ाइल है जो एजेंटों को बताती है क्या पढ़ें और कब। एजेंट राउटर का पालन करते हैं, केवल प्रासंगिक चीज़ें लोड करते हैं — हर बार पूरा ज्ञान-भंडार नहीं।

process/context/
├── all-context.md              # 🧭 Root router — architecture, stack, patterns, conventions
├── tests/all-tests.md          # 🧪 Test runners, commands, debugging procedures
├── container/all-container.md   # 🐳 Docker, deployment, infra procedures
├── uxui/all-uxui.md            # 🎨 Components, design tokens, patterns
├── infra/all-infra.md          # 🖥️ Server infrastructure, deployment
└── {your-domain}/all-{domain}.md  # 📚 Any domain with 3+ durable docs (auto-promoted)

किट केवल प्रोटोकॉल बीज भेजती है — आपके संदर्भ समूह आपके प्रोजेक्ट के लिए vc-setup द्वारा बनाए जाते हैं, आपके असली कोड को स्कैन करके। ये एक पैटर्न हैं, तय सूची नहीं।

📁 फ़ीचर फ़ोल्डर

जब किसी विषय में 5 या उससे ज़्यादा फ़ाइलें जमा हो जाती हैं, तो उसे अपना फ़ीचर फ़ोल्डर मिलता है — एक पूर्ण जीवन-चक्र कंटेनर।

process/features/{feature}/
├── active/{slug}_{date}/   # 📋 Plans being worked on (reports/refs colocated)
├── completed/              # ✅ Archived plans (searchable decision history)
└── backlog/                # 📌 Deferred work (agents check before duplicating)

🧱 स्किल परतें

33 स्किल तीन परतों में बँटी हैं। हर SKILL.md फ्रंटमैटर में अपना layer + trigger_keywords घोषित करता है, और एक जनरेटेड कैटलॉग खोज को तेज़ रखता है।

🧠 खुद को बेहतर बनाती परियोजना-स्मृति

हर पूरा हुआ फ़ीचर सीख को वापस संदर्भ प्रणाली में फीड करता है — ज्ञान जमा होता रहता है, रीसेट नहीं होता।

अधिकांश AI-सहायक कोडबेस में इसका उल्टा होता है: हर नया सत्र ठंडे से शुरू होता है। एजेंट वही फ़ाइलें फिर पढ़ता है, वही पैटर्न फिर खोजता है, वही निर्णय फिर लेता है — क्योंकि पिछले सत्र की समझ केवल एक चैट विंडो में जीई। किट का जवाब कोई प्रॉम्प्ट तरकीब नहीं है। यह एक टिकाऊ संदर्भ-फ़ाइल प्रणाली (process/context/) है जिसे हर एजेंट सत्र शुरू में पढ़ता है, हर वैलिडेटर बचाता है, और हर पूरा हुआ फ़ीचर समृद्ध करता है।

छह महीने और कई मेमोरी रीसेट के बाद भी, एजेंट जानता है क्यों आपका auth उस तरह काम करता है — क्योंकि वह ज्ञान डिस्क पर है, रूटेड है, और ऑडिट-योग्य है, किसी मृत सत्र में बंद नहीं।

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    FEAT["Feature ships\n(EXECUTE + EVL complete)"]
    UP["UPDATE PROCESS phase\nvc-update-process-agent"]
    CTX["process/context/ updated\nsmallest relevant file\n+ all-context.md router"]
    AGENT["Next agent spawned\nreads context router\n→ routes to correct group file"]
    BETTER["Better next feature\nno re-discovery, no stale patterns"]
    FEAT --> UP --> CTX --> AGENT --> BETTER
    BETTER -.->|"compounds each feature"| FEAT

    style FEAT fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style UP fill:#00695C,stroke:#004D40,color:#FFFFFF
    style CTX fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style AGENT fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style BETTER fill:#E65100,stroke:#BF360C,color:#FFFFFF

मुख्य तंत्र: process/context/ एक पोर्टेबल, साझा स्मृति के रूप में

process/context/ में विषय-समूहों में व्यवस्थित संरचित ज्ञान है — वास्तुकला निर्णय, कोडिंग नियम, तैनाती चरण, परीक्षण पैटर्न, अवसंरचना तथ्य। चैट इतिहास के विपरीत, यह ज्ञान:

• हर वर्कर एजेंट में जाता है — vc-context-discovery हर स्पॉन्ड एजेंट को उसके काम के लिए सही all-{group}.md राउटर तक रूट करता है, फिर सबसे छोटी प्रासंगिक गहरी फ़ाइल तक। एक रिसर्च एजेंट, एक योजना एजेंट, और एक कोडिंग एजेंट सभी एक ही साझा समझ से शुरू होते हैं
• मेमोरी रीसेट से बचता है — यह डिस्क पर है, context window में नहीं; एक सिकुड़ा सत्र इसमें से कुछ नहीं खोता
• Claude और Codex दोनों पढ़ सकते हैं — .agents/skills .claude/skills/ का शॉर्टकट लिंक है, इसलिए वही संदर्भ प्रणाली दोनों एजेंटों को डुप्लीकेशन के बिना सेवा देती है

रूट राउटर (all-context.md) समूह राउटरों (all-{group}.md) की ओर इशारा करता है, जो सबसे छोटी प्रासंगिक गहरी फ़ाइल तक रूट करते हैं। एजेंट राउटर का पालन करते हैं — वे फ़ाइल पथ हार्डकोड नहीं करते। इसका मतलब है कि नाम बदलने और समूह विभाजन के लिए केवल राउटर संपादन की ज़रूरत होती है, पूरे कोडबेस में खोज की नहीं।

process/context/
├── all-context.md                  ← root router (architecture, stack, patterns)
├── tests/all-tests.md              ← test runners, debugging, commands
├── container/all-container.md      ← Docker, deployment, infra procedures
├── uxui/all-uxui.md                ← components, design tokens, visual conventions
└── {domain}/all-{domain}.md        ← any domain with 3+ durable docs (auto-promoted)

इसे खुद-बेहतर बनाने वाला क्या बनाता है ("जीवित दस्तावेज़" से अलग)

"जीवित दस्तावेज़" का मतलब आमतौर पर होता है "दस्तावेज़ जिन्हें हम अपडेट रखने का इरादा रखते हैं लेकिन ज़्यादातर भूल जाते हैं।" यह प्रणाली इरादे को यांत्रिक रूप से लागू करती है।

UPDATE PROCESS चरण को बंद होने से पहले प्रति-फ़ाइल संदर्भ समीक्षा चाहिए। vc-update-process-agent कोई चरण तब तक पूरा नहीं कर सकता जब तक हर संभावित-प्रभावित संदर्भ फ़ाइल की प्रति-फ़ाइल ठोस कारण के साथ समीक्षा न हो। "कोई अपडेट ज़रूरी नहीं" की अनुमति है — लेकिन इसे हर समीक्षित फ़ाइल का नाम और क्यों का स्पष्टीकरण देना होगा। अस्पष्ट कारण अस्वीकार किए जाते हैं। चेकपॉइंट बाइनरी है: समीक्षा दर्ज करें, या चरण बंद नहीं होगा।

हर पूरे हुए फ़ीचर के लिए पूरी फीडबैक लूप:

आपका 100वाँ फ़ीचर पहले 99 में सीखी हर चीज़ से लाभान्वित होता है — आकांक्षा के रूप में नहीं, बल्कि एक यांत्रिक गारंटी के रूप में।

आगे की झलक: सीख पीछे नहीं, आगे भी जाती है

हर चरण रिपोर्ट में एक ## Forward Preview अनुभाग होता है जो अगले चरण के एजेंट के लिए लिखा गया है। यह उन्हें सटीक कमांड देता है जो हरी रखनी हैं, निर्भरता बदलाव, और चरण के बीच मिली फ़ाइल-दायरे की जानकारी। Phase 3 उठाने वाले एजेंट को Phase 2 का पूरा आउटपुट फिर से पढ़कर अंदाज़ा नहीं लगाना पड़ता। उसे एक केंद्रित ब्रीफ दी जाती है।

यह संदर्भ दस्तावेज़ों से अलग है: संदर्भ दस्तावेज़ स्थायी ज्ञान रखते हैं (निर्णय जो फ़ीचर के पार सच रहते हैं); Forward Preview अस्थायी हैंडऑफ़ स्थिति रखता है (अगले कार्य-सत्र को अभी क्या जानना है)।

वैलिडेटर सूट सड़न रोकती है

स्थायी ज्ञान पुराना पड़ जाता है जब कोई जाँचता नहीं। किट ऐसे वैलिडेटर भेजती है जो हर चरण बंद होने पर चलते हैं:

ये स्वचालित जाँच की तरह चलते हैं — एक पुराना या अनाथ दस्तावेज़ फेल होता है। सिस्टम अपनी सेहत खुद जाँचता है।

संदर्भ समूह खुद व्यवस्थित होते हैं

जब कोई विषय 3+ दस्तावेज़ों तक पहुँचता है या एकल फ़ाइल ~800 पंक्तियों से बड़ी हो जाती है, तो समूह स्वतः बनते हैं। एजेंट राउटर का पालन करते हैं और पथ हार्डकोड नहीं करते — इसलिए नया समूह जोड़ना (जैसे process/context/billing/all-billing.md) केवल राउटर अपडेट चाहता है, billing का उल्लेख करने वाले हर एजेंट में बदलाव नहीं। राउटर स्थिर संदर्भ है; उसके पीछे की फ़ाइलें स्वतंत्र रूप से पुनर्गठित हो सकती हैं।

किट आपके असली कोडबेस से संदर्भ समूह तैयार करती है (vc-setup के ज़रिए)। समूह तय सूची नहीं हैं — ये एक पैटर्न हैं। जैसे-जैसे प्रोजेक्ट बढ़ता है, आपका auth क्षेत्र, infra क्षेत्र, payments क्षेत्र — सभी प्रथम-श्रेणी रूटेबल ज्ञान बन जाते हैं।

🤖 अंदर क्या है

15 Agents

33 Skills (स्वतः-खोजे जाते हैं)

⚠️ नामकरण नियम: अपनी स्किल या एजेंट के लिए vc- उपसर्ग का उपयोग न करें — वह नेमस्पेस किट-भेजी फ़ाइलों के लिए आरक्षित है, और पुराने-हटाने का गार्ड .claude/skills/ और .claude/agents/ के तहत किसी भी vc-* पथ को किट-स्वामित्व मानता है। इसके बजाय my-, team-, या proj- उपयोग करें।

🪝 10 Hooks

सब कुछ कहाँ रहता है:

your-project/
├── .claude/{agents,skills,hooks}/   # 🤖 15 agents · ⚡ 33 skills · 🪝 10 hooks
├── .codex/agents/                   # 🔄 Mirrored for Codex
├── .agents/skills -> .claude/skills # 🔗 Symlink for Codex discovery
├── CLAUDE.md · AGENTS.md            # 📋 Orchestrator config + cross-tool registry
└── process/
    ├── context/                     # 🧠 Auto-routed knowledge domains
    ├── general-plans/               # 📋 Cross-cutting plans + task folders
    ├── features/                    # 🏷️ Feature-scoped lifecycle folders
    └── development-protocols/       # 📜 22 shared workflow docs

⚡ Quick Fix + Fast Mode

दो हल्के विकल्प जब पूरा RIPER-5 प्रोसेस काम से ज़्यादा लग रहा हो:

🔄 किट जीवन-चक्र: Install · Setup · Update · Publish

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
    TRG["EXECUTE complete\nENTER UPDATE PROCESS MODE"]
    AGT["spawn vc-update-process-agent"]
    A["(a) Archive plan\nactive/ → completed/"]
    B["(b) Update process/context/\nsmallest relevant file\n+ all-context.md router"]
    C["(c) Tier-1 audits\n(change-type gated)"]
    AVC["vc-audit-vc\nharness/agent edits"]
    ACX["vc-audit-context\ncontext-doc edits"]
    APL["vc-audit-plans\nplan/program edits"]
    D["(d) Capture learnings\nto memory"]
    E["(e) Write closeout packet\nvc-generate-closeout"]
    F["(f) Conventional commit\nvc-git-manager"]

    TRG --> AGT --> A --> B --> C
    C --> AVC
    C --> ACX
    C --> APL
    AVC --> D
    ACX --> D
    APL --> D
    D --> E --> F

    style TRG fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
    style AGT fill:#0277BD,stroke:#01579B,color:#FFFFFF
    style A fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
    style B fill:#00695C,stroke:#004D40,color:#FFFFFF
    style C fill:#E65100,stroke:#BF360C,color:#FFFFFF
    style AVC fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style ACX fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style APL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
    style D fill:#558B2F,stroke:#33691E,color:#FFFFFF
    style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
    style F fill:#37474F,stroke:#263238,color:#FFFFFF

💡 vc-update एक preview diff दिखाता है और आपकी OK का इंतज़ार करता है। आपका process/ directory और प्रोजेक्ट-विशिष्ट सामग्री कभी चुपके से नहीं बदली जाती। install दोबारा चलाना सुरक्षित है।

💡 और कारण यह बस काम करता है

कई छोटे, स्मार्ट डिफ़ॉल्ट मिलकर कम निगरानी और कम लागत बनाते हैं।

• हर भूमिका को केवल वही उपकरण मिलते हैं जो उसे चाहिए। योजना बनाते समय एजेंट शाब्दिक रूप से कोड संपादित नहीं कर सकता — वे उपकरण बंद हैं। यह एजेंट को आगे कूदकर योजना मंजूर होने से पहले चीज़ें बदलने से रोकता है। सिस्टम बस इसकी अनुमति नहीं देता।

• यह premium AI model केवल वहाँ उपयोग करता है जहाँ ज़रूरी है। कोड लिखने में शीर्ष model उपयोग होता है। योजना, रिसर्च, समीक्षा, और जाँच — सभी में एक सस्ता, तेज़ model। परिणाम: सब कुछ के लिए शीर्ष model चलाने की तुलना में लगभग 60–70% कम लागत — उस काम में कोई गुणवत्ता हानि नहीं जो मायने रखता है।

• यह निर्माण से पहले जोखिम भरे अनुमानों का परीक्षण करता है। जब एजेंट को यकीन न हो कि कुछ काम करेगा — एक विशिष्ट API व्यवहार, एक लाइब्रेरी फ़ीचर, एक अवसंरचना धारणा — तो पहले एक छोटा असली प्रयोग करता है। परिणाम स्पष्ट: काम करता है, काम नहीं करता, या अस्पष्ट। वह निर्णय और एक सरल-भाषा नोट सीधे योजना में जाते हैं। एजेंट गलत धारणा पर घंटों निर्माण नहीं करता।

• साफ, सार्थक save points। बदलाव स्पष्ट संदेशों के साथ साफ, तार्किक टुकड़ों में स्वतः commit होते हैं। इतिहास पढ़ना और एक-एक टुकड़ा पूर्ववत करना आसान है।

• उपयोगी स्वचालित अनुस्मारक। छोटे अंतर्निर्मित सहायक बदली फ़ाइलों पर सही जाँच चलाने, कोड सरल रखने, और उचित commit संदेश लिखने जैसी चीज़ों के लिए सुझाव देते हैं। आपको इसे पुलिस किए बिना गुणवत्ता ऊँची रहती है।

• आप खुद-सुधार लूप को अकेले चला सकते हैं। वही "समस्याएँ खोजो, ठीक करो, दोहराओ" इंजन जो योजना-जाँच और परीक्षण-सुधार चलाता है, किसी भी गड़बड़ क्षेत्र पर स्वतंत्र उपकरण के रूप में भी काम करता है — एक विनिर्देशन, दस्तावेज़, परीक्षण, एक त्रुटि सूची। इसे उपयोग करने के लिए पूर्ण फ़ीचर निर्माण की ज़रूरत नहीं।

• वर्कफ़्लो नियम वास्तव में काम करते हैं — इसका अंतर्निर्मित प्रमाण। किट अपने साथ अपना परीक्षण सूट भेजती है: जाने-माने-अच्छे और जाने-माने-बुरे उदाहरणों के साथ जाँचों का एक सेट जो साबित करता है कि वर्कफ़्लो नियम सही व्यवहार करते हैं। सिस्टम खुद की जाँच करता है। आपको यह भरोसा नहीं करना होगा कि गार्डरेल लगे हैं — आप जाँचें चला सकते हैं और देख सकते हैं।

Contributing

हम योगदान का स्वागत करते हैं! दिशानिर्देशों के लिए CONTRIBUTING.md देखें।

त्वरित लिंक:

• 🐛 बग रिपोर्ट करें
• 💡 फ़ीचर अनुरोध
• ⚡ स्किल सबमिट करें
• 🌐 अनुवाद जोड़ें

🙏 Credits

vibecode-pro-max-kit spec-driven development framework और self-improving context organization पर ध्यान केंद्रित करती है, बिना आपको 80+ skills से बोझिल किए। कम उपकरण, अधिक संरचना।

⭐ Star History

📄 License

MIT