Claude Code कस्टम स्लैश कमांड: /review, /handoff और /release को टीम मानक बनाएं

आप वही review checklist फिर से चिपकाते हैं। release से पहले steps याद करने पड़ते हैं। Claude Code की लंबी session के बाद भी यह लिखना पड़ता है कि क्या बदला, क्या verify हुआ और क्या जोखिम बचा है। AI coding agent जितना उपयोगी होता जाता है, ये छोटे दोहराए जाने वाले prompts उतने ही ज़रूरी operational pattern बन जाते हैं।

Custom slash commands इन दोहराए गए prompts को छोटे team-owned नामों में बदलते हैं। /review, /handoff और /release सिर्फ shortcuts नहीं हैं। सही तरीके से बनाए जाएँ तो वे team की shared process बनते हैं: code कैसे review होगा, context कैसे handoff होगा और release के लिए क्या evidence चाहिए।

यह guide 3 जून 2026 को verify की गई Claude Code Skills official documentation और Commands reference पर आधारित है। मुख्य बदलाव यह है कि custom commands अब Skills में merge हो चुके हैं। पुराने .claude/commands/*.md files अभी भी काम करते हैं, लेकिन नए team workflows के लिए .claude/skills/<name>/SKILL.md ज़्यादा साफ़ और reviewable pattern है।

मुख्य बात: command एक reusable work procedure है

Claude Code में command session के अंदर / से शुरू होने वाला message है। official reference के अनुसार command message की शुरुआत में पहचाना जाता है, और command name के बाद का text arguments के रूप में pass होता है। इसलिए /release 1.8.0 में 1.8.0 version बन सकता है, और /handoff frontend reviewer handoff note के audience को बता सकता है।

Skill को सरल भाषा में Claude के लिए reusable instruction package मानें। यह एक छोटा playbook है: कब use करना है, कौन से steps follow करने हैं, कौन सा input मायने रखता है और output किस format में चाहिए। .claude/commands/ वाले पुराने files valid हैं, लेकिन Skills directory structure, frontmatter, supporting files, named arguments और बेहतर review workflow देते हैं।

पहला practical caution नाम को लेकर है। current Claude Code environments में /review, /code-review या /security-review पहले से मौजूद हो सकते हैं। अपना /review बनाने से पहले Claude Code में / टाइप करके menu देखें। अगर नाम मौजूद है, तो /team-review, /review-note या कोई team-specific नाम चुनें। इस article में pattern /review है; actual command name आपके environment के हिसाब से होना चाहिए।

File layout: Skills को प्राथमिकता दें, Commands को compatibility के लिए रखें

Team rule project में होनी चाहिए, किसी एक developer के home directory में नहीं। Project Skills Git में commit किए जा सकते हैं, pull request में review हो सकते हैं और repository के साथ evolve कर सकते हैं। Personal Skills उपयोगी हैं, लेकिन वे shared team process का source नहीं होने चाहिए।

Location	Example	Best use
Project Skill	`.claude/skills/team-review/SKILL.md`	Shared review, release, investigation और onboarding routines
Project Command	`.claude/commands/handoff.md`	Existing lightweight commands या migration compatibility
Personal Skill	`~/.claude/skills/my-note/SKILL.md`	Personal notes और private daily workflows
Personal Command	`~/.claude/commands/my-command.md`	Temporary shortcuts

एक practical repository layout ऐसा हो सकता है:

.claude/
├── commands/
│   └── handoff.md
└── skills/
    ├── team-review/
    │   ├── SKILL.md
    │   └── checklists/
    │       └── review.md
    └── release-prep/
        ├── SKILL.md
        └── scripts/
            └── collect-release-notes.sh

Mental model सरल है: repository procedure रखता है, slash menu उसे command की तरह दिखाता है, user arguments देता है, और Claude Code उस procedure को current task context से जोड़ता है।

flowchart LR
  A[".claude/skills या .claude/commands"] --> B["/team-review जैसा command"]
  B --> C["Arguments: $ARGUMENTS या $version"]
  C --> D["Claude Code instructions load करता है"]
  D --> E["Review, handoff या release preparation"]
  E --> F["Human merge या ship का decision लेता है"]

Skill add या edit करने के बाद देखें कि वह / menu में आता है या नहीं। अगर current session update नहीं उठाता, तो /reload-skills use करें या fresh Claude Code session खोलें। Description भी check करें, क्योंकि team members उसी से command discover करते हैं।

Copy-paste starter template

छोटा शुरू करें। यह example /team-review बनाता है ताकि built-in /review से conflict न हो।

mkdir -p .claude/skills/team-review
cat > .claude/skills/team-review/SKILL.md <<'EOF'
---
description: Review the current change with the team's checklist before a pull request or merge.
argument-hint: [target-branch-or-path]
disable-model-invocation: true
---

You are performing a read-only team review.

Target: $ARGUMENTS

If the target is empty, ask which diff, branch, or path to review before scanning broadly.
Do not edit files.
Do not run destructive commands.

Review from these perspectives:
1. Correctness bugs and edge cases
2. Security and privacy risks
3. Test coverage and missing verification
4. Consistency with existing code patterns
5. Documentation, migration notes, and user-facing copy

Output:
- Findings first, ordered by severity
- File path and line number when available
- One short suggestion for each issue
- "No blocking findings" only if you found none
EOF

अब इसे /team-review main, /team-review src/auth या किसी focused target के साथ चलाएँ। disable-model-invocation: true Claude को यह Skill अपने आप चुनने से रोकता है। Review और release जैसे workflows में यह अच्छा है, क्योंकि ये human-triggered checkpoints होने चाहिए।

Use case 1: /review को team checklist बनाना

Review command का value consistency में है। Shared checklist नहीं होगी तो कोई naming देखेगा, कोई security, कोई tests। Command को severity, scope और output format define करना चाहिए ताकि Claude और humans एक ही standard से review करें।

अगर आपके environment में /review पहले से है, तो team-review.md या team-review Skill use करें। अगर conflict नहीं है, तो .claude/commands/review.md अभी भी /review बना सकता है।

---
description: Team review checklist for the current branch or specified path.
argument-hint: [branch-or-path]
disable-model-invocation: true
---

Review target: $ARGUMENTS

Read the diff or files related to the target and report only review findings.
Do not rewrite code unless the user asks for fixes after the review.

Severity:
- P0: data loss, auth bypass, secret leak, production outage
- P1: correctness bug, missing validation, broken user flow
- P2: maintainability, unclear naming, duplicated logic
- P3: optional cleanup

Required checks:
1. Is the change scoped to the request?
2. Are tests or manual verification enough for the risk?
3. Are error paths and empty states handled?
4. Does the code follow existing local patterns?
5. Could the change break monetization links, analytics, or release notes?

Return a short summary after the findings.

सबसे ज़रूरी line है “Do not rewrite code”। अगर review command चुपचाप files edit करता है, तो वह review नहीं, implementation task बन जाता है। पहले read-only review करें, findings accept हों तो अलग fix task शुरू करें।

Use case 2: /handoff से next person या agent को context देना

Long sessions का value तब गिरता है जब अंत में context साफ़ न हो। /handoff task के end को structured note में बदलता है, जिसे tomorrow-you, teammate या next agent पढ़ सके।

---
description: Create a concise handoff note for the current task.
argument-hint: [next-owner-or-audience]
disable-model-invocation: true
---

Create a handoff note for: $ARGUMENTS

Include these sections:
1. Goal: what the task was trying to achieve
2. Changed files: important files and why they changed
3. Decisions: tradeoffs or assumptions made during the work
4. Verification: commands run, screenshots checked, or checks not run
5. Risks: unresolved issues, fragile areas, or things needing human review
6. Next steps: the smallest useful next action

Keep it factual. Do not hide failed attempts. If something was not verified, say so clearly.

Monetized content sites और production apps में यह खास उपयोगी है। Internal links, CTAs, analytics events, screenshots और manual checks कई files के बीच आसानी से छूट जाते हैं। Handoff command इन details को visible रखता है।

Use case 3: /release को publish नहीं, preparation के लिए रखें

Release commands conservative होने चाहिए। लक्ष्य यह नहीं है कि Claude आपके लिए publish करे। लक्ष्य है context collect करना, changelog draft करना, blockers list करना और final release decision human के पास रखना।

यह template named arguments use करता है। current docs में arguments positional inputs को names से map करता है, इसलिए पहला argument $version बनता है।

---
description: Prepare a release checklist and changelog draft without publishing.
argument-hint: [version]
arguments: [version]
disable-model-invocation: true
---

Prepare release $version.

Allowed work:
1. Inspect the current diff, package metadata, and changelog
2. Draft a changelog section for $version
3. Suggest verification commands
4. List release blockers and rollback notes
5. Propose a commit message

Safety rules:
- Do not run git push
- Do not publish packages
- Do not deploy to production
- Do not delete files
- Ask before changing version files

Output:
- Release summary
- Checklist
- Blockers
- Commands the user should run manually

यह release-prep command है, release button नहीं। अगर team publishing automate करना चाहती है, तो उसे CI/CD में रखें, जहाँ approvals, logs और rollback rules साफ़ हों।

Arguments: $ARGUMENTS से शुरू करें

अधिकतर custom commands के लिए $ARGUMENTS काफी है। /handoff backend reviewer में backend reviewer $ARGUMENTS में आएगा। Current docs $ARGUMENTS[0], $0 और frontmatter में declared named arguments जैसे $issue या $branch भी support करते हैं।

---
description: Prepare an issue-specific work plan.
argument-hint: [issue] [branch]
arguments: [issue, branch]
disable-model-invocation: true
---

Issue: $issue
Branch: $branch
All arguments: $ARGUMENTS

Create a plan that:
1. Restates the issue in plain language
2. Lists files to inspect first
3. Identifies likely tests
4. Names one thing that should not be changed

Multi-word argument को साथ रखना हो तो quotes use करें: /plan-issue "login redirect bug" fix-login। पुराने snippets में अगर $1 को first argument बताया गया है, तो current docs से मिलाएँ। Current docs $0 को first positional argument का shorthand बताते हैं।

Versioning और review workflow

Project Skills और Commands को code की तरह treat करें। वे तय करते हैं कि क्या review होगा, क्या छूटेगा और team किसे done मानेगी। .claude/skills/release-prep/SKILL.md में बदलाव pull request में साफ़ दिखना चाहिए, किसी unrelated feature diff में छिपना नहीं चाहिए।

Rule	Purpose
`.claude/skills/` को Git में रखें	Workflow किसने और कब बदला, यह दिखता है
Command-only PRs allow करें	Process changes app code में mix नहीं होते
README या `CLAUDE.md` में commands list करें	New members उन्हें जल्दी खोजते हैं
Prompt में destructive actions ban करें	push, publish, deploy या delete से बचाव
महीने में एक बार cleanup करें	पुरानी commands confusion नहीं बनतीं

Team rollout के लिए इसे Claude Code getting started guide, CLAUDE.md best practices और Claude Code hooks guide के साथ पढ़ें।

Pitfalls और security

सबसे बड़ा mistake है यह मान लेना कि custom command short है इसलिए safe है। वह अभी भी powerful prompt है। अगर आप ! backticks के साथ dynamic context injection use करते हैं, तो Claude Code shell command चलाता है और output को Skill content में Claude के पढ़ने से पहले insert करता है। यह उपयोगी है, लेकिन read-only boundary ज़रूरी है।

---
description: Collect read-only git context for release notes.
disable-model-invocation: true
---

Current status:
!`git status --short`

Recent commits:
!`git log --oneline -20`

Summarize the release notes from the information above.
Do not run write operations.

ऐसे commands को git status और git log जैसी safe inspection तक सीमित रखें। rm, git clean, git push, npm publish, curl ... | sh या production-impacting scripts न डालें। allowed-tools में भी सावधानी रखें: broad Bash access confirmation prompts घटा सकता है। पहले read-only tools से शुरू करें और permission केवल real need पर बढ़ाएँ।

Concrete failure cases आम हैं। Custom /review built-in command से conflict करता है। Skill सिर्फ एक व्यक्ति के home directory में रहता है। Skill body इतना लंबा हो जाता है कि हर load में context खर्च होता है। Empty argument Claude से पूरा repository scan करवा देता है। Release command publishing तक चला जाता है। ये सब convenience को बहुत जल्दी automate करने से होते हैं। Read-only, छोटा target और human confirmation को default रखें।

CTA: templates को अपनी team process में बदलें

इन templates का value तभी है जब वे आपके repository से match करें। Solo developers free Claude Code cheatsheet से शुरुआत कर सकते हैं और safe command patterns पास रख सकते हैं। Reusable review, release और handoff templates के लिए ClaudeCodeLab products देखें। अगर आपकी team permissions, CLAUDE.md, Skill review, CI boundaries और onboarding को साथ design करना चाहती है, तो Claude Code training and consultation बेहतर रास्ता है।

Masa के workflow में इसे आज़माने पर result साफ़ था: तीन commands काफी थे। /team-review, /handoff और /release-prep ने अधिकतर repeated work cover किया, लेकिन Claude Code को unsafe deployment tool नहीं बनाया। सबसे बड़ा सुधार तब आया जब /release को publish करने वाला command नहीं, बल्कि human decision के लिए evidence collect करने वाला command माना गया। Custom slash commands तब सबसे उपयोगी हैं जब वे team को same standard पर रुकने, check करने और context handoff करने में मदद करते हैं।