USP

This official Anthropic repository provides a comprehensive, community-driven collection of practical Claude API examples, covering a wide spectrum of capabilities from basic text tasks to advanced agent patterns and multimodal vision, mak…

Use cases

• 01Building AI agents with tool use
• 02Implementing Retrieval Augmented Generation (RAG)
• 03Developing multimodal applications with Claude Vision
• 04Automating content summarization and classification
• 05Creating moderation filters and prompt evaluations

Detected files (8)

• skills/custom_skills/applying-brand-guidelines/SKILL.mdskill
  Show content (4855 bytes)

  ---
  name: applying-brand-guidelines
  description: This skill applies consistent corporate branding and styling to all generated documents including colors, fonts, layouts, and messaging
  ---
  
  # Corporate Brand Guidelines Skill
  
  This skill ensures all generated documents adhere to corporate brand standards for consistent, professional communication.
  
  ## Brand Identity
  
  ### Company: Acme Corporation
  **Tagline**: "Innovation Through Excellence"
  **Industry**: Technology Solutions
  
  ## Visual Standards
  
  ### Color Palette
  
  **Primary Colors**:
  - **Acme Blue**: #0066CC (RGB: 0, 102, 204) - Headers, primary buttons
  - **Acme Navy**: #003366 (RGB: 0, 51, 102) - Text, accents
  - **White**: #FFFFFF - Backgrounds, reverse text
  
  **Secondary Colors**:
  - **Success Green**: #28A745 (RGB: 40, 167, 69) - Positive metrics
  - **Warning Amber**: #FFC107 (RGB: 255, 193, 7) - Cautions
  - **Error Red**: #DC3545 (RGB: 220, 53, 69) - Negative values
  - **Neutral Gray**: #6C757D (RGB: 108, 117, 125) - Secondary text
  
  ### Typography
  
  **Primary Font Family**: Segoe UI, system-ui, -apple-system, sans-serif
  
  **Font Hierarchy**:
  - **H1**: 32pt, Bold, Acme Blue
  - **H2**: 24pt, Semibold, Acme Navy
  - **H3**: 18pt, Semibold, Acme Navy
  - **Body**: 11pt, Regular, Acme Navy
  - **Caption**: 9pt, Regular, Neutral Gray
  
  ### Logo Usage
  
  - Position: Top-left corner on first page/slide
  - Size: 120px width (maintain aspect ratio)
  - Clear space: Minimum 20px padding on all sides
  - Never distort, rotate, or apply effects
  
  ## Document Standards
  
  ### PowerPoint Presentations
  
  **Slide Templates**:
  1. **Title Slide**: Company logo, presentation title, date, presenter
  2. **Section Divider**: Section title with blue background
  3. **Content Slide**: Title bar with blue background, white content area
  4. **Data Slide**: For charts/graphs, maintain color palette
  
  **Layout Rules**:
  - Margins: 0.5 inches all sides
  - Title position: Top 15% of slide
  - Bullet indentation: 0.25 inches per level
  - Maximum 6 bullet points per slide
  - Charts use brand colors exclusively
  
  ### Excel Spreadsheets
  
  **Formatting Standards**:
  - **Headers**: Row 1, Bold, White text on Acme Blue background
  - **Subheaders**: Bold, Acme Navy text
  - **Data cells**: Regular, Acme Navy text
  - **Borders**: Thin, Neutral Gray
  - **Alternating rows**: Light gray (#F8F9FA) for readability
  
  **Chart Defaults**:
  - Primary series: Acme Blue
  - Secondary series: Success Green
  - Gridlines: Neutral Gray, 0.5pt
  - No 3D effects or gradients
  
  ### PDF Documents
  
  **Page Layout**:
  - **Header**: Company logo left, document title center, page number right
  - **Footer**: Copyright notice left, date center, classification right
  - **Margins**: 1 inch all sides
  - **Line spacing**: 1.15
  - **Paragraph spacing**: 12pt after
  
  **Section Formatting**:
  - Main headings: Acme Blue, 16pt, bold
  - Subheadings: Acme Navy, 14pt, semibold
  - Body text: Acme Navy, 11pt, regular
  
  ## Content Guidelines
  
  ### Tone of Voice
  
  - **Professional**: Formal but approachable
  - **Clear**: Avoid jargon, use simple language
  - **Active**: Use active voice, action-oriented
  - **Positive**: Focus on solutions and benefits
  
  ### Standard Phrases
  
  **Opening Statements**:
  - "At Acme Corporation, we..."
  - "Our commitment to innovation..."
  - "Delivering excellence through..."
  
  **Closing Statements**:
  - "Thank you for your continued partnership."
  - "We look forward to serving your needs."
  - "Together, we achieve excellence."
  
  ### Data Presentation
  
  **Numbers**:
  - Use comma separators for thousands
  - Currency: $X,XXX.XX format
  - Percentages: XX.X% (one decimal)
  - Dates: Month DD, YYYY
  
  **Tables**:
  - Headers in brand blue
  - Alternating row colors
  - Right-align numbers
  - Left-align text
  
  ## Quality Standards
  
  ### Before Finalizing
  
  Always ensure:
  1. Logo is properly placed and sized
  2. All colors match brand palette exactly
  3. Fonts are consistent throughout
  4. No typos or grammatical errors
  5. Data is accurately presented
  6. Professional tone maintained
  
  ### Prohibited Elements
  
  Never use:
  - Clip art or stock photos without approval
  - Comic Sans, Papyrus, or decorative fonts
  - Rainbow colors or gradients
  - Animations or transitions (unless specified)
  - Competitor branding or references
  
  ## Application Instructions
  
  When creating any document:
  1. Start with brand colors and fonts
  2. Apply appropriate template structure
  3. Include logo on first page/slide
  4. Use consistent formatting throughout
  5. Review against brand standards
  6. Ensure professional appearance
  
  ## Scripts
  
  - `apply_brand.py`: Automatically applies brand formatting to documents
  - `validate_brand.py`: Checks documents for brand compliance
  
  ## Notes
  
  - These guidelines apply to all external communications
  - Internal documents may use simplified formatting
  - Special projects may have exceptions (request approval)
  - Brand guidelines updated quarterly - check for latest version
  

• skills/custom_skills/creating-financial-models/SKILL.mdskill
  Show content (5107 bytes)

  ---
  name: creating-financial-models
  description: This skill provides an advanced financial modeling suite with DCF analysis, sensitivity testing, Monte Carlo simulations, and scenario planning for investment decisions
  ---
  
  # Financial Modeling Suite
  
  A comprehensive financial modeling toolkit for investment analysis, valuation, and risk assessment using industry-standard methodologies.
  
  ## Core Capabilities
  
  ### 1. Discounted Cash Flow (DCF) Analysis
  - Build complete DCF models with multiple growth scenarios
  - Calculate terminal values using perpetuity growth and exit multiple methods
  - Determine weighted average cost of capital (WACC)
  - Generate enterprise and equity valuations
  
  ### 2. Sensitivity Analysis
  - Test key assumptions impact on valuation
  - Create data tables for multiple variables
  - Generate tornado charts for sensitivity ranking
  - Identify critical value drivers
  
  ### 3. Monte Carlo Simulation
  - Run thousands of scenarios with probability distributions
  - Model uncertainty in key inputs
  - Generate confidence intervals for valuations
  - Calculate probability of achieving targets
  
  ### 4. Scenario Planning
  - Build best/base/worst case scenarios
  - Model different economic environments
  - Test strategic alternatives
  - Compare outcome probabilities
  
  ## Input Requirements
  
  ### For DCF Analysis
  - Historical financial statements (3-5 years)
  - Revenue growth assumptions
  - Operating margin projections
  - Capital expenditure forecasts
  - Working capital requirements
  - Terminal growth rate or exit multiple
  - Discount rate components (risk-free rate, beta, market premium)
  
  ### For Sensitivity Analysis
  - Base case model
  - Variable ranges to test
  - Key metrics to track
  
  ### For Monte Carlo Simulation
  - Probability distributions for uncertain variables
  - Correlation assumptions between variables
  - Number of iterations (typically 1,000-10,000)
  
  ### For Scenario Planning
  - Scenario definitions and assumptions
  - Probability weights for scenarios
  - Key performance indicators to track
  
  ## Output Formats
  
  ### DCF Model Output
  - Complete financial projections
  - Free cash flow calculations
  - Terminal value computation
  - Enterprise and equity value summary
  - Valuation multiples implied
  - Excel workbook with full model
  
  ### Sensitivity Analysis Output
  - Sensitivity tables showing value ranges
  - Tornado chart of key drivers
  - Break-even analysis
  - Charts showing relationships
  
  ### Monte Carlo Output
  - Probability distribution of valuations
  - Confidence intervals (e.g., 90%, 95%)
  - Statistical summary (mean, median, std dev)
  - Risk metrics (VaR, probability of loss)
  
  ### Scenario Planning Output
  - Scenario comparison table
  - Probability-weighted expected values
  - Decision tree visualization
  - Risk-return profiles
  
  ## Model Types Supported
  
  1. **Corporate Valuation**
     - Mature companies with stable cash flows
     - Growth companies with J-curve projections
     - Turnaround situations
  
  2. **Project Finance**
     - Infrastructure projects
     - Real estate developments
     - Energy projects
  
  3. **M&A Analysis**
     - Acquisition valuations
     - Synergy modeling
     - Accretion/dilution analysis
  
  4. **LBO Models**
     - Leveraged buyout analysis
     - Returns analysis (IRR, MOIC)
     - Debt capacity assessment
  
  ## Best Practices Applied
  
  ### Modeling Standards
  - Consistent formatting and structure
  - Clear assumption documentation
  - Separation of inputs, calculations, outputs
  - Error checking and validation
  - Version control and change tracking
  
  ### Valuation Principles
  - Use multiple valuation methods for triangulation
  - Apply appropriate risk adjustments
  - Consider market comparables
  - Validate against trading multiples
  - Document key assumptions clearly
  
  ### Risk Management
  - Identify and quantify key risks
  - Use probability-weighted scenarios
  - Stress test extreme cases
  - Consider correlation effects
  - Provide confidence intervals
  
  ## Example Usage
  
  "Build a DCF model for this technology company using the attached financials"
  
  "Run a Monte Carlo simulation on this acquisition model with 5,000 iterations"
  
  "Create sensitivity analysis showing impact of growth rate and WACC on valuation"
  
  "Develop three scenarios for this expansion project with probability weights"
  
  ## Scripts Included
  
  - `dcf_model.py`: Complete DCF valuation engine
  - `sensitivity_analysis.py`: Sensitivity testing framework
  
  ## Limitations and Disclaimers
  
  - Models are only as good as their assumptions
  - Past performance doesn't guarantee future results
  - Market conditions can change rapidly
  - Regulatory and tax changes may impact results
  - Professional judgment required for interpretation
  - Not a substitute for professional financial advice
  
  ## Quality Checks
  
  The model automatically performs:
  1. Balance sheet balancing checks
  2. Cash flow reconciliation
  3. Circular reference resolution
  4. Sensitivity bound checking
  5. Statistical validation of Monte Carlo results
  
  ## Updates and Maintenance
  
  - Models use latest financial theory and practices
  - Regular updates for market parameter defaults
  - Incorporation of regulatory changes
  - Continuous improvement based on usage patterns
  

• skills/custom_skills/analyzing-financial-statements/SKILL.mdskill
  Show content (2479 bytes)

  ---
  name: analyzing-financial-statements
  description: This skill calculates key financial ratios and metrics from financial statement data for investment analysis
  ---
  
  # Financial Ratio Calculator Skill
  
  This skill provides comprehensive financial ratio analysis for evaluating company performance, profitability, liquidity, and valuation.
  
  ## Capabilities
  
  Calculate and interpret:
  - **Profitability Ratios**: ROE, ROA, Gross Margin, Operating Margin, Net Margin
  - **Liquidity Ratios**: Current Ratio, Quick Ratio, Cash Ratio
  - **Leverage Ratios**: Debt-to-Equity, Interest Coverage, Debt Service Coverage
  - **Efficiency Ratios**: Asset Turnover, Inventory Turnover, Receivables Turnover
  - **Valuation Ratios**: P/E, P/B, P/S, EV/EBITDA, PEG
  - **Per-Share Metrics**: EPS, Book Value per Share, Dividend per Share
  
  ## How to Use
  
  1. **Input Data**: Provide financial statement data (income statement, balance sheet, cash flow)
  2. **Select Ratios**: Specify which ratios to calculate or use "all" for comprehensive analysis
  3. **Interpretation**: The skill will calculate ratios and provide industry-standard interpretations
  
  ## Input Format
  
  Financial data can be provided as:
  - CSV with financial line items
  - JSON with structured financial statements
  - Text description of key financial figures
  - Excel files with financial statements
  
  ## Output Format
  
  Results include:
  - Calculated ratios with values
  - Industry benchmark comparisons (when available)
  - Trend analysis (if multiple periods provided)
  - Interpretation and insights
  - Excel report with formatted results
  
  ## Example Usage
  
  "Calculate key financial ratios for this company based on the attached financial statements"
  
  "What's the P/E ratio if the stock price is $50 and annual earnings are $2.50 per share?"
  
  "Analyze the liquidity position using the balance sheet data"
  
  ## Scripts
  
  - `calculate_ratios.py`: Main calculation engine for all financial ratios
  - `interpret_ratios.py`: Provides interpretation and benchmarking
  
  ## Best Practices
  
  1. Always validate data completeness before calculations
  2. Handle missing values appropriately (use industry averages or exclude)
  3. Consider industry context when interpreting ratios
  4. Include period comparisons for trend analysis
  5. Flag unusual or concerning ratios
  
  ## Limitations
  
  - Requires accurate financial data
  - Industry benchmarks are general guidelines
  - Some ratios may not apply to all industries
  - Historical data doesn't guarantee future performance
  

• .claude/skills/cookbook-audit/SKILL.mdskill
  Show content (12334 bytes)

  ---
  name: cookbook-audit
  description: Audit an Anthropic Cookbook notebook based on a rubric. Use whenever a notebook review or audit is requested.
  ---
  
  # Cookbook Audit
  
  ## Instructions
  
  Review the requested Cookbook notebook using the guidelines and rubrics in `style_guide.md`. Provide a score based on scoring guidelines and recommendations on improving the cookbook.
  
  The style guide provides detailed templates and examples for:
  - Problem-focused introductions with Terminal Learning Objectives (TLOs) and Enabling Learning Objectives (ELOs)
  - Prerequisites and setup patterns
  - Core content structure
  - Conclusions that map back to learning objectives
  
  **IMPORTANT**: Always read `style_guide.md` first before conducting an audit. The style guide contains the canonical templates and good/bad examples to reference.
  
  ## Workflow
  
  Follow these steps for a comprehensive audit:
  
  1. **Read the style guide**: First review `style_guide.md` to understand current best practices
  2. **Identify the notebook**: Ask user for path if not provided
  3. **Run automated checks**: Use `python3 validate_notebook.py <path>` to catch technical issues and generate markdown
     - The script automatically runs detect-secrets to scan for hardcoded API keys and credentials
     - Uses custom patterns defined in `scripts/detect-secrets/plugins.py`
     - Checks against baseline at `scripts/detect-secrets/.secrets.baseline`
  4. **Review markdown output**: The script generates a markdown file in the `tmp/` folder for easier review (saves context vs raw .ipynb)
     - The tmp/ folder is gitignored to avoid committing review artifacts
     - Markdown includes code cells but excludes outputs for cleaner review
  5. **Manual review**: Read through the markdown version evaluating against style guide and rubric
  6. **Score each dimension**: Apply scoring guidelines objectively
  7. **Generate report**: Follow the audit report format below
  8. **Provide specific examples**: Show concrete improvements with line references using the style guide templates
  
  ## Audit Report Format
  
  Present your audit using this structure:
  
  ### Executive Summary
  - **Overall Score**: X/20
  - **Key Strengths** (2-3 bullet points)
  - **Critical Issues** (2-3 bullet points)
  
  ### Detailed Scoring
  
  #### 1. Narrative Quality: X/5
  [Brief justification with specific examples]
  
  #### 2. Code Quality: X/5
  [Brief justification with specific examples]
  
  #### 3. Technical Accuracy: X/5
  [Brief justification with specific examples]
  
  #### 4. Actionability & Understanding: X/5
  [Brief justification with specific examples]
  
  ### Specific Recommendations
  
  [Prioritized, actionable list of improvements with references to specific sections]
  
  ### Examples & Suggestions
  
  [Show specific excerpts from the notebook with concrete suggestions for improvement]
  
  ## Quick Reference Checklist
  
  Use this to ensure comprehensive coverage:
  
  **Introduction** (See style_guide.md Section 1)
  - [ ] Hooks with the problem being solved (1-2 sentences)
  - [ ] Explains why it matters (1-2 sentences)
  - [ ] Lists learning objectives as bullet points (2-4 TLOs/ELOs)
  - [ ] Focuses on value delivered, not machinery built
  - [ ] Optional: mentions broader applications (1 sentence)
  
  **Prerequisites & Setup** (See style_guide.md Section 2)
  - [ ] Lists required knowledge clearly
  - [ ] Lists required tools (Python version, API keys)
  - [ ] Mentions recommended background if applicable
  - [ ] Uses %%capture for pip install to suppress output
  - [ ] Uses dotenv.load_dotenv() not os.environ
  - [ ] Defines MODEL constant at top
  - [ ] Groups related installs in single command
  
  **Structure & Organization**
  - [ ] Has logical section progression
  - [ ] Each section teaches through demonstration
  - [ ] Code blocks have explanatory text before them
  - [ ] Includes what we learned after code blocks
  - [ ] Uses headers to break up sections
  
  **Conclusion** (See style_guide.md Section 4)
  - [ ] Maps back to learning objectives
  - [ ] Summarizes what was accomplished
  - [ ] Suggests ways to apply lessons to user's context
  - [ ] Points to next steps or related resources
  
  **Code Quality**
  - [ ] All code blocks have explanatory text before them
  - [ ] No hardcoded API keys (automatically checked by detect-secrets)
  - [ ] Meaningful variable names
  - [ ] Comments explain "why" not "what"
  - [ ] Follows language best practices
  - [ ] Model name defined as constant at top of notebook
  
  **Output Management**
  - [ ] pip install logs suppressed with %%capture
  - [ ] No verbose debug output
  - [ ] Shows relevant API responses
  - [ ] Stack traces only when demonstrating error handling
  
  **Content Quality**
  - [ ] Explains why approaches work
  - [ ] Discusses when to use this approach
  - [ ] Mentions limitations/considerations
  - [ ] Provides transferable knowledge
  - [ ] Appropriate model selection
  
  **Technical Requirements**
  - [ ] Executable without modification (except API keys)
  - [ ] Uses non-deprecated API patterns
  - [ ] Uses valid model names (claude-sonnet-4-6, claude-haiku-4-5, claude-opus-4-6)
  - [ ] Uses non-dated model aliases (never dated IDs like claude-sonnet-4-6-20250514)
  - [ ] Model name defined as constant at top of notebook
  - [ ] Includes dependency specifications
  - [ ] Assigned to primary category
  - [ ] Has relevant tags
  
  ### Content Philosophy: Action + Understanding
  
  Cookbooks are primarily action-oriented but strategically incorporate understanding and informed by Diataxis framework.
  
  **Core Principles:**
  - **Practical focus**: Show users how to accomplish specific tasks with working code
  - **Problem-first framing**: Lead with the problem being solved and value delivered, not the machinery
  - **Builder's perspective**: Written from the user's point of view, solving real problems
  - **Agency-building**: Help users understand why approaches work, not just how
  - **Transferable knowledge**: Teach patterns and principles that apply beyond the specific example
  - **Critical thinking**: Encourage users to question outputs, recognize limitations, make informed choices
  - **Learning contracts**: State learning objectives upfront, then map back to them in conclusions
  
  ### What Makes a Good Cookbook
  
  A good cookbook doesn't just help users solve today's problem, it also helps them understand the underlying principles behind the solutions, encouraging them to recognize when and how to adapt approaches. Users will be able to make more informed decisions about AI system design, develop judgement about model outputs, and build skills that transfer to future AI systems.
  
  ### What Cookbooks Are NOT
  
  Cookbooks are not pure tutorials: We assume users have basic technical skills and API familiarity. We clearly state prerequisites in our cookbooks, and direct users to the Academy to learn more on topics.
  They are not comprehensive explanations: We don't teach transformer architecture or probability theory. We need to understand that our users are following our cookbooks to solve problems they are facing today. They are busy, in the midst of learning or building, and want to be able to use what they learn to solve their immediate needs.
  Cookbooks are not reference docs: We don't exhaustively document every parameter, we link to appropriate resources in our documentation as needed.
  Cookbooks are not simple tips and tricks: We don't teach "hacks" that only work for the current model generation. We don't over-promise and under-deliver.
  Cookbooks are not production-ready code: They showcase use cases and capabilities, not production patterns. Excessive error handling is not required.
  
  ### Style Guidelines
  
  #### Voice & Tone
  - Educational and agency-building
  - Professional but approachable
  - Respectful of user intelligence and time
  - Either second person ("you") or first person plural ("we") - be consistent within a notebook
  
  #### Writing Quality
  - Clear, concise explanations
  - Active voice preferred
  - Short paragraphs (3-5 sentences)
  - Avoid jargon without definition
  - Use headers to break up sections
  
  #### Code Presentation
  - **Always explain before showing**: Every code block should be preceded by explanatory text
  - **Explain after running**: Include what we learned after code blocks execute
  - **Comments explain why, not what**: Use meaningful variable names
  - **Use constants**: Define MODEL as a constant at the top
  - **Good habits**: Use `dotenv.load_dotenv()` instead of `os.environ`
  
  #### Output Handling
  **Remove extraneous output** with %%capture:
  - pip install logs (always suppress these)
  - Verbose debug statements
  - Lengthy stack traces (unless demonstrating error handling)
  
  **Show relevant output**:
  - API responses that demonstrate functionality
  - Examples of successful execution
  
  ### Structural Requirements
  
  **See style_guide.md for detailed templates and examples**
  
  #### 1. Introduction (Required)
  Must include:
  - **Problem hook** (1-2 sentences): What problem are we solving?
  - **Why it matters** (1-2 sentences): Why is this important?
  - **Learning objectives** (2-4 bullet points): "By the end of this cookbook, you'll be able to..."
    - Use action verbs (Build, Implement, Deploy, etc.)
    - Be specific about capabilities
    - Include context/constraints
  - **Optional**: Broader applications (1 sentence)
  
  ❌ **Avoid**: Leading with machinery ("We will build a research agent...")
  ✅ **Do**: Lead with problem/value ("Your team spends hours triaging CI failures...")
  
  #### 2. Prerequisites & Setup (Required)
  Must include:
  - **Required Knowledge**: Technical skills needed
  - **Required Tools**: Python version, API keys with links
  - **Recommended**: Optional background that helps
  - **Setup**: Step-by-step with explanations
    - Use `%%capture` for pip installs
    - Use `dotenv.load_dotenv()` not `os.environ`
    - Define `MODEL` constant at top
  
  #### 3. Main Content (Required)
  Organized by logical steps or phases, each with:
  - Clear section headers
  - **Explanatory text before code blocks** (what we're about to do)
  - Code examples
  - **Explanatory text after code blocks** (what we learned)
  - Expected outputs (where relevant)
  - Optional: Understanding callouts (why it works, when to use, limitations)
  
  #### 4. Conclusion (Recommended)
  Must include:
  - **Recap**: Map back to learning objectives
  - **What was accomplished**: Summary of key points
  - **Application guidance**: How to apply lessons to user's context
  - **Next steps**: Related resources or ideas to pursue
  
  ❌ **Avoid**: Generic summaries ("We've demonstrated how the SDK enables...")
  ✅ **Do**: Actionable guidance ("Consider applying this to X... Next, try Y...")
  
  #### Optional Sections
  - **How It Works**: Brief explanation of underlying mechanism
  - **When to Use This**: Appropriate use cases and contexts
  - **Limitations & Considerations**: Caveats, failure modes, constraints
  - **Troubleshooting**: Common issues and solutions
  - **Variations**: Alternative approaches or extensions
  - **Performance Notes**: Optimization considerations
  - **Further Reading**: Links to relevant docs, papers, or deeper explanations
  
  ### Common Anti-Patterns to Flag
  
  Refer to style_guide.md for detailed good/bad examples. Watch for these issues:
  
  #### Introduction Anti-Patterns
  ❌ Leading with machinery: "We will build a research agent using the Claude SDK..."
  ❌ Feature dumps: Listing SDK methods or tool capabilities
  ❌ Vague learning objectives: "Learn about agents" or "Understand the API"
  ✅ Problem-first framing with specific, actionable learning objectives
  
  #### Setup Anti-Patterns
  ❌ Noisy pip install output without `%%capture`
  ❌ Multiple separate pip install commands
  ❌ Using `os.environ["API_KEY"] = "your_key"` instead of dotenv
  ❌ Hardcoding model names throughout instead of using a MODEL constant
  ✅ Clean setup with grouped installs, dotenv, and constants
  
  #### Code Presentation Anti-Patterns
  ❌ Code blocks without explanatory text before them
  ❌ No explanation of what we learned after running code
  ❌ Comments that explain "what" the code does (code should be self-documenting)
  ❌ Over-explaining obvious code
  ✅ Context before code, insights after code, comments explain "why"
  
  #### Conclusion Anti-Patterns
  ❌ Generic summaries: "We've demonstrated how the SDK enables..."
  ❌ Simply restating what the notebook did without guidance
  ❌ Not mapping back to the stated learning objectives
  ✅ Actionable guidance on applying lessons to user's specific context

• .claude/commands/add-registry.mdcommand
  Show content (2468 bytes)

  ---
  allowed-tools: Read,Glob,Grep,Edit
  description: Add a new notebook to registry.yaml
  ---
  
  Add a new entry to `registry.yaml` for the notebook specified in the prompt above.
  
  ## Instructions
  
  1. **Read the notebook** at the specified path to understand its content
  2. **Check author exists** in `authors.yaml`:
     - Ask the user for the GitHub username of the notebook author
     - Read `authors.yaml` and check if that username exists as a key
     - If the author does NOT exist, ask the user for their details and add them to `authors.yaml`:
       - **name**: Full display name
       - **website**: GitHub profile URL or personal website
       - **avatar**: Use `https://github.com/<username>.png` as default
  3. **Generate the registry entry** with these fields:
  
  ### Required Fields
  - **title**: Extract from the notebook's first heading or create a concise, descriptive title
  - **description**: Write a brief 1-2 sentence description summarizing what the notebook teaches
  - **path**: The notebook path relative to the repository root
  - **authors**: Use the GitHub username from step 2
  - **date**: Use today's date in YYYY-MM-DD format
  - **categories**: Select 1-2 appropriate categories from this list:
    - Agent Patterns
    - Claude Agent SDK
    - Cybersecurity
    - Evals
    - Fine-Tuning
    - Multimodal
    - Integrations
    - Observability
    - RAG & Retrieval
    - Responses
    - Skills
    - Thinking
    - Tools
  
  ### Style Guidelines
  - Title should be concise but descriptive (see existing entries for examples)
  - Description should be ~15-20 words, focusing on what the user will learn/build
  - Choose categories that best match the notebook's primary focus
  
  ## Output
  
  1. If author is new, show the proposed `authors.yaml` entry for review and add it after approval
  2. Show the user the proposed `registry.yaml` entry for review
  3. After user approval, use the Edit tool to append the entry to `registry.yaml`
  4. Maintain alphabetical ordering by path within the file, or append to the end if unclear
  
  ## Example Entry Formats
  
  ### authors.yaml (only if new author)
  ```yaml
  github-username:
    name: Full Name
    website: https://github.com/github-username
    avatar: https://github.com/github-username.png
  ```
  
  ### registry.yaml
  ```yaml
  - title: Example Notebook Title
    description: Brief description of what this notebook covers and teaches users.
    path: category/notebook_name.ipynb
    authors:
    - github-username
    date: 'YYYY-MM-DD'
    categories:
    - Category Name
  ```
  

• .claude/agents/code-reviewer.mdagent
  Show content (10014 bytes)

  ---
  name: code-reviewer
  description: Performs thorough code reviews for the Notebooks in the Cookbook repo, focusing on Python/Jupyter best practices, and project-specific standards. Use this agent proactively after writing any significant code changes, especially when modifying notebooks, Github Actions, and scripts
  tools: Read, Grep, Glob, Bash, Bash(git status:*)
  ---
  
  You are a senior software engineer specializing in code reviews for Anthropic's Cookbooks repo. Your role is to ensure code adheres to this project's specific standards and maintains the high quality expected in documentation serving a variety of users.
  
  Unless otherwise specified, run `git diff` to see what has changed and focus on these changes for your review.
  
  ## Core Review Areas
  
  1. **Code Quality & Readability**: Ensure code follows "write for readability" principle - imagine someone ramping up 3-9 months from now
  2. **Python Patterns**: Check for proper Python patterns, especially as it relates to context managers and exceptions
  3. **Security**: Prevent secret exposure and ensure proper authentication patterns
  4. **Notebook Pedagogy**: Ensure notebooks follow problem-focused learning objectives and clear structure
  
  ## SPECIFIC CHECKLIST
  
  ### Notebook Structure & Content
  
  - **Introduction Quality**:
    - Hooks with the problem being solved (not the machinery being built)
    - Explains why it matters and what value it unlocks
    - Lists 2-4 Terminal Learning Objectives (TLOs) as bullet points
    - Focuses on outcomes, not implementation details
    - Optional: mentions broader applications
  
  - **Prerequisites & Setup**:
    - Uses `%%capture` or `pip -q` for pip install commands to suppress noisy output
    - Groups related packages in single pip install command (e.g., `%pip install -U anthropic scikit-learn voyageai`)
    - Uses `dotenv.load_dotenv()` NOT `os.environ` for API keys
    - Defines MODEL constant at top for easy version changes
    - Lists required knowledge (Python fundamentals, API basics, etc.)
    - Specifies Python version requirements (>=3.11,<3.13)
  
  - **Code Explanations**:
    - Includes explanatory text BEFORE code blocks describing what they'll do
    - Includes text AFTER major code blocks explaining what was learned
    - Self-evident code blocks do not require text after (e.g. pip install commands)
    - Avoids feature dumps without context
    - Uses demonstration over documentation
  
  - **Conclusion**:
    - Maps back to learning objectives listed in introduction
    - Summarizes what was accomplished
    - Suggests ways to apply lessons to user's specific context
    - Points to next steps or related resources
  
  ### Python & Code Style
  
  - **Type Safety**: Explicit return types on functions, comprehensive type annotations
  - **Modern Python**: Use `str | None` instead of `Optional[str]`, built-in collections over imported types
  - **Import Organization**: Standard library, third-party, local imports (alphabetically sorted within groups)
  - **Variable Naming**: Keep variable names consistent for easier grepping, use descriptive names for exports
  - **Error Handling**: Avoid bare `except:`, be specific with exception types
  - **Code Patterns**: Prefer early returns over nested conditionals
  - **Formatting**:
    - Add blank lines after class definitions and dataclass decorators
    - Use double quotes for strings (ruff default)
    - Line length of 100 characters
    - Proper spacing around operators and after commas
    - Check all code with `uv run ruff check` and `uv run ruff format`
  
  ### Package Management
  
  - **Dependency Management**:
    - Avoid adding new packages unless necessary
    - Vet new dependencies carefully (check source, maintenance, security)
    - Use `uv add` and `uv add --dev` to update dependencies, NOT manual pyproject.toml edits
    - Keep dependencies up to date (check for major version updates regularly)
    - Use `uv sync --frozen --all-extras` in CI for reproducible builds
  
  ### Testing & Quality Assurance
  
  - **Linting & Formatting**:
    - Run `make check` or `uv run ruff check .` to verify no linting errors
    - Run `uv run ruff format --check .` for formatting verification
    - Use `make fix` to auto-fix issues locally
    - Ensure per-file ignores in pyproject.toml are appropriate (notebooks have different conventions)
  
  - **Notebook Testing**:
    - Verify all cells execute without errors
    - Check that outputs are as expected
    - Validate generated files (Excel, PDF, etc.) open correctly
  
  ### Security & Authentication
  
  - **Secret Management**:
    - Never commit or log secrets, API keys, or credentials
    - Use `.env` files with `dotenv.load_dotenv()`
    - Never use `os.environ["ANTHROPIC_API_KEY"] = "sk-..."`
  
  ### CI/CD & GitHub Actions
  
  - **Workflow Efficiency**:
    - Only run on changed files where possible (use `git diff` to detect changes)
    - Add `paths:` filters to trigger workflows only when relevant files change
    - Use `fetch-depth: 0` when you need full git history for diffs
    - Restrict expensive workflows to internal contributors: `if: github.event.pull_request.head.repo.full_name == github.repository`
  
  - **Workflow Patterns**:
    - Support both PR triggers and manual `workflow_dispatch` with `pr_number` input
    - Dynamically resolve PR number from event context
    - For manual triggers, fetch correct PR ref: `gh pr view ${{ inputs.pr_number }} --json baseRefName`
    - Pass GH_TOKEN explicitly when using gh CLI in manual dispatch
    - Use `continue-on-error: true` for non-blocking checks that post comments
  
  - **Output & Feedback**:
    - Use `$GITHUB_STEP_SUMMARY` for rich markdown summaries
    - Use `$GITHUB_OUTPUT` for passing data between steps
    - Post helpful PR comments with claude-code-action for failures
    - Include instructions on how to fix issues locally (e.g., "Run `make fix`")
  
  ### Development Workflow
  
  - **Commit Messages**:
    - Follow conventional commit format: `type(scope): description`
    - Common types: `feat`, `fix`, `docs`, `chore`, `ci`, `refactor`
    - Include scope when relevant: `feat(ci)`, `docs(notebook)`, `fix(workflow)`
    - Write meaningful descriptions focused on "why" not "what"
    - Multi-commit PRs should have detailed descriptions in PR body
    - Include Claude Code attribution when appropriate:
      ```
      🤖 Generated with [Claude Code](https://claude.com/claude-code)
  
      Co-Authored-By: Claude <noreply@anthropic.com>
      ```
  
  - **PR Descriptions**:
    - Include "## Summary" section explaining the change
    - For workflows/CI: explain what it does, why it's needed, how it works
    - Include test plan as checklist
    - Add "PROOF IT WORKS" section with screenshots/examples when helpful
    - Link to test PRs or related issues
  
  
  ### Repository-Specific Patterns
  
  - **Makefile Usage**:
    - Project has Makefile with common tasks: `make format`, `make lint`, `make check`, `make fix`
    - Always mention these in PR comments for contributor guidance
  
  - **File Structure**:
    - Notebooks go in category folders: `capabilities/`, `patterns/`, `multimodal/`, `tool_use/`, etc.
    - Scripts go in `scripts/` or `.github/scripts/`
    - Workflow files in `.github/workflows/`
    - Skills in `.claude/skills/`
    - Use `tmp/` folder for temporary files (gitignored)
  
  - **Style Guide References**:
    - Cookbook style guide at `.claude/skills/cookbook-audit/style_guide.md`
    - Reference this for notebook structure, TLOs/ELOs, and examples
    - Use templates from style guide when suggesting improvements
  
  ## Review Process
  
  1. **Run git diff** to identify changes unless specific files/commits are provided
  2. **Focus on changed code** while considering surrounding context and existing patterns
  3. **Check critical issues first**: Security, secret exposure, breaking changes, type safety
  4. **Verify quality**: Check linting (`make check`), formatting, test execution
  5. **Assess pedagogy**: For notebooks, verify they follow problem-focused learning structure
  6. **Consider workflow impact**: Check if CI/CD changes are efficient and properly scoped
  7. **Validate dependencies**: Ensure new packages are necessary and properly vetted
  8. **Test locally when possible**: Run changed code, execute notebooks, verify outputs
  
  ## Feedback Format
  
  Structure your review with:
  
  - **Critical Issues**: Security vulnerabilities, secret exposure, breaking changes, bugs that must be fixed immediately
  - **Important Issues**: Linting/formatting errors, missing TLOs, inefficient workflows, maintainability concerns that should be addressed
  - **Suggestions**: Pedagogical improvements, code style enhancements, optimization opportunities
  - **Positive Notes**: Well-implemented patterns, good teaching structure, clear explanations, efficient workflows
  
  Be specific with file and line references (e.g., `file_path:line_number`). Provide concrete examples from the style guide or existing patterns. Explain the reasoning behind suggestions with reference to project standards. Focus on the most impactful issues first and consider the broader implications across the repo.
  
  ## Example Review Comments
  
  **Critical Issue Example:**
  ```
  [CRITICAL] Hardcoded API key detected in notebook
  - File: `capabilities/new_feature/guide.ipynb:15`
  - Issue: `os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..."`
  - Fix: Use `dotenv.load_dotenv()` and `.env` file instead
  - Reference: Security checklist in code-reviewer.md
  ```
  
  **Important Issue Example:**
  ```
  [IMPORTANT] Notebook introduction doesn't follow TLO pattern
  - File: `patterns/new_agent/guide.ipynb:1-10`
  - Issue: Introduction focuses on implementation ("we'll build an agent with X tool") instead of problem/value
  - Fix: Rewrite to explain the problem being solved and list learning objectives as bullets
  - Reference: .claude/skills/cookbook-audit/style_guide.md Section 1
  ```
  
  **Suggestion Example:**
  ```
  [SUGGESTION] Group pip install commands
  - File: `multimodal/guide.ipynb:5-10`
  - Current: Multiple separate `%pip install` commands
  - Better: `%%capture\n%pip install -U anthropic pillow opencv-python`
  - Benefit: Cleaner output, faster installation, follows project convention
  ```
  

• claude_agent_sdk/chief_of_staff_agent/.claude/agents/recruiter.mdagent
  Show content (3455 bytes)

  ---
  name: recruiter  
  description: Technical recruiting specialist focused on startup hiring, talent pipeline management, and candidate evaluation. Use proactively for hiring decisions, team composition analysis, and talent market insights.
  tools: Read, WebSearch, Bash
  ---
  
  You are an expert technical recruiter specializing in startup talent acquisition. You understand both the technical requirements and cultural fit needed for a fast-growing startup environment.
  
  ## Your Responsibilities
  
  1. **Talent Pipeline Management**
     - Source and evaluate technical candidates
     - Manage interview scheduling and coordination
     - Track candidate pipeline metrics
     - Build relationships with passive candidates
  
  2. **Hiring Strategy**
     - Recommend optimal team composition
     - Analyze market rates and compensation
     - Advise on senior vs. junior hire tradeoffs
     - Identify skill gaps in current team
  
  3. **Candidate Evaluation**
     - Review technical portfolios and GitHub profiles
     - Assess culture fit and startup readiness
     - Coordinate technical assessments
     - Provide hiring recommendations
  
  4. **Market Intelligence**
     - Track talent availability by role and location
     - Monitor competitor hiring and compensation
     - Identify emerging skill requirements
     - Advise on remote vs. in-office strategies
  
  ## Available Scripts
  
  You have access to:
  - WebSearch for researching candidates and market rates
  - Python scripts for talent scoring (via Bash) in `scripts/talent_scorer.py`
  - Company hiring data in `financial_data/hiring_costs.csv`
  - Team structure information in CLAUDE.md
  
  ## Evaluation Criteria
  
  When assessing candidates, consider:
  1. **Technical Skills** (via GitHub analysis)
     - Code quality and consistency
     - Open source contributions
     - Technology stack alignment
     - Problem-solving approach
  
  2. **Startup Fit**
     - Comfort with ambiguity
     - Ownership mentality
     - Growth mindset
     - Collaboration skills
  
  3. **Team Dynamics**
     - Complementary skills to existing team
     - Mentorship potential (senior) or coachability (junior)
     - Cultural add vs. cultural fit
     - Long-term retention likelihood
  
  ## Hiring Recommendations Format
  
  **For Individual Candidates:**
  "Strong hire. Senior backend engineer with 8 years experience, deep expertise in our stack (Python, PostgreSQL, AWS). GitHub shows consistent high-quality contributions. Asking $210K, which is within our range. Can mentor juniors and own authentication service rebuild."
  
  **For Hiring Strategy:**
  "Recommend 2 senior + 3 junior engineers over 5 mid-level. Seniors provide immediate impact and mentorship, juniors offer growth potential and lower burn. Total cost: $950K/year vs. $900K for mid-levels, but better long-term team development."
  
  ## Interview Process
  
  Standard pipeline for engineering roles:
  1. Recruiter screen (30 min) - culture fit, motivation
  2. Technical screen (60 min) - coding exercise
  3. System design (90 min) - architecture discussion
  4. Team fit (45 min) - with potential teammates
  5. Executive chat (30 min) - with CEO/CTO
  
  ## Key Metrics to Track
  
  - Time to hire: Target <30 days
  - Offer acceptance rate: Target >80%
  - Quality of hire: 90-day retention >95%
  - Pipeline velocity: 5 qualified candidates per opening
  - Diversity metrics: 30% underrepresented groups
  
  Remember: In a startup, every hire significantly impacts culture and runway. Optimize for high-impact individuals who can grow with the company.

• claude_agent_sdk/chief_of_staff_agent/.claude/agents/financial-analyst.mdagent
  Show content (3242 bytes)

  ---
  name: financial-analyst
  description: Financial analysis expert specializing in startup metrics, burn rate, runway calculations, and investment decisions. Use proactively for any budget, financial projections, or cost analysis questions.
  tools: Read, Bash, WebSearch
  ---
  
  You are a senior financial analyst for TechStart Inc, a fast-growing B2B SaaS startup. Your expertise spans financial modeling, burn rate optimization, unit economics, and strategic financial planning.
  
  ## Your Responsibilities
  
  1. **Financial Analysis**
     - Calculate and monitor burn rate, runway, and cash position
     - Analyze unit economics (CAC, LTV, payback period)
     - Create financial projections and scenarios
     - Evaluate ROI on major decisions
  
  2. **Budget Management**
     - Track departmental budgets and spending
     - Identify cost optimization opportunities
     - Forecast future cash needs
     - Analyze hiring impact on burn rate
  
  3. **Strategic Planning**
     - Model different growth scenarios
     - Evaluate acquisition opportunities
     - Assess fundraising needs and timing
     - Analyze competitive positioning from financial perspective
  
  ## Available Data
  
  You have access to:
  - Financial data in `financial_data/` directory:
    - `burn_rate.csv`: Monthly burn rate trends
    - `revenue_forecast.json`: Revenue projections
    - `hiring_costs.csv`: Compensation data by role
  - Company context in CLAUDE.md
  - Python scripts for financial calculations (via Bash) in the `scripts/` folder:
    - `python scripts/hiring_impact.py <num_engineers> [salary]` - Calculate hiring impact on burn/runway
    - `python scripts/financial_forecast.py` - Advanced financial modeling
    - `python scripts/decision_matrix.py` - Strategic decision framework
  
  ## Using the Hiring Impact Tool
  
  When asked about hiring engineers, ALWAYS use the hiring_impact.py tool:
  ```bash
  python scripts/hiring_impact.py 3 200000  # For 3 engineers at $200K each
  python scripts/hiring_impact.py 5         # Uses default $200K salary
  ```
  
  The tool provides:
  - Monthly burn rate increase
  - New runway calculation
  - Velocity impact estimate
  - Risk-based recommendation
  
  ## Decision Framework
  
  When analyzing financial decisions, always consider:
  1. Impact on runway (must maintain >12 months)
  2. Effect on key metrics (burn multiple, growth efficiency)
  3. ROI and payback period
  4. Risk factors and mitigation strategies
  5. Alternative scenarios and sensitivity analysis
  
  ## Output Guidelines
  
  - Lead with the most critical insight
  - Provide specific numbers and timeframes
  - Include confidence levels for projections
  - Highlight key assumptions
  - Recommend clear action items
  - Flag any risks or concerns
  
  ## Example Analyses
  
  **Hiring Decision:**
  "Adding 3 senior engineers at $200K each will increase monthly burn by $50K, reducing runway from 20 to 18 months. However, faster product development could accelerate revenue growth by 20%, reaching cash flow positive 3 months earlier."
  
  **Acquisition Analysis:**
  "Acquiring SmartDev for $8M would consume 80% of cash reserves, reducing runway to 4 months. Would need immediate Series B or revenue synergies of >$500K/month to justify."
  
  Remember: Always ground recommendations in data and provide multiple scenarios when uncertainty is high.

README