npm - opencode-skills-collection - Versions diffs - 4.0.53 → 4.0.55 - Mend

opencode-skills-collection 4.0.53 → 4.0.55

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1230) hide show

package/bundled-skills/documentation-generation-doc-generate/resources/implementation-playbook.md CHANGED Viewed

@@ -1,6 +1,10 @@
 # Automated Documentation Generation Implementation Playbook
-This file contains detailed patterns, checklists, and code samples referenced by the skill.
+This file contains integration sketches and templates. They are not a complete
+runnable documentation generator: route adapters, schemas, scripts and actual project
+configuration must be supplied. Validate examples against the current source rather
+than treating comments, docstring presence or example architecture as ground truth.
+Publishing a documentation site requires existing user authorization.
 ## Instructions
@@ -63,7 +67,7 @@ class APIDocExtractor:
             tree = ast.parse(f.read())
         for node in ast.walk(tree):
-            if isinstance(node, ast.FunctionDef):
+            if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)):
                 for decorator in node.decorator_list:
                     if self._is_route_decorator(decorator):
                         endpoint = {
@@ -122,7 +126,7 @@ def extract_pydantic_schemas(file_path):
 ### Example 2: OpenAPI Specification Generation
-**OpenAPI Template**
+**OpenAPI template fragment:** define Pagination, Unauthorized and bearerAuth before schema validation; these references are intentionally incomplete below.
 ```yaml
 openapi: 3.0.0
 info:
@@ -376,7 +380,7 @@ def generate_function_docs(func):
     for param_name, param in sig.parameters.items():
         param_str = param_name
         if param.annotation != param.empty:
-            param_str += f": {param.annotation.__name__}"
+            param_str += f": {inspect.formatannotation(param.annotation)}"
         if param.default != param.empty:
             param_str += f" = {param.default}"
         params.append(param_str)
@@ -384,7 +388,7 @@ def generate_function_docs(func):
     return_type = ""
     if sig.return_annotation != sig.empty:
-        return_type = f" -> {sig.return_annotation.__name__}"
+        return_type = f" -> {inspect.formatannotation(sig.return_annotation)}"
     doc_template = f'''
 def {func.__name__}({", ".join(params)}){return_type}:
@@ -460,18 +464,18 @@ def {func.__name__}({", ".join(params)}){return_type}:
 ### Example 7: Interactive API Playground
-**Swagger UI Setup**
+**Swagger UI sketch:** vendor the exact reviewed Swagger UI assets locally first; do not load mutable remote code.
 ```html
 <!DOCTYPE html>
 <html>
 <head>
     <title>API Documentation</title>
-    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/swagger-ui-dist@latest/swagger-ui.css">
+    <link rel="stylesheet" href="/assets/vendor/swagger-ui.css">
 </head>
 <body>
     <div id="swagger-ui"></div>
-    <script src="https://cdn.jsdelivr.net/npm/swagger-ui-dist@latest/swagger-ui-bundle.js"></script>
+    <script src="/assets/vendor/swagger-ui-bundle.js"></script>
     <script>
         window.onload = function() {
             SwaggerUIBundle({
@@ -479,7 +483,7 @@ def {func.__name__}({", ".join(params)}){return_type}:
                 dom_id: '#swagger-ui',
                 deepLinking: true,
                 presets: [SwaggerUIBundle.presets.apis],
-                layout: "StandaloneLayout"
+                layout: "BaseLayout"
             });
         }
     </script>
@@ -526,48 +530,11 @@ curl -X {endpoint['method']} https://api.example.com{endpoint['path']} \\
 ### Example 8: Documentation CI/CD
-**GitHub Actions Workflow**
-```yaml
-name: Generate Documentation
-on:
-  push:
-    branches: [main]
-    paths:
-      - 'src/**'
-      - 'api/**'
-jobs:
-  generate-docs:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v3
-    - name: Set up Python
-      uses: actions/setup-python@v4
-      with:
-        python-version: '3.11'
-    - name: Install dependencies
-      run: |
-        pip install -r requirements-docs.txt
-        npm install -g @redocly/cli
-    - name: Generate API documentation
-      run: |
-        python scripts/generate_openapi.py > docs/api/openapi.json
-        redocly build-docs docs/api/openapi.json -o docs/api/index.html
-    - name: Generate code documentation
-      run: sphinx-build -b html docs/source docs/build
-    - name: Deploy to GitHub Pages
-      uses: peaceiris/actions-gh-pages@v3
-      with:
-        github_token: ${{ secrets.GITHUB_TOKEN }}
-        publish_dir: ./docs/build
-```
+Use the repository's existing documentation build and review workflow. Add the actual
+source paths, locked tool versions and generated output locations to that workflow.
+If using third-party actions, pin reviewed commit SHAs and least-privilege permissions.
+A documentation request does not authorize automatic deployment, token access, or a
+new global package install. Record the exact schema/build/link checks that ran.
 ### Example 9: Documentation Coverage Validation
@@ -590,7 +557,7 @@ class DocCoverage:
             module = ast.parse(open(file_path).read())
             for node in ast.walk(module):
-                if isinstance(node, ast.FunctionDef):
+                if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)):
                     results['total_functions'] += 1
                     if ast.get_docstring(node):
                         results['documented_functions'] += 1
@@ -617,11 +584,11 @@ class DocCoverage:
         # Calculate coverage percentages
         results['function_coverage'] = (
             results['documented_functions'] / results['total_functions'] * 100
-            if results['total_functions'] > 0 else 100
+            if results['total_functions'] > 0 else None
         )
         results['class_coverage'] = (
             results['documented_classes'] / results['total_classes'] * 100
-            if results['total_classes'] > 0 else 100
+            if results['total_classes'] > 0 else None
         )
         return results
@@ -635,6 +602,17 @@ class DocCoverage:
 4. **User Guides**: Step-by-step tutorials
 5. **Developer Guides**: Setup, contribution, and API usage guides
 6. **Reference Documentation**: Complete API reference with examples
-7. **Documentation Site**: Deployed static site with search functionality
+7. **Documentation Site**: Build preview; deploy only within the requested scope
 Focus on creating documentation that is accurate, comprehensive, and easy to maintain alongside code changes.
+## Limits of these extractors
+AST sketches do not resolve arbitrary decorators, imported types, Pydantic factories
+or framework runtime routing. The parameter sketch marks arguments required without
+resolving defaults; the schema sketch likewise cannot infer all Field(...) semantics.
+Use the framework's actual OpenAPI/schema export as the authority when available.
+Docstring coverage reports presence only, not accuracy; no functions/classes means
+no applicable percentage, not 100% quality. Generated snippets containing placeholders
+must remain labelled until replaced and tested. Do not import untrusted project modules
+just to inspect them: imports can execute code.

package/bundled-skills/doubt-driven-development/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: doubt-driven-development
-description: Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident...
+description: "Subjects every non-trivial decision to a fresh-context adversarial review before it stands."
 risk: critical
 source: https://github.com/addyosmani/agent-skills/tree/main/skills/doubt-driven-development
 source_repo: addyosmani/agent-skills

package/bundled-skills/dropbox-automation/SKILL.md CHANGED Viewed

@@ -232,6 +232,12 @@ Several Dropbox operations run asynchronously:
 ## When to Use
 This skill is applicable to execute the workflow or actions described in the overview.
+## Example
+**User request:**
+> Automate Dropbox file management, sharing, search, uploads, downloads, and folder operations via Rube MCP (Composio).
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/dwarf-expert/SKILL.md CHANGED Viewed

@@ -9,6 +9,7 @@ allowed-tools:
   - WebSearch
 risk: critical
 source: community
+date_added: "2026-09-04"
 ---
 # Overview
 This skill provides technical knowledge and expertise about the DWARF standard and how to interact with DWARF files. Tasks include answering questions about the DWARF standard, providing examples of various DWARF features, parsing and/or creating DWARF files, and writing/modifying/analyzing code that interacts with DWARF data.

package/bundled-skills/dx-optimizer/SKILL.md CHANGED Viewed

@@ -81,6 +81,12 @@ You are a Developer Experience (DX) optimization specialist. Your mission is to
 Remember: Great DX is invisible when it works and obvious when it doesn't. Aim for invisible.
+## Example
+**User request:**
+> Use @dx-optimizer for this task: Developer Experience specialist.
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/e2e-testing-patterns/SKILL.md CHANGED Viewed

@@ -31,7 +31,7 @@ Build reliable, fast, and maintainable end-to-end test suites that provide confi
 1. Identify critical user journeys and success criteria.
 2. Build stable selectors and test data strategies.
-3. Implement tests with retries, tracing, and isolation.
+3. Implement isolated tests with observable assertions and tracing; diagnose retries rather than counting a retry as an ordinary pass.
 4. Run in CI with parallelization and artifact capture.
 ## Safety
@@ -43,7 +43,17 @@ Build reliable, fast, and maintainable end-to-end test suites that provide confi
 - `resources/implementation-playbook.md` for detailed E2E patterns and templates.
+## Worked example
+Input: invalid login sometimes appears successful because the test reads the error before rendering finishes. Use a dedicated fixture account and assert `await expect(page.getByRole('alert')).toContainText('Invalid credentials')`. Run the test without retries and confirm the dashboard remains inaccessible. Expected: the failure state is observed reliably; a delayed error cannot silently pass.
+## Inputs and prerequisites
+An authorized test URL, isolated accounts/data, the installed browser runner and known success/failure states. The playbook uses project-specific routes and adapters; install only the dependencies your existing suite needs.
 ## Limitations
-- Use this skill only when the task clearly matches the scope described above.
-- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+- A mocked backend or payment provider proves only the mocked boundary; retain separate real integration checks.
+- Automated accessibility scans miss interaction and assistive-technology problems.
+- Retries, larger timeouts and updated snapshots can hide regressions; preserve first-failure evidence.
+- Browser tooling cannot validate a locked or unavailable interactive environment. Report that gap and continue independent tests.

package/bundled-skills/e2e-testing-patterns/resources/implementation-playbook.md CHANGED Viewed

@@ -1,6 +1,6 @@
 # E2E Testing Patterns Implementation Playbook
-This file contains detailed patterns, checklists, and code samples referenced by the skill.
+Integration sketches for an existing test project. Application routes, test-data adapters and installed framework versions must match your repository; examples do not provision accounts or prove a production flow.
 ## Core Concepts
@@ -16,7 +16,7 @@ This file contains detailed patterns, checklists, and code samples referenced by
 **What NOT to Test with E2E:**
 - Unit-level logic (use unit tests)
 - API contracts (use integration tests)
-- Edge cases (too slow)
+- Pure algorithm edge cases (use unit tests); retain critical failure/recovery paths in E2E
 - Internal implementation details
 ### 2. Test Philosophy
@@ -37,7 +37,7 @@ This file contains detailed patterns, checklists, and code samples referenced by
 - Keep tests independent
 - Make tests deterministic
 - Optimize for speed
-- Use data-testid, not CSS selectors
+- Prefer role/label locators; use explicit test IDs when semantic locators are insufficient
 ## Playwright Patterns
@@ -131,8 +131,7 @@ test('failed login shows error', async ({ page }) => {
     await loginPage.goto();
     await loginPage.login('invalid@example.com', 'wrong');
-    const error = await loginPage.getErrorMessage();
-    expect(error).toContain('Invalid credentials');
+    await expect(loginPage.errorMessage).toContainText('Invalid credentials');
 });
 ```
@@ -157,15 +156,17 @@ type TestData = {
 export const test = base.extend<TestData>({
     testUser: async ({}, use) => {
         const user = {
-            email: `test-${Date.now()}@example.com`,
+            email: `test-${crypto.randomUUID()}@example.com`,
             password: 'Test123!@#',
             name: 'Test User',
         };
         // Setup: Create user in database
         await createTestUser(user);
-        await use(user);
-        // Teardown: Clean up user
-        await deleteTestUser(user.email);
+        try {
+            await use(user);
+        } finally {
+            await deleteTestUser(user.email);
+        }
     },
     adminUser: async ({}, use) => {
@@ -200,7 +201,6 @@ test('user can update profile', async ({ page, testUser }) => {
 await page.waitForTimeout(3000);  // Flaky!
 // ✅ Good: Wait for specific conditions
-await page.waitForLoadState('networkidle');
 await page.waitForURL('/dashboard');
 await page.waitForSelector('[data-testid="user-profile"]');
@@ -221,7 +221,6 @@ expect(data.users).toHaveLength(10);
 // Wait for multiple conditions
 await Promise.all([
     page.waitForURL('/success'),
-    page.waitForLoadState('networkidle'),
     expect(page.getByText('Payment successful')).toBeVisible(),
 ]);
 ```
@@ -407,27 +406,12 @@ test('button in all states', async ({ page }) => {
 ### Pattern 2: Parallel Testing with Sharding
 ```typescript
-// playwright.config.ts
-export default defineConfig({
-    projects: [
-        {
-            name: 'shard-1',
-            use: { ...devices['Desktop Chrome'] },
-            grepInvert: /@slow/,
-            shard: { current: 1, total: 4 },
-        },
-        {
-            name: 'shard-2',
-            use: { ...devices['Desktop Chrome'] },
-            shard: { current: 2, total: 4 },
-        },
-        // ... more shards
-    ],
-});
-// Run in CI
+// Keep one browser project configuration; shard the suite at the CLI level.
+// Run these as independent CI jobs against isolated test data:
 // npx playwright test --shard=1/4
 // npx playwright test --shard=2/4
+// npx playwright test --shard=3/4
+// npx playwright test --shard=4/4
 ```
 ### Pattern 3: Accessibility Testing
@@ -441,7 +425,6 @@ test('page should not have accessibility violations', async ({ page }) => {
     await page.goto('/');
     const accessibilityScanResults = await new AxeBuilder({ page })
-        .exclude('#third-party-widget')
         .analyze();
     expect(accessibilityScanResults.violations).toEqual([]);
@@ -460,7 +443,7 @@ test('form is accessible', async ({ page }) => {
 ## Best Practices
-1. **Use Data Attributes**: `data-testid` or `data-cy` for stable selectors
+1. **Use Semantic Locators**: Role/label first; test IDs for otherwise ambiguous controls
 2. **Avoid Brittle Selectors**: Don't rely on CSS classes or DOM structure
 3. **Test User Behavior**: Click, type, see - not implementation details
 4. **Keep Tests Independent**: Each test should run in isolation
@@ -475,8 +458,9 @@ cy.get('.btn.btn-primary.submit-button').click();
 cy.get('div > form > div:nth-child(2) > input').type('text');
 // ✅ Good selectors
-cy.getByRole('button', { name: 'Submit' }).click();
-cy.getByLabel('Email address').type('user@example.com');
+// With @testing-library/cypress configured:
+cy.findByRole('button', { name: 'Submit' }).click();
+cy.findByLabelText('Email address').type('user@example.com');
 cy.get('[data-testid="email-input"]').type('user@example.com');
 ```
@@ -521,11 +505,8 @@ test('checkout flow', async ({ page }) => {
 await page.pause();  // Pauses execution, opens inspector
 ```
-## Resources
+## Verification and limits
+Run the targeted flow first with retries disabled, then under the intended CI/browser configuration. A retry pass is still a flake to investigate. Use web-first assertions for visible state; `networkidle` is not proof that the UI is ready. Mocked payment responses verify the UI branch, not Stripe fulfillment. Axe results cover automated rules on the scanned state, not full accessibility; add keyboard, focus and responsive checks. Review traces/screenshots for test credentials before sharing.
-- **references/playwright-best-practices.md**: Playwright-specific patterns
-- **references/cypress-best-practices.md**: Cypress-specific patterns
-- **references/flaky-test-debugging.md**: Debugging unreliable tests
-- **assets/e2e-testing-checklist.md**: What to test with E2E
-- **assets/selector-strategies.md**: Finding reliable selectors
-- **scripts/test-analyzer.ts**: Analyze test flakiness and duration
+See the official [Playwright waiting API](https://playwright.dev/docs/api/class-page#page-wait-for-load-state), [sharding guide](https://playwright.dev/docs/test-sharding), and [Cypress Testing Library commands](https://testing-library.com/docs/cypress-testing-library/intro/). No other reference files or analyzer scripts are bundled with this skill.

package/bundled-skills/eas-update-insights/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: eas-update-insights
-description: "Check the health of published EAS Updates: crash rates, install/launch counts, unique users, payload size, and the split between embedded and OTA users per channel. Use when the user asks how an update is performing, whether a rollout is healthy, how many users are on the embedded..."
+description: "Check the health of published EAS Updates: crash rates, install/launch counts, unique users, payload size, and the split between embedded and OTA users per channel."
 risk: critical
 source: https://github.com/expo/skills/tree/main/plugins/expo/skills/eas-update-insights
 source_repo: expo/skills