Build agentic systems that run your business: https://skool.com/scrapes Don't miss the next build - / @simonscrapes Grab the full resources for this video here (free): https://scrapeshq.notion.site/Every-L... Think you're getting the most out of Claude Code? You're probably just scratching the surface. In this video, we break down the 7 levels of mastery, guiding you from basic prompting all the way to building fully autonomous systems. Stop the trial-and-error and start unlocking Claude Code's true potential today. 00:00 - Every Level of Claude Code Explained in 39 Minutes 00:41 - Level 1: The One Thing You Need To Know 03:25 - Level 2: Personalizing CLAUDE for better responses 10:25 - Level 3: Slash Commands, Skills & Hooks - Repeatability 21:21 - Level 4: Connecting Claude Code to Your Apps (MCPs) 26:18 - Level 5: Move from Executor to Supervisor 29:34 - Level 6: Agent Teams 35:57 - Level 7: Fully Autonomous Systems --- Here is a detailed outline of the video, organized by the **sections/levels** and subjects given in the description and expanded using the transcript.​ --- ## Level 0 – Intro and Setup 1. Video introduction and promise [0:00]​ - Host explains he has spent 150+ hours using and studying Claude Code resources (Boris Churney’s posts, top builder workflows, master tutorials).​ - Key insight: most users are stuck around levels 2–3 and missing higher‑leverage workflows.​ - Goal of the video: walk through 7 levels from basic prompting to fully autonomous systems so viewers can stop trial‑and‑error.​ 2. Environment setup (VS Code, installer, first run) [0:41]​ - Opens a fresh VS Code instance, selects a folder, and opens a new terminal.​ - Runs the native Claude Code installer from the README (no Node.js required) inside the terminal.​ - Starts Claude with basic permissions; shows what the initial interface looks like when Claude launches.​ --- ## Level 1 – The One Thing You Need To Know 3. Planning mode vs “just prompting” [0:41–3:25]​ - Defines level 1 as prompting **with intent** instead of “type and hope.”​ - Explains plan mode: toggle via Shift+Tab, compares “accept edits” (default) vs “plan” (read‑only research/plan mode).​ - Plan mode reads the existing codebase or initial brief, then proposes a plan before editing anything.​ 4. Boris Churney’s workflow with plan mode​ - Describes Boris’s rule: if his goal is to write a pull request, he always uses plan mode first and iterates until the plan is solid.​ - Only after approving the plan does he switch to auto‑accept edits and lets Claude one‑shot the execution.​ 5. Ask‑user‑questions tool and content system example​ - Shows how vague prompts like “help me build a social media content creation system” will underperform without clarifying questions.​ - In plan mode, Claude invokes its built‑in ask‑user‑questions tool to gather details: platforms, calendar, automation, brand voice, etc.​ - Claude writes a `plan.md` file capturing assumptions and plan steps before execution.​ 6. Takeaway for Level 1​ - Level‑1 users always plan before executing; they use plan mode and clarify assumptions rather than jumping straight into code.​ --- ## Level 2 – Personalizing CLAUDE for Better Responses 7. Introducing `claude.md` as team “onboarding” doc [3:25–10:25]​ - `claude.md` tells Claude how you work: tech stack, preferences, mistakes to avoid, rules of engagement.​ - Analogy: onboarding a new coworker by writing down how the project works and what rules matter.​ - Example: team shares a single `claude.md` in Git; everyone edits it and even tags changes so Claude won’t repeat specific mistakes.​ 8. Framework for writing `claude.md`​ - Rule: keep it short, specific, and only include what Claude cannot infer.​ - Suggested structure: - “What is this?” – one concise line describing the project objective (e.g., machine that generates daily social posts from Airtable calendar).​ - “How do we run things?” – concrete process steps (where content calendar lives, where posts and image assets are stored, etc.).​ - Brand voice and rules – patterns, platform formatting limits, content rules (teach something, real experience, practical) but referenced via separate docs.​ - “Mistakes and edge cases” – things that will trip Claude up (ambiguous columns, statuses, etc.).​ - “How we work” – file naming conventions, rules about repurposing, publishing constraints.​ 9. “Don’t dump” rule and external brand‑voice docs​ - Explains the “don’t dump” trick: keep `claude.md` lean and point to other files (e.g., `/docs/brandvoice.md`) for detailed guidelines.​ - Emphasizes referencing examples and platform‑specific rules from separate documents to avoid bloating core instructions.​ 10. Example: tightening the file via iteration​ - Shows initial generic `claude.md` for a LinkedIn post about “Google anti‑gravity vs Claude Code.”​ - First output is too technical; user adds rules: never use em dashes, replace “anti‑gravity” with “AG”, avoid technical jargon and focus on business value.​ - Restarts Claude, re‑runs the prompt, and demonstrates improved post (AG instead of anti‑gravity, business‑oriented language, no em dashes).​ 11. Quality checks and `/init` command​ - Quick checks: can you read `claude.md` in 60 seconds, stay under ~20–30 rules, include specific examples, and make it useful to a human freelancer?​ - Shows `/init` command: scans an existing repo and generates an initial `claude.md` that you then prune and refine.​ - Recommends updating rules in real time (e.g., “add this rule to my claude.md file”) as issues arise.​ 12. Level‑2 definition​ - At level 2, Claude now follows your personalization and rules instead of producing generic outputs.​ --- ## Level 3 – Slash Commands, Skills & Hooks (Repeatability) ## 3A. Slash Commands 13. Slash commands as saved prompts [10:25–21:21]​ - Slash commands are reusable prompts you trigger manually with `/command`.​ - Example: `/linkedin-post` that always writes three LinkedIn posts about a topic you pass as an argument.​ 14. Creating a slash command​ - Folder structure: create `.claude/commands/` and a subfolder/file like `linkedin-post.md`.​ - Inside the command file: - Prompt text: “Write three LinkedIn post variations about $arguments.”​ - Rules: pull brand voice from `/docs/brandvoice.md`, start with a hook, body after line break, end with question/CTA, keep under 200 words, no hashtags.​ - Output directive: save drafts to `/output/drafts` folder.​ - Demonstrates restarting Claude so it detects the new command, then invoking `/linkedin-post Anti-gravity vs Claude Code` and seeing drafts saved as files.​ 15. Benefits of commands​ - Eliminates retyping complex prompts; one command wraps logic, rules, and file outputs.​ - Ideal for tasks you trigger repeatedly (daily/weekly workflows).​ ## 3B. Skills 16. Skills as auto‑loaded background knowledge​ - Skills are richer than commands: they load context (multiple files) automatically when relevant, based on a precise description.​ - Represented as folders under `.claude/skills/` with `skill.md` plus additional reference docs (examples, style guides, etc.).​ 17. Installing a community skill (Humanizer)​ - Opens Skills MCP site, filters to “content and media,” searches for “humanizer.”​ - The Humanizer skill removes signs of AI‑generated writing and makes text sound natural and human.​ - Clones the skill’s GitHub repo into `.claude/skills/humanizer` via `git clone`.​ - Inspects `skill.md`: description, guidelines on adding “personality and soul,” voice, opinions, and examples.​ 18. Using skills in practice​ - Key: the description must be precise so Claude knows when to use the skill.​ - Adds instruction in `claude.md`: “Every time you write some content, use the humanizer skill in /skills/humanizer.”​ - Re‑runs `/linkedin-post` command and shows more human‑sounding posts and a summary explaining how the text was humanized.​ - Notes that you can invoke a skill directly (e.g., `/humanizer`) but usually rely on automatic triggering.​ 19. Managing skill libraries​ - Advises against blindly importing huge skill libraries; better to selectively install skills (front‑end design, SEO review, email drafting, etc.) and tweak them.​ ## 3C. Hooks 20. Hooks as “no‑brain” automation​ - Hooks run automatically when certain actions occur; they do not consume LLM tokens.​ - Good for mechanical checks: banned words, word count, formatting, auto‑formatting files.​ 21. Creating hooks in `settings.json`​ - Adds `claude/settings.json` with a `hooks` object describing when and how to run scripts.​ - Example: a hook that checks every LinkedIn draft for banned words and flags issues.​ - Recommends asking Claude to generate the JSON for hooks instead of hand‑writing it.​ - Demonstrates running hook retrospectively on `/output/drafts` and seeing “No banned words found” confirmation.​ 22. Mental model of commands/skills/hooks​ - Commands: things you **manually trigger**; encapsulated prompts that run on demand.​ - Skills: how Claude **thinks**; background knowledge loaded into its “brain” when relevant.​ - Hooks: what happens **after** Claude acts; automatic scripts that enforce rules or transform outputs.​ 23. Brand voice skill example​ - Shows building a dedicated brand‑voice skill containing banned words/phrases, voice description, per‑platform rules, and best‑post examples.​ --- ## Level 4 – Connecting Claude Code to Your Apps (MCPs) 24. MCP servers as bridges to apps [21:21–26:18]​ - Defines MCP (Model Context Protocol) servers as bridges between Claude Code and external apps (e.g., Airtable, Notion).​ - Motivating example: content ideas live in Airtable; instead of copy‑pasting, Claude connects via MCP, reads ideas, generates posts, and writes back.​ 25. Setting up an Airtable MCP​ - Shows `mcp.json` structure listing MCP servers and configuration.​ - Notes you can either hand‑edit `mcp.json` or simply run `/mcp add airtable` and let Claude configure it.​ - Obtains Airtable personal access token with scopes for reading/writing records and base access, then inserts token into `mcp.json`.​ - Restarts Claude to apply MCP configuration.​ 26. Testing connectivity and reading data​ - Asks “What Airtable bases do I have?” and observes Claude using the Airtable MCP to list accessible bases (e.g., LinkedIn carousels base).​ - Asks to show tables and key fields; Claude infers this is a content pipeline for LinkedIn carousels.​ 27. End‑to‑end content example with Airtable​ - Pulls ideas from Airtable after a given date (e.g., one idea containing a transcript).​ - Pipes the idea into `/linkedin-post` slash command to generate three post variations.​ - Instructs Claude to update the corresponding Airtable record in the “system message” or content field with the generated copy.​ - Confirms in Airtable that the field was updated correctly.​ 28. Level‑4 takeaway​ - At level 4, Claude reads from and writes to your day‑to‑day apps via MCPs, executing full plan‑and‑execute loops directly against live data.​ --- ## Level 5 – Move from Executor to Supervisor (GSD Framework) 29. Motivation: context rot and human planning overhead [26:18–29:34]​ - Problem: long sessions fill the context window; as token count grows past ~10k tokens (≈7,500 words), reliability drops and context is auto‑summarized.​ - Humans still provide most planning; aim is to move from executor to supervisor by using a structured planning framework.​ 30. GSD framework overview​ - GSD (Get Stuff Done) is a planning‑plus‑execution framework that breaks large projects into phases with repeated loop: Plan → Execute → Verify (user acceptance testing).​ - Designed for fuzzy or large scopes (e.g., building an entire SaaS) where you need detailed, evolving plans.​ 31. How GSD fights context rot​ - Keeps context in files instead of the transient chat window.​ - Uses a `.planning` folder with project‑level docs: - Roadmap: list of phases (foundation/auth, data management, AI pipeline, payments, etc.).​ - State: which phases have been executed and which remain.​ - Other high‑level documents with relevant context.​ - Each phase has its own documents: plan, execute summary, and user‑acceptance‑test (UAT) file.​ 32. Example of phase structure​ - For “Phase 5: Stripe billing”: - Plan file outlines what will be done first.​ - Summary file records what was actually implemented.​ - UAT file specifies tests that validate Stripe billing against original requirements.​ 33. Level‑5 takeaway​ - At level 5, you supervise a GSD‑driven project where Claude plans, executes, and self‑verifies phases, while context is preserved in structured files instead of raw chat.​ --- ## Level 6 – Agent Teams 34. From single agent to teams of agents [29:34–35:57]​ - Explains sub‑agents as specialized personas that offload specific work while keeping the main agent’s context clean.​ - Cites a Reddit explanation: sub‑agents maintain separate, smaller contexts that can be pulled into the main window, reducing context bloat and token usage.​ 35. Use cases for sub‑agents​ - Quality: delegate to specialists (researcher, writer, reviewer) within one session.​ - Speed: run multiple non‑dependent tasks in parallel across multiple terminals.​ 36. Content system team example​ - Defines roles: - Researcher sub‑agent: deep research on topics with expanded tools.​ - Main Claude instance: content writer.​ - Reviewer sub‑agent: reviews drafts against brand voice and platform rules, suggests edits but doesn’t directly edit.​ 37. Creating agents under `.claude/agents`​ - Creates folder `.claude/agents/`.​ - Adds `content-researcher.md` describing a research specialist with specific allowed tools; tasked with finding angles for social content.​ - Adds `content-reviewer.md` to review drafts against guidelines and platform rules.​ 38. Single‑terminal collaboration example​ - Flow: pull idea from Airtable → call content‑researcher agent for angles → feed research into `/linkedin-post` command → call reviewer agent to critique drafts.​ 39. Multi‑terminal parallelism example​ - Opens several terminals: one generating LinkedIn posts, another Instagram posts, etc., all in parallel.​ - Shows running multiple Claude instances and supervising them, with each agent working a separate part of the content pipeline.​ 40. Using `--dangerously-skip-permissions` in teams​ - Demonstrates starting a Claude instance with `-dangerously-skip-permissions` to avoid constant approvals.​ - Warns that this accepts full liability for actions within that folder; Claude will no longer prompt for permissions.​ 41. Productivity outcomes​ - Example: three tasks that would take ~15 minutes sequentially are condensed into ~5 minutes by running three sub‑agents in parallel.​ - Shows multiple drafts, research, and scheduling produced across terminals while the user only supervises high‑level decisions.​ --- ## Level 7 – Fully Autonomous Systems (Ralph Loop & Pipelines) 42. Goal of level 7 [35:57–39:22]​ - Aim: set up systems where Claude runs the entire show and you return to completed work (e.g., a week of content drafted, reviewed, and ready).​ 43. Ralph loop plugin overview​ - Ralph loop is a plugin that repeatedly invokes Claude in a loop until completion conditions are met.​ - Implemented with three main pieces: a bash script, a `prd.json` (product requirements document), and loop logic that checks for completion or iteration limit.​ 44. PRD (product requirements document) structure​ - `prd.json` holds user stories with: description, acceptance criteria, and completion status field.​ - Claude uses acceptance criteria to generate verification tests and updates status to “done” when criteria are met.​ 45. Example: weekly content batch​ - Creates `prd.json` for a weekly content batch: e.g., six LinkedIn posts under 200 words, no banned words, with specified topics.​ - Runs `/plugin install ralph` (once) then `/ralph-loop` to start autonomous execution.​ - Strong recommendation: always set a `maxIterations` limit as a safeguard against runaway loops and cost overruns.​ 46. Ralph vs GSD roles​ - Ralph is an **executor**: ideal when tasks are well‑defined with clear criteria and it just needs to “do the work.”​ - GSD is a **planner plus executor**: used when scope is fuzzy and you need phased planning and state tracking.​ - Example contrast: - Ralph: “Write six posts under 200 words with no banned words about these topics.”​ - GSD: “Design a Q2 content strategy,” where scope and plan must be developed first.​ 47. Final capabilities at Level 7​ - With levels 1–7 combined, you can build fully autonomous pipelines in Claude Code that plan, execute, verify, and integrate with your day‑to‑day apps.​ - Closing invitation: watch the full GSD project build video and access resources/course links in the description.​ #claudecodetutorial #masterclaudecode #ClaudeCode --- ``` How would I construct an effective Claude.md file. Can you give me an example of a Claude.md file for creating a YouTube channel? ``` An effective `claude.md` is short, concrete, and only contains things Claude **cannot** reliably infer on its own. It should describe what you’re building, how you work, and mistakes to avoid, while pointing to other files for long details.​ Below is a ready‑to‑adapt `claude.md` for a YouTube channel focused on educational/technical content (you can tweak topic, tone, and workflow). --- ## claude.md (YouTube Channel Example) ## 1. What this project is We are building and running a YouTube channel that publishes clear, practical educational videos about AI tools and workflows, aimed at busy knowledge workers and creators. The channel’s goals are: - Help viewers understand and apply AI tools (e.g., Claude Code, ChatGPT, Notion, Airtable) to real workflows. - Grow a loyal audience that trusts the content and finds it practical, not hype‑driven. - Turn each video into a content asset that can be repurposed into shorts, tweets, LinkedIn posts, and a newsletter. ## 2. How we work - Main video formats: - Tutorials (step‑by‑step walkthroughs). - Deep dives (concept explanations). - Workflow breakdowns (real projects, start to finish). - Typical video structure: 1. Hook (problem or outcome) in 10–20 seconds. 2. Brief context: what we’ll do and why it matters. 3. Main steps in clear sections. 4. Quick recap and next steps (what to try, related videos). - For every video, we maintain a simple folder structure: - `ideas/` – rough ideas, brain dumps, viewer questions. - `scripts/` – working and final scripts or outlines. - `assets/` – thumbnails, overlays, B‑roll notes. - `descriptions/` – video descriptions, tags, chapter timestamps. - `repurposed/` – social posts based on each video. - When creating anything new, prefer to: - Scan existing files (ideas, scripts, docs) before inventing from scratch. - Reuse and adapt previous patterns that performed well (hooks, structures, CTAs). ## 3. Audience and positioning - Audience: - Knowledge workers, indie hackers, and creators who are comfortable with tools but not deep engineers. - They value clear explanations and concrete examples over buzzwords. - Positioning: - Practical, honest, and skeptical of hype. - We show both strengths and limitations of tools. - We prioritize workflows that save time or unlock new capabilities. ## 4. Voice, tone, and style - Overall voice: - Friendly but direct. - No fluff, minimal buzzwords. - Prefer plain language over technical jargon. - Writing style for scripts and descriptions: - Use short paragraphs and clear section breaks. - Use concrete examples instead of abstract claims. - Avoid over‑promising (no “this will 10x everything” language). - Prefer active voice: “Do X to get Y.” - Pacing and structure notes: - Get to the value quickly; do not spend more than ~20 seconds on generic intro. - Give viewers a mental model first, then walk through steps. - For tutorials, always mention what tool/version/setup we’re using. (For longer, detailed guidelines and examples of good scripts, see `docs/brand-voice.md` and `docs/script-examples.md`. Claude: read those files when writing scripts or descriptions.) ## 5. Content rules and constraints - Do: - Start every script with a specific problem or outcome. - Include at least one real example or mini case study. - Add at least one “try this yourself” suggestion at the end. - Avoid: - Clickbait titles that misrepresent the content. - Overly technical deep dives without grounding in practical use. - Long personal tangents that don’t help the viewer. - YouTube‑specific considerations: - Titles should be compelling but honest; aim for clarity over curiosity alone. - Descriptions must include: 2–3 sentence summary, key timestamps, tools/resources mentioned, and a short CTA to subscribe. - Thumbnails should communicate the main outcome or problem in 3–5 words max. (For examples of titles, descriptions, and thumbnails we like, see `docs/youtube-examples.md`. Use those as patterns.) ## 6. Workflow conventions When I ask for help, default to the following workflow unless I specify otherwise: - For new video ideas: - Read `ideas/` to understand past and current ideas. - Suggest 3–5 video ideas, each with a working title, one‑line summary, and why it helps the audience. - For scripts: - Create a structured outline first (sections and bullet points). - Wait for my approval or edits on the outline before drafting the full script. - When drafting, keep spoken lines conversational and easy to read aloud. - Flag any parts that might need B‑roll or on‑screen text. - For descriptions: - Pull key points from the script rather than inventing new claims. - Suggest 5–10 tags based on the content and target audience. - Propose a concise title (under ~60 characters where possible). - For repurposing: - When I ask to repurpose a video, create: - 3–5 short hook ideas. - 3 tweet/X drafts. - 2–3 LinkedIn post drafts. - Each repurposed piece must stand alone without assuming viewers saw the video. ## 7. Mistakes and edge cases to avoid - Do not: - Invent non‑existent features or capabilities for tools. - Use sensational claims about income, productivity, or “overnight success.” - Recommend tools that require complex setup without at least briefly noting that setup effort. - Be careful about: - Mixing up different versions of tools (e.g., older Claude Code features vs newer ones). - Overloading a single video with too many concepts; prefer narrower, deeper topics. - If requirements are vague: - Ask clarifying questions before writing a full script (e.g., target length, audience experience level, primary tool focus). - Offer 2–3 possible angles and wait for my pick. ## 8. How to interact with me - If I give a very short or ambiguous prompt (e.g., “script about Claude Code for YouTube”), first: - Ask 3–5 clarifying questions. - Suggest a few possible directions/angles. - When presenting options: - Number them clearly. - Briefly describe pros/cons or use cases for each. - When unsure: - State your assumptions explicitly in a short “Assumptions” section at the top of your response. - Then proceed with the work based on those assumptions. --- If you tell me a bit more about your topic focus (e.g., AI tools, biology explainers, coding tutorials) and your preferred tone, I can tighten this `claude.md` into a version tailored specifically to your channel concept.​ --- Here’s a version of `claude.md` tailored to a YouTube channel about **character rigging in Maya**, from fundamentals to full control rigs.[[youtube](https://www.youtube.com/watch?v=Y09u_S3w2c8)]​ --- ## claude.md – YouTube Channel: Character Rigging in Maya ## 1. What this project is We are building and running a YouTube channel that teaches character rigging in Autodesk Maya, from absolute basics to complete production‑ready control rigs for biped and stylized characters. Channel goals: - Help beginners understand core rigging concepts (joints, hierarchies, constraints, skinning, deformation). - Guide intermediate users through building full control rigs step by step. - Develop a library of reusable rigs, tools, and workflows viewers can follow. ## 2. How we work Main video formats: - Fundamentals: short lessons focused on a single concept (e.g., joint orientation, FK vs IK, constraints). - Guided builds: multi‑part series where we rig a character from scratch. - Workflow breakdowns: explaining rigging decisions in real production scenarios (e.g., why we choose certain control setups). Typical video structure: 1. Hook: the problem or outcome (e.g., “Today we’ll build an IK/FK switch for the arm that won’t break your animation”). 2. Context: where this concept fits in the bigger rigging pipeline. 3. Step‑by‑step demo in Maya. 4. Recap and “what to rig next.” Project folder structure: - `ideas/` – episode ideas, viewer questions, and series plans. - `scripts/` – outlines and scripts for videos. - `assets/` – example Maya scenes, character meshes, reference images. - `descriptions/` – video descriptions, tags, and chapter timestamps. - `docs/` – reference docs (naming conventions, rigging standards, example rigs). - `repurposed/` – shorts, community posts, and social content derived from videos. When creating new content, always: - Check `ideas/` for existing topics and series. - Reuse established naming conventions and rig structures from `docs/rigging-standards.md` (Claude: read this when talking about rig structure or naming). - Assume the viewer is in Maya but may not know specific menus by heart. ## 3. Audience and positioning Audience: - Maya users with basic navigation knowledge but limited or no rigging experience. - Self‑taught artists and junior riggers who want structured, production‑oriented guidance. Positioning: - Practical, Maya‑specific rigging education. - Focus on building rigs that are clean, debuggable, and animator‑friendly, not just “it works once.” - We explicitly call out best practices and common pitfalls (double transforms, bad joint orientation, messy hierarchies). ## 4. Voice, tone, and style Voice: - Friendly and patient, like a mentor explaining rigging in a lab or production setting. - Clear and precise when describing technical steps. Style for scripts: - Use simple, direct sentences that are easy to read aloud. - Reference Maya UI explicitly: menu paths, shelf tools, hotkeys when relevant. - Always pair “what” with “why” (not just “click here,” but also “this avoids double transforms”). - Avoid unnecessary jargon; when a technical term is needed, define it briefly. Pacing: - Get to the Maya viewport quickly; intros should be under ~20 seconds. - Alternate between showing the result and building it, so learners see the purpose of each step. - For complex setups, announce the “checkpoint” (e.g., “By the end of this video, your leg rig should do X, Y, Z”). (For concrete examples of preferred script structure and tone, see `docs/script-examples.md`. Claude: read this file before drafting scripts.) ## 5. Content rules and constraints Do: - Start with the outcome (“Today you’ll have a working arm IK/FK switch”). - Include at least one quick test in Maya to prove the rig works (e.g., rotating controls, checking deformations). - Call out common mistakes (e.g., un‑frozen transforms on controls, non‑zero joint orientations, incorrect parenting). - Mention which Maya version and units we assume when it matters. Avoid: - Very long unstructured videos that mix many unrelated rigging topics. - Overly theoretical discussion without touching the rig in Maya. - Skipping necessary steps that a beginner would not infer (e.g., “make sure your mesh history is clean before binding”). YouTube‑specific: - Titles should clearly state the rigging task and level, e.g., “Maya Rigging Basics: Creating a Clean Joint Chain” or “Maya Character Rig: Full Biped Control Rig – Part 1: Spine.” - Descriptions must include: short summary, learning outcomes, required starting files, and chapter timestamps. - Include links to any downloadable scene files or reference in the description. (For title, thumbnail, and description patterns we like, see `docs/youtube-examples.md`.) ## 6. Rigging conventions Use consistent rigging standards (detailed in `docs/rigging-standards.md`; Claude: read that file when discussing rig implementation): - Naming: - Use clear, systematic names (e.g., `L_arm_JNT`, `C_spine_CTRL`, `R_foot_IK`). - Prefixes for side (L/R/C) and suffixes for type (JNT, CTRL, GEO, IK, FK, LOC). - Hierarchy: - Separate deformation joints, controls, and geometry groups. - No direct constraints on geometry; use joints as the deformation layer. - Keep control hierarchies logical for animators (e.g., global control at top). - Technical choices: - Default to clean, oriented joint chains for limbs. - Use groups to zero out control transforms. - Clearly explain why we choose IK, FK, or IK/FK blends for different body parts. ## 7. Workflow expectations Default workflow when I ask for help: - For fundamentals videos: - Propose a short list of key points and a simple example (e.g., “joint orientation using a basic arm chain”). - Draft an outline: intro, concept explanation, demo, recap. - Then write a script that includes both narration and high‑level on‑screen actions (no need for every click). - For full rig series: - Propose a series breakdown (e.g., Part 1: joints and hierarchy, Part 2: controllers, Part 3: IK/FK arms, Part 4: legs and foot roll, Part 5: skinning basics). - For each part, write an outline first; wait for my adjustments before scripting. - Include a short “prerequisites” note in each outline (what the viewer must have ready). - For descriptions: - Pull the key rigging concepts from the script. - Include what the viewer will have working by the end (e.g., “a spine rig with FK controls and clean deformation”). - Suggest tags that cover Maya, rigging, 3D, and specific techniques used. - For supplementary materials: - Suggest names and locations for scene files (e.g., `assets/base_character_v01.ma`, `assets/rigged_character_spine_v02.ma`). - Propose simple diagrams or notes that could be shared as PDFs or images if useful. ## 8. Mistakes and edge cases to avoid Do not: - Show or recommend destructive actions without a warning (e.g., deleting history on a rigged, animated character). - Mix unrelated workflows into a single video (e.g., UI layout, modelling, texturing alongside rigging). - Assume the viewer knows complex rigging terminology without a brief explanation the first time. Be careful about: - Maya version differences (menu locations, tools) and mention when something is version‑specific. - Terminology (e.g., “constraints” vs “connections”)—be consistent and clear. - Overcomplicating beginner content with advanced setups before they are needed. If my request is vague (e.g., “video on rigging a character”): - Ask clarifying questions: - Is this for absolute beginners or intermediate riggers? - Is the character biped, quadruped, or stylized? - Do we assume existing mesh and clean topology, or should we mention requirements? - Suggest 2–3 possible angles and wait for my choice. ## 9. How to interact with me - When presenting options (video ideas, series breakdown, rigging approaches), number them clearly and briefly explain pros/cons. - If you are making assumptions about the character (e.g., human biped, game‑ready vs film‑ready), list those assumptions at the top of your response. - If some step benefits from a diagram (e.g., joint hierarchy, IK/FK blend structure), explicitly suggest that I create or include one. --- ``` If you tell me more about your **target level** (absolute beginner vs some Maya experience) and whether you prefer **short episodes or long series**, I can refine this further into an even tighter `claude.md` for your exact channel. ``` --- Here’s a version of `claude.md` tailored to a YouTube channel about **character rigging in Maya**, from fundamentals to full control rigs.[[youtube](https://www.youtube.com/watch?v=Y09u_S3w2c8)]​ --- ## claude.md – YouTube Channel: Character Rigging in Maya ## 1. What this project is We are building and running a YouTube channel that teaches character rigging in Autodesk Maya, from absolute basics to complete production‑ready control rigs for biped and stylized characters. Channel goals: - Help beginners understand core rigging concepts (joints, hierarchies, constraints, skinning, deformation). - Guide intermediate users through building full control rigs step by step. - Develop a library of reusable rigs, tools, and workflows viewers can follow. ## 2. How we work Main video formats: - Fundamentals: short lessons focused on a single concept (e.g., joint orientation, FK vs IK, constraints). - Guided builds: multi‑part series where we rig a character from scratch. - Workflow breakdowns: explaining rigging decisions in real production scenarios (e.g., why we choose certain control setups). Typical video structure: 1. Hook: the problem or outcome (e.g., “Today we’ll build an IK/FK switch for the arm that won’t break your animation”). 2. Context: where this concept fits in the bigger rigging pipeline. 3. Step‑by‑step demo in Maya. 4. Recap and “what to rig next.” Project folder structure: - `ideas/` – episode ideas, viewer questions, and series plans. - `scripts/` – outlines and scripts for videos. - `assets/` – example Maya scenes, character meshes, reference images. - `descriptions/` – video descriptions, tags, and chapter timestamps. - `docs/` – reference docs (naming conventions, rigging standards, example rigs). - `repurposed/` – shorts, community posts, and social content derived from videos. When creating new content, always: - Check `ideas/` for existing topics and series. - Reuse established naming conventions and rig structures from `docs/rigging-standards.md` (Claude: read this when talking about rig structure or naming). - Assume the viewer is in Maya but may not know specific menus by heart. ## 3. Audience and positioning Audience: - Maya users with basic navigation knowledge but limited or no rigging experience. - Self‑taught artists and junior riggers who want structured, production‑oriented guidance. Positioning: - Practical, Maya‑specific rigging education. - Focus on building rigs that are clean, debuggable, and animator‑friendly, not just “it works once.” - We explicitly call out best practices and common pitfalls (double transforms, bad joint orientation, messy hierarchies). ## 4. Voice, tone, and style Voice: - Friendly and patient, like a mentor explaining rigging in a lab or production setting. - Clear and precise when describing technical steps. Style for scripts: - Use simple, direct sentences that are easy to read aloud. - Reference Maya UI explicitly: menu paths, shelf tools, hotkeys when relevant. - Always pair “what” with “why” (not just “click here,” but also “this avoids double transforms”). - Avoid unnecessary jargon; when a technical term is needed, define it briefly. Pacing: - Get to the Maya viewport quickly; intros should be under ~20 seconds. - Alternate between showing the result and building it, so learners see the purpose of each step. - For complex setups, announce the “checkpoint” (e.g., “By the end of this video, your leg rig should do X, Y, Z”). (For concrete examples of preferred script structure and tone, see `docs/script-examples.md`. Claude: read this file before drafting scripts.) ## 5. Content rules and constraints Do: - Start with the outcome (“Today you’ll have a working arm IK/FK switch”). - Include at least one quick test in Maya to prove the rig works (e.g., rotating controls, checking deformations). - Call out common mistakes (e.g., un‑frozen transforms on controls, non‑zero joint orientations, incorrect parenting). - Mention which Maya version and units we assume when it matters. Avoid: - Very long unstructured videos that mix many unrelated rigging topics. - Overly theoretical discussion without touching the rig in Maya. - Skipping necessary steps that a beginner would not infer (e.g., “make sure your mesh history is clean before binding”). YouTube‑specific: - Titles should clearly state the rigging task and level, e.g., “Maya Rigging Basics: Creating a Clean Joint Chain” or “Maya Character Rig: Full Biped Control Rig – Part 1: Spine.” - Descriptions must include: short summary, learning outcomes, required starting files, and chapter timestamps. - Include links to any downloadable scene files or reference in the description. (For title, thumbnail, and description patterns we like, see `docs/youtube-examples.md`.) ## 6. Rigging conventions Use consistent rigging standards (detailed in `docs/rigging-standards.md`; Claude: read that file when discussing rig implementation): - Naming: - Use clear, systematic names (e.g., `L_arm_JNT`, `C_spine_CTRL`, `R_foot_IK`). - Prefixes for side (L/R/C) and suffixes for type (JNT, CTRL, GEO, IK, FK, LOC). - Hierarchy: - Separate deformation joints, controls, and geometry groups. - No direct constraints on geometry; use joints as the deformation layer. - Keep control hierarchies logical for animators (e.g., global control at top). - Technical choices: - Default to clean, oriented joint chains for limbs. - Use groups to zero out control transforms. - Clearly explain why we choose IK, FK, or IK/FK blends for different body parts. ## 7. Workflow expectations Default workflow when I ask for help: - For fundamentals videos: - Propose a short list of key points and a simple example (e.g., “joint orientation using a basic arm chain”). - Draft an outline: intro, concept explanation, demo, recap. - Then write a script that includes both narration and high‑level on‑screen actions (no need for every click). - For full rig series: - Propose a series breakdown (e.g., Part 1: joints and hierarchy, Part 2: controllers, Part 3: IK/FK arms, Part 4: legs and foot roll, Part 5: skinning basics). - For each part, write an outline first; wait for my adjustments before scripting. - Include a short “prerequisites” note in each outline (what the viewer must have ready). - For descriptions: - Pull the key rigging concepts from the script. - Include what the viewer will have working by the end (e.g., “a spine rig with FK controls and clean deformation”). - Suggest tags that cover Maya, rigging, 3D, and specific techniques used. - For supplementary materials: - Suggest names and locations for scene files (e.g., `assets/base_character_v01.ma`, `assets/rigged_character_spine_v02.ma`). - Propose simple diagrams or notes that could be shared as PDFs or images if useful. ## 8. Mistakes and edge cases to avoid Do not: - Show or recommend destructive actions without a warning (e.g., deleting history on a rigged, animated character). - Mix unrelated workflows into a single video (e.g., UI layout, modelling, texturing alongside rigging). - Assume the viewer knows complex rigging terminology without a brief explanation the first time. Be careful about: - Maya version differences (menu locations, tools) and mention when something is version‑specific. - Terminology (e.g., “constraints” vs “connections”)—be consistent and clear. - Overcomplicating beginner content with advanced setups before they are needed. If my request is vague (e.g., “video on rigging a character”): - Ask clarifying questions: - Is this for absolute beginners or intermediate riggers? - Is the character biped, quadruped, or stylized? - Do we assume existing mesh and clean topology, or should we mention requirements? - Suggest 2–3 possible angles and wait for my choice. ## 9. How to interact with me - When presenting options (video ideas, series breakdown, rigging approaches), number them clearly and briefly explain pros/cons. - If you are making assumptions about the character (e.g., human biped, game‑ready vs film‑ready), list those assumptions at the top of your response. - If some step benefits from a diagram (e.g., joint hierarchy, IK/FK blend structure), explicitly suggest that I create or include one. --- If you tell me more about your **target level** (absolute beginner vs some Maya experience) and whether you prefer **short episodes or long series**, I can refine this further into an even tighter `claude.md` for your exact channel.