Claude Code और OpenCode: 90-minute crash course

15 concepts, real use का 80%

एक practical crash course. कोई filler नहीं, कोई upsell नहीं। अंत तक आपको पता होगा कि क्या use करना है, कब use करना है, और दोनों tools में ज़्यादा detail चाहिए तो कहाँ देखना है।

वह एक insight जिससे बाकी सब click करता है: agentic coding असल में context-management problem है, जिसने coding tool की costume पहनी हुई है। लगभग हर "advanced technique" एक ही बात पर आ जाती है: सही information को सही समय पर model के अंदर लाना, और गलत information को बाहर रखना। हर section को इसी lens से पढ़ें।

Prerequisite: AI Prompting in 2026. यह page मानता है कि वे तेरह concepts पहले से आपके हाथ में हैं। Colleague की तरह brief करना (concept 1), context को पूरा खेल मानना (concept 4), thinking mode (concept 5), neutral framing (concept 6), iterate loop (concept 7), models से models को check कराना (concept 13): यही discipline है। यह page दिखाता है कि जब model आपके filesystem को touch कर सकता है, तो वही discipline कैसी दिखती है।

Claude Code और OpenCode एक ही idea की दो implementations हैं, जिनकी vocabulary ज़्यादातर वही है और keybinds थोड़े अलग हैं।

दो tools, एक नहीं। जानबूझकर। यहाँ की discipline किसी एक tool से लंबी उम्र रखनी चाहिए। Pricing बदलती है, access restrictions बदलते हैं, model preferences बदलते हैं, strategic shifts आते हैं; आपने जो lessons सीखे हैं वे इनसे stranded नहीं होने चाहिए। हर concept को दोनों tools में दिखाना यह test करने का सबसे अच्छा तरीका भी है कि concept सच में real है या नहीं: अगर कोई technique सिर्फ़ Claude Code में काम करती है, तो वह Claude Code trick है; अगर दोनों में काम करती है (shape वही, keybind अलग), तो वह agentic coding के व्यवहार का हिस्सा है। Frontier model performance constraint हो तो Claude Code reach करें; flexibility, cost control, या openness चाहिए तो OpenCode reach करें। OpenCode free models का set भी देता है जिसे account बनाए बिना use कर सकते हैं। किसी भी तरफ़ से जो skills बनती हैं, वे वही रहती हैं। यही point है, compromise नहीं।

मई 2026 तक current. दोनों tools तेज़ी से ship करते हैं: config schemas, command names, और install commands बदलते हैं। अगर tools अभी आपके पास नहीं हैं, तो installation instructions उन्हीं docs pages पर हैं: Claude Code, OpenCode. किसी और चीज़ पर doubt हो, तो शुरुआत भी वहीं से करें.

दोनों tools frequent update होते हैं; इसलिए कोई भी session शुरू करने से पहले latest version use करने के लिए claude update और opencode upgrade commands दें।

Assumed background: आप command line पर comfortable हैं, आपने git use किया है, और JSON config पहले पढ़ा या लिखा है। LLM coding agents का prior experience ज़रूरी नहीं। यही page उसी के लिए है। अगर MCP, hooks, या LLMs और external tools के बीच protocol layer आपके लिए brand new हैं, तो आगे चलते हुए context से पकड़ लेंगे.

अपना tool चुनें, page follow करेगा

इस पूरे page में जहाँ Claude Code और OpenCode अलग होते हैं, वहाँ switcher है। एक tool चुनें और page का हर switcher उसी से sync हो जाएगा; आपकी choice visits के बीच persist करेगी।

इस page के किसी भी concept का deep version चाहिए?

यह crash course है: एक reading में real use का 80%. नीचे के हर topic की full treatment (rules-file hierarchy, plan mode at depth, skill anatomy, subagent orchestration, hook events, CI/CD, session management) के लिए Chapter 14: Working with General & Coding Agents और Chapter 17: Claude Code for Teams, CI/CD & Advanced Configuration देखें। Crash course map है; वे chapters terrain हैं।

Part 6 में एक complete worked example है: एक realistic task end-to-end, दो बार run किया गया, एक बार हर tool में। अगर आप definitions पढ़ने से ज़्यादा देखकर सीखते हैं, तो पहले वहाँ jump करें और फिर वापस आएँ।

---

Part 1: बुनियाद

ये पहले तीन concepts दोनों tools में identically apply होते हैं। जहाँ commands या keybinds अलग हैं, difference inline बताया गया है।

1. ये tools असल में क्या हैं

ज़्यादातर लोगों का mental model होता है: "एक chatbot जो code जानता है।" यह गलत है, और यही गलती problem है।

Chatbot सवालों के जवाब देता है। Claude Code और OpenCode actions लेते हैं। वे आपकी files पढ़ते हैं, उन्हें edit करते हैं, आपकी machine पर commands run करते हैं, network hit करते हैं, और इन सबको chain करके task पूरा होने तक चलते हैं। आप उन्हें brief देते हैं, वे काम करते हैं, आप review करते हैं।

Mindset shift: सवाल type करना बंद करें, briefs लिखना शुरू करें। "How do I add auth?" chatbot prompt है। "Add email/password auth to this Express app using bcrypt and JWT, store users in the existing Postgres users table, write tests, don't touch the OAuth code" agentic-coding prompt है। दूसरा काम करेगा; पहला भटकती हुई monologue पैदा करेगा।

यह AI Prompting का concept 1 (novice vs. power user) है, PDFs की जगह files के साथ। Brief की shape वही है; stakes ज़्यादा हैं, क्योंकि model उस पर action लेता है।

दोनों tools defaults में अलग हैं, fundamentals में नहीं। Claude Code Anthropic का है, Claude models के साथ आता है, और out of the box polished है। OpenCode open-source है, model-agnostic है (Claude, GPT, Gemini, local), और tool-level permission तक configurable है। अपनी model preferences और config control की ज़रूरत के हिसाब से एक चुनें; इस crash course का बाकी हिस्सा दोनों में काम करता है।

अभी तक कोई tool install नहीं है? आगे पढ़ने से पहले canonical one-liner ले लें; इसके बाद के sections मानते हैं कि आप key press करके कुछ होता हुआ देख सकते हैं। Auth, IDE plugins, और troubleshooting official docs पर हैं।

# macOS / Linux / WSL — recommended (auto-updates)
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# macOS Homebrew (no auto-update — run `brew upgrade claude-code` periodically)
brew install --cask claude-code

# npm fallback
npm install -g @anthropic-ai/claude-code

Full reference: code.claude.com/docs.

Install होने के बाद, जिस folder में काम करना है उसमें terminal open करें और claude (या opencode) type करें। इससे आपका पहला session खुल जाएगा। यहाँ से आगे, इस page का हर concept ऐसा है जिसे आप उसी session में try कर सकते हैं।

2. Plan mode (सबसे कम इस्तेमाल होने वाला feature)

Implementations थोड़ी अलग हैं, लेकिन idea identical है: model को कुछ भी write करने देने से पहले, उसे एक written plan produce करने पर force करें जिसे आप review कर सकें।

Permission modes cycle करने के लिए Shift+Tab press करें। पहला press आपको auto-accept में डालता है; दूसरा press plan mode में डालता है। Plan mode में model read कर सकता है लेकिन write नहीं कर सकता: न file edits, न shell commands।

दोनों cases में यह move आपको दो reasons से slow करता है जो असल में speedups हैं:

1. यह misunderstandings को cost आने से पहले पकड़ता है। Plan contract है। अगर model ने brief misread किया है, तो वह आपको plan में दिखता है, उस 200-line diff में नहीं जिसे revert करना पड़े।
2. यह second pass पर बेहतर code produce करता है। Pre-written plan relevant context (file paths, function names, intended approach) को clean artifact में compress करता है जिस पर implementation phase lean कर सकता है। Plan के बिना model साथ-साथ reason और write कर रहा होता है, और reasoning हारती है।

Rule of thumb: 10-minute change से बड़ा कुछ भी पहले plan mode से गुज़रे। Larger features के लिए model से plan को markdown file (docs/plans/feature-x.md) में save करने को कहें ताकि आप बाद में resume कर सकें या fresh session को feed कर सकें।

Plan mode एक move में दो prompting concepts है: think hard (concept 5) contract के साथ, और outline before drafting (concept 7) filesystem के साथ। Plan edit करें, diff नहीं।

3. Permissions की discipline

दोनों tools action लेने से पहले approval माँगते हैं। दोनों आपको approvals globally skip करने देते हैं: Claude Code में --dangerously-skip-permissions है, OpenCode में आप "permission": "allow" set कर सकते हैं। कम से कम शुरुआत में ऐसा न करें।

काम करने वाला pattern: कुछ sessions manual start करें, देखें कौन से actions auto-approve करने लायक safe हैं, फिर उसे config में लिखें।

.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": ["Bash(rm -rf *)", "Bash(npm publish *)", "Bash(git push *)"]
  }
}

फिर notification helper install करें। Agentic coding को fast feel कराने वाला pattern faster execution नहीं है: यह walk away करने की ability है। Long task set करें, दूसरे काम पर switch करें, ping आए तो वापस आएँ। अगर आप parallel में multiple sessions run करते हैं (real thing, और real productivity unlock), notifications ही बताती हैं कि किस session को आपकी ज़रूरत है।

Claude Code में cc-notify जैसे community helpers हैं। OpenCode का desktop app system notifications natively भेजता है; TUI के लिए, ऐसा plugin लिखें जो session.idle subscribe करे और osascript (macOS) या notify-send (Linux) को shell out करे।

---

Part 2: Context management

अगर इस crash course में सिर्फ़ एक section internalize करना है, तो इसे करें। यहाँ की हर बात दोनों tools पर identically apply होती है; सिर्फ़ command names कभी-कभी अलग होते हैं।

यह AI Prompting का concept 4 (context is the whole game) है, volume बढ़ाकर। वहाँ खराब context से खराब answer मिलता था। यहाँ उससे खराब answer और खराब codebase मिलती है। Discipline वही है, consequences compound होते हैं।

4. Context rot real है

Context window text की वह amount है जिसे model एक साथ hold कर सकता है। Modern models में huge windows हैं: hundreds of thousands of tokens, कभी-कभी million. यह limitless लगता है। है नहीं।

दो बातें समझें:

Real usage window को आपकी सोच से तेज़ भर देता है। कुछ code files, stack trace, paste की गई docs, और 30-turn conversation आपके notice करने से पहले tens of thousands tokens खा लेंगी। आपके laptop पर fuel gauge नहीं दिखता।

Window full होने से बहुत पहले recall degrade हो जाता है। Studies (और आपका अपना experience, अगर आप ध्यान दें) दिखाते हैं कि token counts बढ़ने पर model context की earlier specific details याद रखने में noticeable रूप से खराब होता जाता है। Model exactly forget नहीं करता। वह बस उस information को सही weight देना बंद कर देता है। Symptoms: वह 20 messages पहले stated constraint ignore करता है, पहले किया हुआ काम repeat करता है, ऐसी function signature hallucinate करता है जो earlier सही थी।

Financial dimension भी है। हर message पूरी context window को फिर bill करता है: debug session में twenty times ping की गई 50K-token conversation input का million tokens बन जाती है, हर turn charged. Per-token APIs (ज़्यादातर OpenCode setups, raw Anthropic API) पर यह wallet damage है; subscription tiers (Claude Code Pro/Max) पर यह rate-limit hits बनता है। दोनों तरह से, bloated context आपका budget ठीक तब drain करता है जब आपको काम जारी रखना सबसे ज़्यादा चाहिए।

Takeaway romantic नहीं, practical है: deliberately use किया गया कम context, hope में dump किए गए ज़्यादा context से बेहतर है।

5. /clear and /compact

दो commands, दो situations।

Conversation wipe करके fresh start करें। Unrelated task पर switch करते समय use करें। पुराना context irrelevant noise है जो new task को confuse ही करेगा।

• Claude Code: /clear
• OpenCode: /new (also aliased as /clear)

Conversation summarize करें, summary रखें, बाकी discard करें। तब use करें जब आप single long task में deep हैं और context bloated हो रहा है, लेकिन thread खो नहीं सकते।

• Both tools: /compact (in OpenCode, also aliased as /summarize)

Compact में क्या रखना है, आप guide कर सकते हैं: /compact keep the API contract decisions and current file paths.

ये interchangeable नहीं हैं। /clear का मतलब "new conversation" है। /compact का मतलब "same conversation, less baggage" है। गलत command चुनने से या important context खोता है या useless context बचा रहता है।

6. Sessions resume करना

Conversations save होती हैं। दोनों tools resume करने देते हैं, idea वही, command अलग:

• Claude Code: claude --resume और list से session चुनें।
• OpenCode: saved sessions के बीच switch करने के लिए TUI के अंदर /sessions (also aliased as /resume)।

दो patterns जहाँ यह matter करता है:

• कल pickup करें। Long features rarely one sitting में fit होते हैं। Resume आपको stop करने देता है बिना project की model working memory खोए।
• Multiple branches run करें। कोई भी session resume करें, सिर्फ़ last नहीं। एक session backend task में deep हो सकता है और दूसरा frontend पर काम कर सकता है, और आप उनके बीच switch कर सकते हैं।

अगर आपके पास saved plan file (docs/plans/feature-x.md) है, तो fresh session भी एक message में speed up हो सकता है: "read docs/plans/feature-x.md and continue from step 4." Resume faster है, लेकिन plan file safety net है। (Full pattern: कब resume करना, कब fork करना, bad turn के बाद recover कैसे करना, इसके लिए Chapter 17 § Session Management: Resume, Fork, and Recovery देखें।)

Rewind दोनों में exists करता है, और दोनों file changes roll back कर सकते हैं। Claude Code में, previous user messages की list खोलने के लिए Esc twice (double-tap Esc) press करें, या /rewind run करें; एक चुनें और decide करें क्या restore करना है: code, conversation, या दोनों। यह इसलिए काम करता है क्योंकि Claude Code हर prompt से पहले model की file edits को checkpoint करता है। OpenCode में, /undo last user message rewind करता है और उस turn से file changes revert करता है; /redo last /undo reverse करता है। यह under the hood git use करता है, इसलिए आपका project git repo होना चाहिए। एक real difference: Claude Code checkpointing model की file edits track करती है, लेकिन bash commands से बदली files नहीं (model ने rm या mv run किया तो वह checkpointed नहीं है); OpenCode का git-backed /undo, क्योंकि वह whole working tree diff करता है, bash-driven changes भी catch करता है। दोनों bad prompt से rescue करते हैं; जब bad turn में files touch करने वाली shell commands शामिल थीं, तब specifically OpenCode का /undo reach करें।

तीन commands के लिए quick decision rule:

Diagnostic: context खराब होने पर

Context rot के visible symptoms होते हैं। इनमें से कोई भी दिखे तो ध्यान दें:

• Model progress किए बिना repeatedly apologize करने लगता है।
• वही code block meaningful changes के बिना rewrite करता है।
• ऐसे variables, files, या functions reference करता है जो exist नहीं करते।
• उसी session में पहले stated constraint से contradict करता है।
• हर response लंबा, vague, और ज़्यादा deferential होता जाता है।

जब यह दिखे, typing रोक दें। "बस एक और clarifying prompt" की instinct गलत है; इससे पहले से polluted context में और polluted context जुड़ता है। सही move reset और re-brief है। Conversation में useful core बचाना है तो /compact run करें, सच में start over करना है तो /clear (या OpenCode का /new)। Reset में लगे पाँच minutes poisoned context वाले model से argue करने के एक hour से बेहतर हैं।

Diagnostic: context cost spike होने पर

Cost discipline context discipline है; फर्क इतना है कि एक आपको wallet में महसूस होती है। हर turn पूरा context फिर bill करता है, इसलिए जो bloat recall को hurt करता है वही bill को भी hurt करता है। चाहे आप किसी भी provider का use करें, surprise bills के ज़्यादातर cases पाँच symptoms में आ जाते हैं:

Symptom: token usage spiked suddenly mid-session
    → Cause: rules file or system prompt changed, breaking cache hits.
       Fix: revert the change, or accept the cache miss as a one-time cost.

Symptom: each turn costs noticeably more than the previous one
    → Cause: context is growing without bound. Files keep getting read in,
       exploration output is accumulating, conversation is long.
       Fix: /compact with a "keep architectural decisions and current
       file paths" hint.

Symptom: model is over-explaining, producing walls of text
    → Cause: reasoning effort is too high for the task; or the prompt
       invites narration.
       Fix: turn the reasoning effort down; ask for "code only,
       minimal commentary."

Symptom: monthly bill is much higher than expected
    → Cause: running a frontier-tier model on tasks an economy-tier
       model would handle correctly.
       Fix: route mechanical work (codemods, tests, formatting) to the
       cheaper tier; reserve the frontier model for planning and
       hard reasoning. See Part 8 Pattern 1 for the split.

Symptom: cache hits suddenly dropped from ~70% to ~10%
    → Cause: the system prompt, CLAUDE.md, or the first user message
       changed structure. Cache matches prefixes byte-for-byte.
       Fix: stabilize what comes first; let the variable content
       come later.

इनमें से ज़्यादातर single config change में recover हो जाते हैं। पाँचों के नीचे mechanic वही है जिसके लिए Part 2 argue कर रहा है: stable, narrow context sprawling context से cheaper है और बेहतर recall करता है, हर turn पर।

---

Part 3: Rules file

7. CLAUDE.md / AGENTS.md, सही तरह से

दोनों tools हर session की शुरुआत में project-root markdown file को context में load करते हैं। यह project-level system prompt के सबसे करीब है।

इस file को scratch से न लिखें। Fresh project में किसी भी tool में /init run करें। Model आपका folder scan करके file draft कर देगा। उसके बाद आपका काम उन parts को ruthlessly delete करना है जिनकी ज़रूरत नहीं: यह editing task है, authoring task नहीं। नीचे सब इस बारे में है कि क्या रखना है और क्या cut करना है। (Beginner-level walkthrough: Chapter 14 § CLAUDE.md and AGENTS.md. Advanced: multi-file hierarchy, glob-scoped rules, team conventions के लिए Chapter 17 § The CLAUDE.md Configuration Hierarchy.)

Claude Code CLAUDE.md use करता है। OpenCode AGENTS.md use करता है। Migrators के लिए, OpenCode AGENTS.md present न हो तो fallback के रूप में CLAUDE.md भी पढ़ता है; अगर दोनों files exist करती हैं, तो AGENTS.md जीतता है और CLAUDE.md ignored रहता है। अगर आपने पहले से CLAUDE.md maintain किया है, तो OpenCode उसे उठा लेगा जब तक आप पूरी तरह opt out करने के लिए OPENCODE_DISABLE_CLAUDE_CODE=1 set न करें। Partial disable के लिए, OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=1 सिर्फ़ rules-file fallback skip करता है और OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1 सिर्फ़ skills fallback skip करता है। यह दोनों tools के बीच single biggest portability win है।

लगभग हर कोई जो mistake करता है: इस file को documentation की तरह treat करना, architecture overviews, full coding standards, और codebase की हर quirk उसमें ठूँस देना। Result 20,000-token file है जो हर task पर आपका context budget खाती है, उन tasks में भी जहाँ इसका 90% irrelevant है। Part 2 याद रखें: इस file में जो भी है, वह हर single message पर paid है, चाहे relevant हो या नहीं।

सही model है table of contents, encyclopedia नहीं। ~2,500 tokens से कम aim करें। Deeper context को reference करें जो on demand load हो:

CLAUDE.md. @filename syntax relevant होने पर referenced files auto-load करती है:

# Project: my-app

## Stack

Next.js 14, TypeScript, Postgres, Drizzle ORM.

## Commands

- `npm run dev`: start local server
- `npm test`: run vitest
- `npm run db:migrate`: apply migrations

## Critical rules

- Never edit files in `src/generated/`. They're rebuilt by codegen.
- All API routes use the auth middleware in `src/lib/auth.ts`.
- See @docs/conventions.md for naming and folder rules.
- See @docs/db-schema.md for table structure.

यही shape non-software projects के लिए भी काम करती है। Reports लिखने वाला consultant, lesson plans बनाने वाला teacher, operations चलाने वाला small-business owner: rules file domain से independent "table of contents, not encyclopedia" है। Writing/content project के लिए example (CLAUDE.md या AGENTS.md, same shape):

# Project: blog-and-newsletter

## What this is

A folder of drafts, research, and published posts. I write a weekly newsletter and occasional long-form posts.

## Where things live

- `drafts/`: in-progress posts, one per file
- `research/`: source notes and clippings, organized by topic
- `published/`: shipped posts (do not edit)

## Critical rules

- Never edit anything in `published/`. Fixes go in a new draft with a correction note.
- Footnotes go in `[brackets]` inline; we resolve them to numbered footnotes only at publish time.
- Tone: conversational, no bullet lists in body copy.

my-app version जैसे same principles: tight, declarative, सिर्फ़ वे things जिन्हें model folder देखकर infer नहीं कर सकता।

हर line जिसे add करने का मन हो, पूछें: "अगर मैं इसे delete कर दूँ, तो क्या model ऐसी mistake करेगा जो otherwise नहीं करता?" अगर no, delete करें। Model को TypeScript use करने को मत बताइए: वह .ts files देख सकता है। उसे वे things बताइए जिन्हें वह infer नहीं कर सकता: codegen folder, auth pattern, वे चीज़ें जिन्होंने पहले आपको काटा है।

यह file real failures से grow होनी चाहिए, imagined failures से नहीं। इसे git में commit करें। अपनी team को इसमें add करने दें।

---

Part 4: अपना tool personalize करना

दोनों tools में चार extension types हैं। Decision tree identical है:

इनमें से हर एक context-management tool है। Custom commands और skills सही context को on demand inject करते हैं। Hooks और plugins rules enforce करते हैं बिना tokens खर्च किए कि model उन्हें "remember" करे। Subagents context quarantine करते हैं ताकि वह main thread में leak न हो। Problem वही, shapes अलग।

8. Slash commands

Slash command memorable shortcut के साथ saved prompt है। दोनों tools इन्हें support करते हैं, बहुत similar shapes के साथ।

एक gotcha upfront flag करने लायक है: commands session start पर एक बार load होते हैं। अगर आप mid-session नया command बनाते हैं (चाहे file खुद लिखी हो या model से लिखवाई हो), तो CLI exit और re-enter करने तक वह autocomplete में नहीं दिखेगा। नीचे के दोनों folders इस मामले में same behave करते हैं; किसी भी side पर command बनाने के बाद session restart करें।

.claude/commands/ (project) या ~/.claude/commands/ (personal) में Markdown files. Example .claude/commands/review.md:

Review the current diff for:

1. Bugs and edge cases
2. Test coverage gaps
3. Naming and readability
4. Adherence to @docs/conventions.md

Be specific. Quote the lines you're commenting on.

यह /review command AI Prompting का concept 6 काम में लगाता है।

AI models आपसे agree करना पसंद करते हैं। बिना instructions "review my diff" पूछें और आपको looks good, well-structured, nice naming मिलेगा, सच हो या नहीं।

ऊपर की four-point checklist इसे रोकती है। Model अब सिर्फ़ "looks good" नहीं कह सकता। उसे हर point एक-एक करके check करना है, और fail होने वाली line पर point करना है।

दोनों /review के रूप में invoke होते हैं। दोनों $ARGUMENTS support करते हैं (और OpenCode positional $1, $2, etc. जोड़ता है)। OpenCode prompt में command output inject करने के लिए !`shell command` और command को specific agent तक route करने या subagent में run करने के लिए agent: plan / subtask: true frontmatter भी support करता है। यह review workflows को main context से बाहर रखने में useful है।

Non-software example. ज़्यादातर teams का daily ritual: /standup command. इसे .claude/commands/standup.md (या .opencode/commands/standup.md) के रूप में save करें:

Read yesterday's note in `journal/`. Produce a 4-line standup:

1. What I shipped yesterday (1 line)
2. What I'm working on today (1 line)
3. Blockers (1 line, "none" if clear)
4. One thing I learned (1 line)

Tone: telegraphic. No filler.

अब /standup yesterday's notes से clean status update produce करता है, जब भी आप उसे type करते हैं। Same shape as /review above, बस domain अलग है। यही trick /digest (emails के folder को action items में बदलना), /draft-reply (इस path की email का polite reply लिखना), या किसी भी chore पर काम करती है जिसके लिए आप same instructions दो बार से ज़्यादा type करते हैं।

दोनों tools में unifying test: अगर आप same instructions दो बार से ज़्यादा type कर रहे हैं, तो वह command होना चाहिए। Depth version (folder layout, frontmatter, argument passing, command को skill में promote कब करना है) Chapter 14 § Teach Claude Your Way of Working में है।

Note (Claude Code, 2026): 2026 तक slash commands और skills unified हो गए हैं। .claude/commands/ में files अब भी काम करती हैं और slash commands के रूप में appear होंगी, लेकिन new work increasingly .claude/skills/ में जा रहा है क्योंकि skills ज़्यादा support करती हैं (auto-invocation, subagent execution, file-path filters)। इन्हें continuum की तरह treat करें।

9. Skills

Skill custom command का बड़ा sibling है। Idea वही है, packaged expertise, लेकिन तीन meaningful upgrades हैं जो दोनों tools में identical हैं:

1. Auto-invocation. Model हर session की शुरुआत में skill descriptions पढ़ता है और task match होने पर right skill invoke करता है।
2. Progressive disclosure. Skill में SKILL.md file (entry point) होती है और वह same folder की other files reference कर सकती है। सिर्फ़ SKILL.md upfront load होता है; बाकी on demand. यही context-management principle file format बन गया है।
3. Frontmatter controls. SKILL.md के top पर YAML behavior configure करता है।

File format converge हो गया है। एक tool के लिए लिखा skill largely दूसरे में भी काम करता है।

.claude/skills/extract-transcript/SKILL.md:

---
name: extract-transcript
description: Extract a clean transcript from a YouTube video URL. Use when the user provides a YouTube link and asks for the transcript, captions, or text of the video.
---

# Extract YouTube transcript

1. Take the URL from the user's message.
2. Run `yt-dlp --skip-download --write-auto-sub --sub-format vtt "$URL"`.
3. Convert the VTT to plain text: strip timestamps, deduplicate overlapping captions.
4. Save to `transcripts/{video-id}.txt`.

For formatting conventions (paragraph breaks, speaker labels), see `references/style.md`.

हाँ, ये byte-identical हैं। OpenCode ~/.claude/skills/ और .claude/skills/ को fallbacks के रूप में भी पढ़ता है, इसलिए Claude Code के लिए लिखा कोई भी skill OpenCode में बिना changes के काम करता है।

Description सबसे important field है: यही model use करता है यह decide करने के लिए कि skill apply होता है या नहीं। Vague descriptions ("helps with videos") हर चीज़ पर fire करती हैं; specific descriptions ("Use when the user provides a YouTube link...") सिर्फ़ relevant होने पर fire करती हैं।

SKILL.md को खुद short रखें: under ~200 lines अच्छा rule है। Depth को same directory की reference files में push करें और उनसे link करें। इससे quick task सिर्फ़ overview की कीमत चुकाता है; deep task needed references pull कर सकता है। (Foundational walkthrough: skill क्या है, कब activate होता है, progressive disclosure कैसे काम करता है, इसके लिए Chapter 14 § The Concept Behind Skills और Building Your Own Skills देखें। Team/CI variant: frontmatter fields, glob-scoped activation के लिए Chapter 17 § Custom Skills with Frontmatter.)

Skills scratch से मत लिखें। Claude Code skill-creator skill ship करता है जो new skills correctly scaffold करता है। Same fallback की वजह से, इसे एक बार install करें और दोनों tools invoke कर सकते हैं। (Note: file discovery shared है, लेकिन Claude Code-specific tools reference करने वाली skill bodies को OpenCode में cleanly run करने के लिए light edits चाहिए हो सकते हैं। New agents के लिए, जो OpenCode में separate concept हैं, interactive agent scaffolder के लिए opencode agent create use करें।)

एक और pattern: small skills chain करें, monoliths मत बनाइए। "weekly content digest" skill जो research, write, format, और review सब एक साथ करे, maintain करने में मुश्किल और हर step पर worse होता है compared to चार separate skills (research, draft, format, review) जो एक-दूसरे को hand off करते हैं। Handoff usually filesystem-mediated होता है: research अपना output tmp/research.md में लिखता है, फिर draft को उसे पढ़ने को कहा जाता है; draft tmp/draft.md लिखता है, और आगे भी यही। आप model को sequence में run करने को prompt भी कर सकते हैं ("use the research skill, then draft a post from the output"), लेकिन file-based pipeline /clear के across ज़्यादा durable और debug करने में आसान है। दोनों तरह, हर skill अपने step पर focused रहता है। Reusability nice है, लेकिन real win per-step context isolation है: format skill को research notes load करने की ज़रूरत नहीं, और research skill को formatting conventions जानने की ज़रूरत नहीं। Same principle as subagents, छोटे granularity पर applied।

10. Hooks (Claude Code) / Plugins (OpenCode)

Skills probabilistic हैं: model decide करता है कि उन्हें invoke करना है या नहीं। Hooks और plugins deterministic हैं: specific events पर हर बार fire होते हैं, model judgment के बिना।

Idea वही, machinery अलग। यही वह जगह है जहाँ दोनों tools सबसे ज़्यादा diverge करते हैं। Tabs से पहले एक naming note: Claude Code के पास "plugins" नाम की अलग चीज़ भी है (bundles जो commands, skills, और hooks package करते हैं)। यह section उस बारे में नहीं है। यहाँ "hook" हमेशा Claude Code lifecycle hook है, और "plugin" हमेशा OpenCode event module. दोनों अपने-अपने tool में same slot occupy करते हैं: deterministic guardrail.

Hooks .claude/settings.json में lifecycle events से attached shell commands हैं। Big events: SessionStart, UserPromptSubmit, PreToolUse (exit code 2 blocks), PostToolUse. Structure के तीन levels हैं: event (PreToolUse), matcher group जो tool name (Bash) से filter करता है, और handler जो run होता है। Handler का if field actual command match करके further narrow करता है, ताकि handler सिर्फ़ तब spawn हो जब ज़रूरत हो। Example: model जो भी feel कर रहा हो, rm -rf block करें:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(rm -rf *)",
            "command": "echo 'Blocked dangerous command' >&2; exit 2"
          }
        ]
      }
    ]
  }
}

if: "Bash(rm -rf *)" filter matching करता है; जब तक command run होता है, tool call already known rm -rf है, इसलिए command को बस refuse करना है (exit code 2 blocks)। जब hook को genuinely tool input inspect करना हो (सिर्फ़ उस पर match नहीं), Claude Code वह input stdin पर JSON के रूप में pass करता है, जिसे command jq से पढ़ता है। नीचे placeholder example में आप यही देखेंगे।

Non-software example: drafts ship न हों जिनमें placeholder markers बचे हों। मान लीजिए आप drafts में कभी-कभी [TODO] या [FIX] markers छोड़ देते हैं और publish से पहले resolve करना भूल जाते हैं। Hook published/ में any write block कर सकता है अगर file में अभी भी placeholder हो:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -e '(.tool_input.file_path | test(\"/published/\")) and (.tool_input.content | test(\"\\\\[TODO\\\\]|\\\\[FIX\\\\]\"))' >/dev/null && { echo 'Refusing to publish draft with TODO/FIX markers' >&2; exit 2; }; exit 0"
          }
        ]
      }
    ]
  }
}

यह one file के inside देखता है, इसलिए rm -rf block से ज़्यादा करता है। matcher हर Write catch करता है; command Claude Code द्वारा stdin पर pass किए गए JSON को सीधे एक jq test में pipe करता है जो दो चीज़ें एक साथ check करता है, और सिर्फ़ तब block करता है जब दोनों true हों: file_path published/ के नीचे है, और content में placeholder marker है। drafts/ file में [TODO] pass होता है; published/ में clean file pass होती है; सिर्फ़ marked file जो published/ जा रही है exit code 2 के साथ stop होती है। Model file लिखता है, hook check करता है, और अगर placeholder leak हुआ है, तो file ship होने से पहले model को उसे resolve करना पड़ता है।

Trade real है: OpenCode plugins ज़्यादा capable हैं; Claude Code hooks simpler हैं।

Bash लिखने वाला कोई भी Claude Code hook पाँच minutes में लिखकर repo में ship कर सकता है, Node toolchain के बिना। OpenCode plugins को Bun या Node, npm dependencies, और TypeScript या JavaScript fluency चाहिए। One-line check ("block rm -rf") के लिए shell cost पर जीतता है। Structured logging, async work, या multiple event subscriptions चाहिए हों तो JS/TS module genuinely cleaner है। जो build कर रहे हैं, उसके constraints से match करने वाला tool चुनें।

Production codebases पर इन tools को चलाने वाले लोगों से useful pattern: write time पर block न करें, commit time पर block करें। Model को अपना काम finish करने दें (mid-edit interrupt करना उसे confuse करता है) और commit step पर hook/plugin run करें जो tests pass, types check, formatter happy check करे। कुछ fail हो तो model को fix loop में वापस force करें।

जिन चीज़ों को 100% of the time true होना चाहिए, उनके लिए hooks/plugins use करें। जिन चीज़ों को model ज़्यादातर समय remember करे तो अच्छा है, उनके लिए skills use करें।

11. Subagents

Subagent अपने own context window के साथ isolated agent instance है। आप उसे task delegate करते हैं; वह private में काम करता है; summary return करता है। उसकी file searches, log dumps, और exploratory reads आपके main thread को कभी touch नहीं करते।

Context-management terms में यह क्यों matter करता है: सबसे context-poisoning thing है "codebase explore करके X कहाँ होता है यह find करें।" ऐसा task dozens of files context में खींचता है, जिनमें से ज़्यादातर आपको नहीं चाहिए। Subagent में करने का मतलब main session सिर्फ़ conclusion देखता है ("X happens in src/services/billing.ts:142"), search नहीं।

दोनों tools read-only Explore subagent (among others; OpenCode broader delegated work के लिए General subagent भी ship करता है) के साथ आते हैं जो main thread को pollute किए बिना codebase exploration handle करता है। Claude Code में plan mode auto-delegates to Explore: आप mostly बिना सोचे use करेंगे, और model खुद भी asked होने पर plan mode self-enter कर सकता है। OpenCode में Plan agent same way subagents auto-invoke कर सकता है (subagent delegation normal primary-agent capability है), या आप @explore से explicitly call कर सकते हैं; लेकिन Plan mode itself में enter करना Tab के via deliberate user action है।

Custom subagents के लिए:

.claude/agents/doc-fetcher.md:

---
name: doc-fetcher
description: Fetches and summarizes external library documentation. Use when the user references a library and we need to understand its current API.
tools: WebFetch, Read, Write
---

You are a documentation researcher. Given a library name and a topic, fetch the official docs, extract only the API surface relevant to the topic, and write a focused summary to `tmp/docs-{library}.md`. Don't paste full pages: extract the patterns and signatures we need.

Non-software example: research subagent. मान लीजिए आपके पास long PDFs का folder है (industry reports, legal contracts, academic papers) और आप चाहते हैं कि agent focused summary निकाले बिना पूरा document main thread में drag किए:

---
name: pdf-summarizer
description: Reads a long PDF and writes a focused summary. Use when the user references a PDF and wants the key points without dumping the whole document into the conversation.
tools: Read, Write
---

You are a research summarizer. Given a PDF path and a question, read the document, extract only the passages relevant to the question, and write a focused summary to `tmp/summary-{pdf-name}.md`. Do not paste full pages: pull out the patterns, claims, and quotes the user actually needs.

Same shape as doc-fetcher above, domain अलग। 200-page PDF main conversation से बाहर रहता है; सिर्फ़ answer वापस आता है।

Invocation दोनों tools में same है। दोनों subagent की description के आधार पर auto-invoke करते हैं (यही path आप most often use करेंगे: good description लिखें, और task match होने पर model right helper चुनता है)। दोनों prompt में @subagent-name के साथ explicit invocation भी support करते हैं; OpenCode इसे autocomplete में ज़्यादा prominently surface करता है, लेकिन Claude Code भी इसे उतना ही accept करता है। Default auto-invocation use करें, @name तब reach करें जब आप sure होना चाहते हैं कि specific subagent run हो (या जब कई candidates के बीच description ambiguous हो)।

दोनों में identical general rule: अगर task में बहुत reading शामिल है जो final answer के लिए relevant नहीं होगी, तो वह subagent में belongs करता है। (Chapter 14 § Subagents and Orchestration अपना subagent लिखना और उन्हें chain करना walk through करता है।)

---

Part 5: बाहरी दुनिया से connect करना

12. MCP, honest तरीके से

MCP (Model Context Protocol) standardized way है external tools (Slack, Notion, आपका database, GitHub, whatever) को agent के सामने expose करने का। Claude Code और OpenCode दोनों same protocol से MCP support करते हैं। एक के लिए लिखा server दूसरे में काम करता है।

Configuration shape cosmetically अलग है:

Typically CLI (claude mcp add ...) से या .claude/settings.json में configured.

Pitch दोनों tools में real है: agent को आपके tools से connect करने का मतलब वह आपके work पर act कर सकता है, सिर्फ़ talk नहीं। Linear ticket पढ़ना, Slack update post करना, production read-replicas query करना: सब reasonable हैं।

Honest qualification, जो दोनों tools पर apply होती है: MCP हमेशा right answer नहीं है, और कुछ experienced users heavy MCP use से simple CLIs की तरफ़ चले गए हैं। Reasoning: MCP server underlying tool को fixed operations के set में abstract करता है, और हर operation upfront tool descriptions में context cost pay करता है। CLI बस CLI है: agent उसका --help पढ़ सकता है, flags compose कर सकता है, outputs pipe कर सकता है, और improvise कर सकता है। Stateless tools (GitHub, AWS, Jira) के लिए gh, aws, और jira CLIs अक्सर MCP equivalents से ज़्यादा flexible होते हैं।

OpenCode docs explicitly यह call out करती हैं, warning देती हैं कि MCP servers आपके context में add करते हैं और आपको carefully choose करना चाहिए कि कौन से enable हैं: "Certain MCP servers, like the GitHub MCP server, tend to add a lot of tokens and can easily exceed the context limit."

Useful working model: MCP उन stateful या auth-heavy services के लिए use करें जहाँ protocol layer सच में काम कर रही है (Playwright canonical example है: browser session manage करना hard है)। बाकी सबके लिए CLIs use करें। दस MCP servers इसलिए install न करें क्योंकि वे exist करते हैं; एक तब install करें जब real reason हो।

---

Part 6: Complete worked example, दो बार

यह section है जिसकी तरफ़ crash course का बाकी हिस्सा point करता है। एक realistic task, हर concept, दोनों tools. Same eight decisions, Claude Code में एक बार और OpenCode में एक बार side by side, ताकि आपको दिखे कि actually कितना कम difference है।

आप code की एक भी line नहीं लिखेंगे। Laptop और files के folder वाला कोई भी इसे follow कर सकता है: manager, teacher, small-business owner, student. Task small team की meeting notes use करता है, लेकिन same way school committee, volunteer group, freelance practice, या किसी भी group के लिए काम करता है जो notes रखते हैं और उनमें से action items निकालना चाहते हैं।

आपका task

आपके पास notes/ नाम का folder है जिसमें पाँच files हैं: आपकी team की last week की meeting notes. वे messy हैं। कुछ meetings action items को ## Action Items के नीचे list करती हैं। कुछ ## Todos use करती हैं। एक lowercase ## todo use करती है। कुछ action items other sections के अंदर deep hide करती हैं। कुछ bullets [private] या [HR] tagged हैं और उन्हें public में नहीं जाना चाहिए।

आप एक clean file चाहते हैं, weekly-actions.md, जो हर action item list करे, owner के हिसाब से grouped, और source meeting का link back दे। कोई private चीज़ leak न हो। कुछ lost न हो। और अगर कोई deadline public holiday पर पड़ती है, तो warning चाहिए।

📁 पहले पाँच starter files लें (expand करने के लिए click करें)

शुरू करने से पहले इन्हें notes/ folder में copy करें। Example इन्हीं के around engineered है: हर file specific role निभाती है, इसलिए अगर एक skip करते हैं, तो नीचे का कोई step काम करना बंद कर देता है। (Folder setup skip करना चाहते हैं? पाँचों files सीधे अपने tool की chat में paste करें और उसे कहें कि इन्हें notes/ के contents की तरह treat करे।)

notes/2026-12-07-monday-team-meeting.md

# Monday Team Meeting - 2026-12-07

Attendees: @sara, @diego, @priya, @marcus

## Discussion

Reviewed last month's customer satisfaction scores. Renewals are down slightly in the small-business segment.

## Action Items

- @sara: draft a revised welcome email by Dec 18
- @diego: check spam-folder reports with our email vendor by Dec 16
- @marcus: pull renewal numbers for the last two quarters and share with the team
- @sara: finalize offer terms for the new account manager [HR]

notes/2026-12-08-customer-feedback.md

# Customer Feedback Review - 2026-12-08

Attendees: @sara, @amara, @marcus

## Summary

Read through the top twenty customer comments from last week. Three themes came up: pricing page is confusing, the call-back service is slow, and the FAQ on the website is out of date.

## Todos

- rewrite the pricing page in plain language
- @marcus: log a complaint with the call center vendor about response times
- look into why the FAQ has not been updated in six months
- @amara: draft a customer note explaining the upcoming changes
- review all printed brochures for outdated photos and pricing

notes/2026-12-08-q1-planning.md

# Q1 2027 Planning - 2026-12-08

Attendees: @sara, @diego, @amara, @lukas

## Initiatives

We walked through the four candidate initiatives for Q1.

### Year-end promotional campaign

Time-bound: wraps before the holiday break.

#### Action Items

- @amara: finalize the year-end promotional brochure by Dec 25
- @lukas: confirm placement with paid media partners by Dec 20

### Onboarding overhaul

Top priority next quarter.

## todo

- @diego: write the project brief by Jan 15
- @sara: own messaging and visual direction

notes/2026-12-09-all-hands-prep.md

# All-Hands Prep - 2026-12-09

Attendees: @sara, @marcus

## Agenda

Walked through the December all-hands agenda. Most slides are in good shape; a couple still need owners.

## Next Steps

- @marcus: set up the video call and record a practice run
- @sara: finalize the Q4 numbers slide
- @sara: prepare the bonus and compensation talking points [private]
- @marcus: book the venue for the team holiday dinner

notes/2026-12-11-vendor-review.md

# Vendor Review - 2026-12-11

Attendees: @sara, @amara, external partner

## Summary

Confidential contract negotiation with our printing and fulfillment vendor. Details under NDA.

## Action Items

- @sara: circulate the revised contract to the vendor [private]
- @amara: draft the internal announcement once terms are agreed [private]
- @sara: review the legal redlines on the new pricing schedule [private]

इस section को कैसे पढ़ें

इस chapter के आठ context-management decisions में से हर एक को नीचे numbered step मिला है। हर step की same shape है:

• What you do: exact thing जिसे आप type या press करते हैं
• Why: एक paragraph कि यह decision आपको क्या buy कर रहा है
• What changes in OpenCode: दूसरे tool का version

अगर कोई step कहता है "identical in OpenCode", तो वह line skip करके आगे बढ़ सकते हैं।

---

Decision 1: Rules file trim करना

What you do (Claude Code). अपने project folder में Claude Code open करें। /init run करें। यह CLAUDE.md नाम की file create करता है जो बहुत लंबी है। उसका ज़्यादातर हिस्सा delete करें। सिर्फ़ यह छोड़ें:

# weekly-rollup

## Layout

- `notes/`: meeting notes, one file per meeting
- `weekly-actions.md`: the rollup we are creating
- `plans/weekly-rollup-plan.md`: the plan we will save and reuse

## Critical rules

- Action items can appear under `## Action Items`, `## Todos`, `## Next Steps`, or `## todo` (one meeting uses lowercase). Look at all heading levels, not just the top.
- Owners are written as `@name`. Items with no owner go to an "Unassigned" section.
- Never include any bullet tagged `[private]` or `[HR]`.

Why. यह file हर message की शुरुआत में read होती है। आप यहाँ जो भी डालते हैं, उसकी कीमत हर turn चुकाते हैं। इसलिए इसे short रखें: सिर्फ़ वे चीज़ें जिन्हें model folder देखकर खुद figure out नहीं कर सकता। Privacy rule, especially, ऐसी चीज़ है जिसे वह guess नहीं कर सकता।

What changes in OpenCode. File का नाम CLAUDE.md के बजाय AGENTS.md है। Same content, same purpose. (और अगर आपके पास पहले से CLAUDE.md है, तो OpenCode उसे भी पढ़ेगा; आपको कुछ rename करने की ज़रूरत नहीं।)

---

Decision 2: Writing से पहले plan करना

What you do (Claude Code). Shift+Tab दो बार press करें। इससे model plan mode में आता है: वह आपकी files read कर सकता है लेकिन कुछ change नहीं कर सकता। फिर type करें:

Read every file in notes/. Produce weekly-actions.md grouped by
owner. For each item include the action, the source filename, and
the meeting date. Skip anything tagged [private] or [HR]. Do not
lose any action items.

Model एक minute सोचता है, फिर written plan लेकर आता है जो exactly बताता है कि वह क्या करना चाहता है।

Why. यह दोनों tools में सबसे underused feature है। Plan read करने में 30 seconds लगते हैं। Bad change revert करने में उससे ज़्यादा। आपको हमेशा पहले plan चाहिए। (Foundations: Chapter 14 § Hello Claude दोनों tools में plan mode introduce करता है; Chapter 17 § Plan Mode vs Direct Execution deeper जाता है कि यह कब pay off करता है और कब बस slow करता है।)

What changes in OpenCode. Build agent से Plan agent पर switch करने के लिए Tab press करें। Brief और result identical हैं; सिर्फ़ keystroke अलग है।

---

Decision 3: Plan पर push back करना

What you do (Claude Code). Plan carefully पढ़ें। दो चीज़ें शायद गलत होंगी।

पहली: वह सिर्फ़ top-level headings (## Action Items, ## Todos) mention करेगा। लेकिन आपकी meeting files में से एक (Q1 planning notes) action items को ### Year-end promotional campaign के अंदर, #### Action Items के नीचे hide करती है। Plan उन्हें miss कर देगा।

दूसरी: वह यह नहीं कहेगा कि जिन action items का कोई owner नहीं है (next to them no @name, जैसे customer-feedback file का "rewrite the pricing page in plain language") उनके साथ क्या करना है। वे silently disappear हो जाएँगे।

आप push back करते हैं:

Two changes. (1) Look at all heading levels, not just the top.
Some action items live under sub-headings. (2) Items without an
owner go to an "Unassigned" section at the bottom; never drop
them.

Model plan update करता है। आप उससे final plan को plans/weekly-rollup-plan.md में save करने को कहते हैं ताकि अगले Friday reuse कर सकें।

Why. Plan contract है। Problems यहाँ पकड़ें, जब cost zero है, न कि file already written होने के बाद जब cleanup करना पड़े।

What changes in OpenCode. Identical.

---

Decision 4: उसे काम करने देना

What you do (Claude Code). Plan mode छोड़ने के लिए Shift+Tab press करें। Model को go ahead कहें।

वह पाँचों files read करता है। weekly-actions.md लिखता है। Items को owner के हिसाब से group करता है। [private] और [HR] bullets drop करता है। Orphan items को Unassigned section में डालता है। आप यह happen होते देखते हैं।

Why. अभी तक आप careful रहे हैं। अब उसे काम करने दें। क्योंकि आपने plan किया, work mostly first try में correct है।

Check where the file landed

weekly-actions.md project root में होना चाहिए, notes/ के next to, notes/ के अंदर नहीं। अगर model ने इसे notes/ में लिखा, तो यह signal है कि Decision 1 के CLAUDE.md Layout section missing है या ignore हो रहा है। अभी fix करें: Decision 6 safety net root-level weekly-actions.md में filenames grep करता है, और wrong place की file नहीं पाएगा।

What changes in OpenCode. आपसे हर file write को first time approve करने के लिए पूछा जाएगा। आप yes कह सकते हैं, या later runs smoother बनाने के लिए opencode.json में common actions pre-approve कर सकते हैं।

---

Decision 5: Conversation long होने पर summarize करना

What you do (Claude Code). Conversation अब long है। Model ने हर meeting note read की है, और उस raw content का बहुत सा हिस्सा अभी भी इसकी memory में बैठा है, including कुछ private bullets जिन्हें उसने correctly skip किया। आपको अब उस raw content की ज़रूरत नहीं। आप type करते हैं:

/compact keep the heading rules, the owner list, and the
private/HR exclusion rule

Conversation summarized होकर सिर्फ़ उन parts तक आ जाती है जिन्हें आपने keep करने को कहा।

Why. Long, cluttered conversation model को बेहतर नहीं, खराब बनाती है। यह ज़्यादा cost भी करती है। अब जो relevant नहीं है उसे clear करें, especially private content, जिसे memory में ज़रूरत से ज़्यादा देर नहीं रहना चाहिए।

What changes in OpenCode. Identical command.

---

Decision 6: Commit के लिए safety net लगाना

What you do (Claude Code). Git में work save करने से पहले आप ensure करना चाहते हैं कि कोई meeting accidentally skip न हुई हो। आप Claude Code hook add करेंगे: छोटा safety net जो हर commit से पहले automatically run होता है।

यह model से न लिखवाएँ: इसे paste करें

Chapter में यह एक जगह है जहाँ आप config block खुद paste करते हैं, model से लिखवाने के बजाय। इसके दो reasons हैं, दोनों hard way से सीखे गए।

(1) "Hook" ambiguous है। अगर आप model से "create a hook" कहेंगे, तो Claude Code git hook (.git/hooks/ में file) की तरफ़ जा सकता है, Claude Code hook (.claude/settings.json में entry) की तरफ़ नहीं। ये अलग चीज़ें हैं; आपको दूसरी चाहिए।

(2) Model clever बनने की कोशिश करेगा और silently safety net break कर देगा। आपका CLAUDE.md कहता है कि [private] और [HR] items skip करने हैं। अगर आप vaguely ask करते हैं, model उस rule को पढ़ता है और "helpfully" वही filter hook script में bake कर देता है, जिसका मतलब vendor-review meeting (हर bullet [private] है) quietly ignored हो जाती है और hook कभी fire नहीं करता। Hook का पूरा point वही case पकड़ना है। Model से ऐसे watchdog को लिखवाना जो उन्हीं rules के against है जिन्हें उसे honour करने को कहा गया है, losing game है।

Safe move यही है कि configuration paste करें।

.claude/settings.json open करें (file न हो तो create करें) और इसे exactly paste करें:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git commit *)",
            "command": "for f in notes/*.md; do grep -q \"$(basename $f)\" weekly-actions.md || { echo \"Missing: $f\" >&2; exit 2; }; done"
          }
        ]
      }
    ]
  }
}

Plain English में: matcher कहता है "Bash tool watch करें"; if उसे सिर्फ़ git commit commands तक narrow करता है; फिर command notes/ की हर .md file पर loop करता है, weekly-actions.md में उसके basename को grep करता है, और अगर कोई file mention नहीं है, तो code 2 से exit करता है (जो commit block करता है)। कोई content filters नहीं, कोई [private] checks नहीं, कोई exceptions नहीं। सिर्फ़ filenames. यही पूरा point है।

अब model को commit करने को कहें। Safety net fire होता है: Missing: notes/2026-12-11-vendor-review.md. Reason logical है: उस meeting में हर action item [private] tagged था, और Decision 1 के rules उन्हें drop करने को कहते हैं; इसलिए rollup build होने पर इस file से लिखने के लिए कुछ नहीं था, और filename कभी आया ही नहीं। Hook को इनमें से कुछ नहीं पता; उसे सिर्फ़ दिखता है कि file unmentioned है, और वह block करता है।

Model error पढ़ता है और rollup को placeholder entry से patch करता है जो file का नाम explicitly देती है, e.g.:

## From 2026-12-11-vendor-review.md

- All items confidential — see meeting owner.

Filename अब weekly-actions.md में present है, hook का grep इसे find करता है, commit pass हो जाता है। Rollup में कुछ private leak नहीं हुआ; audit trail intact है।

आपने इस loop में कुछ नहीं किया। Safety net ने mistake पकड़ी और model ने खुद fix किया।

Why. जिन चीज़ों को हर single time true होना चाहिए, वे model की memory पर depend नहीं करनी चाहिए। उन्हें automatically check होना चाहिए। और check ऐसी जगह रहना चाहिए जहाँ model खुद को please करने के लिए quietly rewrite न कर सके: इसलिए यह paste है, prompt नहीं।

What changes in OpenCode. OpenCode इन्हें hooks के बजाय plugins कहता है, और वे छोटे JavaScript file के रूप में लिखे जाते हैं। Idea वही, outcome वही, same paste-don't-prompt logic. .opencode/plugins/check-rollup-complete.js create करें (folder अभी न हो सकता है) और यह paste करें:

// .opencode/plugins/check-rollup-complete.js
import { readdirSync, readFileSync } from "fs";

export const CheckRollupCompletePlugin = async ({ $ }) => {
  return {
    "tool.execute.before": async (input, output) => {
      if (
        input.tool === "bash" &&
        output.args.command?.startsWith("git commit")
      ) {
        const rollup = readFileSync("weekly-actions.md", "utf8");
        const missing = readdirSync("notes")
          .filter((f) => f.endsWith(".md"))
          .filter((f) => !rollup.includes(f));
        if (missing.length) {
          throw new Error(`Missing from rollup: ${missing.join(", ")}`);
        }
      }
    },
  };
};

Same shape: notes/ की हर file list करें, check करें कि हर basename rollup में है, कोई missing हो तो throw करें। अंदर कोई [private] filter नहीं। Behaviour Claude Code version जैसा identical है: missing file, commit blocked, model खुद fix करता है।

Hook/plugin material depth में (exit codes, matcher syntax, full event list) Chapter 14 § Hooks and Extensibility में है (और OpenCode side के लिए Plugins: Putting It All Together).

---

Decision 7: Side-task helper को भेजना

What you do (Claude Code). कुछ action items में deadlines हैं जैसे "by Dec 25" या "before year-end." आप उन deadlines को flag करना चाहते हैं जो public holiday पर पड़ती हैं ताकि owners adjust कर सकें। आप type करते हैं:

Use the doc-fetcher helper to look up the 2026 international
public holidays list and write the dates to tmp/holidays-2026.md.

एक अलग helper जाता है, web से long page fetch करता है, सिर्फ़ dates extract करता है, और उन्हें small file में लिखता है। आपकी main conversation सिर्फ़ small file देखती है, long page नहीं।

फिर model आपके rollup की deadlines पढ़ता है, holidays से cross-reference करता है, और brochure deadline के next to note add करता है: ⚠ falls on Christmas Day.

Why. Web page directly fetch करने से pages of text आपकी conversation में dump हो जाते, जिससे यह slow और cluttered हो जाती। Helper को भेजने का मतलब सिर्फ़ answer वापस आता है, noise नहीं।

What changes in OpenCode. Helper call करने के लिए आप direct @doc-fetcher type कर सकते हैं; यह autocomplete में दिखता है। Same helper, easier to invoke.

---

Decision 8: जो सीखा उसे save करना

What you do (Claude Code). यह Friday ritual है; आप इसे हर week करेंगे। आप next Friday ये सारे decisions याद नहीं रखना चाहते। इसलिए model से इन्हें skill के रूप में save करने को कहें:

Create a skill at ~/.claude/skills/weekly-meeting-rollup/SKILL.md
based on what we just did. Include: the four heading variants,
the all-headings rule, the private/HR exclusion, the Unassigned
section, the missing-file check, and the holiday cross-reference.

Next Friday, आप सिर्फ़ "do the weekly rollup" type करेंगे और model automatically यह skill pull कर लेगा। आज किए गए हर decision, free में apply होंगे।

Why. यही payoff है। इस week किया काम सिर्फ़ इस week के लिए नहीं था; इसने model को यह task हमेशा के लिए करना सिखाया।

What changes in OpenCode. Skill थोड़ा different folder (~/.config/opencode/skills/...) में save होता है, लेकिन file itself byte-for-byte identical है। इसे दोनों tools के बीच copy करें और दोनों में काम करता है। यही chapter की thesis का strongest possible proof है।

---

अभी क्या हुआ

आठ steps पर वापस देखें। इनमें से किसी ने भी आपसे code लिखवाया नहीं। किसी ने भी यह जानना require नहीं किया कि API क्या है। आपने actually आठ छोटे acts किए model की attention manage करने के: उसे क्या देखना है, कब plan करना है, कब forget करना है, कब delegate करना है, कब खुद पर भरोसा रोकना है, और कब remember करना है।

यही पूरा chapter है।

और देखें कि दोनों tools में कितना कम difference था:

• Rules file के लिए different filename (CLAUDE.md vs AGENTS.md)
• Plan mode enter करने के लिए different keystroke (Shift+Tab vs Tab)
• Safety-net file के लिए different language (JSON vs JavaScript)
• End में skill के लिए different folder (लेकिन same file)

बस इतना।

Thinking tool है। Configs decoration हैं। इस तरह सोचना सीखें और आपकी skills किसी भी winning tool से survive करेंगी।

---

Part 7: इसे कहाँ run करें, और कैसे grow करें

13. Terminal, IDE, or desktop?

दोनों tools कई places पर run होते हैं।

Claude Code: terminal, VS Code / JetBrains plugins, Claude desktop app, और async work के लिए cloud-hosted variants.

OpenCode: terminal (TUI flagship है), desktop app (macOS/Windows/Linux पर beta), ACP support के via IDE extension, SDK के via web interface, plus GitHub और GitLab integrations.

आप क्या कर रहे हैं उसके आधार पर चुनें। Lots of file editing वाले greenfield development के लिए IDE plugins hard to beat हैं: आप diff happen होते देखते हैं। Long-running tasks जहाँ notifications और parallel sessions चाहिए, terminal fine है। Non-coding work और scheduled jobs के लिए desktop apps ज़्यादा pleasant हैं।

दोनों tools में strong recommendation: terminal या IDE plugin से start करें। एक बार आप समझ लें कि underneath क्या हो रहा है (model कौन सी files read करता है, कौन सी commands run करता है, कौन से decisions लेता है), तो हर other interface thin wrapper बन जाता है जिसे आप पढ़ सकते हैं। अगर आप heavily abstracted UI से start करते हैं, तो चीज़ें sideways जाने पर debug करने में struggle करेंगे, क्योंकि आपको पता नहीं होगा कि क्या sideways जा सकता है।

14. Personal context library धीरे-धीरे build करें

जब आपके कुछ projects किसी भी tool का use करने लगेंगे, तो notice होगा कि आप हर rules file में similar चीज़ें लिख रहे हैं: आपका code style, commit conventions, testing philosophy. Copy-paste रोकें।

Shared parts को home config में रखें और हर project की rules file से reference करें:

~/.claude/:

# CLAUDE.md

@~/.claude/style/typescript.md
@~/.claude/style/commits.md

## Project-specific

[only the things unique to this project]

Same idea skills के लिए भी काम करता है। ~/.claude/skills/ (जिसे OpenCode भी पढ़ता है) या ~/.config/opencode/skills/ में commit-message skill या code-review skill everywhere automatically available है।

Discipline: इसे pre-build न करें। Saturday को perfect personal setup design करने का temptation होगा। Resist करें। हर entry real failure से आनी चाहिए: वह moment जहाँ model ने कुछ गलत किया, या आपने same चीज़ तीसरी बार type की। Regret से build करें, imagination से नहीं। Real friction से grow हुई library छोटी और useful रहती है; advance में designed library बड़ी और ignored होती है।

15. Basics से आगे memory

Built-in resume + well-tended rules file ज़्यादातर लोगों के लिए ज़्यादातर समय enough है। अगर आपको ज़्यादा चाहिए (past conversations के across search, persistent project notes, knowledge जो /clear survive करे), तो options हैं:

• Project में notes/ folder, जहाँ agent major work के बाद structured notes लिखे। Cheap, durable, greppable. Surprisingly effective. दोनों tools में बिना setup काम करता है।
• Memory MCP server. कई exist करते हैं; वे agent को explicit save/recall API देते हैं। दोनों tools में काम करता है।
• Conversation history पर vector search for "have I solved this before" queries. Tool-specific implementations exist; ecosystem pages check करें।

जो actually remember करना है उसके आधार पर चुनें। अगर वह "इस codebase के decisions and gotchas" है, तो notes/ folder enough है। अगर "मैंने model को all projects में जो कुछ बताया है सब" है, तो heavier चीज़ चाहिए। जिस problem का infrastructure नहीं चाहिए, वह install न करें।

---

Part 8: Claude Code और OpenCode को compose करना

Earlier parts ने Claude Code और OpenCode को alternatives की तरह treat किया: एक चुनें, सीखें। वह framing deliberate थी: चीज़ें complicate करने से पहले हर concept दोनों tools में make sense करना चाहिए। लेकिन fundamentals आने के बाद interesting question composition है। Same project पर दो tools साथ use करना सिर्फ़ fallback नहीं है कि एक fail हो जाए। यह काम करने का अलग तरीका है, और उन्हें साथ use करने की mechanics अपना part deserve करती है।

Substrate: git worktrees

Patterns से पहले, operational layer जो इसे safe बनाती है।

दोनों tools parallel sessions support करते हैं, लेकिन अगर दो agents same file same time edit करते हैं, last write wins और आपको stomped diffs मिलते हैं। Fix है git worktrees: हर worktree आपके repo की checked-out copy है जो अलग branch पर होती है, same .git directory share करती हुई। Two agents in two worktrees अलग files parallel में edit कर सकते हैं बिना same path touch किए।

# from your main repo directory
git worktree add ../myproject-backend feature/auth-core
git worktree add ../myproject-frontend feature/auth-ui

# now you have two parallel working dirs, two branches
cd ../myproject-backend && claude
# in another terminal
cd ../myproject-frontend && opencode

काम done होने पर git worktree remove ../myproject-backend से worktrees remove करें।

File-edit rule, तीन tiers में:

Pattern	Verdict
Two sessions editing the same file simultaneously	Bad: last write wins, the other session's edits are lost
Two sessions editing different directories	Good: no contention, parallel speedup is real
One session edits, commits, hands off to the other	Acceptable: the commit is the handoff artifact

Rule of thumb: हर task के लिए एक session से start करें। Second तभी add करें जब आप clearly point कर सकें कि हर session कौन सी files own करता है। दो agentic sessions के बीच context-switching की cognitive cost real है; यह तभी win है जब work genuinely partition होता है।

Shared layer जो इसे काम कराती है: project के rules और skills. दोनों tools same CLAUDE.md और same .claude/skills/ directory पढ़ते हैं (Concepts 7 और 9 इसे cover करते हैं)। Project conventions के लिए one source of truth; दो tools उसे consume करते हुए।

Pattern 1: Plan / Execute split

Agentic coding में expensive cognitive work planning है: codebase पढ़ना, approach decide करना, edge cases anticipate करना। Cheap mechanical work वह plan implement करना है जो already exist करता है। Pricing यही reflect करती है: frontier-tier models per token economy-tier models से roughly order of magnitude ज़्यादा cost करते हैं, और वे planning पर यह price earn करते हैं, implementation पर नहीं।

Composition:

1. Claude Code को plan mode में open करें (Concept 2)। Brief state करें। उसे plan produce करने दें।
2. Plan को docs/plans/feature-x.md में save करें।
3. Separate worktree में OpenCode open करें, economy-tier model पर pointed (current setup के लिए opencode.ai/docs/providers देखें)। First message: read docs/plans/feature-x.md and implement it.
4. OpenCode file edits करता है, tests run करता है, lint fix करता है।
5. (Optional) Merge से पहले diff review करने के लिए Claude Code फिर open करें।

Plan file contract है। यह session loss survive करती है, architectural decisions encode करती है, और cheap session को expensive thinking redo किए बिना काम करने देती है। यह pattern अकेला अक्सर teams को "cheaper model पर switch" करने से जो cost savings चाहिए होती हैं उसका ज़्यादातर हिस्सा दे देता है, frontier-model planning की quality खोए बिना।

Pattern 2: Cross-model review

यह AI Prompting का concept 13 habit से architecture में promoted है। वहाँ आपने same draft दो chat windows में चलाया; यहाँ दो coding tools एक-दूसरे के diffs cross-check करते हैं।

Different models के blind spots अलग होते हैं। जिस model ने code लिखा है, वही उस code का worst possible reviewer है, क्योंकि उसके पास वही blind spots हैं जिन्होंने original produce किया। Different family का model (different training data, different reasoning habits) ऐसी चीज़ें catch करेगा जो author miss कर गया।

Composition:

1. Tool A (any model) अपने worktree पर feature implement करता है।
2. Tool B (different model, ideally different family) diff पढ़ता है और critique को docs/reviews/feature-x.md में लिखता है। Reviewer edit नहीं करता; text produce करता है।
3. Tool A review पढ़ता है और decide करता है कि किन points पर act करना है।

यह जितना sound करता है उससे ज़्यादा useful है। Cheap economy models पर running reviewers surprising amount of real value catch करते हैं: missing edge cases, security oversights, naming inconsistencies, dead code. Review pass run करने का dollar cost छोटा है; merge के बाद bug पकड़ने का time cost बड़ा है।

Pattern तब best काम करता है जब reviewer और implementer different model families से हों: Claude reviewing Claude वह miss करता है जो GPT या DeepSeek catch कर सकता है, और vice versa. Same-family review still no review से बेहतर है, लेकिन value diversity में है, act में नहीं।

Single-tool क्या रहता है

Composition में overhead है। Two tools मतलब two configs, two permission lists, two notification setups. ज़्यादातर short tasks (single function, quick refactor, bug fix) के लिए single session across tools orchestrate करने से faster, simpler, और cheaper है।

Composition तब reach करें जब task इतना बड़ा हो कि planning genuinely implementation से separable हो, entire task पर frontier model की cost wasteful हो, या independent review pass की value उसके cost से ज़्यादा हो। बाकी सबके लिए Parts 1-7 की single-session discipline right move है।

Composition बस वह है जो तब होता है जब आप one tool और one model को unit of work मानना बंद करते हैं, और agentic coding session को unit मानना शुरू करते हैं।

---

इसमें सच में अच्छे कैसे बनें

यह crash course पढ़ने से आप agentic coding में अच्छे नहीं होते। इसे use करने से होते हैं, और path ऐसा दिखता है:

आप manual शुरू करते हैं। Friction महसूस करते हैं: हर approval prompt, हर "wait, why doesn't it know X." वही friction curriculum है। Friction का हर piece ऊपर के fifteen concepts में से एक से map होता है:

• "Why does it keep forgetting the auth pattern?" → rules file missing या bloated है।
• "Why did it just delete my migrations folder?" → permissions tight enough नहीं थीं।
• "Why is it so slow after an hour?" → context rot; आपको /compact चाहिए था।
• "Why am I typing the same thing every Monday?" → वह skill है।
• "Why did my tests pass locally but break in CI?" → वह hook या plugin है।
• "Why does exploring the codebase always pollute my conversation?" → वह subagent है।

हर problem hit होने पर उसका response build करें, पहले नहीं। आपकी rules file दस lines होनी चाहिए, फिर बारह, फिर बीस: हर line उस mistake से earned जो अब prevent करती है। आपके skills folder में दस skills से पहले एक skill होना चाहिए। आपके hooks/plugins इसलिए exist करने चाहिए क्योंकि उनके बिना कुछ टूटा था, इसलिए नहीं कि किसी ने कहा hooks powerful हैं।

80/20 fifteen concepts memorize करना नहीं है। यह notice करना है कि given problem किस concept में belongs करता है, इतनी fast कि आप right tool reach करें। यही noticing skill है, और यह सिर्फ़ real work पर agentic coding tools को succeed और fail होते देखने से आती है।

The portability dividend. एक tool के लिए यह noticing बना लेने के बाद, यह transfer होती है। ऊपर का friction-to-concept map Claude Code और OpenCode में identical है। Start करने के लिए एक चुनें, उसका specific config सीखें, और जब भी switch करने का decide करें (cost reasons, model preference, license, या कोई new tool जो अभी exist नहीं करता) आपकी knowledge साथ आती है। Configs बदलते हैं। Thinking नहीं।

एक project से start करें। हर non-trivial चीज़ के लिए plan mode use करें। Context watch करें। बाकी अपने आप build होता है।

---

Quick reference

15 concepts, हर one line में

1. Tools actions लेते हैं, सिर्फ़ answers नहीं देते। Questions नहीं, briefs लिखें।
2. Plan mode (CC में Shift+Tab, OC में Tab to Plan agent). किसी write से पहले read-only investigation.
3. Permissions discipline. Manual start करें, allow/deny time के साथ codify करें। rm -rf को कभी auto-approve न करें।
4. Context rot real है। Window fill होने से पहले recall degrade होता है, और हर turn पूरा context फिर bill करता है।
5. /clear vs /compact. New task vs same task lighter. गलत चुनेंगे तो wrong thing खोएगी।
6. Resume sessions. जहाँ छोड़ा था वहाँ pickup करें बिना re-explain किए; saved plan files के साथ pair करें।
7. CLAUDE.md / AGENTS.md table of contents है। Under ~2,500 tokens, references on demand load होते हैं।
8. Slash commands. Saved prompts जिन्हें आप same चीज़ type करते रहने पर name से trigger करते हैं।
9. Skills. Saved expertise जिसे model description से auto-invoke करता है; SKILL.md plus references से progressive disclosure.
10. Hooks (CC) / Plugins (OC). Lifecycle events पर deterministic guardrails. Production के लिए optional नहीं।
11. Subagents. Noisy reads (codebase exploration, doc fetching) के लिए isolated context windows.
12. MCP, carefully use किया गया। External tools के लिए standard protocol; stateless services में CLIs अक्सर MCP से बेहतर हैं।
13. कहाँ run करें। Terminal या IDE plugin से start करें ताकि देख सकें agent क्या कर रहा है।
14. Personal context library, slowly. Projects के across configs share करें; regret से build करें, imagination से नहीं।
15. Memory beyond basics. Built-in resume + good rules file most के लिए enough है। ज़्यादा चाहिए तो notes/ folder.

Command quick-ref

Want to...	Claude Code	OpenCode
Initialize project rules file	/init	/init
Enter plan mode	Shift+Tab (twice)	Tab (cycle to Plan agent)
Wipe conversation, start fresh	/clear	/new (or /clear)
Summarize and continue	/compact	/compact (or /summarize)
Resume a saved session	claude --resume	/sessions (or /resume)
Jump back to a previous message	Esc Esc (or /rewind)	/undo
Roll back the model's file edits	Esc Esc (checkpointing)	/undo (needs git)
Roll back bash-command file changes	(not tracked)	/undo (whole-tree diff)
Redo (reverse the last /undo)	(not bundled)	/redo
Share session	/share	/share

File location quick-ref

What	Claude Code	OpenCode
Project rules	CLAUDE.md	AGENTS.md (also reads CLAUDE.md as fallback)
Project permissions	.claude/settings.json	opencode.json
Project commands	.claude/commands/*.md	.opencode/commands/*.md
Project skills	.claude/skills/<name>/SKILL.md	.opencode/skills/<name>/SKILL.md (also reads .claude/skills/)
Project hooks/plugins	.claude/settings.json (hooks block)	.opencode/plugins/*.{js,ts}
Project subagents	.claude/agents/*.md	.opencode/agents/*.md
Personal/global rules	~/.claude/CLAUDE.md	~/.config/opencode/AGENTS.md
Personal commands/skills/agents	~/.claude/{commands,skills,agents}/	~/.config/opencode/{commands,skills,agents}/
MCP servers	.claude/settings.json (mcp block)	opencode.json (mcp block)

Extension type decision tree

Need to do the same thing repeatedly, manually?
    → Slash command (CC) / Custom command (OC)

Want the model to apply expertise automatically when a task matches?
    → Skill

Need something to happen every single time, no model judgment?
    → Hook (CC) / Plugin (OC)

Need a chunk of work done in isolation so it doesn't pollute main context?
    → Subagent

जब कुछ गलत लगे

Model apologizing without progress, rewriting the same code,
hallucinating variables, contradicting earlier constraints?
    → Context is poisoned. Stop typing. Run /compact or /clear.
       Don't try to fix it with another prompt.

---

Flashcards से अभ्यास

---

Quiz: 15 concepts पर 50 सवाल

Crash course के हर concept को cover करने वाला comprehensive bank. हर session 18 questions का fresh batch दिखाता है, इसलिए retakes में new material मिलता है। ऊपर अपना tool चुनें ताकि answers आपकी toolchain में grounded रहें।

Checking access...