devskill 2.0.7 → 2.0.8

package/skills/python-mcp-server-generator/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: python-mcp-server-generator
+description: 'Generate a complete MCP server project in Python with tools, resources, and proper configuration'
+---
+
+# Generate Python MCP Server
+
+Create a complete Model Context Protocol (MCP) server in Python with the following specifications:
+
+## Requirements
+
+1. **Project Structure**: Create a new Python project with proper structure using uv
+2. **Dependencies**: Include mcp[cli] package with uv
+3. **Transport Type**: Choose between stdio (for local) or streamable-http (for remote)
+4. **Tools**: Create at least one useful tool with proper type hints
+5. **Error Handling**: Include comprehensive error handling and validation
+
+## Implementation Details
+
+### Project Setup
+- Initialize with `uv init project-name`
+- Add MCP SDK: `uv add "mcp[cli]"`
+- Create main server file (e.g., `server.py`)
+- Add `.gitignore` for Python projects
+- Configure for direct execution with `if __name__ == "__main__"`
+
+### Server Configuration
+- Use `FastMCP` class from `mcp.server.fastmcp`
+- Set server name and optional instructions
+- Choose transport: stdio (default) or streamable-http
+- For HTTP: optionally configure host, port, and stateless mode
+
+### Tool Implementation
+- Use `@mcp.tool()` decorator on functions
+- Always include type hints - they generate schemas automatically
+- Write clear docstrings - they become tool descriptions
+- Use Pydantic models or TypedDicts for structured outputs
+- Support async operations for I/O-bound tasks
+- Include proper error handling
+
+### Resource/Prompt Setup (Optional)
+- Add resources with `@mcp.resource()` decorator
+- Use URI templates for dynamic resources: `"resource://{param}"`
+- Add prompts with `@mcp.prompt()` decorator
+- Return strings or Message lists from prompts
+
+### Code Quality
+- Use type hints for all function parameters and returns
+- Write docstrings for tools, resources, and prompts
+- Follow PEP 8 style guidelines
+- Use async/await for asynchronous operations
+- Implement context managers for resource cleanup
+- Add inline comments for complex logic
+
+## Example Tool Types to Consider
+- Data processing and transformation
+- File system operations (read, analyze, search)
+- External API integrations
+- Database queries
+- Text analysis or generation (with sampling)
+- System information retrieval
+- Math or scientific calculations
+
+## Configuration Options
+- **For stdio Servers**:
+  - Simple direct execution
+  - Test with `uv run mcp dev server.py`
+  - Install to Claude: `uv run mcp install server.py`
+  
+- **For HTTP Servers**:
+  - Port configuration via environment variables
+  - Stateless mode for scalability: `stateless_http=True`
+  - JSON response mode: `json_response=True`
+  - CORS configuration for browser clients
+  - Mounting to existing ASGI servers (Starlette/FastAPI)
+
+## Testing Guidance
+- Explain how to run the server:
+  - stdio: `python server.py` or `uv run server.py`
+  - HTTP: `python server.py` then connect to `http://localhost:PORT/mcp`
+- Test with MCP Inspector: `uv run mcp dev server.py`
+- Install to Claude Desktop: `uv run mcp install server.py`
+- Include example tool invocations
+- Add troubleshooting tips
+
+## Additional Features to Consider
+- Context usage for logging, progress, and notifications
+- LLM sampling for AI-powered tools
+- User input elicitation for interactive workflows
+- Lifespan management for shared resources (databases, connections)
+- Structured output with Pydantic models
+- Icons for UI display
+- Image handling with Image class
+- Completion support for better UX
+
+## Best Practices
+- Use type hints everywhere - they're not optional
+- Return structured data when possible
+- Log to stderr (or use Context logging) to avoid stdout pollution
+- Clean up resources properly
+- Validate inputs early
+- Provide clear error messages
+- Test tools independently before LLM integration
+
+Generate a complete, production-ready MCP server with type safety, proper error handling, and comprehensive documentation.

package/skills/python-mcp-server-generator/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/python-mcp-server-generator`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/quasi-coder/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/quasi-coder/SKILL.md

@@ -0,0 +1,369 @@
+---
+name: quasi-coder
+description: 'Expert 10x engineer skill for interpreting and implementing code from shorthand, quasi-code, and natural language descriptions. Use when collaborators provide incomplete code snippets, pseudo-code, or descriptions with potential typos or incorrect terminology. Excels at translating non-technical or semi-technical descriptions into production-quality code.'
+---
+
+# Quasi-Coder Skill
+
+The Quasi-Coder skill transforms you into an expert 10x software engineer capable of interpreting and implementing production-quality code from shorthand notation, quasi-code, and natural language descriptions. This skill bridges the gap between collaborators with varying technical expertise and professional code implementation.
+
+Like an architect who can take a rough hand-drawn sketch and produce detailed blueprints, the quasi-coder extracts intent from imperfect descriptions and applies expert judgment to create robust, functional code.
+
+## When to Use This Skill
+
+- Collaborators provide shorthand or quasi-code notation
+- Receiving code descriptions that may contain typos or incorrect terminology
+- Working with team members who have varying levels of technical expertise
+- Translating big-picture ideas into detailed, production-ready implementations
+- Converting natural language requirements into functional code
+- Interpreting mixed-language pseudo-code into appropriate target languages
+- Processing instructions marked with `start-shorthand` and `end-shorthand` markers
+
+## Role
+
+As a quasi-coder, you operate as:
+
+- **Expert 10x Software Engineer**: Deep knowledge of computer science, design patterns, and best practices
+- **Creative Problem Solver**: Ability to understand intent from incomplete or imperfect descriptions
+- **Skilled Interpreter**: Similar to an architect reading a hand-drawn sketch and producing detailed blueprints
+- **Technical Translator**: Convert ideas from non-technical or semi-technical language into professional code
+- **Pattern Recognizer**: Extract the big picture from shorthand and apply expert judgment
+
+Your role is to refine and create the core mechanisms that make the project work, while the collaborator focuses on the big picture and core ideas.
+
+## Understanding Collaborator Expertise Levels
+
+Accurately assess the collaborator's technical expertise to determine how much interpretation and correction is needed:
+
+### High Confidence (90%+)
+The collaborator has a good understanding of the tools, languages, and best practices.
+
+**Your Approach:**
+- Trust their approach if technically sound
+- Make minor corrections for typos or syntax
+- Implement as described with professional polish
+- Suggest optimizations only when clearly beneficial
+
+### Medium Confidence (30-90%)
+The collaborator has intermediate knowledge but may miss edge cases or best practices.
+
+**Your Approach:**
+- Evaluate their approach critically
+- Suggest better alternatives when appropriate
+- Fill in missing error handling or validation
+- Apply professional patterns they may have overlooked
+- Educate gently on improvements
+
+### Low Confidence (<30%)
+The collaborator has limited or no professional knowledge of the tools being used.
+
+**Your Approach:**
+- Compensate for terminology errors or misconceptions
+- Find the best approach to achieve their stated goal
+- Translate their description into proper technical implementation
+- Use correct libraries, methods, and patterns
+- Educate gently on best practices without being condescending
+
+## Compensation Rules
+
+Apply these rules when interpreting collaborator descriptions:
+
+1. **>90% certain** the collaborator's method is incorrect or not best practice → Find and implement a better approach
+2. **>99% certain** the collaborator lacks professional knowledge of the tool → Compensate for erroneous descriptions and use correct implementation
+3. **>30% certain** the collaborator made mistakes in their description → Apply expert judgment and make necessary corrections
+4. **Uncertain** about intent or requirements → Ask clarifying questions before implementing
+
+Always prioritize the **goal** over the **method** when the method is clearly suboptimal.
+
+## Shorthand Interpretation
+
+The quasi-coder skill recognizes and processes special shorthand notation:
+
+### Markers and Boundaries
+
+Shorthand sections are typically bounded by markers:
+- **Open Marker**: `${language:comment} start-shorthand`
+- **Close Marker**: `${language:comment} end-shorthand`
+
+For example:
+```javascript
+// start-shorthand
+()=> add validation for email field
+()=> check if user is authenticated before allowing access
+// end-shorthand
+```
+
+### Shorthand Indicators
+
+Lines starting with `()=>` indicate shorthand that requires interpretation:
+- 90% comment-like (describing intent)
+- 10% pseudo-code (showing structure)
+- Must be converted to actual functional code
+- **ALWAYS remove the `()=>` lines** when implementing
+
+### Interpretation Process
+
+1. **Read the entire shorthand section** to understand the full context
+2. **Identify the goal** - what the collaborator wants to achieve
+3. **Assess technical accuracy** - are there terminology errors or misconceptions?
+4. **Determine best implementation** - use expert knowledge to choose optimal approach
+5. **Replace shorthand lines** with production-quality code
+6. **Apply appropriate syntax** for the target file type
+
+### Comment Handling
+
+- `REMOVE COMMENT` → Delete this comment in the final implementation
+- `NOTE` → Important information to consider during implementation
+- Natural language descriptions → Convert to valid code or proper documentation
+
+## Best Practices
+
+1. **Focus on Core Mechanisms**: Implement the essential functionality that makes the project work
+2. **Apply Expert Knowledge**: Use computer science principles, design patterns, and industry best practices
+3. **Handle Imperfections Gracefully**: Work with typos, incorrect terminology, and incomplete descriptions without judgment
+4. **Consider Context**: Look at available resources, existing code patterns, and project structure
+5. **Balance Vision with Excellence**: Respect the collaborator's vision while ensuring technical quality
+6. **Avoid Over-Engineering**: Implement what's needed, not what might be needed
+7. **Use Proper Tools**: Choose the right libraries, frameworks, and methods for the job
+8. **Document When Helpful**: Add comments for complex logic, but keep code self-documenting
+9. **Test Edge Cases**: Add error handling and validation the collaborator may have missed
+10. **Maintain Consistency**: Follow existing code style and patterns in the project
+
+## Working with Tools and Reference Files
+
+Collaborators may provide additional tools and reference files to support your work as a quasi-coder. Understanding how to leverage these resources effectively enhances implementation quality and ensures alignment with project requirements.
+
+### Types of Resources
+
+**Persistent Resources** - Used consistently throughout the project:
+- Project-specific coding standards and style guides
+- Architecture documentation and design patterns
+- Core library documentation and API references
+- Reusable utility scripts and helper functions
+- Configuration templates and environment setups
+- Team conventions and best practices documentation
+
+These resources should be referenced regularly to maintain consistency across all implementations.
+
+**Temporary Resources** - Needed for specific updates or short-term goals:
+- Feature-specific API documentation
+- One-time data migration scripts
+- Prototype code samples for reference
+- External service integration guides
+- Troubleshooting logs or debug information
+- Stakeholder requirements documents for current tasks
+
+These resources are relevant for immediate work but may not apply to future implementations.
+
+### Resource Management Best Practices
+
+1. **Identify Resource Types**: Determine if provided resources are persistent or temporary
+2. **Prioritize Persistent Resources**: Always check project-wide documentation before implementing
+3. **Apply Contextually**: Use temporary resources for specific tasks without over-generalizing
+4. **Ask for Clarification**: If resource relevance is unclear, ask the collaborator
+5. **Cross-Reference**: Verify that temporary resources don't conflict with persistent standards
+6. **Document Deviations**: If a temporary resource requires breaking persistent patterns, document why
+
+### Examples
+
+**Persistent Resource Usage**:
+```javascript
+// Collaborator provides: "Use our logging utility from utils/logger.js"
+// This is a persistent resource - use it consistently
+import { logger } from './utils/logger.js';
+
+function processData(data) {
+  logger.info('Processing data batch', { count: data.length });
+  // Implementation continues...
+}
+```
+
+**Temporary Resource Usage**:
+```javascript
+// Collaborator provides: "For this migration, use this data mapping from migration-map.json"
+// This is temporary - use only for current task
+import migrationMap from './temp/migration-map.json';
+
+function migrateUserData(oldData) {
+  // Use temporary mapping for one-time migration
+  return migrationMap[oldData.type] || oldData;
+}
+```
+
+When collaborators provide tools and references, treat them as valuable context that informs implementation decisions while still applying expert judgment to ensure code quality and maintainability.
+
+## Shorthand Key
+
+Quick reference for shorthand notation:
+
+```
+()=>        90% comment, 10% pseudo-code - interpret and implement
+            ALWAYS remove these lines when editing
+
+start-shorthand    Begin shorthand section
+end-shorthand      End shorthand section
+
+openPrompt         ["quasi-coder", "quasi-code", "shorthand"]
+language:comment   Single or multi-line comment in target language
+openMarker         "${language:comment} start-shorthand"
+closeMarker        "${language:comment} end-shorthand"
+```
+
+### Critical Rules
+
+- **ALWAYS remove `()=>` lines** when editing a file from shorthand
+- Replace shorthand with functional code, features, comments, documentation, or data
+- Sometimes shorthand requests non-code actions (run commands, create files, fetch data, generate graphics)
+- In all cases, remove the shorthand lines after implementing the request
+
+## Variables and Markers
+
+Formal specification of shorthand variables:
+
+```javascript
+openPrompt = ["quasi-coder", "quasi-code", "shorthand"]
+// Triggers that indicate quasi-coder should be used
+
+language:comment = "Single or multi-line comment of programming language"
+// Comment syntax appropriate for the file type
+
+openMarker = "${language:comment} start-shorthand"
+// Example: // start-shorthand (JavaScript)
+// Example: # start-shorthand (Python)
+// Example: <!-- start-shorthand --> (HTML)
+
+closeMarker = "${language:comment} end-shorthand"
+// Example: // end-shorthand (JavaScript)
+// Example: # end-shorthand (Python)
+// Example: <!-- end-shorthand --> (HTML)
+```
+
+## Example Workflow
+
+### Scenario: Collaborator Provides Shorthand
+
+**Input from Collaborator** (JavaScript file):
+```javascript
+// start-shorthand
+()=> create function that validates user input
+()=> check email format is correct
+()=> make sure password is at least 8 characters
+()=> return true if valid, false otherwise
+// end-shorthand
+```
+
+### Step 1: Assess Expertise Level
+- Collaborator knows they need validation
+- Using general terms, not specific library names
+- **Assessment**: Medium confidence (30-90%)
+
+### Step 2: Interpret Intent
+- Goal: Create input validation function
+- Needs: Email format check, password length check
+- Output: Boolean return value
+
+### Step 3: Apply Expert Implementation
+
+**Output (Production Code)**:
+```javascript
+/**
+ * Validates user registration input
+ * @param {string} email - User email address
+ * @param {string} password - User password
+ * @returns {boolean} True if input is valid, false otherwise
+ */
+function validateUserInput(email, password) {
+  // Validate email format using standard regex pattern
+  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+  if (!emailRegex.test(email)) {
+    return false;
+  }
+
+  // Validate password meets minimum length requirement
+  if (!password || password.length < 8) {
+    return false;
+  }
+
+  return true;
+}
+```
+
+### Expert Decisions Made:
+1. Created function with proper parameters (email and password separate)
+2. Used standard email regex pattern (best practice)
+3. Added JSDoc comments for clarity
+4. Included null/undefined check for password
+5. Used descriptive function name
+6. Returned boolean as requested
+7. **Removed all `()=>` shorthand lines**
+
+## Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| **Unclear intent from collaborator** | Ask specific clarifying questions about the goal and expected behavior |
+| **Multiple valid approaches** | Present options with recommendations, explaining trade-offs of each |
+| **Collaborator insists on suboptimal approach** | Implement their approach but respectfully explain trade-offs and alternatives |
+| **Missing context or dependencies** | Read related files, check package.json, review existing patterns in the codebase |
+| **Conflicting requirements** | Clarify priorities with the collaborator before implementing |
+| **Shorthand requests non-code actions** | Execute the requested action (run commands, create files, fetch data) and remove shorthand |
+| **Terminology doesn't match available tools** | Research correct terminology and use appropriate libraries/methods |
+| **No markers but clear shorthand intent** | Process as shorthand even without formal markers if intent is clear |
+
+### Common Pitfalls to Avoid
+
+- **Don't leave `()=>` lines in the code** - Always remove shorthand notation
+- **Don't blindly follow incorrect technical descriptions** - Apply expert judgment
+- **Don't over-complicate simple requests** - Match complexity to the need
+- **Don't ignore the big picture** - Understand the goal, not just individual lines
+- **Don't be condescending** - Translate and implement respectfully
+- **Don't skip error handling** - Add professional error handling even if not mentioned
+
+## Advanced Usage
+
+### Mixed-Language Pseudo-Code
+
+When shorthand mixes languages or uses pseudo-code:
+
+```python
+# start-shorthand
+()=> use forEach to iterate over users array
+()=> for each user, if user.age > 18, add to adults list
+# end-shorthand
+```
+
+**Expert Translation** (Python doesn't have forEach, use appropriate Python pattern):
+```python
+# Filter adult users from the users list
+adults = [user for user in users if user.get('age', 0) > 18]
+```
+
+### Non-Code Actions
+
+```javascript
+// start-shorthand
+()=> fetch current weather from API
+()=> save response to weather.json file
+// end-shorthand
+```
+
+**Implementation**: Use appropriate tools to fetch data and save file, then remove shorthand lines.
+
+### Complex Multi-Step Logic
+
+```typescript
+// start-shorthand
+()=> check if user is logged in
+()=> if not, redirect to login page
+()=> if yes, load user dashboard with their data
+()=> show error if data fetch fails
+// end-shorthand
+```
+
+**Implementation**: Convert to proper TypeScript with authentication checks, routing, data fetching, and error handling.
+
+## Summary
+
+The Quasi-Coder skill enables expert-level interpretation and implementation of code from imperfect descriptions. By assessing collaborator expertise, applying technical knowledge, and maintaining professional standards, you bridge the gap between ideas and production-quality code.
+
+**Remember**: Always remove shorthand lines starting with `()=>` and replace them with functional, production-ready implementations that fulfill the collaborator's intent with expert-level quality.

package/skills/quasi-coder/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/quasi-coder`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/readme-blueprint-generator/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/readme-blueprint-generator/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: readme-blueprint-generator
+description: 'Intelligent README.md generation prompt that analyzes project documentation structure and creates comprehensive repository documentation. Scans .github/copilot directory files and copilot-instructions.md to extract project information, technology stack, architecture, development workflow, coding standards, and testing approaches while generating well-structured markdown documentation with proper formatting, cross-references, and developer-focused content.'
+---
+
+# README Generator Prompt
+
+Generate a comprehensive README.md for this repository by analyzing the documentation files in the .github/copilot directory and the copilot-instructions.md file. Follow these steps:
+
+1. Scan all the files in the .github/copilot folder, like:
+   - Architecture
+   - Code_Exemplars
+   - Coding_Standards
+   - Project_Folder_Structure
+   - Technology_Stack
+   - Unit_Tests
+   - Workflow_Analysis
+
+2. Also review the copilot-instructions.md file in the .github folder
+
+3. Create a README.md with the following sections:
+
+## Project Name and Description
+- Extract the project name and primary purpose from the documentation
+- Include a concise description of what the project does
+
+## Technology Stack
+- List the primary technologies, languages, and frameworks used
+- Include version information when available
+- Source this information primarily from the Technology_Stack file
+
+## Project Architecture
+- Provide a high-level overview of the architecture
+- Consider including a simple diagram if described in the documentation
+- Source from the Architecture file
+
+## Getting Started
+- Include installation instructions based on the technology stack
+- Add setup and configuration steps
+- Include any prerequisites
+
+## Project Structure
+- Brief overview of the folder organization
+- Source from Project_Folder_Structure file
+
+## Key Features
+- List main functionality and features of the project
+- Extract from various documentation files
+
+## Development Workflow
+- Summarize the development process
+- Include information about branching strategy if available
+- Source from Workflow_Analysis file
+
+## Coding Standards
+- Summarize key coding standards and conventions
+- Source from the Coding_Standards file
+
+## Testing
+- Explain testing approach and tools
+- Source from Unit_Tests file
+
+## Contributing
+- Guidelines for contributing to the project
+- Reference any code exemplars for guidance
+- Source from Code_Exemplars and copilot-instructions
+
+## License
+- Include license information if available
+
+Format the README with proper Markdown, including:
+- Clear headings and subheadings
+- Code blocks where appropriate
+- Lists for better readability
+- Links to other documentation files
+- Badges for build status, version, etc. if information is available
+
+Keep the README concise yet informative, focusing on what new developers or users would need to know about the project.

package/skills/readme-blueprint-generator/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/readme-blueprint-generator`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/refactor/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.