以下为本文档的中文说明Cookbook 审计技能是一个专门用于审查 Anthropic Cookbook 笔记本的质量评估工具基于预定义的评分标准进行系统性评审。它的核心功能包括对照风格指南评估笔记本质量、提供详细评分和改进建议、确保内容符合教学标准。使用场景是在需要对 Cookbook 笔记本进行审阅或审计时触发。该技能要求首先读取 style_guide.md 文件来了解权威模板和标准然后按照系统化的审计流程操作。风格指南提供了详细的模板和示例涵盖问题导向的引言包含终端学习目标和使能学习目标、前置条件和环境设置模式、核心内容结构以及映射回学习目标的结论。审计工作流程包括阅读风格指南了解标准、按评分指南逐项打分、提供改进建议、生成综合审计报告。核心特点在于教育导向和标准化评审。它不仅仅是一个内容检查工具更是一个教学质量保证系统通过结构化的学习目标和系统的内容评估确保每个 Cookbook 笔记本都能有效地传递知识和技能。该技能的价值不仅体现在直接的功能实现上还在于它与现有技术生态系统的良好兼容性和集成能力。无论是作为独立工具使用还是嵌入到更大的工作流中它都能发挥出应有的作用。通过遵循标准化的接口规范和协议它减少了系统集成过程中的摩擦点让用Cookbook AuditInstructionsReview the requested Cookbook notebook using the guidelines and rubrics instyle_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 patternsCore content structureConclusions that map back to learning objectivesIMPORTANT: Always readstyle_guide.mdfirst before conducting an audit. The style guide contains the canonical templates and good/bad examples to reference.WorkflowFollow these steps for a comprehensive audit:Read the style guide: First reviewstyle_guide.mdto understand current best practicesIdentify the notebook: Ask user for path if not providedRun automated checks: Usepython3 validate_notebook.py pathto catch technical issues and generate markdownThe script automatically runs detect-secrets to scan for hardcoded API keys and credentialsUses custom patterns defined inscripts/detect-secrets/plugins.pyChecks against baseline atscripts/detect-secrets/.secrets.baselineReview markdown output: The script generates a markdown file in thetmp/folder for easier review (saves context vs raw .ipynb)The tmp/ folder is gitignored to avoid committing review artifactsMarkdown includes code cells but excludes outputs for cleaner reviewManual review: Read through the markdown version evaluating against style guide and rubricScore each dimension: Apply scoring guidelines objectivelyGenerate report: Follow the audit report format belowProvide specific examples: Show concrete improvements with line references using the style guide templatesAudit Report FormatPresent your audit using this structure:Executive SummaryOverall Score: X/20Key Strengths(2-3 bullet points)Critical Issues(2-3 bullet points)Detailed Scoring1. 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 ChecklistUse 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 builtOptional: mentions broader applications (1 sentence)Prerequisites Setup(See style_guide.md Section 2)Lists required knowledge clearlyLists required tools (Python version, API keys)Mentions recommended background if applicableUses %%capture for pip install to suppress outputUses dotenv.load_dotenv() not os.environDefines MODEL constant at topGroups related installs in single commandStructure OrganizationHas logical section progressionEach section teaches through demonstrationCode blocks have explanatory text before themIncludes what we learned after code blocksUses headers to break up sectionsConclusion(See style_guide.md Section 4)Maps back to learning objectivesSummarizes what was accomplishedSuggests ways to apply lessons to user’s contextPoints to next steps or related resourcesCode QualityAll code blocks have explanatory text before themNo hardcoded API keys (automatically checked by detect-secrets)Meaningful variable namesComments explain “why” not “what”Follows language best practicesModel name defined as constant at top of notebookOutput Managementpip install logs suppressed with %%captureNo verbose debug outputShows relevant API responsesStack traces only when demonstrating error handlingContent QualityExplains why approaches workDiscusses when to use this approachMentions limitations/considerationsProvides transferable knowledgeAppropriate model selectionTechnical RequirementsExecutable without modification (except API keys)Uses non-deprecated API patternsUses 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 notebookIncludes dependency specificationsAssigned to primary categoryHas relevant tagsContent Philosophy: Action UnderstandingCookbooks 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 codeProblem-first framing: Lead with the problem being solved and value delivered, not the machineryBuilder’s perspective: Written from the user’s point of view, solving real problemsAgency-building: Help users understand why approaches work, not just howTransferable knowledge: Teach patterns and principles that apply beyond the specific exampleCritical thinking: Encourage users to question outputs, recognize limitations, make informed choicesLearning contracts: State learning objectives upfront, then map back to them in conclusionsWhat Makes a Good CookbookA 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 NOTCookbooks 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 GuidelinesVoice ToneEducational and agency-buildingProfessional but approachableRespectful of user intelligence and timeEither second person (“you”) or first person plural (“we”) - be consistent within a notebookWriting QualityClear, concise explanationsActive voice preferredShort paragraphs (3-5 sentences)Avoid jargon without definitionUse headers to break up sectionsCode PresentationAlways explain before showing: Every code block should be preceded by explanatory textExplain after running: Include what we learned after code blocks executeComments explain why, not what: Use meaningful variable namesUse constants: Define MODEL as a constant at the topGood habits: Usedotenv.load_dotenv()instead ofos.environOutput HandlingRemove extraneous outputwith %%capture:pip install logs (always suppress these)Verbose debug statementsLengthy stack traces (unless demonstrating error handling)Show relevant output:API responses that demonstrate functionalityExamples of successful executionStructural RequirementsSee style_guide.md for detailed templates and examples1. 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 capabilitiesInclude context/constraintsOptional: 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 neededRequired Tools: Python version, API keys with linksRecommended: Optional background that helpsSetup: Step-by-step with explanationsUse%%capturefor pip installsUsedotenv.load_dotenv()notos.environDefineMODELconstant at top3. Main Content (Required)Organized by logical steps or phases, each with:Clear section headersExplanatory text before code blocks(what we’re about to do)Code examplesExplanatory 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 objectivesWhat was accomplished: Summary of key pointsApplication guidance: How to apply lessons to user’s contextNext 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 SectionsHow It Works: Brief explanation of underlying mechanismWhen to Use This: Appropriate use cases and contextsLimitations Considerations: Caveats, failure modes, constraintsTroubleshooting: Common issues and solutionsVariations: Alternative approaches or extensionsPerformance Notes: Optimization considerationsFurther Reading: Links to relevant docs, papers, or deeper explanationsCommon Anti-Patterns to FlagRefer 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 objectivesSetup Anti-Patterns❌ Noisy pip install output without%%capture❌ Multiple separate pip install commands❌ Usingos.environ[API_KEY] your_keyinstead of dotenv❌ Hardcoding model names throughout instead of using a MODEL constant✅ Clean setup with grouped installs, dotenv, and constantsCode 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 context3e:[“ , ,,L41”,null,{“content”:“$42”,“frontMatter”:{“name”:“cookbook-audit”,“description”:“Audit an Anthropic Cookbook notebook based on a rubric. Use whenever a notebook review or audit is requested.”}}]