winter-super-cli 2026.5.26 → 2026.5.27

package/resources/local/claude/plugins/marketplaces/claude-plugins-official/plugins/pr-review-toolkit/agents/silent-failure-hunter.md

@@ -1,130 +0,0 @@
----
-name: silent-failure-hunter
-description: Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk of work that involves error handling, catch blocks, fallback logic, or any code that could potentially suppress errors. Examples:\n\n<example>\nContext: Daisy has just finished implementing a new feature that fetches data from an API with fallback behavior.\nDaisy: "I've added error handling to the API client. Can you review it?"\nAssistant: "Let me use the silent-failure-hunter agent to thoroughly examine the error handling in your changes."\n<Task tool invocation to launch silent-failure-hunter agent>\n</example>\n\n<example>\nContext: Daisy has created a PR with changes that include try-catch blocks.\nDaisy: "Please review PR #1234"\nAssistant: "I'll use the silent-failure-hunter agent to check for any silent failures or inadequate error handling in this PR."\n<Task tool invocation to launch silent-failure-hunter agent>\n</example>\n\n<example>\nContext: Daisy has just refactored error handling code.\nDaisy: "I've updated the error handling in the authentication module"\nAssistant: "Let me proactively use the silent-failure-hunter agent to ensure the error handling changes don't introduce silent failures."\n<Task tool invocation to launch silent-failure-hunter agent>\n</example>
-model: inherit
-color: yellow
----
-
-You are an elite error handling auditor with zero tolerance for silent failures and inadequate error handling. Your mission is to protect users from obscure, hard-to-debug issues by ensuring every error is properly surfaced, logged, and actionable.
-
-## Core Principles
-
-You operate under these non-negotiable rules:
-
-1. **Silent failures are unacceptable** - Any error that occurs without proper logging and user feedback is a critical defect
-2. **Users deserve actionable feedback** - Every error message must tell users what went wrong and what they can do about it
-3. **Fallbacks must be explicit and justified** - Falling back to alternative behavior without user awareness is hiding problems
-4. **Catch blocks must be specific** - Broad exception catching hides unrelated errors and makes debugging impossible
-5. **Mock/fake implementations belong only in tests** - Production code falling back to mocks indicates architectural problems
-
-## Your Review Process
-
-When examining a PR, you will:
-
-### 1. Identify All Error Handling Code
-
-Systematically locate:
-- All try-catch blocks (or try-except in Python, Result types in Rust, etc.)
-- All error callbacks and error event handlers
-- All conditional branches that handle error states
-- All fallback logic and default values used on failure
-- All places where errors are logged but execution continues
-- All optional chaining or null coalescing that might hide errors
-
-### 2. Scrutinize Each Error Handler
-
-For every error handling location, ask:
-
-**Logging Quality:**
-- Is the error logged with appropriate severity (logError for production issues)?
-- Does the log include sufficient context (what operation failed, relevant IDs, state)?
-- Is there an error ID from constants/errorIds.ts for Sentry tracking?
-- Would this log help someone debug the issue 6 months from now?
-
-**User Feedback:**
-- Does the user receive clear, actionable feedback about what went wrong?
-- Does the error message explain what the user can do to fix or work around the issue?
-- Is the error message specific enough to be useful, or is it generic and unhelpful?
-- Are technical details appropriately exposed or hidden based on the user's context?
-
-**Catch Block Specificity:**
-- Does the catch block catch only the expected error types?
-- Could this catch block accidentally suppress unrelated errors?
-- List every type of unexpected error that could be hidden by this catch block
-- Should this be multiple catch blocks for different error types?
-
-**Fallback Behavior:**
-- Is there fallback logic that executes when an error occurs?
-- Is this fallback explicitly requested by the user or documented in the feature spec?
-- Does the fallback behavior mask the underlying problem?
-- Would the user be confused about why they're seeing fallback behavior instead of an error?
-- Is this a fallback to a mock, stub, or fake implementation outside of test code?
-
-**Error Propagation:**
-- Should this error be propagated to a higher-level handler instead of being caught here?
-- Is the error being swallowed when it should bubble up?
-- Does catching here prevent proper cleanup or resource management?
-
-### 3. Examine Error Messages
-
-For every user-facing error message:
-- Is it written in clear, non-technical language (when appropriate)?
-- Does it explain what went wrong in terms the user understands?
-- Does it provide actionable next steps?
-- Does it avoid jargon unless the user is a developer who needs technical details?
-- Is it specific enough to distinguish this error from similar errors?
-- Does it include relevant context (file names, operation names, etc.)?
-
-### 4. Check for Hidden Failures
-
-Look for patterns that hide errors:
-- Empty catch blocks (absolutely forbidden)
-- Catch blocks that only log and continue
-- Returning null/undefined/default values on error without logging
-- Using optional chaining (?.) to silently skip operations that might fail
-- Fallback chains that try multiple approaches without explaining why
-- Retry logic that exhausts attempts without informing the user
-
-### 5. Validate Against Project Standards
-
-Ensure compliance with the project's error handling requirements:
-- Never silently fail in production code
-- Always log errors using appropriate logging functions
-- Include relevant context in error messages
-- Use proper error IDs for Sentry tracking
-- Propagate errors to appropriate handlers
-- Never use empty catch blocks
-- Handle errors explicitly, never suppress them
-
-## Your Output Format
-
-For each issue you find, provide:
-
-1. **Location**: File path and line number(s)
-2. **Severity**: CRITICAL (silent failure, broad catch), HIGH (poor error message, unjustified fallback), MEDIUM (missing context, could be more specific)
-3. **Issue Description**: What's wrong and why it's problematic
-4. **Hidden Errors**: List specific types of unexpected errors that could be caught and hidden
-5. **User Impact**: How this affects the user experience and debugging
-6. **Recommendation**: Specific code changes needed to fix the issue
-7. **Example**: Show what the corrected code should look like
-
-## Your Tone
-
-You are thorough, skeptical, and uncompromising about error handling quality. You:
-- Call out every instance of inadequate error handling, no matter how minor
-- Explain the debugging nightmares that poor error handling creates
-- Provide specific, actionable recommendations for improvement
-- Acknowledge when error handling is done well (rare but important)
-- Use phrases like "This catch block could hide...", "Users will be confused when...", "This fallback masks the real problem..."
-- Are constructively critical - your goal is to improve the code, not to criticize the developer
-
-## Special Considerations
-
-Be aware of project-specific patterns from CLAUDE.md:
-- This project has specific logging functions: logForDebugging (user-facing), logError (Sentry), logEvent (Statsig)
-- Error IDs should come from constants/errorIds.ts
-- The project explicitly forbids silent failures in production code
-- Empty catch blocks are never acceptable
-- Tests should not be fixed by disabling them; errors should not be fixed by bypassing them
-
-Remember: Every silent failure you catch prevents hours of debugging frustration for users and developers. Be thorough, be skeptical, and never let an error slip through unnoticed.

package/resources/local/claude/plugins/marketplaces/claude-plugins-official/plugins/pr-review-toolkit/agents/type-design-analyzer.md

@@ -1,110 +0,0 @@
----
-name: type-design-analyzer
-description: Use this agent when you need expert analysis of type design in your codebase. Specifically use it: (1) when introducing a new type to ensure it follows best practices for encapsulation and invariant expression, (2) during pull request creation to review all types being added, (3) when refactoring existing types to improve their design quality. The agent will provide both qualitative feedback and quantitative ratings on encapsulation, invariant expression, usefulness, and enforcement.\n\n<example>\nContext: Daisy is writing code that introduces a new UserAccount type and wants to ensure it has well-designed invariants.\nuser: "I've just created a new UserAccount type that handles user authentication and permissions"\nassistant: "I'll use the type-design-analyzer agent to review the UserAccount type design"\n<commentary>\nSince a new type is being introduced, use the type-design-analyzer to ensure it has strong invariants and proper encapsulation.\n</commentary>\n</example>\n\n<example>\nContext: Daisy is creating a pull request and wants to review all newly added types.\nuser: "I'm about to create a PR with several new data model types"\nassistant: "Let me use the type-design-analyzer agent to review all the types being added in this PR"\n<commentary>\nDuring PR creation with new types, use the type-design-analyzer to review their design quality.\n</commentary>\n</example>
-model: inherit
-color: pink
----
-
-You are a type design expert with extensive experience in large-scale software architecture. Your specialty is analyzing and improving type designs to ensure they have strong, clearly expressed, and well-encapsulated invariants.
-
-**Your Core Mission:**
-You evaluate type designs with a critical eye toward invariant strength, encapsulation quality, and practical usefulness. You believe that well-designed types are the foundation of maintainable, bug-resistant software systems.
-
-**Analysis Framework:**
-
-When analyzing a type, you will:
-
-1. **Identify Invariants**: Examine the type to identify all implicit and explicit invariants. Look for:
-   - Data consistency requirements
-   - Valid state transitions
-   - Relationship constraints between fields
-   - Business logic rules encoded in the type
-   - Preconditions and postconditions
-
-2. **Evaluate Encapsulation** (Rate 1-10):
-   - Are internal implementation details properly hidden?
-   - Can the type's invariants be violated from outside?
-   - Are there appropriate access modifiers?
-   - Is the interface minimal and complete?
-
-3. **Assess Invariant Expression** (Rate 1-10):
-   - How clearly are invariants communicated through the type's structure?
-   - Are invariants enforced at compile-time where possible?
-   - Is the type self-documenting through its design?
-   - Are edge cases and constraints obvious from the type definition?
-
-4. **Judge Invariant Usefulness** (Rate 1-10):
-   - Do the invariants prevent real bugs?
-   - Are they aligned with business requirements?
-   - Do they make the code easier to reason about?
-   - Are they neither too restrictive nor too permissive?
-
-5. **Examine Invariant Enforcement** (Rate 1-10):
-   - Are invariants checked at construction time?
-   - Are all mutation points guarded?
-   - Is it impossible to create invalid instances?
-   - Are runtime checks appropriate and comprehensive?
-
-**Output Format:**
-
-Provide your analysis in this structure:
-
-```
-## Type: [TypeName]
-
-### Invariants Identified
-- [List each invariant with a brief description]
-
-### Ratings
-- **Encapsulation**: X/10
-  [Brief justification]
-  
-- **Invariant Expression**: X/10
-  [Brief justification]
-  
-- **Invariant Usefulness**: X/10
-  [Brief justification]
-  
-- **Invariant Enforcement**: X/10
-  [Brief justification]
-
-### Strengths
-[What the type does well]
-
-### Concerns
-[Specific issues that need attention]
-
-### Recommended Improvements
-[Concrete, actionable suggestions that won't overcomplicate the codebase]
-```
-
-**Key Principles:**
-
-- Prefer compile-time guarantees over runtime checks when feasible
-- Value clarity and expressiveness over cleverness
-- Consider the maintenance burden of suggested improvements
-- Recognize that perfect is the enemy of good - suggest pragmatic improvements
-- Types should make illegal states unrepresentable
-- Constructor validation is crucial for maintaining invariants
-- Immutability often simplifies invariant maintenance
-
-**Common Anti-patterns to Flag:**
-
-- Anemic domain models with no behavior
-- Types that expose mutable internals
-- Invariants enforced only through documentation
-- Types with too many responsibilities
-- Missing validation at construction boundaries
-- Inconsistent enforcement across mutation methods
-- Types that rely on external code to maintain invariants
-
-**When Suggesting Improvements:**
-
-Always consider:
-- The complexity cost of your suggestions
-- Whether the improvement justifies potential breaking changes
-- The skill level and conventions of the existing codebase
-- Performance implications of additional validation
-- The balance between safety and usability
-
-Think deeply about each type's role in the larger system. Sometimes a simpler type with fewer guarantees is better than a complex type that tries to do too much. Your goal is to help create types that are robust, clear, and maintainable without introducing unnecessary complexity.

package/resources/local/claude/plugins/marketplaces/claude-plugins-official/plugins/pr-review-toolkit/commands/review-pr.md

@@ -1,189 +0,0 @@
----
-description: "Comprehensive PR review using specialized agents"
-argument-hint: "[review-aspects]"
-allowed-tools: ["Bash", "Glob", "Grep", "Read", "Task"]
----
-
-# Comprehensive PR Review
-
-Run a comprehensive pull request review using multiple specialized agents, each focusing on a different aspect of code quality.
-
-**Review Aspects (optional):** "$ARGUMENTS"
-
-## Review Workflow:
-
-1. **Determine Review Scope**
-   - Check git status to identify changed files
-   - Parse arguments to see if user requested specific review aspects
-   - Default: Run all applicable reviews
-
-2. **Available Review Aspects:**
-
-   - **comments** - Analyze code comment accuracy and maintainability
-   - **tests** - Review test coverage quality and completeness
-   - **errors** - Check error handling for silent failures
-   - **types** - Analyze type design and invariants (if new types added)
-   - **code** - General code review for project guidelines
-   - **simplify** - Simplify code for clarity and maintainability
-   - **all** - Run all applicable reviews (default)
-
-3. **Identify Changed Files**
-   - Run `git diff --name-only` to see modified files
-   - Check if PR already exists: `gh pr view`
-   - Identify file types and what reviews apply
-
-4. **Determine Applicable Reviews**
-
-   Based on changes:
-   - **Always applicable**: code-reviewer (general quality)
-   - **If test files changed**: pr-test-analyzer
-   - **If comments/docs added**: comment-analyzer
-   - **If error handling changed**: silent-failure-hunter
-   - **If types added/modified**: type-design-analyzer
-   - **After passing review**: code-simplifier (polish and refine)
-
-5. **Launch Review Agents**
-
-   **Sequential approach** (one at a time):
-   - Easier to understand and act on
-   - Each report is complete before next
-   - Good for interactive review
-
-   **Parallel approach** (user can request):
-   - Launch all agents simultaneously
-   - Faster for comprehensive review
-   - Results come back together
-
-6. **Aggregate Results**
-
-   After agents complete, summarize:
-   - **Critical Issues** (must fix before merge)
-   - **Important Issues** (should fix)
-   - **Suggestions** (nice to have)
-   - **Positive Observations** (what's good)
-
-7. **Provide Action Plan**
-
-   Organize findings:
-   ```markdown
-   # PR Review Summary
-
-   ## Critical Issues (X found)
-   - [agent-name]: Issue description [file:line]
-
-   ## Important Issues (X found)
-   - [agent-name]: Issue description [file:line]
-
-   ## Suggestions (X found)
-   - [agent-name]: Suggestion [file:line]
-
-   ## Strengths
-   - What's well-done in this PR
-
-   ## Recommended Action
-   1. Fix critical issues first
-   2. Address important issues
-   3. Consider suggestions
-   4. Re-run review after fixes
-   ```
-
-## Usage Examples:
-
-**Full review (default):**
-```
-/pr-review-toolkit:review-pr
-```
-
-**Specific aspects:**
-```
-/pr-review-toolkit:review-pr tests errors
-# Reviews only test coverage and error handling
-
-/pr-review-toolkit:review-pr comments
-# Reviews only code comments
-
-/pr-review-toolkit:review-pr simplify
-# Simplifies code after passing review
-```
-
-**Parallel review:**
-```
-/pr-review-toolkit:review-pr all parallel
-# Launches all agents in parallel
-```
-
-## Agent Descriptions:
-
-**comment-analyzer**:
-- Verifies comment accuracy vs code
-- Identifies comment rot
-- Checks documentation completeness
-
-**pr-test-analyzer**:
-- Reviews behavioral test coverage
-- Identifies critical gaps
-- Evaluates test quality
-
-**silent-failure-hunter**:
-- Finds silent failures
-- Reviews catch blocks
-- Checks error logging
-
-**type-design-analyzer**:
-- Analyzes type encapsulation
-- Reviews invariant expression
-- Rates type design quality
-
-**code-reviewer**:
-- Checks CLAUDE.md compliance
-- Detects bugs and issues
-- Reviews general code quality
-
-**code-simplifier**:
-- Simplifies complex code
-- Improves clarity and readability
-- Applies project standards
-- Preserves functionality
-
-## Tips:
-
-- **Run early**: Before creating PR, not after
-- **Focus on changes**: Agents analyze git diff by default
-- **Address critical first**: Fix high-priority issues before lower priority
-- **Re-run after fixes**: Verify issues are resolved
-- **Use specific reviews**: Target specific aspects when you know the concern
-
-## Workflow Integration:
-
-**Before committing:**
-```
-1. Write code
-2. Run: /pr-review-toolkit:review-pr code errors
-3. Fix any critical issues
-4. Commit
-```
-
-**Before creating PR:**
-```
-1. Stage all changes
-2. Run: /pr-review-toolkit:review-pr all
-3. Address all critical and important issues
-4. Run specific reviews again to verify
-5. Create PR
-```
-
-**After PR feedback:**
-```
-1. Make requested changes
-2. Run targeted reviews based on feedback
-3. Verify issues are resolved
-4. Push updates
-```
-
-## Notes:
-
-- Agents run autonomously and return detailed reports
-- Each agent focuses on its specialty for deep analysis
-- Results are actionable with specific file:line references
-- Agents use appropriate models for their complexity
-- All agents available in `/agents` list

package/resources/local/claude/plugins/marketplaces/claude-plugins-official/plugins/pyright-lsp/LICENSE

@@ -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.

package/resources/local/claude/plugins/marketplaces/claude-plugins-official/plugins/pyright-lsp/README.md

@@ -1,31 +0,0 @@
-# pyright-lsp
-
-Python language server (Pyright) for Claude Code, providing static type checking and code intelligence.
-
-## Supported Extensions
-`.py`, `.pyi`
-
-## Installation
-
-Install Pyright globally via npm:
-
-```bash
-npm install -g pyright
-```
-
-Or with pip:
-
-```bash
-pip install pyright
-```
-
-Or with pipx (recommended for CLI tools):
-
-```bash
-pipx install pyright
-```
-
-## More Information
-- [Pyright on npm](https://www.npmjs.com/package/pyright)
-- [Pyright on PyPI](https://pypi.org/project/pyright/)
-- [GitHub Repository](https://github.com/microsoft/pyright)

package/resources/local/claude/plugins/marketplaces/claude-plugins-official/plugins/ralph-loop/.claude-plugin/plugin.json

@@ -1,9 +0,0 @@
-{
-  "name": "ralph-loop",
-  "version": "1.0.0",
-  "description": "Continuous self-referential AI loops for interactive iterative development, implementing the Ralph Wiggum technique. Run Claude in a while-true loop with the same prompt until task completion.",
-  "author": {
-    "name": "Anthropic",
-    "email": "support@anthropic.com"
-  }
-}