# एक ओपन-सोर्स एजेंट के साथ CI में AI कोड रिव्यू: वह सेटअप जो सचमुच टिका रहा

> हमें एक दूसरा रिव्यूअर चाहिए था जो कभी थके नहीं, पर हवा से कोई समस्या भी न गढ़े। यहाँ बताया है कि हमने ऑटोमेटेड कोड रिव्यू के लिए Octomind को GitHub Actions में कैसे जोड़ा — octomind-action के असली inputs, टीम की असली lint और test कमांड्स को .agents/tools/ के ज़रिए चलाना, CI को non-interactive और सुरक्षित रखना, और लागत को सीमित रखना।

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

हमें वह बॉट नहीं चाहिए था। हमें एक दूसरा रिव्यूअर चाहिए था जो कभी थके नहीं, पर हवा से कोई समस्या भी न गढ़े। एक रिव्यूअर जो हमारे _असली_ टेस्ट सुइट को चलाए, अनुमान न लगाए, जो पाया उसे एक ही बार कमेंट करे, और जिसकी लागत पूर्वानुमेय हो। यह वह सेटअप है जो कुछ शर्मिंदा करने वाली इटरेशनों के बाद हमारे CI में सचमुच टिका रहा।

यहाँ सब कुछ ओपन सोर्स पर चलता है: [Octomind](https://github.com/Muvon/octomind), सेशन-आधारित एजेंट, और [octomind-action](https://github.com/Muvon/octomind-action), वह GitHub Action जो इसे लपेटता है। कोई SaaS रिव्यूअर नहीं, कोई प्रति-सीट कीमत नहीं, और आपके रनर से कोड कहीं नहीं जाता सिवाय उस मॉडल प्रोवाइडर के जिसे आप पहले से ही भुगतान करते हैं।

---

## SaaS बॉट की जगह "सेल्फ-होस्टेड AI रिव्यूअर" क्यों

आज होस्टेड AI कोड-रिव्यू उत्पादों का एक स्वस्थ बाज़ार है। वे काम करते हैं। पर CI में AI कोड रिव्यू के लिए, तीन बातों ने हमें अपनी ही GitHub Actions के भीतर चलने वाले एक सेल्फ-होस्टेड AI रिव्यूअर की ओर धकेला:

1. **रिव्यूअर को हमारी कमांड्स चलानी चाहिए, हमारी कमांड्स का उसका अनुमान नहीं।** एक होस्टेड बॉट डिफ़ पढ़ता है। वह हमारे सटीक lint कॉन्फ़िग के साथ `cargo clippy --all-targets` नहीं चलाता, न ही सही feature flags के पीछे हमारा इंटीग्रेशन सुइट। एक रिव्यूअर जो प्रोजेक्ट की असली जाँचें नहीं चला सकता, टेक्स्ट पर पैटर्न-मैचिंग तक सिमट जाता है — और ठीक यहीं से हैल्यूसिनेशन आते हैं।
2. **एजेंट उसी रनर पर चलता है जिस पर हम पहले से भरोसा करते हैं।** वही checkout, वही सीक्रेट सीमा, वही नेटवर्क egress नियम। डिफ़ का कुछ भी वहाँ नहीं जाता जिसे हमने पहले से अधिकृत न किया हो।
3. **यह रेपो में एक कॉन्फ़िग फ़ाइल है, किसी भी अन्य की तरह रिव्यू की गई।** रिव्यूअर का व्यवहार एक workflow YAML और वर्शन कंट्रोल में पड़े कुछ `.agents/tools/` स्क्रिप्ट हैं। जब वह शोरगुल वाला हो जाए, आप इसे एक PR में ठीक करते हैं। जब कोई नया व्यक्ति पूछे "बॉट असल में जाँचता क्या है", तो जवाब है `git log`।

अगर आपने हमारा पहले का लेख पढ़ा हो कि क्यों [कस्टम MCP आपके रेपो में रहते हैं](/blog/custom-mcps-belong-in-your-repo), तो यह वही दर्शन है CI की ओर तानी हुई: जो टूलिंग आपके एजेंट को चलाती है वह उसी कोड के बगल में रहती है जिस पर वह काम करती है।

---

## `octomind run` non-interactive रूप से कैसे व्यवहार करता है

सब कुछ एजेंट के बारे में एक तथ्य से शुरू होता है: `octomind run` उसी क्षण non-interactive मोड में चला जाता है जब आप उसे `--format` देते हैं या उसे stdin पाइप करते हैं। CLI परिभाषा से:

```
--format <FORMAT>   Output format: plain or jsonl. When set, runs
                    non-interactively (reads input from stdin).
```

भीतर, रनटाइम फ़्लैग से और इस आधार पर कि stdin टर्मिनल है या नहीं, एक output मोड तय करता है:

| कॉल                                          | मोड                                     |
| -------------------------------------------- | --------------------------------------- |
| टर्मिनल में `octomind run`                   | `Interactive` (प्रॉम्प्ट, रंग, एनिमेशन) |
| `echo "..." \| octomind run` (पाइप किया हुआ) | `NonInteractive`                        |
| `octomind run --format plain`                | `NonInteractive`                        |
| `octomind run --format jsonl`                | `Jsonl` (प्रति लाइन एक JSON ऑब्जेक्ट)   |

CI पाइप वाला मामला है, और `--format jsonl` वही है जो आपको वहाँ चाहिए। यह इंटरैक्टिव सजावट दबा देता है और संरचित इवेंट्स की एक धारा उत्सर्जित करता है — असिस्टेंट संदेश, एक अंतिम लागत इवेंट — जिसे workflow गद्य खुरचे बिना पार्स कर सकता है। यही पूरी वजह है कि एजेंट ऑटोमेटेबल है: कोई छिपा प्रॉम्प्ट किसी इंसान के `y` दबाने का इंतज़ार नहीं करता।

आप इसे हाथ से चलाकर देख सकते हैं:

```bash
echo "Review the staged diff and report only real defects." \
  | octomind run developer:rust --format jsonl
```

अंतिम `assistant` इवेंट रिव्यू का टेक्स्ट लाता है; एक अनुगामी `cost` इवेंट टोकन और डॉलर का कुल योग लाता है। यह वही धारा है जिसे GitHub Action पार्स करता है।

---

## Action, और उसके असली inputs

`octomind-action` दो प्रवेश-बिंदु देता है। हम अलग-अलग कामों के लिए दोनों इस्तेमाल करते हैं:

- `muvon/octomind-action@v1` (`muvon/octomind-action/run@v1` का उपनाम) एक प्रॉम्प्ट से एकल `octomind run` सेशन चलाता है।
- `muvon/octomind-action/workflow@v1` एक TOML फ़ाइल से बहु-चरणीय `octomind workflow` चलाता है।

कोड रिव्यू के लिए, एकल-सेशन वाला `run` काफ़ी है। ये इसके असली inputs हैं — `action.yml` से कॉपी किए गए, गढ़े नहीं गए:

| Input           | डिफ़ॉल्ट              | क्या करता है                                              |
| --------------- | --------------------- | --------------------------------------------------------- |
| `prompt`        | _(अनिवार्य)_          | octomind को भेजा गया कार्य/संदेश                          |
| `role`          | कॉन्फ़िग डिफ़ॉल्ट     | रोल/एजेंट टैग, जैसे `developer:rust`                      |
| `model`         | —                     | मॉडल ओवरराइड, जैसे `openrouter:anthropic/claude-sonnet-5` |
| `name`          | —                     | नामित सेशन (बनाएँ या फिर से शुरू करें)                    |
| `resume`        | —                     | एक नामित सेशन फिर से शुरू करें                            |
| `resume_recent` | `false`               | cwd के लिए सबसे हालिया सेशन फिर से शुरू करें              |
| `sandbox`       | `false`               | फ़ाइल-सिस्टम लेखन को वर्किंग डायरेक्टरी तक सीमित करें     |
| `version`       | `latest`              | इंस्टॉल करने के लिए Octomind संस्करण                      |
| `tap`           | —                     | चलाने से पहले एक tap जोड़ें                               |
| `config`        | —                     | octomind कॉन्फ़िग फ़ाइल का पथ                             |
| `comment`       | `none`                | PR कमेंट मोड: `full`, `compact`, या `none`                |
| `github_token`  | `${{ github.token }}` | PR कमेंट पोस्ट करने के लिए टोकन                           |

और outputs जिन्हें आप बाद के चरणों में पढ़ सकते हैं:

| Output       | क्या लाता है                                    |
| ------------ | ----------------------------------------------- |
| `result`     | अंतिम असिस्टेंट संदेश (रिव्यू स्वयं)            |
| `session_id` | सेशन ID, बाद के चरण में फिर से शुरू करने के लिए |
| `cost`       | `{"tokens": N, "cost": N}`                      |
| `raw_output` | पूरी JSONL धारा                                 |
| `exit_code`  | प्रक्रिया एग्ज़िट कोड                           |

इनमें से दो रिव्यूअर के लिए भार-वहन करते हैं। `comment: compact` रिव्यू को PR पर एक मोड़ने योग्य `<details>` ब्लॉक के रूप में पोस्ट करता है — एक कमेंट, मोड़ने योग्य, लागत एक `<sub>` फ़ुटर में — टेक्स्ट की दीवार के बजाय। और `cost` आपको हर रिव्यू की कीमत लॉग में डालने देता है, जो सुनने में जितना लगता है उससे ज़्यादा मायने रखता है।

---

## टीम के असली `lint` और `test` को `.agents/tools/` के ज़रिए जोड़ना

यही वह हिस्सा है जिसने "सचमुच टिका रहा" को "एक हफ़्ते में बंद" से अलग किया। एक रिव्यूअर जो केवल टेक्स्ट पढ़ता है, समस्याएँ गढ़ता है क्योंकि टेक्स्ट ही उसके पास सब कुछ है। उसे आपकी असली जाँचें चलाने की क्षमता दें और वह अनुमान लगाना बंद कर देता है।

Octomind प्रोजेक्ट-लोकल टूल्स को `<workdir>/.agents/tools/<name>` पर खोजता है — shebang स्क्रिप्ट जिनका कमेंट हेडर एक टूल स्कीमा बन जाता है। वे मॉडल को एक `local` MCP सर्वर के रूप में दिखते हैं, कोई अलग सर्वर प्रोसेस नहीं, कोई रजिस्ट्रेशन नहीं। हमने यांत्रिकी को [कस्टम MCP आपके रेपो में रहते हैं](/blog/custom-mcps-belong-in-your-repo) में कवर किया था; यहाँ CI-संगत बात है: जो स्क्रिप्ट आपके डेवलपरों के एजेंट लोकल रूप से इस्तेमाल करते हैं, वही रिव्यू एजेंट CI में चलाता है, क्योंकि वे रेपो में कमिट हैं।

तो हमने टीम की _सटीक_ कमांड्स को नामित टूल्स के पीछे रखा।

`.agents/tools/lint`:

```bash
#!/usr/bin/env bash
# @description Run the project linter exactly as CI does. Returns warnings and errors.
set -euo pipefail
cd "$OCTOMIND_WORKDIR"
cargo clippy --all-targets --all-features -- -D warnings
```

`.agents/tools/test`:

```bash
#!/usr/bin/env bash
# @description Run the test suite. Defaults to the fast unit set.
# @param scope string One of: unit, all (default: unit)
set -euo pipefail
cd "$OCTOMIND_WORKDIR"
scope="${OCTOMIND_PARAM_SCOPE:-unit}"
case "$scope" in
  unit) cargo test --lib ;;
  all)  cargo test --all-targets ;;
  *) echo "Unknown scope: $scope" >&2; exit 2 ;;
esac
```

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

हैल्यूसिनेटेड-समस्या वाली फ़ेल्योर मोड के ख़िलाफ़ यह सबसे बड़ा लीवर है। मॉडल यह भविष्यवाणी करने में बुरा है कि आपका कोड कंपाइल होता है या नहीं। वह _उस कमांड के आउटपुट को पढ़ने_ में बिलकुल ठीक है जिसने इसे कंपाइल किया।

---

## रिव्यूअर को क्या छूने की अनुमति है, इसे सीमित करना

एक रिव्यूअर को पढ़ना, जाँचें चलाना और रिपोर्ट करना चाहिए। उसे फ़ाइलें संपादित नहीं करनी चाहिए, push नहीं करना चाहिए, या PR नहीं खोलने चाहिए। Octomind रोल्स इसे `server_refs` (रोल कौन-से टूल सर्वर देखता है) और `allowed_tools` (उनके भीतर कौन-से टूल) से नियंत्रित करते हैं। आकार, साथ आने वाले रोल टेम्पलेट्स से:

```toml
[[roles]]
name = "reviewer:strict"
system = """
You are a code reviewer. Run the project's lint and test tools to ground
every claim. Report only defects you can substantiate with tool output or a
specific line. If you find nothing, say so in one sentence. Never edit files.
"""
temperature = 0.1

[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view", "lint", "test"]
```

इसमें कुछ जानबूझकर लिए गए निर्णय हैं। `temperature = 0.1` क्योंकि एक रिव्यूअर को नीरस और दोहराने योग्य होना चाहिए, रचनात्मक नहीं। `allowed_tools` केवल पढ़ने और जाँच वाले टूल सूचीबद्ध करता है — कोई shell लेखन नहीं, कोई संपादन नहीं — ताकि भले ही मॉडल कुछ "ठीक" करने का निर्णय ले, उसके पास ऐसा करने का कोई टूल न हो। और system प्रॉम्प्ट के अंतिम दो वाक्य शोर नियंत्रण हैं: _केवल वही रिपोर्ट करो जिसे प्रमाणित कर सको; अगर कुछ न मिले, तो एक वाक्य में कह दो।_ उस एक निर्देश ने हमारे औसत कमेंट को चौदह "समस्याओं" से, एक साफ़ PR पर, "कोई दोष नहीं मिला" तक ला दिया।

अतिरिक्त बेल्ट-और-सस्पेंडर के लिए, Action का `sandbox: true` input किसी भी फ़ाइल-सिस्टम लेखन को वर्किंग डायरेक्टरी तक सीमित करता है — तो जिस टूल को सचमुच एक temp फ़ाइल लिखनी हो, वह लिख सकता है, पर कुछ भी checkout से बाहर नहीं जाता।

---

## non-interactive रन में अनुमतियाँ और सुरक्षा

CI में एजेंट को लेकर लोग जिस बात से चिंतित होते हैं वह है अप्रूवल। एक इंटरैक्टिव सेशन में टूल चलने से पहले आपसे पूछा जाता। CI में पूछने के लिए कोई नहीं है, और यही मुद्दा है: non-interactive मोड में कोई `y/n` गेट नहीं जो जॉब को लटका दे। सुरक्षा लूप में किसी इंसान से नहीं आती — वह लूप के संकीर्ण होने से आती है:

- **रोल का `allowed_tools` MCP-सर्वर टूल्स की अनुमति-सूची है।** रिव्यूअर ऐसा सर्वर टूल कॉल नहीं कर सकता जो सूचीबद्ध न हो — यह एक स्थैतिक सीमा है, रनटाइम में लिया गया कोई निर्णय नहीं जिससे मॉडल को बहलाया जा सके। अपवाद हैं प्रोजेक्ट-लोकल `.agents/tools/` स्क्रिप्ट, जो हमेशा उपलब्ध रहती हैं: उनकी सीमा वही है जो आप उस डायरेक्टरी में कमिट करते हैं, और PR रिव्यू उसका हर बदलाव देखता है।
- **`sandbox: true`** लेखन को checkout के भीतर रखता है।
- **सीक्रेट रनर के एनवायरनमेंट में रहते हैं**, रेपो में कभी नहीं। `.agents/tools/` स्क्रिप्ट एनवायरनमेंट से `ACME_TOKEN` और साथी पढ़ती हैं; स्क्रिप्ट कमिट है, सीक्रेट एक GitHub Actions सीक्रेट है। अगर कोई सीक्रेट गायब है, तो टूल एक स्पष्ट संदेश के साथ ग़ैर-शून्य कोड पर बाहर निकल जाता है, बजाय कोई परिणाम गढ़ने के।
- **`github_token` केवल कमेंट करने तक सीमित है।** डिफ़ॉल्ट `${{ github.token }}` PR कमेंट पोस्ट करता है; इसे मॉडल को टूल के रूप में नहीं सौंपा जाता।

रिव्यूअर का प्रभाव-क्षेत्र है: फ़ाइलें पढ़ना, दो अनुमति-सूची वाली कमांड्स चलाना, एक PR कमेंट लिखना। यह एक ऐसी सीमा है जिस पर आप तर्क कर सकते हैं — जो "मॉडल ने वादा किया कि वह कुछ नहीं छुएगा" से कहीं अधिक है।

---

## वह workflow जो टिका रहा

यह असली रिव्यू जॉब है, पूरी तरह ऊपर के inputs पर आधारित:

```yaml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write # needed to post the review comment

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # so the agent can diff against the base

      - uses: muvon/octomind-action@v1
        with:
          role: reviewer:strict
          model: openrouter:anthropic/claude-sonnet-5
          sandbox: true
          comment: compact
          prompt: |
            Review the changes on this branch against the base.
            Run the `lint` and `test` tools to ground your findings.
            Report ONLY defects you can substantiate with tool output or a
            specific changed line. Group by severity. If nothing is wrong,
            reply in one sentence. Do not restate the diff.
        env:
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
```

निर्णयों पर टिप्पणियाँ:

- **`role: reviewer:strict`** कम तापमान, टूल अनुमति-सूची, और "प्रमाणित करो या चुप रहो" वाला system प्रॉम्प्ट लाता है। प्रॉम्प्ट input _कार्य_ है; रोल _व्यक्तित्व और रेलिंग_ है। इन्हें अलग रखें ताकि अलग-अलग ट्यून कर सकें।
- **`model:` पिन किया हुआ है**, बहकने के लिए नहीं छोड़ा गया। मॉडल पिन करना आपके लागत-नियंत्रण का आधा और आपकी पुनरुत्पादनीयता का अधिकांश है। हम एक Sonnet-श्रेणी मॉडल पर पिन करते हैं और उसे केवल जानबूझकर बदलते हैं।
- **`comment: compact`** प्रति रन एक मोड़ने योग्य कमेंट देता है। `synchronize` पर (PR में हर push) आपको एक ताज़ा रिव्यू मिलता है बिना थ्रेड के एक स्क्रॉल में बदले।
- **`OPENROUTER_API_KEY`** जॉब को चाहिए एकमात्र सीक्रेट है। Octomind OpenRouter, Anthropic, OpenAI, DeepSeek, Google Vertex, AWS Bedrock और Cloudflare से बात करता है; आपके द्वारा सेट किया गया env वेरिएबल प्रोवाइडर चुनता है।

यही पूरा रिव्यूअर है। एक जॉब, एक Action, दो कमिट किए गए टूल स्क्रिप्ट, एक रोल परिभाषा।

---

## लागत को सीमित रखना

एक एजेंट जो टूल चला सकता है, सिद्धांत रूप में हमेशा के लिए लूप कर सकता है और हमेशा के लिए बिल कर सकता है। व्यवहार में हम इसे कुछ नीरस, प्रभावी लीवरों से सीमित करते हैं:

- **मॉडल पिन करें।** एक पिन किया हुआ Sonnet-श्रेणी मॉडल प्रति-टोकन पूर्वानुमेय लागत रखता है। "नवीनतम और बेहतरीन" वही है जिससे आपको एक चौंका देने वाला बिल मिलता है।
- **सही इवेंट्स पर ट्रिगर करें।** केवल `opened` और `synchronize`। हर कमेंट पर नहीं, ड्राफ़्ट PR पर नहीं (जब चाहें तब `if: github.event.pull_request.draft == false` से छानें)।
- **`cost` output पढ़ें और लॉग करें।** हर रन `cost` को `{"tokens": N, "cost": N}` के रूप में उत्सर्जित करता है। इसे जॉब summary में डालें। एक बार हर रिव्यू की कीमत आपके Actions लॉग में बैठ जाए, तो लागत एक एहसास से एक संख्या बन जाती है जिस पर आप एक सीमा रख सकते हैं।

```yaml
      - run: echo "Review cost: ${{ steps.review.outputs.cost }}" >> "$GITHUB_STEP_SUMMARY"
```

सबसे बड़ा लागत-चालक टूल हैं, प्रॉम्प्ट नहीं। एक रिव्यूअर जो हर push पर आपका पूरा इंटीग्रेशन सुइट चलाता है, महँगा है क्योंकि _सुइट_ महँगा है, इसलिए नहीं कि एजेंट है। हमारा `test` टूल ठीक इसी कारण डिफ़ॉल्ट रूप से तेज़ unit सेट का उपयोग करता है; एजेंट `scope: all` की ओर केवल तब बढ़ता है जब डिफ़ किसी ऐसी चीज़ को छूता है जो इसकी माँग करती है, और तब भी हम इसे रोल स्तर पर सीमित कर सकते हैं।

---

## ईमानदारी से, अड़चनें

**अनिश्चितता (Non-determinism)।** एक ही डिफ़ पर दो रन रिव्यू को अलग-अलग शब्दों में लिख सकते हैं, और कभी-कभी एक वह ढूँढ लेता है जो दूसरा नहीं। `temperature = 0.1` इसे बहुत घटाता है पर ख़त्म नहीं करता। हल अनिश्चितता का पीछा करना नहीं है — यह AI रिव्यू को कई में से एक _सलाहकारी_ जाँच मानना है। यह अपने आप कभी merge नहीं रोकता। वह एक इंसान और असली CI जाँचें करती हैं।

**शोर एक प्रॉम्प्ट समस्या है, मॉडल समस्या नहीं।** हमारा पहला रिव्यूअर शोरगुल वाला था क्योंकि हमने उससे "कोड रिव्यू करो" कहा, जिसे एक उत्साही मॉडल "चौदह चीज़ें ढूँढो" के रूप में पढ़ता है। इलाज system प्रॉम्प्ट के दो वाक्य थे: _हर दावे को प्रमाणित करो; अगर कुछ न मिले, तो एक वाक्य में कह दो।_ साथ में टूल — आधा शोर मॉडल का उन परिणामों का अनुमान लगाना था जिन्हें वह बस चला सकता था। अगर आपका रिव्यूअर शोरगुल वाला है, तो मॉडल को दोष देने से पहले प्रॉम्प्ट ठीक करें और उसे जाँचने की क्षमता दें।

**टूल आउटपुट में सीक्रेट।** एक टूल जो एनवायरनमेंट या विस्तृत लॉग उगलता है, एक सीक्रेट सीधे PR कमेंट में लीक कर सकता है। टूल आउटपुट कसा रखें: lint/test परिणाम लौटाएँ, पूरी दुनिया नहीं। हमने यह तब सीखा जब एक verbose टेस्ट रनर ने रिव्यू बॉडी में एक कनेक्शन स्ट्रिंग echo कर दी। अब टूल परिणाम छापते हैं, एनवायरनमेंट नहीं।

**base-ref डिफ़।** checkout पर `fetch-depth: 0` का उपयोग करें वरना एजेंट बेस ब्रांच से तुलना नहीं कर पाता और पूरी फ़ाइल "रिव्यू" कर बैठता है। सस्ती ग़लती, चिढ़ाने वाला लक्षण।

**यह एक दूसरा रिव्यूअर है, _वह_ रिव्यूअर नहीं।** जिस दिन आप इस पर भरोसा करने लगें कि यह सब कुछ पकड़ लेगा, वही दिन है जब यह उस एक को चूकता है जो मायने रखता है। यह एक अथक पहला पास है। थके हुए इंसान अभी भी merge के मालिक हैं।

---

## अक्सर पूछे जाने वाले प्रश्न

**क्या एजेंट को मेरे रेपो में लेखन-पहुँच चाहिए?**

नहीं। रिव्यूअर रोल `allowed_tools` में केवल पढ़ने और जाँच वाले टूल सूचीबद्ध करता है, `sandbox: true` किसी भी लेखन को checkout तक सीमित करता है, और `github_token` केवल कमेंट पोस्ट करने के लिए उपयोग होता है। मॉडल को कभी push या edit टूल नहीं सौंपा जाता।

**क्या मैं एक सामान्य के बजाय टीम के असली lint/test चला सकता हूँ?**

यही तो पूरी बात है। अपनी सटीक कमांड्स `.agents/tools/lint` और `.agents/tools/test` में डालें, उन्हें कमिट करें, और एजेंट उन्हें CI में चलाता है। वही स्क्रिप्ट जो आपके डेवलपरों के लोकल एजेंट उपयोग करते हैं। देखें [कस्टम MCP आपके रेपो में रहते हैं](/blog/custom-mcps-belong-in-your-repo)।

**मैं एक रिव्यू की लागत कैसे पढ़ूँ?**

Action एक `cost` output (`{"tokens": N, "cost": N}`) और `raw_output` के ज़रिए पूरी JSONL देता है। `cost` को `$GITHUB_STEP_SUMMARY` में echo करें और यह हर रन के लॉग में रहेगा।

**अगर मुझे एक बहु-चरणीय पाइपलाइन चाहिए, एक अकेला रिव्यू नहीं?**

एक TOML फ़ाइल के साथ `muvon/octomind-action/workflow@v1` का उपयोग करें — एक चरण में संदर्भ जुटाएँ, अगले में रिव्यू करें, तीसरे में सारांश। वही प्रोवाइडर env, वही PR-कमेंट प्लंबिंग, साथ में टोकन ख़र्च किए बिना पाइपलाइन को मान्य करने के लिए एक `dry_run` input।

**कौन-से मॉडल प्रोवाइडर काम करते हैं?**

जिसे आप पहले से भुगतान करते हैं: OpenRouter, Anthropic, OpenAI, DeepSeek, Google Vertex, AWS Bedrock, Cloudflare। संगत API key को `env` में सेट करें और `model` input से मॉडल पिन करें।

---

## बदलाव

एक AI रिव्यूअर के साथ सहज प्रवृत्ति है उसे और होशियार बनाना — बेहतर मॉडल, लंबा प्रॉम्प्ट, और चतुर। जो हमारे लिए सचमुच टिका रहा वह था उसे _संकीर्ण और अधिक आधारित_ बनाना। कम टूल, सभी हमारे। एक कम तापमान। एक system प्रॉम्प्ट जिसका पूरा काम मॉडल को तब तक चुप रखना है जब तक वह बात साबित न कर सके। और असली जाँचें चलाने की क्षमता, ताकि वह `cargo clippy` के आउटपुट से तर्क करे, न कि इस हुनक से कि `cargo clippy` क्या कह सकता है।

परिणाम कोई प्रतिभाशाली रिव्यूअर नहीं है। यह एक भरोसेमंद रिव्यूअर है: यह कभी नहीं थकता, हर बार वही जाँचें चलाता है, और — वह हिस्सा जो कमाने में सबसे लंबा लगा — उसने हवा से समस्याएँ गढ़ना बंद कर दिया। इसके इर्द-गिर्द जो व्यापक चीज़ें आईं, उनके बारे में बाक़ी [जून 2026 की समीक्षा](/blog/release-round-june-2026) में है।

इसे पहले एक कम-जोखिम वाले रेपो पर जोड़ें। कुछ रिव्यू देखें। प्रॉम्प्ट दो बार ट्यून करें। फिर इसे आपके PR पर चुपचाप बैठने दें — वह दूसरी जोड़ी आँखें जो कभी नहीं झपकतीं।

— Don

---

_[Octomind](https://github.com/Muvon/octomind) और [octomind-action](https://github.com/Muvon/octomind-action) Apache-2.0 के तहत ओपन सोर्स हैं। अगर आपका रिव्यूअर शोरगुल वाला है, तो इलाज लगभग हमेशा प्रॉम्प्ट और टूल हैं — और अगर नहीं, तो JSONL के साथ [एक issue खोलें](https://github.com/Muvon/octomind/issues) और हम देखेंगे।_