October 2025 में, एक ही GitHub commit ने एक लोकप्रिय agents repository में 47 LLM-generated "skills" ड्रॉप कर दीं। इनमें से एक ने Claude को npx react-codeshift चलाना सिखाया। वह package मौजूद नहीं था। वह कभी मौजूद नहीं था। Claude ने उसे training के दौरान hallucinate किया था, author ने चेक नहीं किया, और कुछ हफ़्तों में वह file 237 forks तक फैल गई। असली developers ने असली terminals में वह command चलाई। npm ने हज़ारों बार खुशी-खुशी एक phantom package को resolve करने की कोशिश की।

यह AI-agent कहानी का वह हिस्सा है जो keynote में नहीं आता। Agents drift करते हैं। एक shell और एक धुंधला task दे दीजिए, और वे सबसे प्लॉज़िबल-साउंडिंग command की ओर बढ़ेंगे, भले ही वह मौजूद न हो — और जितना general tool आप उन्हें देंगे, उतना ही ज़्यादा वे drift करेंगे।

2026 में मानक उत्तर है: एक custom MCP server लिखो। वे actions define करो जो आप चाहते हैं कि agent ले, उन्हें सख्त schemas दो, उन्हें एक अलग binary के रूप में ship करो, उन्हें agent की config में register करो। bash के बजाय specific tools देकर model को constrain करो।

मानक उत्तर सिद्धांत में सही है और व्यवहार में गलत। एक असली MCP server लिखना — JSON-RPC framing, stdio handshake, schema definitions, अलग dependency tree — एक shell command के लिए, यह engineering theater है। ज़्यादातर teams हार मान लेती हैं और drift के साथ जीती हैं।

Octomind 0.29.0 यह gap बंद करता है। एक custom MCP एक project नहीं होना चाहिए। यह आपके repo में एक file होनी चाहिए।

Drift समस्या, संख्याओं द्वारा समर्थित

अगर आपने थोड़ी देर एक agent को चलते देखा है, तो आपने drift देखी है:

  • वह pnpm monorepo में npm test चलाता है।
  • वह आपके असली, auth-gated https://api-staging.acme.internal/v3 के बजाय https://staging.example.com/api को curl करता है।
  • वह एक ऐसा package install करने की कोशिश करता है जिसका नाम लगभग — पर बिलकुल नहीं — सही है।
  • वह आपकी team के release script के बजाय raw git tag का इस्तेमाल करता है।

May 2025 का paper RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection (Gan & Sun) ने एक MCP stress test चलाया और पाया कि baseline tool-selection accuracy scale पर 13.62% तक गिर गई — model अब reliably सही tool नहीं चुन सकता था क्योंकि हर tool description जिस पर उसे विचार करना था, prompt को भीड़भाड़ देती थी और attention को diluted करती थी। उनका retrieval-आधारित fix इसे तीन गुना से ज़्यादा बढ़ाकर 43.13% कर देता है जबकि prompt tokens को 50% से अधिक काट देता है। फिर भी accuracy खराब है, पर curve की दिशा ही मुख्य बात है: जितने tools आप ठूँसते हैं, model उतना ही उनमें से चुनने में खराब होता जाता है।

Anthropic, जिसने MCP protocol लिखा, ने 4 November 2025 को वही बात स्वीकारी:

"In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request."

उनके अपने benchmarks ने दिखाया कि एक Drive → Salesforce flow naive MCP loading के तहत 150,000 tokens लेता है। Code-execution और on-demand tool discovery के साथ, वही flow 2,000 tokens में चला — 98.7% की कटौती। उनका follow-up Tool Search Tool (API version 20251119) tool definitions को तब तक defer करता है जब तक उनकी ज़रूरत न पड़े; documentation बताती है कि यह आमतौर पर context bloat को 85% से अधिक काट देता है और note करती है कि "Claude's ability to correctly pick the right tool degrades significantly once you exceed 30–50 available tools."

सबक जिस पर सब converge कर रहे हैं: कम, संकीर्ण, project-relevant tools हर बार एक विशाल catalog को हराते हैं। Model बेहतर perform करता है। Token bill गिरता है। Drift उसके साथ गिरती है।

तो सही सवाल नहीं है "मैं और MCPs कैसे लिखूँ?" यह है "जिन्हें मुझे वास्तव में चाहिए, उन्हें लिखने और ship करने में कुछ खर्च न हो — यह कैसे करूँ?"

"बस एक MCP Server लिखो" Scale क्यों नहीं करता

February 2026 का Bloomberry analysis of 1,412 MCP servers ने पाया कि उनमें से 38.7% बिना किसी authentication के ship करते हैं, median server केवल five tools expose करता है, और जो companies उन्हें publish कर रही हैं उनमें से लगभग आधी के पास पहले स्थान पर एक public API ही नहीं है। Bloomberry की framing: "MCP might not be a wrapper on an existing API. It might be the first machine-readable interface they've ever shipped." (MCP एक मौजूदा API पर wrapper नहीं हो सकता। यह उनके द्वारा कभी ship किया गया पहला machine-readable interface हो सकता है।) इस विस्फोट का अधिकांश हिस्सा वे लोग ship कर रहे हैं जो production में इसे figure out कर रहे हैं।

समस्या यह नहीं है कि protocol टूटा है। यह है कि unit of work गलत है project-specific actions के लिए। एक Python या Node MCP server लिखना stdio framing, schema registration, और एक अलग deployment pipeline के साथ "GitHub API" या "Postgres database" के लिए सही shape है। यह "run our staging deploy script" के लिए गलत shape है — कोड का एक टुकड़ा जो चालीस लाइन bash है, पहले से bin/deploy में है, जिसे आप चाहते हैं कि agent अनुमान लगाने के बजाय नाम से call करे।

Practitioners इसी निष्कर्ष पर पहुँच रहे हैं। Hacker News thread "MCP explained without hype or fluff" (item 44063141) से, commenter 0x457:

"Many of MCPs shouldn't have existed, IMO. […] I wanted amazon q to interact with github, so I added to its context that it can use gh-cli and it it worked pretty well. […] To make its and mine life easier, common things were saved as scripts in bin/ and Justfile (also generated by it). […] Using github's official MCP bricks chat session every time for me."

और dvt:

"MCP is bloated AI hype that basically solves nothing […]. It's APIs talking to APIs that talk to other APIs."

दोनों comments वे जिन cases का वर्णन करते हैं उनके बारे में सही हैं। CLIs काम करते हैं। bin/ में local scripts काम करते हैं। एक one-line shell command को 200-line MCP server में लपेटना क्योंकि वही एकमात्र blessed pattern है — यही टूटा है।

एक MCP Tool वास्तव में क्या है

Protocol को हटा दीजिए और एक MCP tool तीन चीज़ें हैं:

  1. एक नाम और description ताकि model को पता हो कि इसे कब उठाना है।
  2. एक parameter schema ताकि model को पता हो कि क्या pass करना है।
  3. एक executable जो काम करता है।

बाकी सब — JSON-RPC framing, stdio handshake, capability negotiation — runtime concern है, author concern नहीं। 2023 का paper Tool Documentation Enables Zero-Shot Tool-Usage with Large Language Models (Hsieh et al.) ने empirically दिखाया कि अपरिचित tools के लिए, clear documentation few-shot demonstrations को हराती है — और "zero-shot prompts with only tool documentation" out-of-distribution tasks पर few-shot prompts से match कर सकते हैं। निहितार्थ: tool पर एक छोटा, सटीक description एक complex schema या examples के ढेर से ज़्यादा मूल्यवान है।

अगर tool छोटा है और docs छोटे हैं, तो पूरा interface उस script पर कुछ header comments की लाइनों के रूप में expressible होना चाहिए जो काम करती है।

यही Octomind 0.29.0 करता है।

Pattern: .agents/tools/<name>

यहाँ पूरा contract है:

mkdir -p .agents/tools
cat > .agents/tools/deploy <<'EOF'
#!/usr/bin/env bash
# @description Deploy the API service to a target environment using our team's pipeline.
# @param *env string Target environment (staging|production)
# @param dry_run boolean If true, validate without applying

set -euo pipefail
cd "$OCTOMIND_WORKDIR"

env="$OCTOMIND_PARAM_ENV"
dry="${OCTOMIND_PARAM_DRY_RUN:-false}"

if [[ "$dry" == "true" ]]; then
  ./bin/deploy --env "$env" --dry-run
else
  ./bin/deploy --env "$env"
fi
EOF
chmod +x .agents/tools/deploy

तीन बातें अभी हुईं:

  1. अगली बार जब session चलेगा तो Octomind ने script को discover किया।
  2. इसने @description और @param लाइनों को एक JSON-Schema tool definition में parse किया।
  3. Model अब एक deploy tool देखता है — इस repo के लिए scoped — env (required) और dry_run (optional) के साथ। यह bash("./bin/deploy --env staging") के बजाय deploy(env="staging") को pick करेगा क्योंकि named tool का signal-to-noise ratio ज़्यादा साफ़ है।

वह preference वही guardrail है जो आप चाहते हैं। Model अब "deploy" से "kubectl apply" से "helm install" तक free-associate नहीं कर रहा है। उसके पास एक entry point है, एक typed parameter के साथ, जो team का असली deploy करता है।

Wiring verify करने के लिए, validation one-liner चलाएँ:

echo "/mcp" | octomind run

आपको output में एक local MCP server दिखेगा जिसके नीचे deploy listed होगा। अगर script नहीं दिखती, तो runtime आपको बिल्कुल बताता है क्यों — गलत permissions, गायब @description, filename में dot।

Header का Anatomy

Leading comment block ही पूरा interface है। Octomind इसे हर turn पर फिर से पढ़ता है (cheap — एक read_dir) और schema को rebuild करता है। Edit करें और save करें, अगला tool call नया version इस्तेमाल करता है। कोई daemon restart नहीं।

#!/usr/bin/env bash
# @description Short summary the model sees. Continuation lines without an
# @-tag append to the previous one, so multi-line descriptions Just Work.
# @param *target string Path to operate on (* prefix = required)
# @param force boolean Overwrite if the destination exists
# @param count integer Number of iterations
# @param tags array JSON list, e.g. ["foo","bar"]

Comment prefix # (bash, python, ruby, lua, perl, awk), // (node, deno), या -- (lua, SQL wrappers) हो सकता है। Runtime को परवाह नहीं है कि कौन सी language काम करती है।

जब model tool को call करता है, octomind आपको parameters दो तरीकों से देता है:

Channel Form
stdin One JSON object then EOF: {"target":"src/x","force":true}
env OCTOMIND_PARAM_TARGET=src/x, OCTOMIND_PARAM_FORCE=true, plus OCTOMIND_WORKDIR and OCTOMIND_TOOL_NAME

Bash scripts आमतौर पर env vars पढ़ते हैं। Python scripts आमतौर पर stdin JSON parse करते हैं। दोनों हर call पर आते हैं। Stdout वह result बन जाता है जो model देखता है। Stderr को [stderr] marker के साथ append किया जाता है। Non-zero exit → tool error।

बस यही पूरी सतह है।

चार असली Drifts, चार असली Tools

हमने wrapper लिखने से पहले अपने repos में इनमें से हर एक पर agent को fail होते देखा है। Wrapper ने failure रोकी।

1. The Drift: "वह pnpm monorepo में npm test चलाता है"

Agent root पर एक package.json देखता है, npm test type करता है, "no script found" errors की एक दीवार पाता है, और project को टूटा हुआ report करता है।

The wrapper — .agents/tools/test:

#!/usr/bin/env bash
# @description Run the project test suite. Defaults to fast unit tests.
# @param scope string One of: unit, integration, all (default: unit)
# @param package string Optional package filter, e.g. @acme/api

set -euo pipefail
cd "$OCTOMIND_WORKDIR"

scope="${OCTOMIND_PARAM_SCOPE:-unit}"
pkg="${OCTOMIND_PARAM_PACKAGE:-}"

case "$scope" in
  unit)        cmd=("pnpm" "-r" "test:unit") ;;
  integration) cmd=("pnpm" "-r" "test:integration" "--" "--runInBand") ;;
  all)         cmd=("pnpm" "-r" "test") ;;
  *) echo "Unknown scope: $scope" >&2; exit 2 ;;
esac

[[ -n "$pkg" ]] && cmd+=("--filter" "$pkg")
exec "${cmd[@]}"

अब agent अपनी tool list में test(scope, package) देखता है। Description उसे defaults बताती है। यह test() call करता है और पहली ही try में असली result पाता है। Team में कोई फिर कभी chat window में "use pnpm -r test:unit" type नहीं करता।

2. The Drift: "इसने staging URL को hallucinate कर दिया"

Agent को आपके असली staging API से https://api-staging.acme.internal/v3/users/42 पर एक record पढ़ना है, जिसके लिए एक X-Acme-Token header चाहिए। यह इसके बजाय https://staging.example.com/api/users/42 को curl करता है — एक URL जो उसने training data से गढ़ा — कुछ नहीं मिलता, और service को down report करता है।

The wrapper — .agents/tools/api:

#!/usr/bin/env bash
# @description Call our internal staging API. Returns raw JSON.
# @param *path string Path under /v3, e.g. /users/42
# @param method string HTTP method (default: GET)
# @param body string Optional JSON body for POST/PUT/PATCH

set -euo pipefail
: "${ACME_STAGING_TOKEN:?ACME_STAGING_TOKEN not set in environment}"

path="$OCTOMIND_PARAM_PATH"
method="${OCTOMIND_PARAM_METHOD:-GET}"
body="${OCTOMIND_PARAM_BODY:-}"
url="https://api-staging.acme.internal/v3${path}"

args=(-sS -X "$method" -H "X-Acme-Token: $ACME_STAGING_TOKEN")
[[ -n "$body" ]] && args+=(-H "Content-Type: application/json" --data "$body")

curl "${args[@]}" "$url"

URL अब drift नहीं करता क्योंकि URL अब model का काम नहीं है। Agent api(path="/users/42") call करता है और असली URL script में रहता है। Token developer के environment से आता है (.envrc, direnv, आपका shell rc) — tool commit होता है, secret नहीं।

3. The Drift: "उसने feature flag service चौथी बार फिर से समझाई"

Agent एक UI issue debug कर रहा है। आप उसे (फिर से) याद दिलाते हैं कि feature-flag service मौजूद है, कि flags हर environment के लिए अलग हैं, और staging प्रासंगिक है। यह सिर हिलाता है, भूल जाता है, अगले session में फिर पूछता है।

The wrapper — .agents/tools/flags:

#!/usr/bin/env python3
# @description Return the currently enabled feature flags for an environment.
# @param env string Environment to inspect (default: staging)

import json, os, sys, urllib.request

params = json.load(sys.stdin) if not sys.stdin.isatty() else {}
env = params.get("env") or os.environ.get("OCTOMIND_PARAM_ENV") or "staging"

url = f"https://flags.acme.internal/api/snapshot?env={env}"
req = urllib.request.Request(url, headers={"X-Acme-Token": os.environ["ACME_TOKEN"]})

with urllib.request.urlopen(req, timeout=10) as r:
    flags = json.load(r)

enabled = sorted(k for k, v in flags.items() if v.get("enabled"))
print("\n".join(enabled) if enabled else "(no flags enabled)")

Model अब एक session खोलता है, अपनी tool list में flags देखता है, और जब चाहिए तब खुद उसे call करता है। आप "staging में क्या on है" के लिए human cache होना बंद कर देते हैं।

4. The Drift: "इसने हमारे release script के बजाय git tag का इस्तेमाल किया"

आपकी team ने acme-cli बनाया ताकि version bumps, changelogs, और tag-then-push सही क्रम में हों। Agent इसे skip कर देता है, raw git tag v1.2.3 चलाता है, convention तोड़ता है, और अब अगला CI run changelog नहीं ढूँढ सकता।

The wrapper — .agents/tools/release:

#!/usr/bin/env bash
# @description Cut a release using the team's acme-cli. Bumps version, updates
# CHANGELOG, tags the commit, and pushes. Use bump=patch unless minor or major
# is explicitly requested.
# @param *bump string One of: patch, minor, major
# @param dry_run boolean If true, show what would happen without pushing

set -euo pipefail
cd "$OCTOMIND_WORKDIR"

bump="$OCTOMIND_PARAM_BUMP"
dry="${OCTOMIND_PARAM_DRY_RUN:-false}"

args=(release --bump "$bump")
[[ "$dry" == "true" ]] && args+=(--dry-run)

acme-cli "${args[@]}"

यह वही है जो teammates को राज़ी करता है। Agent अब अपनी ओर से आपकी team की release convention follow करता है — version, changelog, tag, push — क्योंकि tool repo में मौजूद है और model इसे raw git के ऊपर pick करता है।

Compounding Effect: यह Repo में रहता है

Anthropic की MCP code-execution post का तर्क है कि future dynamic discovery है: ज़रूरत पड़ने पर tools load करो, बाकी समय छोड़ दो। Shebang pattern उस idea का local-first version है। तीन properties एक साथ stack होती हैं:

1. Narrow surface, कम drift. Model एक generic shell के बजाय एक one-line description के साथ named, parameterized action देखता है। Hsieh et al. ने पाया कि description ही tool selection के लिए अधिकांश काम करती है — examples nice-to-have हैं। Shebang header उसी के लिए सटीक सही shape है: नाम, description, typed params, सब एक comment block में जो tool author कोड के साथ-साथ पहले से maintain करता है।

2. पूरी team को मुफ्त में मिलता है। एक traditional MCP server एक developer के laptop पर रहता है। जब एक teammate repo clone करता है, server वहाँ नहीं होता, agent tool नहीं देखता, और drift वापस आ जाता है। एक .agents/tools/ script git में commit होती है। Clone, octomind run, सबको वही tools मिलते हैं।

3. Tools कोड के साथ विकसित होते हैं। एक service rename की? उसी PR में wrapper update कीजिए। एक feature flag जोड़ा? उसी PR में wrapper update कीजिए। आपका AI tooling किसी भी अन्य चीज़ की तरह code review के अधीन है। Agent को क्या लगता है कि repo कैसा दिखता है और repo वास्तव में कैसा दिखता है के बीच का drift — agent reliability का slow-burn killer — अपने आप बंद हो जाता है।

इसके एक हफ़्ते बाद, हर developer के terminal में agent एक ही behavior पर converge करता है क्योंकि सब एक ही repo से एक ही tools चलाते हैं। Institutional knowledge "जो मैंने chat में agent को बताया" होना बंद हो जाता है और एक versioned, reviewable artifact बन जाता है।

इसके बजाय MCP Server कब Reach करें

Local tools project-specific 90% कवर करते हैं। वे सब कुछ कवर नहीं करते। इस matrix का इस्तेमाल कीजिए:

आप चाहते हैं… Use
Project-specific action (deploy, test, query flags, hit an internal endpoint) .agents/tools/ shebang
Domain instructions को context में inject करें Skills
Reusable cross-project tool with rich schema and multi-step logic Author a tap with an MCP server
Long-lived process (connection pool, browser session, websocket) External stdio/http MCP server

Mental model: अगर आपके MCP server का body "parse params, spawn this binary, return stdout" है, तो आपको server नहीं चाहिए — आपको एक 15-line shell script चाहिए।

Validation Loop

कोई भी tool लिखने या बदलने के बाद यह चलाएँ:

echo "/mcp" | octomind run

यह current directory में एक session boot करता है, scope में हर MCP server list करता है, और exit करता है। आप देखेंगे:

local: ✅ Running
  Type: LocalTools
  Configured tools: deploy, test, api, flags, release

अगर एक tool गायब है:

Symptom Cause Fix
Not in /mcp output Not executable chmod +x .agents/tools/<name>
Not in /mcp output Missing @description Add the line
Not in /mcp output Filename has . Drop the extension (deploy, not deploy.sh)
Tool errors when called Param-reading mismatch Confirm you read OCTOMIND_PARAM_* or stdin, not $1

गहरी debugging के लिए: OCTOMIND_LOG=debug echo "/mcp" | octomind run दिखाता है कि क्यों हर candidate file को accept या skip किया गया।

Runtime .agents/tools/ को hot-reloaded मानता है — edit, save, अगला tool call नया version इस्तेमाल करता है। कोई octomind restart नहीं, कोई daemon नहीं। Write, save, call।

शुरुआत करना

अगर आपके पास octomind नहीं है:

# macOS
brew install muvon/tap/octomind

# Any platform
cargo install octomind

फिर किसी भी repo में:

mkdir -p .agents/tools
cat > .agents/tools/branch <<'EOF'
#!/usr/bin/env bash
# @description Print the current branch name.
git -C "$OCTOMIND_WORKDIR" rev-parse --abbrev-ref HEAD
EOF
chmod +x .agents/tools/branch

echo "/mcp" | octomind run

आपको branch के साथ local listed दिखना चाहिए। उसे commit करें:

git add .agents/tools/branch
git commit -m "agent: add branch-name tool for AI sessions"

बस यही पूरा pattern है। हर dev जो repo pull करता है, उसके पास tool होता है। Directory में हर agent run इसे देखता है। किसी की machine पर कोई और setup नहीं।

FAQ

अगर underlying command वही है तो wrapped tool drift क्यों कम करता है?

क्योंकि model अब हज़ारों समान रूप से प्लॉज़िबल shell invocations के बीच नहीं चुन रहा है। यह उसके लिए लिखे गए descriptions वाले मुट्ठी भर named, typed tools के बीच चुन रहा है। RAG-MCP ने प्रभाव को measure किया: catalog बढ़ने के साथ tool-selection accuracy गिरती है। clear descriptions के साथ एक छोटा, named set tool-using LLMs के लिए empirically correct shape है।

क्या यह Octomind-specific है?

.agents/tools/ discovery एक Octomind runtime feature है। Octomind के अंदर, हर model — Claude, Kimi, GLM, GPT, local models — इन्हें standard MCP tools के रूप में देखता है। अगर आप Claude Desktop या Cursor भी इस्तेमाल करते हैं, तो आप .agents/tools/ को एक पतले MCP shim के साथ wrap कर सकते हैं, पर सबसे ज़्यादा leverage Octomind के अंदर है जहाँ discovery automatic और project-scoped है।

Secrets के बारे में क्या?

Tool repo में है। Secret नहीं है। Scripts developer के environment से ACME_TOKEN (या समान) पढ़ते हैं — direnv, .envrc, shell rc। Tool commit करें, credential नहीं। अगर env var गायब है, एक स्पष्ट message के साथ non-zero exit करें ताकि model एक गढ़ी हुई error के बजाय असली error surface करे।

क्या agent मेरे हर call को approve किए बिना इनमें से कोई भी tool चला सकता है?

हाँ — किसी भी MCP tool जैसा ही permission flow। Read-only tools (branch, flags) को auto-approve करें। Destructive वाले (deploy, release) के लिए हमेशा पूछें। Octomind permission system के लिए local tools को first-class मानता है।

अगर मुझे multiple repos में एक ही tool चाहिए तो?

दो options। Lightweight: .agents/tools/foo को shared location पर symlink करें। Proper: एक tap author करें — एक Homebrew-style registry। Local tools इस specific repo के लिए हैं। Taps cross-project reusability के लिए हैं।

क्या यह CI / non-interactive runs में काम करता है?

हाँ। octomind run --format=plain और --format=jsonl दोनों .agents/tools/ को honor करते हैं। हम अपने ही CI में इसी तरह agent-driven code review चलाते हैं — review agent के lint, test, और coverage tools सब .agents/tools/ में रहते हैं और team की exact commands को wrap करते हैं।

एक tool नाम built-in से collide करता है। क्या होता है?

Built-in जीतता है। आप shell या view को script का नाम shell रखकर shadow नहीं कर सकते — octomind collision log करता है और original रखता है। Deliberate guardrail।

The Shift

अभी एक कहानी सुनाई जा रही है कि agents का future अधिक MCP servers है — बड़े catalogs, समृद्ध ecosystems, अधिक integrations। RAG-MCP का data, Bloomberry audit, Anthropic की अपनी code-execution post, और CLIs पर चुपचाप वापस जाते developers — सब एक अलग दिशा की ओर इशारा करते हैं: जो agents असली repos में सबसे अच्छा perform करते हैं वे कम tools, संकीर्ण tools, और उस project के लिए लिखे गए tools देखते हैं जिसमें वे हैं।

एक .agents/tools/ script उस pattern की सबसे छोटी संभव unit है। साठ सेकंड "मैं इस पर agent को drift करते देख रहा हूँ" से "agent के पास इसके लिए tool है, team के पास है, यह git में है, हम आगे बढ़ते हैं" तक।

अगली बार जब आप खुद को कुछ दो बार समझाते हुए पाएँ, इसे try करें।

— Don

Octomind Apache-2.0 के तहत open source है। Local-tool feature 0.29.0 में ship हुआ। अगर यहाँ कुछ workflow unblock करता है, issue खोलें — May में request किए गए features June में ship हो जाते हैं।