Claude Code से डेवलपमेंट वर्कफ़्लो ऑटोमेट करने की व्यावहारिक गाइड

Claude Code से वर्कफ़्लो ऑटोमेशन का मतलब यह नहीं है कि एजेंट को बिना निगरानी merge करने दिया जाए। सुरक्षित तरीका छोटा और स्पष्ट होता है: Claude Code से Issue का सार बनवाना, सीमित बदलाव करवाना, PR समीक्षा करवाना, मेंटेनेंस रिपोर्ट बनवाना, और जहाँ इंसानी निर्णय चाहिए वहाँ रुकना।

इस गाइड में gh, git, node, npm और claude कमांड के साथ चलने वाले उदाहरण हैं। असली लाभ तब मिलता है जब ऑटोमेशन को एक नियंत्रित ढाँचे की तरह बनाया जाए: input क्या होगा, कौन से action अनुमति में हैं, logs कहाँ रहेंगे, retry कैसे होगा, rollback कैसे होगा, और किन बिंदुओं पर मानव approval अनिवार्य होगा।

पहले ऑटोमेशन की सीमा तय करें

चरण	Claude Code क्या करे	इंसान क्या तय करे
छँटाई	Issue, diff और failing logs का सार	priority और product निर्णय
बदलाव	छोटे fixes, tests, docs update	scope और release निर्णय
समीक्षा	bug, security risk, missing tests	कौन सा सुझाव लागू करना है
संचालन	scheduled checks, पुराने TODO, dependencies	merge, delete, release, billing impact

flowchart LR
  A["Issue / PR"] --> B["छोटा prompt"]
  B --> C["Claude Code"]
  C --> D["diff और logs"]
  D --> E["tests"]
  E --> F["मानव approval"]
  F --> G["PR / release"]

पूरे pipeline संदर्भ के लिए Claude Code CI/CD setup guide और Claude Code Hooks guide भी देखें।

उपयोग केस 1: Issue से सुरक्षित work branch बनाना

यह script GitHub Issue पढ़ती है, deterministic branch बनाती या reuse करती है, Claude Code से सबसे छोटा उपयोगी बदलाव करवाती है, tests चलाती है, और commit का निर्णय आपके पास छोड़ती है।

इसे scripts/claude-issue-work.sh के रूप में सेव करें।

#!/usr/bin/env bash
set -euo pipefail

ISSUE_NUMBER="${1:-}"
if [ -z "$ISSUE_NUMBER" ]; then
  echo "Usage: ./scripts/claude-issue-work.sh <issue-number>"
  exit 1
fi

for command_name in git gh claude npm; do
  if ! command -v "$command_name" >/dev/null 2>&1; then
    echo "Missing command: $command_name"
    exit 1
  fi
done

: "${ANTHROPIC_API_KEY:?Set ANTHROPIC_API_KEY before running this script}"

mkdir -p .claude-logs
ISSUE_FILE=".claude-logs/issue-${ISSUE_NUMBER}.md"
LOG_FILE=".claude-logs/issue-${ISSUE_NUMBER}-$(date +%Y%m%d-%H%M%S).log"
BRANCH="claude/issue-${ISSUE_NUMBER}"

gh issue view "$ISSUE_NUMBER" --json title,body,labels --jq '
  "# " + .title + "\n\n" + (.body // "") + "\n\nLabels: " + ([.labels[].name] | join(", "))
' > "$ISSUE_FILE"

if git show-ref --verify --quiet "refs/heads/$BRANCH"; then
  git switch "$BRANCH"
else
  git switch -c "$BRANCH"
fi

PROMPT=$(cat <<PROMPT
आप इस repository के development assistant हैं।
नीचे दिए गए Issue को पढ़ें और सबसे छोटा उपयोगी बदलाव करें।

सीमाएँ:
- edit करने से पहले संबंधित files inspect करें।
- मौजूदा architecture, naming और test style को प्राथमिकता दें।
- requirement अस्पष्ट हो तो बड़ा design न गढ़ें; TODO या सवाल छोड़ें।
- secrets, environment files या unrelated articles को न छुएँ।
- repository को npm test चलाने लायक छोड़ें।
- commit, push, PR create या merge न करें।

Issue:
$(cat "$ISSUE_FILE")
PROMPT
)

claude -p "$PROMPT" \
  --max-turns 8 \
  --permission-mode acceptEdits \
  --output-format text 2>&1 | tee "$LOG_FILE"

npm test 2>&1 | tee -a "$LOG_FILE"
git diff --stat | tee -a "$LOG_FILE"

echo "Review the diff, then commit manually if it is correct."
echo "Log: $LOG_FILE"

यहाँ सुरक्षा बहुत जटिल नहीं है, पर असरदार है। ANTHROPIC_API_KEY न हो तो script शुरुआत में ही रुकती है। branch का नाम fixed है, इसलिए दोबारा run करने पर duplicate branch नहीं बनती। .claude-logs में prompt और test output बचते हैं, जिससे अगले दिन debugging आसान रहती है।

उपयोग केस 2: GitHub Actions में PR review gate जोड़ना

आधिकारिक Claude Code GitHub Action PR events पर चल सकता है। नीचे वाला workflow सिर्फ review करता है; code edit, push और merge की अनुमति नहीं देता।

इसे .github/workflows/claude-review.yml के रूप में सेव करें।

name: Claude Review Gate

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            इस Pull Request की समीक्षा करें।
            bug, security, missing tests, backward compatibility और operational logs पर ध्यान दें।
            हर finding को high, medium या low severity दें और fix suggestion ठोस लिखें।
            code edit, push या merge न करें।
          claude_args: |
            --max-turns 6
            --permission-mode plan

Permissions कम रखें। PR review के लिए आम तौर पर contents: read और pull-requests: write मुख्य होते हैं। अगर workflow Issue पर भी comment करता है, तभी issues: write जोड़ें।

पुराने उदाहरण copy करने से पहले Claude Code CLI official reference, Claude Code GitHub Actions official docs और GitHub Actions workflow syntax देखें। @beta या direct_prompt वाले पुराने snippets को आज के @v1 और prompt format में बदलना चाहिए।

उपयोग केस 3: Node.js से maintenance report बनाना

Scheduled maintenance को files बदलने की जरूरत नहीं होती। failing tests, बड़े diffs, पुराने TODO, missing logs और rollback risk की report भी बहुत काम बचा सकती है।

इसे scripts/claude-maintenance.mjs के रूप में सेव करें।

#!/usr/bin/env node
import { spawnSync } from "node:child_process";
import { existsSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
import { join } from "node:path";

const logDir = ".claude-logs";
const lockFile = join(logDir, "maintenance.lock");
const stamp = new Date().toISOString().replace(/[:.]/g, "-");
const logFile = join(logDir, `maintenance-${stamp}.log`);

function fail(message) {
  console.error(message);
  process.exit(1);
}

function run(command, args, options = {}) {
  const result = spawnSync(command, args, {
    encoding: "utf8",
    shell: process.platform === "win32",
    ...options,
  });

  const output = `${result.stdout || ""}${result.stderr || ""}`;
  if (result.status !== 0) {
    writeFileSync(logFile, output);
    fail(`Command failed: ${command} ${args.join(" ")}. See ${logFile}`);
  }
  return output;
}

if (!process.env.ANTHROPIC_API_KEY) {
  fail("Set ANTHROPIC_API_KEY before running this script.");
}

mkdirSync(logDir, { recursive: true });
if (existsSync(lockFile)) {
  fail(`Another maintenance run is active: ${lockFile}`);
}

writeFileSync(lockFile, String(process.pid));

try {
  const status = run("git", ["status", "--short"]);
  const tests = run("npm", ["test", "--", "--runInBand"]);
  const prompt = [
    "आप इस repository के maintenance reviewer हैं।",
    "git status और test output पढ़कर आज के risks summarize करें।",
    "कुछ भी edit, delete, commit या push न करें।",
    "report को credentials / idempotency / retry / rollback / logs / human approval में group करें।",
    "",
    "git status:",
    status || "(clean)",
    "",
    "test output:",
    tests.slice(-12000),
  ].join("\n");

  const review = run("claude", [
    "-p",
    prompt,
    "--max-turns",
    "5",
    "--permission-mode",
    "plan",
    "--output-format",
    "text",
  ]);

  writeFileSync(logFile, review);
  console.log(`Maintenance report written to ${logFile}`);
} finally {
  rmSync(lockFile, { force: true });
}

अगर आपका project Jest नहीं चलाता, तो npm test -- --runInBand को अपने test command से बदलें। script सिर्फ आखिरी 12000 characters भेजती है, क्योंकि बहुत लंबा prompt असली failure line को छिपा देता है।

उपयोग केस 4: cron या Task Scheduler से चलाना

Linux और macOS पर cron इस्तेमाल करें। Windows पर Task Scheduler इस्तेमाल करें। GitHub Actions का schedule भी काम करता है, लेकिन local database, VPN या internal credentials वाले checks के लिए local run अक्सर बेहतर होता है।

# weekdays 08:15 पर चलाएँ
15 8 * * 1-5 cd /path/to/repo && /usr/bin/node scripts/claude-maintenance.mjs >> .claude-logs/cron.log 2>&1

# Windows daily task register करें
schtasks /Create /TN "ClaudeMaintenance" /SC DAILY /ST 08:15 /F /TR "powershell -NoProfile -ExecutionPolicy Bypass -Command \"cd C:\path\to\repo; node scripts\claude-maintenance.mjs\""

Scheduled automation idempotent होनी चाहिए। idempotent का मतलब है कि वही काम दो बार चलाने पर duplicate PR, duplicate comment या duplicate branch न बने। lock file, stable branch name, existing PR check और logs रखें।

उपयोग केस 5: prompt में मानव approval लिखना

छोटा prompt हमेशा सुरक्षित नहीं होता। अच्छे workflow prompt में allowed, forbidden और human approval वाली बातें साफ लिखी जाती हैं।

claude -p "
लक्ष्य:
  PR #123 की review feedback लागू करें।

अनुमति:
  - संबंधित implementation और test files edit करना।
  - npm test चलाना।
  - failing logs summarize करना।

निषिद्ध:
  - git push
  - gh pr merge
  - .env या secrets दिखाना
  - unrelated refactor

मानव approval आवश्यक:
  - API response compatibility बदलना
  - database migration जोड़ना
  - existing tests हटाना

अंतिम report:
  - बदली गई files
  - चलाए गए tests
  - बचे हुए risks
  - rollback steps
" --max-turns 6 --permission-mode acceptEdits

Review structure के लिए Claude Code review checklist और verification receipt workflow देखें।

जिन failure modes के लिए पहले से design करें

Failure mode	क्या होता है	व्यावहारिक उपाय
Prompt बहुत लंबा	constraints दब जाते हैं, run धीमा होता है	केवल relevant files और log tail भेजें
Credentials missing	CI ANTHROPIC_API_KEY या GH_TOKEN पर fail होता है	शुरुआत में env vars validate करें
Idempotency नहीं	duplicate PR, comments या branches बनते हैं	stable names, locks और state checks
Logs नहीं	एजेंट ने क्या किया, कोई नहीं जानता	.claude-logs या GitHub artifacts save करें
Retry गलत	temporary failure duplicate write बन जाता है	reads retry करें, write से पहले state फिर check करें
Rollback नहीं	बड़ा commit revert करना मुश्किल होता है	छोटे PR और rollback notes रखें
Approval gate नहीं	एजेंट product या release decision लेता है	compatibility, data, billing, deletion और merge मानव रखें

संबंधित विषयों के लिए Claude Code security audit, Claude Code testing strategies और Git workflow automation पढ़ें।

Monetization CTA और AdSense ध्यान

इस विषय की स्वाभाविक conversion practical help है। अकेले काम कर रहे हैं तो Claude Code free cheatsheet से शुरू करें। अगर टीम को repository-specific prompts, review gates, approval policy और rollout training चाहिए, तो Claude Code training और consultation देखें। Ready-to-use setup material के लिए Claude Code setup guide paid shortcut है।

Ads और CTA को command sequence के बीच में न रखें। AdSense quality के लिए इस तरह के article में runnable code, concrete failure modes, official links, internal links और hands-on result होना चाहिए।

निष्कर्ष

Claude Code workflow automation तब भरोसेमंद होती है जब stop points पहले design हों। Issue triage और PR review से शुरू करें, फिर छोटे edits जोड़ें, और अंत में scheduled maintenance तथा human approval वाले CI gates तक जाएँ।

Masa के practical test में सबसे बड़ा लाभ automatic PR creation नहीं था। असली लाभ repeatable Issue logs और fixed PR review prompt से आया। ANTHROPIC_API_KEY missing, बहुत लंबा test output और उसी branch पर दोबारा run करने से एक-एक बार failure हुआ, लेकिन env checks, log tailing और deterministic branch names जोड़ने के बाद अगला diagnosis बहुत आसान हो गया।