Claude Code aur OpenCode: 90-Minute Crash Course

15 Concepts, Real Use ka 80%

Aik practical crash course. Koi filler nahin, koi upsell nahin. Aakhir tak aap jaan jayenge ke dono tools mein kya use karna hai, kab use karna hai, aur jab zyada detail chahiye ho to kahan dekhna hai.

Woh aik insight jo baqi sab ko click karwa deti hai: agentic coding aik context-management problem hai jo coding tool ka costume pehne hue hai. Taqreeban har "advanced technique" aakhir mein isi baat par aati hai: sahi waqt par sahi information model ke paas lana, aur ghalat information ko bahar rakhna. Har section ko isi lens se parhein.

Prerequisite: 2026 mein AI Prompting. Yeh page assume karta hai ke woh thirteen concepts aap ke paas pehle se hain. Colleague ki tarah brief karna (concept 1), context ko poora game samajhna (concept 4), thinking mode (concept 5), neutral framing (concept 6), iterate loop (concept 7), models checking models (concept 13): yahi discipline hai. Yeh page dikhata hai ke jab model aap ke filesystem ko touch kar sakta hai to woh discipline kaisa dikhta hai.

Claude Code aur OpenCode aik hi idea ki do implementations hain, zyadatar wahi vocabulary aur thore se mukhtalif keybinds ke saath.

Do tools, aik nahin. Jaan boojh kar. Yahan ka discipline kisi bhi aik tool se zyada lamba chalna chahiye. Pricing changes, access restrictions, model preferences, aur strategic shifts aap ki seekhi hui cheezon ko phansana nahin chahiye. Har concept ko dono tools mein dikhana is baat ka sab se mazboot test bhi hai ke concept real hai ya nahin: agar koi technique sirf Claude Code mein kaam karti hai, to woh Claude Code ki trick hai; agar woh dono mein kaam karti hai (same shape, different keybinds), to woh agentic coding ke real behavior ka hissa hai. Claude Code tab use karein jab frontier model performance constraint ho; OpenCode tab use karein jab flexibility, cost control, ya openness matter karta ho. OpenCode free models ke set ke saath bhi aata hai jinhein aap account banaye baghair use kar sakte hain. Aap jo skills banate hain, dono taraf same rehti hain. Yahi point hai, compromise nahin.

May 2026 tak current. Dono tools fast ship hote hain: config schemas, command names, aur install commands badalte rehte hain. Agar aap ke paas abhi tools nahin hain, to installation instructions unhi docs pages par hain: Claude Code, OpenCode. Baqi kisi bhi cheez par doubt ho, to shuru bhi unhi pages se karein.

Dono tools frequently update hote hain; is liye koi bhi session shuru karne se pehle latest version use karne ke liye claude update aur opencode upgrade commands dein.

Assumed background: aap command line par comfortable hain, aap ne git use kiya hai, aur aap JSON config pehle parh ya likh chuke hain. LLM coding agents ka pehle se experience zaroori nahin. Yeh page isi ke liye hai. Agar MCP, hooks, ya LLMs aur external tools ke darmiyan protocol layer aap ke liye bilkul nayi hai, to aage chalte chalte context se samajh aa jayegi.

Pick your tool, page follows

Is page mein jahan Claude Code aur OpenCode ke darmiyan sections differ karte hain, wahan switcher hai. Aik tool choose karein; page ke saare switchers us ke saath sync ho jayenge, aur aap ki choice future visits mein bhi yaad rahegi.

Is page ke kisi bhi concept ki deep version chahiye?

Yeh crash course hai - aik read mein real use ka 80%. Neeche ke har topic ki full treatment ke liye (rules-file hierarchy, plan mode at depth, skill anatomy, subagent orchestration, hook events, CI/CD, session management), Chapter 14: Working with General & Coding Agents aur Chapter 17: Claude Code for Teams, CI/CD & Advanced Configuration dekhein. Crash course map hai; woh chapters terrain hain.

Aik mukammal worked example Part 6 mein hai: aik realistic task end-to-end, do baar run kiya gaya, har tool mein aik baar. Agar aap definitions parhne ke bajaye dekh kar behtar seekhte hain, to pehle wahan jayein aur phir wapas aayein.

---

Part 1: Foundations

Yeh pehle teen concepts dono tools mein yaksaan tareeqe se apply hote hain. Jahan commands ya keybinds mukhtalif hain, wahan farq inline bataya gaya hai.

1. Yeh tools asal mein kya hain

Zyadatar logon ka mental model "aik chatbot jo code jaanta hai" hai. Yeh ghalat hai, aur yahi ghalati masla hai.

Aik chatbot sawalon ke jawab deta hai. Claude Code aur OpenCode actions lete hain. Woh aapki files parhte hain, unhein edit karte hain, aapki machine par commands run karte hain, network hit karte hain, aur yeh sab aik saath jodte hain jab tak aik task poora na ho jaye. Aap unhein aik brief dete hain, woh kaam karte hain, aap review karte hain.

Mindset shift: sawal type karna band karein, briefs likhna shuru karein. "How do I add auth?" aik chatbot prompt hai. "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" aik agentic-coding prompt hai. Doosra kaam karega; pehla aik wandering monologue dega.

Yeh AI prompting ke concept 1 - ibtidai sarif vs. mahir sarif - ka wohi pattern hai, bas PDFs ki jagah files hain. Brief ki shape wohi hai; stakes zyada hain, kyun ke model is dafa action leta hai.

Dono tools defaults mein mukhtalif hain lekin fundamentals mein nahin. Claude Code Anthropic ka hai, Claude models ke saath aata hai, out of box polished hai. OpenCode open-source hai, model-agnostic (Claude, GPT, Gemini, local) hai, aur tool-level permission tak configurable hai. Apni model preferences aur kitna config control aap chahte hain us ke mutabiq aik ka intikhab karein; is crash course ka baqi hissa dono mein kaam karta hai.

Abhi tak koi bhi install nahin kiya? Aage parhne se pehle canonical one-liner le lein; is ke baad ke sections assume karte hain ke aap key press kar sakte hain aur kuch hota hua dekh sakte hain. Auth, IDE plugins, aur troubleshooting official docs par hain.

# 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

Mukammal reference: code.claude.com/docs.

Install ho jaye to jis folder mein kaam karna ho us mein terminal kholein aur claude (ya opencode) type karein. Is se aap ka pehla session shuru ho jayega. Yahan se aage is page ka har concept woh cheez hai jo aap us session mein try kar sakte hain.

2. Plan mode (sab se kam istemal hone wala feature)

Implementations thori mukhtalif hain lekin idea aik jaisa hai: model ko kuch bhi likhne dene se pehle, usse aik likha hua plan banane par majboor karein jise aap review kar sakein.

Shift+Tab dabayein permission modes mein cycle karne ke liye. Pehli baar dabane par aap auto-accept mein aa jayenge; doosri baar dabane par aap plan mode mein aa jayenge. plan mode mein, model read kar sakta hai lekin write nahin kar sakta: koi file edits nahin, koi shell commands nahin.

Dono sooraton mein yeh qadam do wajah se slow lagta hai, lekin asal mein speed-up hai:

1. Yeh ghalat fehmiyon ko pakad leta hai isse pehle ke woh aapko nuqsan pahunchayein. Plan aik contract hai. Agar model ne brief ko ghalat samjha, to aap usse plan mein dekhte hain, na ke aik 200-line ke diff mein jise aapko revert karna pade.
2. Yeh doosri baar mein behtar code banata hai. Aik pehle se likha hua plan relevant context (file paths, function names, intended approach) ko aik saaf artifact mein compress karta hai jis par implementation phase bharosa kar sakta hai. Plan ke baghair, model aik saath reasoning aur writing kar raha hota hai, aur reasoning haar jati hai.

Simple rule: 10-minute se zyada ki koi bhi change pehle plan mode se guzarti hai. Bade features ke liye, model se plan ko aik markdown file (docs/plans/feature-x.md) mein save karne ko kahein taake aap usay baad mein resume kar sakein ya aik fresh session mein feed kar sakein.

Plan mode aik hi move mein do prompting concepts ko jor deta hai: think hard (concept 5), lekin saath contract bhi hota hai; aur outline before drafting (concept 7), lekin filesystem ke saath. Diff edit karne ke bajaye plan edit karein.

3. Permissions discipline

Dono tools action lene se pehle approval maangte hain. Dono aapko globally approvals skip karne dete hain: Claude Code mein --dangerously-skip-permissions hai, OpenCode aapko "permission": "allow" set karne deta hai. Aisa na karein, kam az kam shuru mein nahin.

Jo pattern kaam karta hai: kuch sessions ke liye manual shuru karein, gaur karein ke kaun se actions auto-approve karne ke liye kaafi safe hain, phir usse config mein likh lein.

.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 *)"]
  }
}

Phir aik notification helper install karein. Woh pattern jo agentic coding ko tez mehsoos karata hai woh tez execution nahin hai: asal cheez kaam laga kar side par ho jana hai. Aik lamba task shuru karein, doosre kaam par switch karein, jab aapko ping kiya jaye tab wapas aayein. Agar aap kai sessions parallel mein chalate hain (aik haqeeqi cheez, aur aik haqeeqi productivity unlock), to notifications woh tareeqa hain jisse aap track rakhte hain ke kis session ko aapki zaroorat hai.

Claude Code ke paas community helpers hain jaise cc-notify. OpenCode ka desktop app natively system notifications bhejta hai; TUI ke liye, aik plugin likhein jo session.idle ko subscribe karta hai aur osascript (macOS) ya notify-send (Linux) ko shell out karta hai.

---

Hissa 2: Context management

Yeh crash course ka sab se ahem section hai. Agar aap sirf aik hissa achhi tarah samjhein, to woh yeh wala hona chahiye. Yahan sab kuch dono tools mein yaksaan tareeqe se apply hota hai; sirf command names kabhi kabhi mukhtalif hote hain.

Yeh AI prompting ke concept 4 - context is the whole game - ka zyada intense version hai. Wahan bura context sirf bura jawab deta tha. Yahan bura context bura jawab aur bura codebase dono de sakta hai. Discipline wohi hai, consequences zyada gehre hain.

4. Context rot waqai hota hai

Context window text ki woh miqdar hai jo model aik waqt mein hold kar sakta hai. Modern models ke paas bade windows hote hain: lakhon tokens, kabhi kabhi aik million tak. Yeh limitless lagta hai. Lekin aisa nahin hai.

Do cheezein samajhne ke liye:

Real usage window ko aap ki soch se zyada tezi se bhar deta hai. Kuch code files, aik stack trace, kuch docs jo aap ne paste kiye, aur aik 30-turn conversation aap ke notice karne se pehle hazaron tokens kha jayenge. Aap ka laptop fuel gauge nahin dikhata.

Recall window ke bharne se bahut pehle kharab ho jati hai. Studies (aur aap ka apna experience, agar aap tawajjo dein) dikhate hain ke jaise jaise token counts barhte hain, model context mein pehle ki khaas details yaad rakhne mein numayan taur par kharab ho jata hai. Model theek se bhoolta nahin hai. Yeh sirf us information ko sahi tareeqe se weight karna band kar deta hai. Symptoms: yeh aik constraint ko nazar andaz karta hai jo aap ne 20 messages pehle bataya tha, woh kaam dohrata hai jo pehle hi kar chuka tha, aik function signature ko hallucinate karta hai jo pehle sahi tha.

Aik financial dimension bhi hai. Har message poori context window ko dobara bill karta hai: aik debug session ke dauran bees baar ping ki gayi 50K-token conversation aik million tokens ka input hai, jo har turn par charge hota hai. Per-token APIs par (zyadatar OpenCode setups, raw Anthropic API) yeh wallet damage hai; subscription tiers par (Claude Code Pro/Max) yeh rate-limit hits ke taur par dikhta hai. Dono sooraton mein, bloated context aap ka budget tabhi drain karta hai jab aap ko sab se zyada kaam karne ki zaroorat hoti hai.

Takeaway unromantic lekin practical hai: kam context, soch samajh kar istemal kiya gaya, us zyada context se behtar hai jo umeed mein dump kiya gaya ho.

5. /clear aur /compact

Do commands, do situations.

Conversation wipe karein aur naye sire se shuru karein. Jab kisi gair-mutaliqa task par switch karein tab istemal karein. Purana context gair-zaroori shor hai jo naye task ko sirf confuse karega.

• Claude Code: /clear
• OpenCode: /new (jise /clear bhi kehte hain)

Conversation ko summarize karein, summary rakhein, baqi discard karein. Jab aap kisi aik lambe task mein gehre hon aur context zyada ho raha ho, lekin aap thread nahin kho sakte, tab istemal karein.

• Dono tools: /compact (OpenCode mein, jise /summarize bhi kehte hain)

Aap guide kar sakte hain ke compact mein kya rakhna hai: /compact keep the API contract decisions and current file paths.

Yeh interchangeable nahin hain. /clear ka matlab hai "new conversation." /compact ka matlab hai "same conversation, less baggage." Ghalat command chunne se ya to zaroori context kho jayega ya bekar context bachha rahega.

6. Sessions resume karein

Conversations save hoti hain. Dono tools aapko resume karne dete hain, idea same hai, command different:

• Claude Code: claude --resume aur list se aik session choose karein.
• OpenCode: TUI ke andar saved sessions ke darmiyan switch karne ke liye /sessions (jise /resume bhi kehte hain).

Do patterns jahan yeh matter karta hai:

• Kal se pick up karein. Long features rarely aik sitting mein fit hote hain. Resume aapko rukne deta hai baghair model ki project working memory lose kiye.
• Multiple branches chalayein. Kisi bhi session ko resume karein, sirf last session ko nahin. Aap aik session backend task par deep chala sakte hain aur doosra frontend par, phir un ke darmiyan switch kar sakte hain.

Agar aap ke paas saved plan file (docs/plans/feature-x.md) hai, to fresh session ko bhi aik message mein speed par laya ja sakta hai: "read docs/plans/feature-x.md and continue from step 4." Resume faster hai, lekin plan file safety net hai. (Full pattern - kab resume karna hai, kab fork karna hai, aur bad turn ke baad recover kaise karna hai - Chapter 17 Session Management: Resume, Fork, and Recovery mein hai.)

Rewind dono mein hota hai, aur dono file changes roll back kar sakte hain. Claude Code mein Esc do baar dabayein (double-tap Esc), ya /rewind run karein, apni previous user messages ki list kholne ke liye; aik choose karein aur phir aap decide karte hain kya restore karna hai: code, conversation, ya dono. Yeh is liye kaam karta hai kyun ke Claude Code har prompt se pehle model ki file edits ko checkpoint karta hai. OpenCode mein /undo last user message rewind karta hai aur us turn ki file changes revert karta hai; /redo last /undo ko reverse karta hai. Yeh under the hood git use karta hai, is liye aap ka project git repo hona chahiye. Aik real difference: Claude Code ki checkpointing model ki file edits track karti hai, lekin bash commands se badli hui files nahin (model ka chalaya hua rm ya mv checkpointed nahin hota); OpenCode ka git-backed /undo, kyun ke woh poori working tree diff karta hai, bash-driven changes bhi catch kar leta hai. Dono bad prompt se bacha lete hain; OpenCode ka /undo khaas taur par tab use karein jab bad turn mein shell commands ne files touch ki hon.

Teen commands ke liye quick decision rule:

Diagnostic: jab context kharab ho jaye

Context rot ke visible symptoms hote hain. In mein se kisi par bhi nazar aaye to alert ho jayen:

• Model baar baar apologize karta hai lekin progress nahin karta.
• Woh code ke usi block ko dobara likhta hai, meaningful changes ke baghair.
• Woh aise variables, files, ya functions reference karta hai jo exist nahin karte.
• Woh us constraint ko contradict karta hai jo aap ne isi session mein pehle bataya tha.
• Har response lamba, vague, aur zyada deferential hota jata hai.

Jab yeh dikhe, typing band karein. "Bas aik aur clarifying prompt" dene ka instinct ghalat hai; is se already polluted context mein aur polluted context add hota hai. Sahi move reset aur re-brief karna hai. Agar conversation mein koi useful core preserve karna hai to /compact run karein; agar waqai fresh start chahiye to /clear (ya OpenCode ka /new). Panch minute ka reset us model se aik ghanta argue karne se behtar hai jiska context poison ho chuka ho.

Diagnostic: jab context ki cost spike kare

Cost discipline bhi context discipline hi hai; bas aik cheez aap wallet mein mehsoos karte hain. Har turn poora context dobara bill karta hai, is liye jo bloat recall ko hurt karta hai woh bill ko bhi hurt karta hai. Provider koi bhi ho, surprise bills mein aksar yeh five symptoms milte hain:

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.

Zyadatar cases aik single config change mein recover ho jate hain. In paanchon ke neeche mechanic wahi hai jo Part 2 argue kar raha hai: stable, narrow context cheaper hota hai aur better recall karta hai; sprawling context har turn mehnga bhi hota hai aur unreliable bhi.

---

Hissa 3: Rules file

7. CLAUDE.md / AGENTS.md, sahi tareeqe se

Dono tools har session ke start par project-root markdown file ko context mein load karte hain. Yeh project-level system prompt ke sab se qareeb cheez hai.

Is file ko scratch se mat likhein. Fresh project mein kisi bhi tool ke andar /init run karein. Model aap ka folder scan karta hai aur file ka draft bana deta hai. Us ke baad aap ka kaam hai be-rehmi se delete karna jo zaroori nahin: yeh authoring task nahin, editing task hai. Neeche sab kuch isi bare mein hai ke kya rakhna hai aur kya cut karna hai. (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 karta hai. OpenCode AGENTS.md use karta hai. Migrators ke liye, OpenCode CLAUDE.md ko fallback ke taur par bhi read karta hai jab AGENTS.md present na ho; agar dono files exist karti hain, to AGENTS.md jeetta hai aur CLAUDE.md ignore hota hai. Agar aap pehle se CLAUDE.md maintain kar rahe hain, to OpenCode usay pick up karega jab tak aap complete opt-out ke liye OPENCODE_DISABLE_CLAUDE_CODE=1 set nahin karte. Partial disable ke liye, OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=1 sirf rules-file fallback skip karta hai aur OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1 sirf skills fallback skip karta hai. Dono tools ke darmiyan yeh sab se bara portability win hai.

Jo ghalti taqreeban har koi karta hai woh yeh hai ke is file ko documentation samajh leta hai: architecture overviews, full coding standards, aur codebase ki har quirk bhar deta hai. Result aik 20,000-token file hoti hai jo har task par aap ka context budget khati hai, un tasks mein bhi jahan is ka 90% irrelevant hota hai. Part 2 yaad rakhein: is file mein jo kuch bhi hai, har single message par us ki cost pay hoti hai, chahe relevant ho ya nahin.

Sahi model table of contents hai, encyclopedia nahin. ~2,500 tokens se kam target rakhein. Deep context ko reference karein jo demand par load hota hai:

CLAUDE.md. @filename syntax mutaliqa hone par referenced files ko auto-load karta hai:

# 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.

Yahi tareeqa non-software projects ke liye bhi kaam karta hai. Aik consultant jo reports likh raha hai, aik teacher jo lesson plans bana raha hai, aik small-business owner jo operations chala raha hai: rules file "table of contents, not encyclopedia" hai, domain koi bhi ho. Aik writing/content project ke liye misaal (CLAUDE.md ya AGENTS.md, yahi tareeqa):

# 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 jaise hi principles: tight, declarative, sirf woh cheezein jo model folder ko dekh kar infer nahin kar sakta.

Har us line ke liye jo aap add karne ka soch rahe hain, poochhein: "agar mein isko delete kar dun, to kya model aisi ghalti karega jo woh warna nahin karta?" Agar nahin, to delete kar dein. Model ko TypeScript use karne ko na batayein: woh .ts files dekh sakta hai. Usko woh cheezein batayein jo woh infer nahin kar sakta: codegen folder, auth pattern, woh cheezein jinhone aapko pehle pareshan kiya hai.

Yeh file asal failures se banani chahiye, na ke khayali failures se. Isko git mein commit karein. Apni team ko is mein add karne dein.

---

Hissa 4: Apne tool ko personalize karna

Dono tools mein chaar extension types hain. Decision tree aik jaisa hai:

In mein se har aik context-management tool hai. Custom commands aur skills zaroorat ke mutabiq sahi context inject karte hain. Hooks aur plugins rules ko enforce karte hain baghair tokens kharch kiye model ke "yaad rakhne" par. Subagents context ko quarantine karte hain taake woh aap ke main thread mein leak na ho. Masla wahi, tareeqe alag.

8. Slash commands

Slash command aik saved prompt hota hai jiska shortcut yaad rakhna asaan hota hai. Dono tools isay support karte hain, aur shape kaafi similar hai.

Aik gotcha pehle hi note kar lein: commands session start par aik dafa load hoti hain. Agar aap mid-session nayi command banate hain (chahe file khud likhi ho ya model se likhwai ho), to woh autocomplete mein tab tak nahin aayegi jab tak aap CLI se exit kar ke dobara enter nahin karte. Neeche ke dono folders mein behavior same hai; command banane ke baad session restart karein.

Markdown files .claude/commands/ (project) ya ~/.claude/commands/ (personal) mein. Misaal .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.

Yeh /review command AI Prompting ke concept 6 ko kaam mein lagati hai.

AI models aap se agree karna pasand karte hain. Agar aap baghair instructions ke "review my diff" poochhein, to aksar jawab aata hai looks good, well-structured, nice naming, chahe sach ho ya na ho.

Upar wali four-point checklist isay rok deti hai. Model ab sirf "looks good" nahin keh sakta. Usay har point one by one check karna hota hai, aur fail hone wali line par point karna hota hai.

Dono /review ke taur par invoke hoti hain. Dono $ARGUMENTS support karte hain (aur OpenCode positional $1, $2, etc. bhi add karta hai). OpenCode !`shell command` se command output prompt mein inject kar sakta hai, aur agent: plan / subtask: true frontmatter se command ko specific agent tak route kar sakta hai ya subagent mein run kar sakta hai. Yeh review workflows ko main context se bahar rakhne ke liye useful hai.

Aik non-software example. Daily ritual ke liye /standup command, jo aksar teams mein hota hai. Isay .claude/commands/standup.md (ya .opencode/commands/standup.md) ke taur par save karein:

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.

Ab jab bhi aap /standup type karte hain, yeh kal ke notes se clean status update bana deta hai. Shape upar wale /review jaisi hi hai, bas domain different hai. Yahi trick /digest (emails ke folder ko action items mein badalna), /draft-reply (is path par email ka polite reply likhna), ya kisi bhi chore ke liye kaam karti hai jahan aap do dafa se zyada same instructions type karte hain.

Dono tools mein unifying test yeh hai: agar aap same instructions do dafa se zyada type kar rahe hain, to woh command honi chahiye. Depth version (folder layout, frontmatter, argument passing, command ko skill mein kab promote karna hai) Chapter 14 Teach Claude Your Way of Working mein hai.

Note (Claude Code, 2026): 2026 tak slash commands aur skills unify ho chuki hain. .claude/commands/ mein files ab bhi kaam karti hain aur slash commands ke taur par nazar aayengi, lekin naya kaam increasingly .claude/skills/ mein ja raha hai kyun ke skills zyada support karti hain (auto-invocation, subagent execution, file-path filters). Dono ko continuum samjhein.

9. Skills

Skill custom command ka bara sibling hota hai. Idea wahi hai, packaged expertise, lekin teen meaningful upgrades ke saath jo dono tools mein identical hain:

1. Auto-invocation. Model har session ke start par skill descriptions read karta hai aur jab task match kare to right skill invoke karta hai.
2. Progressive disclosure. Skill mein SKILL.md file hoti hai (entry point) aur woh same folder ki baqi files reference kar sakti hai. Up front sirf SKILL.md load hoti hai; baqi demand par load hoti hain. Yeh context-management principle ko file format bana deta hai.
3. Frontmatter controls. SKILL.md ke top par YAML behavior configure karta hai.

File format converge ho chuka hai. Aik tool ke liye likhi skill largely doosre tool mein bhi kaam karti hai.

.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`.

Haan, yeh byte-identical hain. OpenCode ~/.claude/skills/ aur .claude/skills/ ko fallback ke taur par bhi read karta hai, is liye jo skill aap Claude Code ke liye pehle likh chuke hain woh OpenCode mein baghair changes kaam kar jati hai.

Description sab se important field hai: model isi se decide karta hai ke skill apply hoti hai ya nahin. Vague descriptions ("helps with videos") har jagah fire hoti hain; specific descriptions ("Use when the user provides a YouTube link...") sirf relevant cases mein fire hoti hain.

SKILL.md ko short rakhein: ~200 lines se kam achha rule hai. Depth ko same directory ki reference files mein push karein aur un se link karein. Is tarah quick task sirf overview ki cost pay karta hai; deep task zaroorat ke references pull kar sakta hai. (Foundational walkthrough ke liye - skill hai kya, kab activate hoti hai, progressive disclosure kaise kaam karta hai - Chapter 14 The Concept Behind Skills aur Building Your Own Skills dekhein. Team/CI variant ke liye - frontmatter fields, glob-scoped activation - Chapter 17 Custom Skills with Frontmatter dekhein.)

Skills scratch se mat likhein. Claude Code ke saath skill-creator skill aati hai jo nayi skills ko correctly scaffold karti hai. Same fallback ki wajah se isay aik dafa install karein aur dono tools invoke kar sakte hain. (Note: file discovery shared hai, lekin skill bodies agar Claude Code-specific tools reference karti hon to OpenCode mein clean run karne ke liye light edits chahiye ho sakti hain. Naye agents ke liye, jo OpenCode mein alag concept hain, interactive agent scaffolder ke liye opencode agent create use karein.)

Aik aur pattern: small skills chain karein, monoliths na banayein. Aisi "weekly content digest" skill jo research, writing, formatting, aur review sab aik saath kare, maintain karna mushkil hota hai aur har step par kamzor hoti hai. Is se behtar chaar separate skills (research, draft, format, review) hain jo aik doosre ko hand off karte hain. Handoff aksar filesystem-mediated hota hai: research apna output tmp/research.md mein likhta hai, phir draft ko us se read karne ko kaha jata hai; draft tmp/draft.md mein likhta hai, aur isi tarah aage. Aap model ko sequence mein run karne ka prompt bhi de sakte hain ("use the research skill, then draft a post from the output"), lekin file-based pipeline /clear ke across zyada durable aur debug karne mein asaan hoti hai. Dono sooraton mein, har skill apne step par focused rehti hai. Reusability achhi hai, lekin real win per-step context isolation hai: format skill ko research notes load karne ki zaroorat nahin, aur research skill ko formatting conventions janne ki zaroorat nahin. Wahi principle jo subagents mein hai, chhoti granularity par.

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

Skills probabilistic hoti hain: model decide karta hai invoke karni hai ya nahin. Hooks aur plugins deterministic hote hain: specific events par fire karte hain, har dafa, baghair model judgment ke.

Idea same hai, machinery different. Yahan dono tools sab se zyada diverge karte hain. Tabs se pehle aik naming note: Claude Code ke paas aik separate cheez bhi hai jise woh "plugins" kehta hai (bundles jo commands, skills, aur hooks ko package karte hain). Yeh section us bare mein nahin hai. Yahan "hook" ka matlab hamesha Claude Code lifecycle hook hai, aur "plugin" ka matlab hamesha OpenCode event module hai. Dono apne apne tool mein same slot occupy karte hain: deterministic guardrail.

Hooks shell commands hain jo .claude/settings.json mein lifecycle events se attach hoti hain. Big events: SessionStart, UserPromptSubmit, PreToolUse (exit code 2 blocks), PostToolUse. Structure ke teen levels hain: event (PreToolUse), matcher group jo tool name (Bash) se filter karta hai, aur handler jo run hota hai. Handler ka if field actual command match kar ke further narrow karta hai, taake handler sirf zaroorat par spawn ho. Example: rm -rf block karein, chahe model ka mood kuch bhi ho:

{
  "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 karta hai; jab tak command run hota hai, tool call already known rm -rf hoti hai, is liye command ko sirf refuse karna hota hai (exit code 2 blocks). Jab hook ko waqai tool input inspect karna ho (sirf match nahin), Claude Code woh input stdin par JSON ke taur par pass karta hai, jise command jq se read karti hai. Neeche placeholder example mein aap yeh dekhenge.

Aik non-software example: aise drafts ship na hon jin mein placeholder markers abhi bhi hon. Maan lein aap drafts mein kabhi kabhi [TODO] ya [FIX] markers chhor dete hain aur publish karne se pehle resolve karna bhool jate hain. Hook published/ mein koi bhi write block kar sakta hai agar file mein placeholder abhi bhi ho:

{
  "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"
          }
        ]
      }
    ]
  }
}

Is check ko file ke andar dekhna padta hai, is liye yeh rm -rf block se zyada kaam karta hai. matcher har Write catch karta hai; command Claude Code ke stdin par diye gaye JSON ko seedha aik jq test mein pipe karta hai jo do cheezen aik saath check karta hai, aur sirf tab block karta hai jab dono true hon: file_path published/ ke andar ho, aur content mein placeholder marker ho. drafts/ file mein [TODO] pass ho jata hai; published/ mein clean file pass ho jati hai; sirf marked file jo published/ ki taraf ja rahi ho code 2 ke saath rukti hai. Model file likhta hai, hook check karta hai, aur agar placeholder leak ho gaya ho to model ko file ship hone se pehle usay resolve karna padta hai.

Trade real hai: OpenCode plugins zyada capable hain; Claude Code hooks simpler hain.

Jo bhi bash likh sakta hai woh paanch minute mein Claude Code hook likh kar Node toolchain ke baghair repo mein ship kar sakta hai. OpenCode plugins ko Bun ya Node, npm dependencies, aur TypeScript ya JavaScript fluency chahiye. One-line check, jaise rm -rf block karna, mein shell cost par jeet jata hai. Structured logging, async work, ya multiple event subscriptions ke liye JS/TS module waqai cleaner hota hai. Woh tool chunen jiski constraints aap ke build se match karti hon.

Production codebases par in tools ko chalane walon ka useful pattern: write time par block na karein, commit time par block karein. Model ko apna kaam finish karne dein (mid-edit interrupt usay confuse karta hai) aur commit step par hook/plugin chalayein jo check kare ke tests pass hain, types check hain, formatter khush hai. Agar kuch fail ho, model ko fix loop mein wapas bhejein.

Hooks/plugins un cheezon ke liye use karein jo aapko 100% waqt true chahiye hoti hain. Skills un cheezon ke liye use karein jo aap chahte hain ke model aksar yaad rakhe.

11. Subagents

Aik subagent aik isolated agent instance hai jis ki apni context window hoti hai. Aap use aik task delegate karte hain; woh private mein kaam karta hai; woh aik summary wapas karta hai. Us ki file searches, log dumps, aur exploratory reads kabhi bhi aap ke main thread ko touch nahin karte.

Context-management ke lihaz se yeh kyun zaroori hai: sab se zyada context-poisoning cheez jo aap kar sakte hain woh hai "codebase ko explore karna yeh janne ke liye ke X kahan hota hai." Is tarah ka task darjanon files ko context mein khinch leta hai, jin mein se zyada tar ki aapko zaroorat nahin hoti. Ise aik subagent mein karne ka matlab hai ke aap ka main session sirf nateeja dekhta hai ("X src/services/billing.ts:142 mein hota hai"), search nahin.

Dono tools aik read-only Explore subagent ke saath aate hain (doosron ke ilawa; OpenCode aik General subagent bhi ship karta hai zyada bade delegated work ke liye) jo aap ke main thread ko pollute kiye bagair codebase exploration ko handle karta hai. Claude Code mein, plan mode auto-delegate karta hai Explore ko: aap zyada tar ise soche bagair istemal karenge, aur model khud bhi pooche jane par plan mode mein self-enter kar sakta hai. OpenCode mein, Plan agent subagents ko usi tarah auto-invoke kar sakta hai (subagent delegation aik normal primary-agent capability hai), ya aap ise @explore ke saath explicitly call kar sakte hain; Plan mode mein khud enter karna, lekin, Tab ke zariye aik deliberate user action hai.

Custom subagents ke liye:

.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.

Aik non-software misaal: aik research subagent. Farz karein aap ke paas lambi PDFs (industry reports, legal contracts, academic papers) ka aik folder hai aur aap chahte hain ke agent aik focused summary extract kare poore document ko apni main thread mein laaye baghair:

---
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.

Upar diye gaye doc-fetcher jaisa hi shape, alag domain. 200-page PDF aapki main conversation se bahar rehti hai; sirf jawab wapas aata hai.

Invocation dono tools mein same hai. Dono subagent ki description ki bunyad par auto-invoke karte hain (yeh woh path hai jo aap zyada use karenge: achhi description likhein, aur jab task match karega model right helper choose kar lega). Dono prompt mein explicit invocation with @subagent-name bhi support karte hain; OpenCode isay autocomplete mein zyada prominently dikhata hai, lekin Claude Code bhi isay accept karta hai. Default auto-invocation rakhein; @name tab use karein jab aap sure karna chahte hon ke specific subagent run ho (ya jab description multiple candidates ke darmiyan ambiguous ho).

Aam qanoon, dono mein yaksaan: agar kisi task mein bahut zyada reading shamil hai jo final answer se relevant nahin hogi, to woh subagent mein belong karta hai. (Chapter 14 Subagents and Orchestration apna subagent likhne aur unhein chain karne ka walkthrough deta hai.)

---

Hissa 5: Duniya se judna

12. MCP, imandari se istemal kiya gaya

MCP (Model Context Protocol) external tools (Slack, Notion, aapka database, GitHub, ya kuch bhi) ko expose karne ka aik standardized tareeqa hai agent ko. Claude Code aur OpenCode dono aik hi protocol ka istemal karte hue MCP ko support karte hain. Aik ke liye likha gaya server doosre mein kaam karta hai.

Configuration ka shape cosmetically mukhtalif hai:

Aam taur par CLI ke zariye configure kiya jata hai (claude mcp add ...) ya .claude/settings.json mein.

Dono tools mein yeh pitch haqeeqi hai: agent ko aap ke tools se connect karne ka matlab hai ke woh aap ke kaam par amal kar sakta hai, sirf us ke bare mein baat nahin kar sakta. Aik Linear ticket parhna, aik Slack update post karna, production read-replicas ko query karna: sab munasib hain.

Dono tools par lagu hone wali imandaar shart yeh hai: MCP hamesha sahi jawab nahin hota, aur kuch tajurbekar users ne zyada MCP istemal karne ke bajaye simple CLIs ko tarjeeh di hai. Wajah yeh hai: aik MCP server underlying tool ko operations ke aik fixed set mein abstract karta hai, aur har operation tool descriptions mein pehle se hi aik context cost pay karta hai. Aik CLI sirf aik CLI hai: agent uski --help parh sakta hai, flags compose kar sakta hai, outputs pipe kar sakta hai, aur improvise kar sakta hai. Stateless tools (GitHub, AWS, Jira) ke liye, gh, aws, aur jira CLIs aksar un ke MCP equivalents se zyada flexible hote hain.

OpenCode ke docs mein yeh baat wazeh taur par kahi gayi hai: "MCP servers aap ke context mein izafa karte hain, isliye aapko unhein enable karte waqt ehtiyat baratna chahiye. Kuch MCP servers, jaise ke GitHub MCP server, bahut zyada tokens add karte hain aur aasani se context limit ko exceed kar sakte hain."

Aik mufeed working model: MCP ko stateful ya auth-heavy services ke liye istemal karein jahan protocol layer asal mein kaam kar raha ho (Playwright aik misali misaal hai: browser session manage karna mushkil hai). Baqi sab ke liye CLIs istemal karein. Das MCP servers sirf isliye install na karein kyunki woh maujood hain; aik tab install karein jab koi asal wajah ho.

---

Hissa 6: Aik mukammal misaal, do baar

Yeh woh section hai jiski taraf baqi crash course ishara karta hai. Aik haqeeqi task, har concept, dono tools. Wohi aath faisle, aik baar Claude Code mein aur aik baar OpenCode mein dikhaye gaye hain, side by side, taake aap dekh sakein ke asal mein kitna kam farq hai.

Aap code ki aik bhi line nahin likhenge. Koi bhi shakhs jis ke paas laptop aur files ka aik folder ho, woh saath chal sakta hai: aik manager, aik teacher, aik small-business owner, aik student. Yeh task aik choti team ke meeting notes istemal karta hai, lekin yeh school committee, volunteer group, freelance practice, ya logon ke kisi bhi aise group ke liye usi tarah kaam karta hai jo notes rakhte hain aur unse action items nikalne ki zaroorat hoti hai.

Aapka task

Aap ke paas notes/ naam ka aik folder hai jismein paanch files hain: aapki team ke pichle hafte ke meeting notes. Woh messy hain. Kuch meetings mein action items ## Action Items ke tehat list kiye gaye hain. Kuch ## Todos istemal karte hain. Aik lowercase ## todo istemal karta hai. Kuch action items dusre sections ke andar gehrai mein chhupe hue hain. Kuch bullets [private] ya [HR] tag kiye gaye hain aur unhein public nahin hona chahiye.

Aapko aik clean file, weekly-actions.md, chahiye jo har action item ko list kare, us ke owner ke hisab se group kiya gaya ho, aur us meeting ka link bhi ho jahan se woh aaya hai. Koi bhi private cheez leak nahin honi chahiye. Kuch bhi gum nahin hona chahiye. Aur agar koi deadline public holiday par aati hai, to aapko aik warning chahiye.

Paanch starter files pehle lein (expand karne ke liye click karein)

Shuru karne se pehle inhein notes/ folder mein copy karein. Yeh misaal un ke ird-gird banayi gayi hai: har file ka aik khaas role hai, isliye agar aap aik ko skip karte hain, to neeche diye gaye steps mein se aik kaam karna band kar dega. (Agar aapko folder set up karne ka dil nahin karta, to aap paanch files ko seedhe apne tool ke chat mein paste kar sakte hain aur usse keh sakte hain ke woh unhein notes/ ke contents samjhe.)

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]

Is section ko kaise parhein

Is chapter ki eight context-management decisions neeche numbered steps ki shakal mein di gayi hain. Har step ka pattern aik jaisa hai:

• Aap kya karte hain: woh exact cheez jo aap type ya press karte hain
• Kyun: aik paragraph jo batata hai ke yeh decision aap ko kya deta hai
• OpenCode mein kya badalta hai: doosre tool ka version

Agar kisi step mein likha ho "OpenCode mein identical" to aap us line ko skip kar sakte hain.

---

Decision 1: Rules file trim karein

Aap kya karte hain (Claude Code). Apne project folder mein Claude Code open karein. /init run karein. Yeh CLAUDE.md naam ki file banata hai jo aksar bohat lambi hoti hai. Us ka zyada hissa delete kar dein. Sirf yeh rakhein:

# 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]`.

Kyun. Yeh file har message ke start par read hoti hai. Jo kuch aap yahan daalte hain us ki cost har turn par lagti hai. Is liye isay short rakhein: sirf woh cheezen jo model folder dekh kar khud infer nahin kar sakta. Privacy rule khaas taur par aisi cheez hai jo woh guess nahin kar sakta.

OpenCode mein kya badalta hai. File ka naam CLAUDE.md ke bajaye AGENTS.md hota hai. Content aur maqsad wohi rehte hain. Agar aap ke paas pehle se CLAUDE.md hai, OpenCode use bhi read kar lega; rename karna zaroori nahin.

---

Decision 2: Likhne se pehle plan

Aap kya karte hain (Claude Code). Shift+Tab do dafa press karein. Model plan mode mein chala jata hai: woh files read kar sakta hai lekin kuch change nahin kar sakta. Phir type karein:

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 aik minute sochta hai, phir likha hua plan wapas deta hai ke woh exactly kya karne wala hai.

Kyun. Yeh dono tools ka sab se underused feature hai. Plan read karne mein 30 seconds lagte hain. Ghalat change revert karne mein kaafi zyada waqt lagta hai. Hamesha pehle plan chahiye. (Foundations: Chapter 14 Hello Claude dono tools mein plan mode introduce karta hai; Chapter 17 Plan Mode vs Direct Execution zyada depth mein batata hai ke yeh kab payoff deta hai aur kab sirf slow karta hai.)

OpenCode mein kya badalta hai. Tab press kar ke Build agent se Plan agent par switch karein. Brief aur result identical hain; sirf keystroke badalta hai.

---

Decision 3: Plan par push back karein

Aap kya karte hain (Claude Code). Plan ko dhyan se parhein. Do cheezen aksar ghalat hoti hain.

Pehli: plan sirf top-level headings (## Action Items, ## Todos) ka zikr karega. Lekin aik meeting file (Q1 planning notes) action items ko ### Year-end promotional campaign ke andar, aur us ke neeche #### Action Items mein chhupati hai. Plan unhein miss kar dega.

Doosri: plan yeh nahin batayega ke jin action items ka owner nahin hai (jis ke paas @name nahin, jaise customer-feedback file ka "rewrite the pricing page in plain language"), un ke saath kya karna hai. Woh chup chaap drop ho sakte hain.

Aap push back karte hain:

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 karta hai. Aap us se final plan plans/weekly-rollup-plan.md mein save karwate hain taake aglay Friday reuse ho sake.

Kyun. Plan aik contract hai. Problems yahan pakrein, jab in ki cost zero hai - file likhne ke baad safai karna mushkil hota hai.

OpenCode mein kya badalta hai. Identical.

---

Decision 4: Isay kaam karne dein

Aap kya karte hain (Claude Code). Plan mode se bahar nikalne ke liye Shift+Tab press karein. Model ko kaam shuru karne ko kahen.

Woh paanch files read karta hai. weekly-actions.md likhta hai. Items ko owner ke hisaab se group karta hai. [private] aur [HR] bullets drop karta hai. Orphan items ko Unassigned section mein daalta hai. Aap yeh sab hota hua dekhte hain.

Kyun. Ab tak aap ne carefully setup kiya hai. Ab usay kaam karne dein. Plan ki wajah se pehli try mein kaam zyada tar sahi hota hai.

Dekhein file kahan bani hai

weekly-actions.md project root mein hona chahiye, notes/ ke saath, notes/ ke andar nahin. Agar model ne isay notes/ mein likh diya, to yeh signal hai ke Decision 1 ka CLAUDE.md Layout section missing hai ya ignore ho raha hai. Isay abhi fix karein: Decision 6 ka safety net root-level weekly-actions.md mein filenames grep karega, aur ghalat jagah wali file nahin dhoond payega.

OpenCode mein kya badalta hai. Pehli dafa har file write par approval poochi jayegi. Aap yes keh sakte hain, ya baad ki runs ko smooth banane ke liye common actions opencode.json mein pre-approve kar sakte hain.

---

Decision 5: Jab conversation lambi ho jaye to summarize karein

Aap kya karte hain (Claude Code). Conversation ab lambi ho chuki hai. Model har meeting note read kar chuka hai, aur bohat sa raw content ab bhi memory mein hai - kuch private bullets bhi, jinhein us ne sahi taur par skip kiya. Ab aap ko yeh raw content nahin chahiye. Type karein:

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

Conversation sirf un cheezon tak summarize ho jati hai jo aap ne rakhne ko kahi thin.

Kyun. Lambi, cluttered conversation model ko behtar nahin, worse banati hai. Cost bhi zyada hoti hai. Jo relevant nahin raha use clear kar dein - khaas taur par private content, jise memory mein zaroorat se zyada der nahin rehna chahiye.

OpenCode mein kya badalta hai. Command identical hai.

---

Decision 6: Commit ke liye safety net set karein

Aap kya karte hain (Claude Code). Git mein kaam save karne se pehle aap ensure karna chahte hain ke koi meeting accidentally skip na hui ho. Aap aik Claude Code hook add karenge: aik chhota safety net jo har commit se pehle automatically run hota hai.

Model se yeh wala na likhwain: khud paste karein

Yeh chapter ki aik jagah hai jahan aap model se config block likhwana nahin, balkay khud paste karna hai. Is ki do wajahen hain, dono mushkil experience se seekhi gayi hain.

(1) "Hook" ambiguous hai. Agar aap model se kahen "create a hook," to Claude Code git hook (.git/hooks/ ki file) ki taraf ja sakta hai, Claude Code hook (.claude/settings.json ki entry) ki taraf nahin. Yeh dono alag cheezein hain; aap ko doosri chahiye.

(2) Model clever banne ki koshish karega aur safety net quietly break kar dega. Aap ka CLAUDE.md kehta hai ke [private] aur [HR] items skip karo. Agar aap vaguely poochhein, to model woh rule read karega aur "helpfully" hook script mein bhi same filter bake kar dega. Natija yeh hoga ke vendor-review meeting (jahan har bullet [private] hai) quietly ignore ho jayegi aur hook kabhi fire nahin karega. Hook ka poora point wahi case catch karna hai. Model se usi rules ke khilaf watchdog likhwane ko kehna, jinhein woh pehle se honour karne ko kaha gaya hai, losing game hai.

Safe move yeh hai ke configuration seedha paste kar dein.

.claude/settings.json kholein (file exist nahin karti to create karein) aur yeh exactly paste karein:

{
  "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"
          }
        ]
      }
    ]
  }
}

Seedhi zaban mein: matcher kehta hai "Bash tool ko watch karo"; if usay sirf git commit commands tak narrow karta hai; command phir notes/ ki har .md file par loop karta hai, us ke basename ko weekly-actions.md mein grep karta hai, aur agar koi file mentioned nahin hoti to code 2 ke saath exit karta hai (jo commit block karta hai). Koi content filters nahin, koi [private] checks nahin, koi exceptions nahin. Sirf filenames. Yahi poora point hai.

Ab model ko commit karne ko kahen. Safety net fire hota hai: Missing: notes/2026-12-11-vendor-review.md. Reason logical hai: us meeting mein har action item [private] tagged tha, aur Decision 1 ke rules kehte hain unhein drop karna hai; is liye jab rollup bana to is file se likhne ko kuch nahin tha, aur filename kabhi include nahin hua. Hook ko yeh sab nahin pata; woh sirf dekhta hai ke file unmentioned hai, aur block kar deta hai.

Model error read karta hai aur rollup ko placeholder entry se patch karta hai jo file ka naam explicitly mention karti hai, example:

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

- All items confidential — see meeting owner.

Ab filename weekly-actions.md mein present hai, hook ka grep usay find kar leta hai, aur commit go through ho jata hai. Rollup mein kuch private leak nahin hua; audit trail intact hai.

Is loop ke dauran aap ne kuch nahin kiya. Safety net ne mistake pakri aur model ne khud fix kar li.

Kyun. Jo cheezein aap har single time true chahte hain, unhein model ke yaad rakhne par depend nahin karna chahiye. Unhein automatically check hona chahiye. Aur check aisi jagah rehna chahiye jahan model aap ko please karne ke liye quietly rewrite na kar sake: isi liye yeh paste hai, prompt nahin.

OpenCode mein kya badalta hai. OpenCode inhein plugins kehta hai, hooks nahin, aur yeh chhoti JavaScript file ke taur par likhi jati hain. Same idea, same outcome, same paste-don't-prompt logic. .opencode/plugins/check-rollup-complete.js create karein (folder shayad abhi exist na karta ho) aur yeh paste karein:

// .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/ ki har file list karo, har basename ko rollup mein check karo, aur koi missing ho to throw karo. Andar koi [private] filter nahin. Behavior Claude Code version jaisa hi hai: missing file, commit blocked, model fixes itself.

Hook/plugin material depth mein (exit codes, matcher syntax, full event list) Chapter 14 Hooks and Extensibility mein hai (aur OpenCode side ke liye Plugins: Putting It All Together).

---

Decision 7: Side-task helper ko bhejein

Aap kya karte hain (Claude Code). Kuch action items mein deadlines hoti hain jaise "by Dec 25" ya "before year-end." Aap flag karna chahte hain ke agar koi deadline public holiday par aa rahi ho to owners adjust kar saken. Aap type karte hain:

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

Aik separate helper web se lamba page fetch karta hai, sirf dates extract karta hai, aur unhein aik chhoti file mein likhta hai. Aap ki main conversation sirf chhoti file dekhti hai, lamba page nahin.

Phir model aap ke rollup ki deadlines read karta hai, holidays se cross-reference karta hai, aur brochure deadline ke paas note add karta hai: ⚠ falls on Christmas Day.

Kyun. Web page direct fetch karne se pages ka text aap ki conversation mein dump ho jata, jis se session slow aur cluttered hota. Helper ko bhejne ka matlab hai sirf answer wapas aata hai, noise nahin.

OpenCode mein kya badalta hai. Aap helper ko call karne ke liye seedha @doc-fetcher type kar sakte hain; yeh autocomplete mein dikhta hai. Same helper, invoke karna asaan.

---

Decision 8: Jo seekha use save karein

Aap kya karte hain (Claude Code). Yeh Friday ritual hai; aap har week karenge. Aap next Friday yeh sab decisions dobara yaad nahin rakhna chahte. Is liye model se kehte hain ke inhein skill ke taur par save kare:

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 aap sirf "do weekly rollup" type karenge aur model yeh skill automatically pull kar lega. Aaj ke saare decisions free mein apply ho jayenge.

Kyun. Yahi payoff hai. Is week ka kaam sirf is week ke liye nahin tha; is ne model ko yeh task hamesha ke liye karna sikhaya.

OpenCode mein kya badalta hai. Skill thore different folder (~/.config/opencode/skills/...) mein save hoti hai, lekin file khud byte-for-byte identical rehti hai. Dono tools ke darmiyan copy karein aur kaam karti hai. Yeh chapter ki thesis ka sab se strong proof hai.

---

Abhi kya hua

Eight steps ko dobara dekhein. In mein se kisi ne aap se code likhne ko nahin kaha. Kisi ne aap se yeh nahin manga ke aap jante hon API kya hoti hai. Aap ne asal mein model ki attention manage karne ke eight chhote acts kiye: use bataya kya dekhna hai, kab plan karna hai, kab bhoolna hai, kab delegate karna hai, kab khud par trust band karna hai, aur kab yaad rakhna hai.

Yahi poora chapter hai.

Aur dekhein dono tools mein kitna kam farq tha:

• Rules file ka filename alag (CLAUDE.md vs AGENTS.md)
• Plan mode enter karne ka keystroke alag (Shift+Tab vs Tab)
• Safety-net file ki language alag (JSON vs JavaScript)
• Aakhir mein skill ka folder alag (lekin same file)

Bas itna.

Thinking hi tool hai. Configs decoration hain. Is tareeqe se sochna seekhein aur aap ki skills jis tool ki bhi jeet ho, survive karengi.

---

Part 7: Kahan chalana hai, aur kaise grow karna hai

13. Terminal, IDE, ya desktop?

Dono tools kai jagahon par run hote hain.

Claude Code: terminal, VS Code / JetBrains plugins, Claude desktop app, aur async work ke liye cloud-hosted variants.

OpenCode: terminal (TUI flagship hai), desktop app (macOS/Windows/Linux par beta), ACP support ke zariye IDE extension, SDK ke zariye web interface, plus GitHub aur GitLab integrations.

Apna interface is baat par choose karein ke aap kya kar rahe hain. Greenfield development aur bohat file editing ke liye IDE plugins ko beat karna mushkil hai: aap diff ko hota hua dekhte hain. Long-running tasks jahan notifications aur parallel sessions chahiye hon, wahan terminal theek hai. Non-coding work aur scheduled jobs ke liye desktop apps zyada pleasant hain.

Dono tools ke liye strong recommendation: terminal ya IDE plugin se shuru karein. Jab aap samajh lete hain ke neeche kya ho raha hai - model kaun si files read karta hai, kaun si commands run karta hai, aur kaun se decisions leta hai - baqi har interface aik thin wrapper ban jata hai jise aap read through kar sakte hain. Agar aap heavily abstracted UI se start karte hain, to jab cheezen sideways jayengi to debug karna mushkil hoga, kyun ke aap ko pata nahin hoga kya sideways ja sakta hai.

14. Personal context library ahista banayein

Jab aap kuch projects mein in tools ko use kar chuke honge, aap notice karenge ke har rules file mein similar cheezen likh rahe hain: aap ka code style, commit conventions, aur testing philosophy. Copy-paste band karein.

Shared parts ko apni home config mein rakhein aur har project ki rules file se unhein reference karein:

~/.claude/:

# CLAUDE.md

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

## Project-specific

[only the things unique to this project]

Skills ke liye bhi same idea kaam karta hai. Aik commit-message skill ya code-review skill ko ~/.claude/skills/ mein rakhein (jise OpenCode bhi read karta hai), ya ~/.config/opencode/skills/ mein rakhein, to woh har jagah available ho jati hai.

Discipline yeh hai: isko pehle se over-build na karein. Perfect personal setup design karne ke liye Saturday kharch karna tempting hota hai. Resist karein. Har entry kisi real failure se aani chahiye: aik moment jahan model ne kuch ghalat kiya, ya aap ne teesri baar wahi baat type ki. Regret se build karein, imagination se nahin. Jo library real friction se grow hoti hai woh chhoti aur useful hoti hai; jo pehle se design hoti hai woh bari aur ignored hoti hai.

15. Basics se aage memory

Built-in resume aur well-tended rules file zyada tar logon ke liye zyada tar waqt kaafi hote hain. Agar aap ko zyada chahiye - past conversations mein search, persistent project notes, ya aisi knowledge jo /clear ke baad bhi zinda rahe - to options hain:

• Project ke andar aik notes/ folder, jahan agent important kaam ke baad structured notes likhta hai. Cheap, durable, greppable. Surprisingly effective. Dono tools mein kisi setup ke baghair kaam karta hai.
• Aik memory MCP server. Kai options maujood hain; yeh agent ko explicit save/recall API dete hain. Dono tools mein kaam karte hain.
• Aap ki conversation history par vector search, "kya mein ne yeh pehle solve kiya tha?" type queries ke liye. Tool-specific implementations maujood hain; ecosystem pages check karein.

Choice is baat par karein ke aap waqai kya remember karna chahte hain. Agar maqsad "is codebase ke decisions aur gotchas" hain, to notes/ folder kaafi hai. Agar maqsad "har project mein model ko kabhi bhi batayi hui har cheez" hai, to heavier infrastructure chahiye. Aisa infrastructure install na karein jis ka problem abhi aap ke paas nahin.

---

Part 8: Claude Code aur OpenCode ko compose karna

Pehle parts ne Claude Code aur OpenCode ko alternatives ke taur par treat kiya: aik choose karein, usay seekhein. Yeh framing deliberate thi: har concept ko kisi bhi tool mein sense banana chahiye, is se pehle ke aap cheezon ko complex banayein. Lekin fundamentals aa jane ke baad zyada interesting sawal composition hai. Aik hi project par do tools saath use karna sirf fallback nahin hota agar aik fail ho jaye. Yeh kaam karne ka alag tareeqa hai, aur inhein saath use karne ki mechanics apna part deserve karti hain.

Substrate: git worktrees

Patterns se pehle, woh operational layer jo is sab ko safe banati hai.

Dono tools parallel sessions support karte hain, lekin agar do agents same file aik hi waqt edit karein, to last write wins aur stomped diffs milte hain. Fix hai git worktrees: har worktree aap ke repo ki checked-out copy hoti hai different branch par, lekin same .git directory share karti hai. Do agents do worktrees mein different files parallel edit kar sakte hain baghair same path touch kiye.

# 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

Kaam ho jaye to worktree remove karne ke liye git worktree remove ../myproject-backend use karein.

File-edit rule, teen tiers mein:

Pattern	Verdict
Do sessions same file simultaneously edit karein	Bad: last write wins, doosre session ki edits lost
Do sessions different directories edit karein	Good: contention nahin, parallel speedup real hai
Aik session edit + commit kare, phir doosre ko de	Acceptable: commit handoff artifact hai

Rule of thumb: har task ke liye aik session se start karein. Doosra sirf tab add karein jab aap clearly point kar saken ke har session kaunsi files own karta hai. Do agentic sessions ke darmiyan context-switching ka cognitive cost real hai; yeh sirf tab win hai jab work waqai partition hota ho.

Shared layer jo yeh sab kaam karwati hai project ke rules aur skills hain. Dono tools same CLAUDE.md aur same .claude/skills/ directory read karte hain (Concepts 7 aur 9 isay cover karte hain). Project conventions ke liye aik source of truth; do tools usay consume kar rahe hain.

Pattern 1: Plan / Execute split

Agentic coding mein expensive cognitive work planning hai: codebase read karna, approach decide karna, edge cases anticipate karna. Cheap mechanical work us plan ko implement karna hai jo already exist karta ho. Pricing bhi isi ko reflect karti hai: frontier-tier models per token economy-tier models se roughly order of magnitude mehngay hote hain, aur yeh price planning par earn karte hain, implementation par nahin.

Composition:

1. Claude Code ko plan mode mein open karein (Concept 2). Brief dein. Usay plan produce karne dein.
2. Plan ko docs/plans/feature-x.md mein save karein.
3. Separate worktree mein OpenCode open karein, economy-tier model par pointed (current setup ke liye opencode.ai/docs/providers dekhein). Pehla message: read docs/plans/feature-x.md and implement it.
4. OpenCode file edits karta hai, tests run karta hai, lint fix karta hai.
5. (Optional) Merge se pehle diff review karne ke liye Claude Code dobara open karein.

Plan file contract hai. Yeh session loss survive karti hai, architectural decisions encode karti hai, aur cheap session ko expensive thinking dobara kiye baghair kaam karne deti hai. Akela yeh pattern aksar woh most cost savings de deta hai jo teams "cheaper model par switch" se expect karti hain, baghair frontier-model planning ki quality lose kiye.

Pattern 2: Cross-model review

Yeh AI Prompting ka concept 13 hai jo habit se architecture ban gaya hai. Wahan aap same draft do chat windows mein chalate the; yahan do coding tools aik doosre ke diffs cross-check karte hain.

Different models ke blind spots different hote hain. Jo model code likhta hai woh us code ka worst reviewer hota hai, kyun ke us ke paas wahi blind spots hote hain jinhon ne original produce kiya. Different family ka model (different training data, different reasoning habits) woh cheezein catch karega jo author miss kar gaya.

Composition:

1. Tool A (koi bhi model) apni worktree par feature implement karta hai.
2. Tool B (different model, ideally different family) diff read karta hai aur critique docs/reviews/feature-x.md mein likhta hai. Reviewer edit nahin karta; sirf text produce karta hai.
3. Tool A review read karta hai aur decide karta hai kin points par act karna hai.

Yeh sunne se zyada useful hai. Cheap economy models par chalne wale reviewers bhi surprising amount mein real value catch kar lete hain: missing edge cases, security oversights, naming inconsistencies, dead code. Review pass ki dollar cost chhoti hoti hai; merge ke baad bug pakarne ki time cost bari hoti hai.

Pattern best tab kaam karta hai jab reviewer aur implementer different model families se hon: Claude reviewing Claude woh miss karta hai jo GPT ya DeepSeek catch kar leta, aur vice versa. Same-family review phir bhi no review se behtar hai, lekin value diversity mein hai, sirf act mein nahin.

Single-tool kya rehta hai

Composition ka overhead hota hai. Do tools ka matlab do configs, do permission lists, do notification setups. Zyada tar short tasks ke liye (single function, quick refactor, bug fix) single session cross-tool orchestration se faster, simpler, aur cheaper hota hai.

Composition tab use karein jab task itna bara ho ke planning genuinely implementation se separable ho, jab frontier model ko poore task par chalana wasteful ho, ya jab independent review pass ki value us ki cost se zyada ho. Baqi sab ke liye Parts 1-7 ki single-session discipline sahi move hai.

Composition bas yeh hai ke aap one tool aur one model ko unit of work samajhna band kar dete hain, aur agentic coding session ko unit samajhna shuru kar dete hain.

---

Is mein waqai achha kaise hona hai

Sirf yeh crash course parhna aap ko agentic coding mein achha nahin banata. Isay use karna banata hai, aur path kuch is tarah dikhta hai:

Manual shuru karein. Friction mehsoos karein: har approval prompt, har "wait, isay X kyun nahin pata?" Wohi friction curriculum hai. Har friction piece upar ke concepts mein se kisi aik se map hota hai:

• "Auth pattern yeh baar baar kyun bhool raha hai?" -> rules file missing ya bloated hai.
• "Is ne mera migrations folder kyun delete kar diya?" -> permissions tight nahin thin.
• "Aik ghante ke baad itna slow kyun ho gaya?" -> context rot; /compact chahiye tha.
• "Mein har Monday wahi cheez kyun type kar raha hoon?" -> yeh skill hai.
• "Tests local pass hue lekin CI mein kyun break hue?" -> yeh hook ya plugin hai.
• "Codebase explore karna hamesha conversation ko pollute kyun karta hai?" -> yeh subagent hai.

Har problem ka response tab build karein jab aap us problem se takrayen, pehle nahin. Aap ki rules file pehle ten lines honi chahiye, phir twelve, phir twenty: har line kisi aisi mistake se earn ho jo ab woh prevent karti hai. Aap ke skills folder mein pehle aik skill ho, phir ten. Hooks/plugins is liye hon ke un ke baghair kuch break hua tha, is liye nahin ke kisi ne kaha hooks powerful hain.

80/20 yeh nahin ke fifteen concepts memorize kiye jayen. Asli skill yeh notice karna hai ke given problem kis concept se belong karti hai, itni fast ke aap sahi tool choose kar saken. Yeh noticing real work par agentic coding tools ko succeed aur fail hote dekhne se aati hai.

Yeh portability dividend hai. Jab aap ne aik tool mein yeh noticing build kar li, woh transfer hoti hai. Friction-to-concept map Claude Code aur OpenCode dono mein identical hai. Start ke liye aik tool choose karein, us ki specific config seekhein, aur jab aap cost, model preference, license, ya kisi naye tool ki wajah se switch karne ka faisla karein, to aap ka knowledge saath aata hai. Configs badalte hain. Thinking nahin.

Aik project se shuru karein. Har non-trivial cheez ke liye plan mode use karein. Apna context watch karein. Baqi system khud build hota jata hai.

---

Quick Reference

15 concepts, har aik aik line mein

1. Tools sirf jawab nahin dete, actions lete hain. Questions nahin, briefs likhein.
2. Plan mode (CC mein Shift+Tab, OC mein Tab se Plan agent). Kisi bhi write se pehle read-only investigation.
3. Permissions discipline. Manual se start karein, phir allow/deny rules gradually config mein codify karein. rm -rf kabhi auto-approve na karein.
4. Context rot real hai. Window fill hone se kaafi pehle recall degrade hoti hai, aur har turn poora context dobara bill karta hai.
5. /clear vs /compact. New task ke liye fresh start; same task ke liye lighter context. Ghalat command ghalat cheez lose karwa sakti hai.
6. Resume sessions. Dobara explain kiye baghair jahan chhora tha wahan se pick up karein; saved plan files ke saath pair karein.
7. CLAUDE.md / AGENTS.md table of contents hai. ~2,500 tokens se kam rakhein; references demand par load hon.
8. Slash commands. Saved prompts jinhein aap name se trigger karte hain jab same instructions baar baar type karni paren.
9. Skills. Saved expertise jo model description ke basis par auto-invoke karta hai; SKILL.md plus references progressive disclosure dete hain.
10. Hooks (CC) / Plugins (OC). Lifecycle events par deterministic guardrails. Production work ke liye optional nahin.
11. Subagents. Noisy reads ke liye isolated context windows (codebase exploration, doc fetching).
12. MCP, carefully use karein. External tools ke liye standard protocol; stateless services mein CLIs aksar MCP se behtar hoti hain.
13. Kahan run karna hai. Terminal ya IDE plugin se start karein taake aap dekh saken agent kya kar raha hai.
14. Personal context library, slowly. Configs projects ke darmiyan share karein; regret se build karein, imagination se nahin.
15. Basic memory se aage. Built-in resume + achhi rules file zyada tar cases ke liye enough hai. Zyada chahiye to notes/ folder use karein.

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)
Previous message par jump back	Esc Esc (or /rewind)	/undo
Model ki file edits roll back	Esc Esc (checkpointing)	/undo (needs git)
Bash-command file changes roll back	(not tracked)	/undo (whole-tree diff)
Redo (last /undo reverse)	(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

Jab kuch ghalat mehsoos ho

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 ka Study Aid

---

Quiz: 15 Concepts par 50 Sawalat

Crash course ke har concept ko cover karne wala comprehensive bank. Har session 18 questions ka fresh batch dikhata hai, is liye retakes par naya material milta hai. Answers ko apne toolchain mein ground karne ke liye upar apna tool choose karein.

Checking access...