claude-code-playbook (avinashmyerolkar) — Summary

claude-code-playbook by avinashmyerolkar is a structured personal study guide documenting Claude Code's core features through 8 topic folders, each containing a notes.md with research and learnings. Topics progress from slash commands and CLAUDE.md through spec-driven development, plan mode, custom slash commands, skills, sub-agents, and MCP integration. Four topics are marked complete (01, 02, 03, 08); four are flagged "coming soon" (04–07). The repo ships zero runnable primitives — no commands, skills, agents, hooks, or MCP servers. Its primary value is as a personal learning log and reference document, particularly strong on spec-driven development concepts (vibe coding vs SDD comparison table, 7-step workflow, spec vs design doc separation). The SDD notes explicitly describe the full flow: Spec Doc → Review → Design Doc → Review → Tasks → Build → Validate within a Git branch workflow.

Differs from seeds: Closest to agent-os Archetype 4 (pure markdown scaffold), but with an even narrower scope — it is a personal study notebook, not a deployable framework. Unlike openspec or spec-kit (which ship runnable SDD workflows), this repo teaches the concepts without automating them. The SDD content overlaps conceptually with kiro's spec/design/tasks decomposition but ships none of Kiro's tooling.

claude-code-playbook (avinashmyerolkar) — Overview

Origin

Personal study guide by avinashmyerolkar documenting Claude Code feature research. 2 stars, last commit 2026-05-02. No license.

"A structured study guide covering the core features of Claude Code — Anthropic's official CLI for agentic software development. Each topic has a notes.md with research and learnings." "Built to document and share learnings about Claude Code."

Philosophy

Learning-by-documenting. Each topic is researched and distilled into a single notes.md with:

• The core problem and solution
• Key concepts and definitions
• How things work internally
• Best practices and real examples

Notable content: Spec-Driven Development (topic 03)

The SDD notes articulate the clearest concise definition of vibe coding vs SDD in this batch:

"Vibe coding — describing what you want and letting AI build it — feels fast. But it silently transfers all decision-making to the AI. The core problem: you lose control over your own application."

SDD workflow defined:

Spec Doc → Review → Design Doc → Review → Tasks → Build → Validate

Within Git:

Pull latest → Create branch → Switch to branch
     ↓
  Spec → Review → Design → Review → Tasks → Build → Validate
     ↓
Commit → Push → Create PR → Merge → Delete branch → Switch to main

Two-document separation principle (from topic 03)

• Spec Doc: Non-technical, product-requirements style, written from product owner's perspective. Answers "What are we building and why?" Does NOT include technical decisions.
• Design Doc: Technical document answering "How are we going to build it?" Created using Plan Mode in Claude Code (ideally Opus model).
• Philosophy: "The spec doc is stable — requirements don't change just because you switch from REST to GraphQL."

claude-code-playbook (avinashmyerolkar) — Architecture

Distribution type

methodology-doc — pure markdown study notes. No packages, no binaries.

Install

npm install -g @anthropic-ai/claude-code   # install Claude Code itself
git clone https://github.com/avinashmyerolkar/claude-code-playbook   # clone notes

Directory structure

.
├── README.md
├── 01-slash-commands/
│   └── notes.md          ✅ Done
├── 02-claude-md/
│   └── notes.md          ✅ Done
├── 03-spec-driven-development/
│   └── notes.md          ✅ Done
├── 04-plan-mode/         🔜 Coming soon
├── 05-custom-slash-commands/  🔜 Coming soon
├── 06-skills/            🔜 Coming soon
├── 07-sub-agents/        🔜 Coming soon
└── 08-claude-mcp/
    └── notes.md          ✅ Done

Runtime requirements

None for the notes themselves. Claude Code CLI for experimentation.

Target AI tools

Claude Code (primary subject of study).

claude-code-playbook (avinashmyerolkar) — Components

Runnable primitives

None — 0 commands, 0 skills, 0 agents, 0 hooks, 0 MCP servers.

Documentation modules (4 complete notes.md files)

01-slash-commands/notes.md

• Session management commands: /exit, /resume, /rename, /export, claude -r
• Quick query commands: /btw (ephemeral question that disappears from history)
• Model/config: /model, /config, /usage
• Context commands: /context, /compact, /clear, /permission
• Built-in vs custom slash commands taxonomy
• Best practices table: one session = one task, commit frequently, use /btw for quick questions

02-claude-md/notes.md

• All 5 CLAUDE.md types and their scopes
• .claude/ folder structure
• Auto memory behavior
• Project memory patterns

03-spec-driven-development/notes.md

• Vibe coding vs SDD comparison table (8 dimensions)
• 7-step SDD workflow
• Spec Doc definition and structure
• Design Doc definition (created via Plan Mode / Opus)
• Git integration pattern
• What goes in a Spec Document (section structure)

08-claude-mcp/notes.md

• MCP protocol overview
• SQLite integration
• Figma integration
• GitHub integration

claude-code-playbook (avinashmyerolkar) — Uniqueness

Differs from seeds

A personal study notebook — the most minimal framework type in the entire corpus. Closest to agent-os Archetype 4, but without even the 5 runnable commands agent-os ships. The SDD notes (topic 03) overlap conceptually with kiro (spec/design/tasks decomposition) and openspec (spec-driven workflow) but ship none of their tooling. The /btw command documentation captures a behavioral nuance (ephemeral questions that don't pollute session history) not documented in any seed framework. The clear separation of Spec Doc (non-technical, product-owner owned) from Design Doc (technical, engineering-owned, created via Plan Mode + Opus) is a useful articulation of an SDD principle — it could serve as reference material for implementing a proper spec workflow.

Positioning

A learning resource and personal reference. Value is in the notes quality, not the automation. The SDD section is the strongest content.

Observable failure modes

1. 50% incomplete — 4 of 8 topics are "coming soon"; the framework is unfinished.
2. No enforcement — all described practices require developer discipline.
3. No templates — the notes describe what to do but provide no copy-paste artifacts.
4. 2 stars — minimal community validation; may not reflect current best practices.