claude-mpm 4.25.10__py3-none-any.whl → 5.1.8__py3-none-any.whl

claude_mpm/skills/bundled/main/internal-comms/SKILL.md

@@ -1,43 +0,0 @@
----
-name: internal-comms
-description: A set of resources to help me write all kinds of internal communications, using the formats that my company likes to use. Claude should use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.).
-license: Complete terms in LICENSE.txt
-progressive_disclosure:
-  entry_point:
-    summary: "Write internal communications using company-specific formats and guidelines"
-    when_to_use: "Writing 3P updates, newsletters, FAQs, status reports, leadership updates, project updates, or incident reports"
-    quick_start: |
-      1. Identify communication type (3P update, newsletter, FAQ, etc.)
-      2. Load appropriate guideline from examples/ directory
-      3. Follow specific instructions for formatting, tone, and content
-      Available: examples/3p-updates.md, examples/company-newsletter.md, examples/faq-answers.md, examples/general-comms.md
-    note: "Already optimal at 32 lines - examples/ directory provides all format guidelines, no fragmentation needed"
-  references: []
----
-
-## When to use this skill
-To write internal communications, use this skill for:
-- 3P updates (Progress, Plans, Problems)
-- Company newsletters
-- FAQ responses
-- Status reports
-- Leadership updates
-- Project updates
-- Incident reports
-
-## How to use this skill
-
-To write any internal communication:
-
-1. **Identify the communication type** from the request
-2. **Load the appropriate guideline file** from the `examples/` directory:
-    - `examples/3p-updates.md` - For Progress/Plans/Problems team updates
-    - `examples/company-newsletter.md` - For company-wide newsletters
-    - `examples/faq-answers.md` - For answering frequently asked questions
-    - `examples/general-comms.md` - For anything else that doesn't explicitly match one of the above
-3. **Follow the specific instructions** in that file for formatting, tone, and content gathering
-
-If the communication type doesn't match any existing guideline, ask for clarification or more context about the desired format.
-
-## Keywords
-3P updates, company newsletter, company comms, weekly update, faqs, common questions, updates, internal comms

claude_mpm/skills/bundled/main/internal-comms/examples/3p-updates.md

@@ -1,47 +0,0 @@
-## Instructions
-You are being asked to write a 3P update. 3P updates stand for "Progress, Plans, Problems." The main audience is for executives, leadership, other teammates, etc. They're meant to be very succinct and to-the-point: think something you can read in 30-60sec or less. They're also for people with some, but not a lot of context on what the team does.
-
-3Ps can cover a team of any size, ranging all the way up to the entire company. The bigger the team, the less granular the tasks should be. For example, "mobile team" might have "shipped feature" or "fixed bugs," whereas the company might have really meaty 3Ps, like "hired 20 new people" or "closed 10 new deals." 
-
-They represent the work of the team across a time period, almost always one week. They include three sections:
-1) Progress: what the team has accomplished over the next time period. Focus mainly on things shipped, milestones achieved, tasks created, etc.
-2) Plans: what the team plans to do over the next time period. Focus on what things are top-of-mind, really high priority, etc. for the team.
-3) Problems: anything that is slowing the team down. This could be things like too few people, bugs or blockers that are preventing the team from moving forward, some deal that fell through, etc.
-
-Before writing them, make sure that you know the team name. If it's not specified, you can ask explicitly what the team name you're writing for is.
-
-
-## Tools Available
-Whenever possible, try to pull from available sources to get the information you need:
-- Slack: posts from team members with their updates - ideally look for posts in large channels with lots of reactions
-- Google Drive: docs written from critical team members with lots of views
-- Email: emails with lots of responses of lots of content that seems relevant
-- Calendar: non-recurring meetings that have a lot of importance, like product reviews, etc.
-
-
-Try to gather as much context as you can, focusing on the things that covered the time period you're writing for:
-- Progress: anything between a week ago and today
-- Plans: anything from today to the next week
-- Problems: anything between a week ago and today
-
-
-If you don't have access, you can ask the user for things they want to cover. They might also include these things to you directly, in which case you're mostly just formatting for this particular format.
-
-## Workflow
-
-1. **Clarify scope**: Confirm the team name and time period (usually past week for Progress/Problems, next
-week for Plans)
-2. **Gather information**: Use available tools or ask the user directly
-3. **Draft the update**: Follow the strict formatting guidelines
-4. **Review**: Ensure it's concise (30-60 seconds to read) and data-driven
-
-## Formatting
-
-The format is always the same, very strict formatting. Never use any formatting other than this. Pick an emoji that is fun and captures the vibe of the team and update.
-
-[pick an emoji] [Team Name] (Dates Covered, usually a week)
-Progress: [1-3 sentences of content]
-Plans: [1-3 sentences of content]
-Problems: [1-3 sentences of content]
-
-Each section should be no more than 1-3 sentences: clear, to the point. It should be data-driven, and generally include metrics where possible. The tone should be very matter-of-fact, not super prose-heavy.

claude_mpm/skills/bundled/main/internal-comms/examples/company-newsletter.md

@@ -1,65 +0,0 @@
-## Instructions
-You are being asked to write a company-wide newsletter update. You are meant to summarize the past week/month of a company in the form of a newsletter that the entire company will read. It should be maybe ~20-25 bullet points long. It will be sent via Slack and email, so make it consumable for that.
-
-Ideally it includes the following attributes:
-- Lots of links: pulling documents from Google Drive that are very relevant, linking to prominent Slack messages in announce channels and from executives, perhgaps referencing emails that went company-wide, highlighting significant things that have happened in the company.
-- Short and to-the-point: each bullet should probably be no longer than ~1-2 sentences
-- Use the "we" tense, as you are part of the company. Many of the bullets should say "we did this" or "we did that"
-
-## Tools to use
-If you have access to the following tools, please try to use them. If not, you can also let the user know directly that their responses would be better if they gave them access.
-
-- Slack: look for messages in channels with lots of people, with lots of reactions or lots of responses within the thread
-- Email: look for things from executives that discuss company-wide announcements
-- Calendar: if there were meetings with large attendee lists, particularly things like All-Hands meetings, big company announcements, etc. If there were documents attached to those meetings, those are great links to include.
-- Documents: if there were new docs published in the last week or two that got a lot of attention, you can link them. These should be things like company-wide vision docs, plans for the upcoming quarter or half, things authored by critical executives, etc.
-- External press: if you see references to articles or press we've received over the past week, that could be really cool too.
-
-If you don't have access to any of these things, you can ask the user for things they want to cover. In this case, you'll mostly just be polishing up and fitting to this format more directly.
-
-## Sections
-The company is pretty big: 1000+ people. There are a variety of different teams and initiatives going on across the company. To make sure the update works well, try breaking it into sections of similar things. You might break into clusters like {product development, go to market, finance} or {recruiting, execution, vision}, or {external news, internal news} etc. Try to make sure the different areas of the company are highlighted well.
-
-## Prioritization
-Focus on:
-- Company-wide impact (not team-specific details)
-- Announcements from leadership
-- Major milestones and achievements
-- Information that affects most employees
-- External recognition or press
-
-Avoid:
-- Overly granular team updates (save those for 3Ps)
-- Information only relevant to small groups
-- Duplicate information already communicated
-
-## Example Formats
-
-:megaphone: Company Announcements
-- Announcement 1
-- Announcement 2
-- Announcement 3
-
-:dart: Progress on Priorities
-- Area 1
-    - Sub-area 1
-    - Sub-area 2
-    - Sub-area 3
-- Area 2
-    - Sub-area 1
-    - Sub-area 2
-    - Sub-area 3
-- Area 3
-    - Sub-area 1
-    - Sub-area 2
-    - Sub-area 3
-
-:pillar: Leadership Updates
-- Post 1
-- Post 2
-- Post 3
-
-:thread: Social Updates
-- Update 1
-- Update 2
-- Update 3

claude_mpm/skills/bundled/main/internal-comms/examples/faq-answers.md

@@ -1,30 +0,0 @@
-## Instructions
-You are an assistant for answering questions that are being asked across the company. Every week, there are lots of questions that get asked across the company, and your goal is to try to summarize what those questions are. We want our company to be well-informed and on the same page, so your job is to produce a set of frequently asked questions that our employees are asking and attempt to answer them. Your singular job is to do two things:
-
-- Find questions that are big sources of confusion for lots of employees at the company, generally about things that affect a large portion of the employee base
-- Attempt to give a nice summarized answer to that question in order to minimize confusion.
-
-Some examples of areas that may be interesting to folks: recent corporate events (fundraising, new executives, etc.), upcoming launches, hiring progress, changes to vision or focus, etc.
-
-
-## Tools Available
-You should use the company's available tools, where communication and work happens. For most companies, it looks something like this:
-- Slack: questions being asked across the company - it could be questions in response to posts with lots of responses, questions being asked with lots of reactions or thumbs up to show support, or anything else to show that a large number of employees want to ask the same things
-- Email: emails with FAQs written directly in them can be a good source as well
-- Documents: docs in places like Google Drive, linked on calendar events, etc. can also be a good source of FAQs, either directly added or inferred based on the contents of the doc
-
-## Formatting
-The formatting should be pretty basic:
-
-- *Question*: [insert question - 1 sentence]
-- *Answer*: [insert answer - 1-2 sentence]
-
-## Guidance
-Make sure you're being holistic in your questions. Don't focus too much on just the user in question or the team they are a part of, but try to capture the entire company. Try to be as holistic as you can in reading all the tools available, producing responses that are relevant to all at the company.
-
-## Answer Guidelines
-- Base answers on official company communications when possible
-- If information is uncertain, indicate that clearly
-- Link to authoritative sources (docs, announcements, emails)
-- Keep tone professional but approachable
-- Flag if a question requires executive input or official response

claude_mpm/skills/bundled/main/internal-comms/examples/general-comms.md

@@ -1,16 +0,0 @@
-  ## Instructions
-  You are being asked to write internal company communication that doesn't fit into the standard formats (3P
-  updates, newsletters, or FAQs).
-
-  Before proceeding:
-  1. Ask the user about their target audience
-  2. Understand the communication's purpose
-  3. Clarify the desired tone (formal, casual, urgent, informational)
-  4. Confirm any specific formatting requirements
-
-  Use these general principles:
-  - Be clear and concise
-  - Use active voice
-  - Put the most important information first
-  - Include relevant links and references
-  - Match the company's communication style

claude_mpm/skills/bundled/main/mcp-builder/LICENSE.txt

@@ -1,202 +0,0 @@
-
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
-
-   END OF TERMS AND CONDITIONS
-
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright [yyyy] [name of copyright owner]
-
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.

claude_mpm/skills/bundled/main/mcp-builder/SKILL.md

@@ -1,160 +0,0 @@
----
-name: mcp-builder
-description: Create high-quality MCP servers that enable LLMs to effectively interact with external services. Use when building MCP integrations for APIs or services in Python (FastMCP) or Node/TypeScript (MCP SDK).
-license: Complete terms in LICENSE.txt
-progressive_disclosure:
-  entry_point:
-    summary: "Build agent-friendly MCP servers through research-driven design, thoughtful implementation, and evaluation-based iteration"
-    when_to_use: "When integrating external APIs/services via MCP protocol. Prioritize agent workflows over API wrappers, optimize for context efficiency, design actionable errors."
-    quick_start: "1. Research protocol & API docs 2. Plan agent-centric tools 3. Implement with validation 4. Create evaluations 5. Iterate based on agent feedback"
-  references:
-    - design_principles.md
-    - workflow.md
-    - mcp_best_practices.md
-    - python_mcp_server.md
-    - node_mcp_server.md
-    - evaluation.md
----
-
-# MCP Server Development Guide
-
-## Overview
-
-Build high-quality MCP (Model Context Protocol) servers that enable LLMs to accomplish real-world tasks through well-designed tools. Quality is measured not by API coverage, but by how effectively agents can use your tools to complete realistic workflows.
-
-**Core insight:** MCP servers expose tools for AI agents, not human users. Design for agent constraints (limited context, no visual UI, workflow-oriented) rather than human convenience.
-
-## When to Use This Skill
-
-Activate when:
-- Building MCP servers for external API integration
-- Adding tools to existing MCP servers
-- Improving MCP server tool design for better agent usability
-- Creating evaluations to test MCP server effectiveness
-- Debugging why agents struggle with your MCP tools
-
-**Language Support:**
-- Python: FastMCP framework (recommended for rapid development)
-- Node/TypeScript: MCP SDK (recommended for production services)
-
-## The Iron Law
-
-```
-DESIGN FOR AGENTS, NOT HUMANS
-
-Every tool must optimize for:
-- Context efficiency (agents have limited tokens)
-- Workflow completion (not just API calls)
-- Actionable errors (guide agents to success)
-- Natural task subdivision (how agents think)
-```
-
-If your tools are just thin API wrappers, you're violating the Iron Law.
-
-## Core Principles
-
-1. **Agent-Centric Design First**: Study design principles before coding. Tools should enable workflows, not mirror APIs.
-
-2. **Research-Driven Planning**: Load MCP docs, SDK docs, and exhaustive API documentation before writing code.
-
-3. **Evaluation-Based Iteration**: Create realistic evaluations early. Let agent feedback drive improvements.
-
-4. **Context Optimization**: Every response token matters. Default to concise, offer detailed when needed.
-
-5. **Actionable Errors**: Error messages should teach agents correct usage patterns.
-
-## Quick Start
-
-### Phase 1: Research and Planning (40% of effort)
-1. **Study Design Principles**: Load [design_principles.md](./reference/design_principles.md) to understand agent-centric design
-2. **Load Protocol Docs**: Fetch `https://modelcontextprotocol.io/llms-full.txt` for MCP specification
-3. **Study SDK Docs**: Load Python or TypeScript SDK documentation from GitHub
-4. **Study API Exhaustively**: Read ALL API documentation, endpoints, authentication, rate limits
-5. **Create Implementation Plan**: Define tools, shared utilities, pagination strategy, error handling
-
-See [workflow.md](./reference/workflow.md) for complete Phase 1 steps.
-
-### Phase 2: Implementation (30% of effort)
-1. **Setup Project**: Create structure following language-specific guide
-2. **Build Shared Utilities**: API helpers, error handlers, formatters BEFORE tools
-3. **Implement Tools**: Use Pydantic (Python) or Zod (TypeScript) for validation
-4. **Follow Best Practices**: Load language-specific guide for patterns
-
-See [workflow.md](./reference/workflow.md) for complete Phase 2 steps and language guides.
-
-### Phase 3: Review and Refine (15% of effort)
-1. **Code Quality Review**: Check DRY, composability, consistency, type safety
-2. **Test Build**: Verify syntax, imports, build process
-3. **Quality Checklist**: Use language-specific checklist
-
-See [workflow.md](./reference/workflow.md) for complete Phase 3 steps.
-
-### Phase 4: Create Evaluations (15% of effort)
-1. **Understand Purpose**: Evaluations test if agents can answer realistic questions using your tools
-2. **Create 10 Questions**: Complex, read-only, independent, verifiable questions
-3. **Verify Answers**: Solve yourself to ensure stability and correctness
-4. **Run Evaluation**: Use provided scripts to test agent effectiveness
-
-See [evaluation.md](./reference/evaluation.md) for complete evaluation guidelines.
-
-## Navigation
-
-### Core Design and Workflow
-- **[🎯 Design Principles](./reference/design_principles.md)** - Agent-centric design philosophy: workflows over APIs, context optimization, actionable errors, natural task subdivision. Read FIRST before implementation.
-
-- **[🔄 Complete Workflow](./reference/workflow.md)** - Detailed 4-phase development process with step-by-step instructions, decision trees, and when to load each reference file.
-
-### Universal MCP Guidelines
-- **[📋 MCP Best Practices](./reference/mcp_best_practices.md)** - Naming conventions, response formats, pagination, character limits, security, tool annotations, error handling. Applies to all MCP servers.
-
-### Language-Specific Implementation
-- **[🐍 Python Implementation](./reference/python_mcp_server.md)** - FastMCP patterns, Pydantic validation, async/await, complete examples, quality checklist. Load during Phase 2 for Python servers.
-
-- **[⚡ TypeScript Implementation](./reference/node_mcp_server.md)** - MCP SDK patterns, Zod validation, project structure, complete examples, quality checklist. Load during Phase 2 for TypeScript servers.
-
-### Evaluation and Testing
-- **[✅ Evaluation Guide](./reference/evaluation.md)** - Creating realistic questions, answer verification, XML format, running evaluations, interpreting results. Load during Phase 4.
-
-## Key Reminders
-
-- **Research First**: Spend 40% of time researching before coding
-- **Agent-Centric**: Design for AI workflows, not API completeness
-- **Context Efficient**: Every token counts - default concise, offer detailed
-- **Actionable Errors**: Guide agents to correct usage
-- **Shared Utilities**: Extract common code - avoid duplication
-- **Evaluation-Driven**: Create evals early, iterate based on feedback
-- **MCP Servers Block**: Never run servers directly - use evaluation harness or tmux
-
-## Red Flags - STOP
-
-If you catch yourself:
-- "Just wrapping these API endpoints directly"
-- "Returning all available data fields"
-- "Error message just says what failed" (not how to fix)
-- Starting implementation without reading design principles
-- Coding before loading MCP protocol documentation
-- Creating tools without knowing agent use cases
-- Skipping evaluation creation
-- Running `python server.py` directly (will hang forever)
-
-**ALL of these mean: STOP. Return to design principles and workflow.**
-
-## Integration with Other Skills
-
-- **systematic-debugging**: Debug MCP server issues methodically
-- **test-driven-development**: Create failing tests before implementation
-- **verification-before-completion**: Verify build succeeds before claiming completion
-- **defense-in-depth**: Add input validation at multiple layers
-
-## Real-World Impact
-
-From MCP server development experience:
-- Well-designed servers: 80-90% task completion rate by agents
-- API wrapper approach: 30-40% task completion rate
-- Context-optimized responses: 3x more information in same token budget
-- Actionable errors: 60% reduction in agent retry attempts
-- Evaluation-driven iteration: 2-3x improvement in agent success rate
-
----
-
-**Remember:** The quality of an MCP server is measured by how well it enables LLMs to accomplish realistic tasks, not by how comprehensively it wraps an API.