@pikaa-ai/pikaa 0.3.22 → 0.3.24

package/skills/opentrons-integration/SKILL.md

@@ -1,322 +0,0 @@
----
-name: opentrons-integration
-description: Author, review, migrate, simulate, and troubleshoot official Opentrons Python Protocol API v2 protocols for Flex and OT-2 robots. Use for robot-specific liquid handling, deck and labware setup, pipettes, modules, runtime parameters, liquid classes, and Opentrons App analysis. Use pylabrobot instead when one workflow must support multiple robot vendors.
-license: MIT
-compatibility: Requires Python 3.10+ and uv for local simulation. Flex examples target opentrons 9.1.1 and API 2.29; the separate OT-2 line targets API 2.28 and uses opentrons 9.0.0 as its local compatibility simulator. Physical execution requires compatible hardware, current robot software, and the appropriate Opentrons App.
-allowed-tools: Read Write Edit Bash
-metadata:
-  version: "2.0"
-  skill-author: "K-Dense Inc."
----
-
-# Opentrons Integration
-
-## Overview
-
-Create production-minded Python Protocol API v2 protocols for Opentrons Flex and
-OT-2. This skill covers protocol structure, hardware and deck configuration,
-liquid handling, runtime customization, module control, simulation, and safe
-deployment.
-
-The verified baseline as of **2026-07-23** is:
-
-- `opentrons==9.1.1` for reproducible Flex simulation.
-- `opentrons==9.0.0` for local OT-2 API 2.28 compatibility simulation.
-- Flex supports API levels 2.15 through 2.29 on current software.
-- OT-2 supports API levels 2.0 through 2.28 on current software.
-- API 2.29 is Flex-only at this baseline. Do not put `2.29` in an OT-2 protocol.
-
-Read `references/sources.md` for the upstream documentation used for this
-snapshot. Recheck the official versioning page before targeting newer robot
-software.
-
-## Safety Boundary
-
-Opentrons protocols control physical equipment. Never treat successful Python
-syntax or local simulation as permission to run on a robot.
-
-Before live execution:
-
-1. Simulate locally with the same pinned `opentrons` version used for authoring.
-2. Import the protocol into the correct Opentrons App and require successful
-   analysis.
-3. Verify robot model, software, pipettes, mounts, modules, adapters, labware
-   definitions, deck fixtures, tip count, source volumes, dead volumes, and
-   destination capacity.
-4. Review the run preview and deck map with the operator.
-5. Perform a slow dry run with nonhazardous liquid when geometry, custom
-   labware, partial tip pickup, or gripper moves are new.
-6. Keep the emergency stop accessible and follow site-specific biosafety,
-   chemical-safety, and contamination-control procedures.
-
-Simulation cannot verify physical calibration, liquid properties, meniscus
-behavior, labware manufacturing tolerances, cap or seal removal, tubing, or all
-possible collisions.
-
-## Choose the Right Interface
-
-Use this skill for Python files imported into the Opentrons App and run through
-the Protocol API.
-
-- Use **Protocol Designer** for supported no-code workflows.
-- Use **PyLabRobot** for a hardware-agnostic workflow spanning vendors.
-- Treat the robot's HTTP API as a separate integration surface. If direct HTTP
-  control is explicitly required, use the OpenAPI document served by the target
-  robot and do not infer endpoints from Protocol API methods.
-
-## Required Intake
-
-Do not write final protocol code until these facts are known:
-
-- Robot: Flex or OT-2, plus installed robot software.
-- Pipette model, volume range, channel count, and mount.
-- Modules and generations; Flex Gripper or Stacker availability.
-- Exact labware API load names and custom definition files, if any.
-- Deck fixtures: Flex trash bin, waste chute, staging slots, or Stackers.
-- Source volumes, destination volumes, dead volume, mixing needs, and liquid
-  characteristics.
-- Tip policy: contamination boundaries, reuse policy, filters, partial pickup,
-  and total tips.
-- Operator interventions, incubation timing, runtime parameters, and output
-  files.
-- Acceptance criteria: tolerated volume error, required controls, and dry-run
-  plan.
-
-If any physical configuration is uncertain, produce a parameterized draft and
-an explicit assumptions list rather than guessing.
-
-## Install and Simulate
-
-Flex:
-
-```bash
-uv run --with "opentrons==9.1.1" opentrons_simulate protocol.py
-```
-
-OT-2 API 2.28:
-
-```bash
-uv run --with "opentrons==9.0.0" opentrons_simulate protocol.py
-```
-
-The 9.1.1 package intentionally rejects OT-2 protocols after the Flex/OT-2
-release-line split. Always complete OT-2 analysis in the current OT-2 App.
-
-For a dedicated Flex environment:
-
-```bash
-uv venv --python 3.10
-uv pip install --python .venv/bin/python -r skills/opentrons-integration/requirements-flex.txt
-.venv/bin/opentrons_simulate protocol.py
-```
-
-Use `requirements-ot2.txt` instead for an OT-2 compatibility environment. On
-Windows, invoke the executable from `.venv\Scripts\opentrons_simulate.exe`.
-Local simulation is for Python protocols; import Protocol Designer JSON files
-into the appropriate Opentrons App instead.
-
-## Protocol Skeletons
-
-### Flex, API 2.29
-
-For Flex, `requirements` is mandatory. Put `apiLevel` only in `requirements`,
-not in both `metadata` and `requirements`.
-
-```python
-from opentrons import protocol_api
-
-metadata = {
-    "protocolName": "Flex transfer",
-    "author": "Your Name",
-    "description": "Transfer buffer into a plate.",
-}
-requirements = {"robotType": "Flex", "apiLevel": "2.29"}
-
-
-def run(protocol: protocol_api.ProtocolContext) -> None:
-    tips = protocol.load_labware(
-        "opentrons_flex_96_tiprack_200ul", "D1"
-    )
-    reservoir = protocol.load_labware("nest_12_reservoir_15ml", "D2")
-    plate = protocol.load_labware("nest_96_wellplate_200ul_flat", "C2")
-    protocol.load_trash_bin("A3")
-    pipette = protocol.load_instrument(
-        "flex_1channel_1000", "left", tip_racks=[tips]
-    )
-
-    pipette.transfer(
-        100,
-        reservoir["A1"],
-        plate["A1"],
-        new_tip="always",
-    )
-```
-
-### OT-2, API 2.28
-
-For OT-2 API 2.15 and later, a `requirements` block is recommended. OT-2 has a
-fixed trash in slot 12; do not call `load_trash_bin()`.
-
-```python
-from opentrons import protocol_api
-
-metadata = {
-    "protocolName": "OT-2 transfer",
-    "author": "Your Name",
-}
-requirements = {"robotType": "OT-2", "apiLevel": "2.28"}
-
-
-def run(protocol: protocol_api.ProtocolContext) -> None:
-    tips = protocol.load_labware("opentrons_96_tiprack_300ul", "1")
-    reservoir = protocol.load_labware("nest_12_reservoir_15ml", "2")
-    plate = protocol.load_labware("nest_96_wellplate_200ul_flat", "3")
-    pipette = protocol.load_instrument(
-        "p300_single_gen2", "left", tip_racks=[tips]
-    )
-    pipette.transfer(100, reservoir["A1"], plate["A1"])
-```
-
-Use the lowest API level that provides every required feature when a protocol
-must run across a mixed software fleet. Use the current maximum only when the
-workflow needs its behavior or capabilities.
-
-## Authoring Workflow
-
-### 1. Select robot and API level
-
-Check the maximum supported API in the App under the robot's advanced settings.
-Map every requested feature to its minimum API level using
-`references/api_reference.md`.
-
-Important gates:
-
-- 2.20: CSV runtime parameters, liquid presence detection, expanded partial
-  nozzle layouts.
-- 2.21: Absorbance Plate Reader.
-- 2.22: current labware-level liquid loading methods.
-- 2.23: meniscus locations and labware lids.
-- 2.24: liquid classes and liquid-class complex commands.
-- 2.25: Flex Stacker and Flex 96-Channel 200 µL pipette.
-- 2.27: dynamic pipetting and concurrent module actions.
-- 2.28: 20 µL Flex tips, improved partial-tip return, and thermocycler ramp rate.
-- 2.29: step grouping; Flex only at the verified baseline.
-
-### 2. Build the deck explicitly
-
-- Use exact load names from the official Labware Library.
-- Load Flex trash bins or the waste chute explicitly.
-- Account for module footprints, staging slots, Stacker shuttles, gripper paths,
-  and tall-labware adjacency.
-- Load labware on adapters or module contexts in the documented order.
-- Never substitute a similarly named labware definition; geometry and offsets
-  are part of the protocol's safety model.
-
-See `references/modules_and_deck.md`.
-
-### 3. Select pipettes and tips
-
-Current load names are:
-
-- Flex: `flex_1channel_50`, `flex_1channel_1000`,
-  `flex_8channel_50`, `flex_8channel_1000`,
-  `flex_96channel_200`, `flex_96channel_1000`.
-- OT-2 GEN2: `p20_single_gen2`, `p20_multi_gen2`,
-  `p300_single_gen2`, `p300_multi_gen2`, `p1000_single_gen2`.
-
-Check that every requested volume is within the configured pipette and tip
-range. A 100 nL operation is not an Opentrons pipetting task.
-
-### 4. Choose a liquid-handling layer
-
-- Use `aspirate()`, `dispense()`, `mix()`, `air_gap()`, `blow_out()`, and
-  `touch_tip()` for explicit control.
-- Use `transfer()`, `distribute()`, and `consolidate()` for standard movements.
-- On Flex, consider `transfer_with_liquid_class()`,
-  `distribute_with_liquid_class()`, or `consolidate_with_liquid_class()` for
-  Opentrons-verified aqueous, volatile, or viscous behavior.
-- Use dynamic start/end locations or `dynamic_mix()` only when API 2.27+ and the
-  geometry has been reviewed.
-
-Model contamination boundaries before optimizing tips. Never reuse a tip across
-unrelated samples merely to reduce consumables. See
-`references/liquid_handling.md`.
-
-### 5. Add setup information and runtime controls
-
-Use `define_liquid()` and labware-level `load_liquid()` or
-`load_liquid_by_well()` to improve setup visualization. Do not use deprecated
-`Well.load_liquid()` in new API 2.22+ protocols.
-
-Define operator-controlled values in `add_parameters()` and read them from
-`protocol.params`. Validate ranges and use defaults that produce a safe,
-meaningful simulation. CSV parameters have no default and only one CSV
-parameter can be selected per run.
-
-### 6. Budget resources
-
-Before simulation, calculate:
-
-- Tips or tip sets required under every branch.
-- Source volume = delivered volume + mixing loss + disposal volume + dead
-  volume + a justified reserve.
-- Maximum destination volume after every addition and mix.
-- Number of module, adapter, trash, and staging positions.
-- Incubation and module timing, including concurrent tasks.
-
-### 7. Validate in layers
-
-1. Compile: `python -m py_compile protocol.py`.
-2. Simulate with the pinned package.
-3. Inspect the run log for command count, tip changes, pauses, and unexpected
-   locations.
-4. Import into the appropriate App and require successful analysis.
-5. Check protocol visualization, runtime parameter defaults, deck map, module
-   setup, and labware offsets.
-6. Perform an operator-reviewed dry run before first use.
-
-See `references/validation_and_operations.md`.
-
-## Common Failure Modes
-
-- Using old names such as `p300_single_flex`; use current `flex_*` load names.
-- Declaring `apiLevel` in both `metadata` and `requirements`.
-- Using API 2.29 for OT-2.
-- Forgetting a Flex trash bin or waste chute.
-- Loading a Magnetic Module on Flex; use supported Flex magnetic hardware.
-- Calling `read(wavelengths=...)` on the plate reader; call `initialize()` first,
-  then `read()`.
-- Using deprecated `Well.load_liquid()` instead of labware-level methods.
-- Assuming simulation verifies calibration, liquid height, or physical
-  clearances.
-- Passing an unsafe well to a partial-nozzle pipette, which can place tips
-  outside labware and cause a crash.
-- Using `new_tip="once"` across samples with incompatible contamination
-  requirements.
-
-## Bundled Templates
-
-| File | Purpose |
-| --- | --- |
-| `scripts/basic_protocol_template.py` | Minimal Flex 2.29 transfer with current names |
-| `scripts/ot2_basic_protocol_template.py` | Minimal OT-2 2.28 transfer |
-| `scripts/serial_dilution_template.py` | Full-plate 1:2 dilution with an 8-channel Flex pipette |
-| `scripts/pcr_setup_template.py` | Flex PCR setup and Thermocycler cycling |
-| `scripts/runtime_parameters_template.py` | Safe numeric and Boolean runtime parameters |
-| `scripts/absorbance_reader_template.py` | Correct Flex plate-reader initialization and read workflow |
-
-Templates are starting points, not validated assays. Replace volumes, labware,
-liquids, timing, and tip policies only after checking hardware compatibility and
-the wet-lab method.
-
-## Reference Guide
-
-| Reference | Use it for |
-| --- | --- |
-| `references/api_reference.md` | Current load names, version gates, and high-value methods |
-| `references/protocol_authoring.md` | Requirements, labware, runtime parameters, and design workflow |
-| `references/liquid_handling.md` | Command selection, liquid classes, sensing, and partial tips |
-| `references/modules_and_deck.md` | Module compatibility, deck fixtures, gripper, and Stacker |
-| `references/validation_and_operations.md` | Simulation, App analysis, dry runs, and troubleshooting |
-| `references/migration-api-2-19-to-2-29.md` | Updating older protocols and this skill's former patterns |
-| `references/sources.md` | Official documentation and release sources |

package/skills/optimize-for-gpu/SKILL.md

@@ -1,176 +0,0 @@
----
-name: optimize-for-gpu
-description: GPU-accelerates scientific Python on NVIDIA hardware and verifies that the result is correct and faster. Use for CUDA/GPU optimization; CPU-bound NumPy, SciPy, pandas, scikit-learn, NetworkX, scikit-image, vector-search, image-processing, graph, simulation, or file-I/O workloads; CuPy, cuDF, cuML, cuGraph, cuVS, cuCIM, KvikIO, Warp, Newton, Numba-CUDA, or RAFT questions; and profiling, memory-transfer, kernel, or multi-GPU bottlenecks. Also use when large data-parallel Python code is slow and GPU acceleration is a plausible option, even if the user does not name CUDA.
-license: MIT
-compatibility: Requires an NVIDIA CUDA-capable GPU for GPU execution. RAPIDS 26.06 requires Python 3.11+ on Linux or WSL2 and matching CUDA 12 or 13 wheels. Package installation needs network access.
-metadata:
-  version: "1.3"
-  skill-author: K-Dense, Inc.
----
-
-# GPU Optimization for Python with NVIDIA
-
-Treat GPU acceleration as an evidence-driven optimization, not an automatic rewrite. Preserve the
-user's numerical and algorithmic contract, measure with representative data, and keep the GPU
-version only when synchronized end-to-end benchmarks show a useful improvement.
-
-## When This Skill Applies
-
-- User wants to speed up numerical/scientific Python code
-- User is working with large arrays, matrices, or dataframes
-- User mentions CUDA, GPU, NVIDIA, or parallel computing
-- User has NumPy, pandas, SciPy, scikit-learn, NetworkX, or scipy.sparse.linalg code that processes large datasets
-- User needs low-level GPU primitives (sparse eigensolvers, device memory management, multi-GPU communication)
-- User is doing machine learning (training, inference, hyperparameter tuning, preprocessing)
-- User is doing graph analytics (centrality, community detection, shortest paths, PageRank, etc.)
-- User is doing vector search, nearest neighbor search, similarity search, or building a RAG pipeline
-- User has Faiss, Annoy, ScaNN, or sklearn NearestNeighbors code that could be GPU-accelerated
-- User wants GPU-accelerated interactive dashboards, cross-filtering, or exploratory data analysis on large datasets
-- User is doing geospatial analysis (point-in-polygon, spatial joins, trajectory analysis, distance calculations) with GeoPandas or shapely
-- User is doing image processing, computer vision, or medical imaging (filtering, segmentation, morphology, feature detection) with scikit-image or OpenCV
-- User is working with whole-slide images (WSI), digital pathology, microscopy, or remote sensing imagery
-- User is loading large binary data files into GPU memory (numpy.fromfile → cupy, or Python open() → GPU array)
-- User needs to read files from S3, HTTP, or WebHDFS directly into GPU memory
-- User mentions GPUDirect Storage (GDS) or wants to bypass CPU-memory staging for file IO
-- User is doing physics simulation (particles, cloth, fluids, rigid bodies) or differentiable simulation
-- User needs mesh operations (ray casting, closest-point queries, signed distance fields) or geometry processing on GPU
-- User is doing robotics (kinematics, dynamics, control) with transforms and quaternions
-- User has Python simulation loops that could be JIT-compiled to GPU kernels
-- User mentions NVIDIA Warp or wants differentiable GPU simulation integrated with PyTorch/JAX
-- User is doing simulations, signal processing, financial modeling, bioinformatics, physics, or any compute-intensive work
-- User wants to optimize existing code and GPU acceleration is the right answer
-
-## Choose the Smallest Suitable Layer
-
-Prefer a maintained library implementation over a custom kernel:
-
-| Existing workload | Preferred path | Use for |
-| --- | --- | --- |
-| NumPy / SciPy | **CuPy** | arrays, sparse matrices, linear algebra, FFTs, signal processing |
-| pandas | **cudf.pandas**, then **cuDF** | accelerator mode first; native API for more control |
-| scikit-learn | **cuml.accel**, then **cuML** | accelerator mode first; native estimators as needed |
-| NetworkX | **nx-cugraph**, then **cuGraph** | backend dispatch first; native graph API at scale |
-| scikit-image | **cuCIM** | GPU image processing and whole-slide imaging |
-| Faiss / Annoy / k-NN | **cuVS** | exact and approximate vector search |
-| Raw or remote file I/O | **KvikIO** | GPU buffers and GPUDirect Storage |
-| Custom array kernels | **Numba-CUDA-MLIR** for new work; **Numba-CUDA** for existing code | explicit SIMT kernels and shared memory |
-| Spatial or differentiable kernels | **Warp** | geometry, simulation kernels, robotics, autodiff |
-| High-level physics simulation | **Newton** | maintained engine that succeeds the removed `warp.sim` module |
-| Low-level RAPIDS primitives | **RAFT** (`pylibraft`) | sparse eigensolvers, resources, multi-GPU building blocks |
-
-Do not move code out of PyTorch, JAX, TensorFlow, or another GPU-native framework merely to use
-one of these libraries. First remove CPU round trips and use the framework's compiler, profiler,
-mixed-precision, and batching facilities.
-
-Treat these as legacy-only:
-
-| Project | Status | Guidance |
-| --- | --- | --- |
-| **cuxfilter** | Final release 26.06 | Maintain existing dashboards only. For new work, combine cuDF with HoloViews/hvPlot/Datashader and serve with Panel, Dash, Streamlit, or Bokeh. |
-| **cuSpatial** | Archived at 25.04 | Use only in an isolated legacy environment. For new work, keep geometry in GeoPandas/Shapely and accelerate compatible tabular stages with cuDF. |
-
-Full per-library guidance, including when each is the *wrong* choice and how to combine
-them, is in [references/decision_framework.md](references/decision_framework.md).
-Install commands and CUDA version selection are in
-[references/installation.md](references/installation.md). Before/after conversions for
-every library are in
-[references/code_transformation_patterns.md](references/code_transformation_patterns.md).
-
-## Optimization Workflow
-
-### 1. Define the contract and baseline
-
-- Capture a representative input, expected output, and acceptable numerical tolerance.
-- Measure the current end-to-end path, including input, transfers, compute, and output.
-- Profile before changing code. Use CPU profilers for CPU code and identify whether the real limit
-  is compute, memory bandwidth, allocation, transfer, synchronization, or storage.
-- Record hardware, package versions, dtypes, shapes, batch size, and warm-up policy with results.
-
-### 2. Check suitability before porting
-
-GPU execution is promising when the hot path exposes substantial independent work, runs often
-enough to amortize initialization and transfer, and has a working set that fits available device
-memory with room for temporaries. Keep a CPU path when the workload is small, mostly sequential,
-dominated by unsupported operations, or requires frequent host-device round trips.
-
-Do not use fixed row-count thresholds as proof. Benchmark the user's actual shapes and hardware.
-For out-of-core data, estimate peak working memory and choose chunking, Dask, or a streaming design
-before allocating.
-
-### 3. Try the least disruptive implementation
-
-1. If the code already uses a GPU-native framework, optimize within that framework.
-2. Try accelerator or backend modes (`cudf.pandas`, `cuml.accel`, `nx-cugraph`).
-3. Move to a native GPU API only where accelerator coverage or performance is insufficient.
-4. Write a custom kernel only when profiling shows an operation without a suitable library
-   implementation.
-
-Read the relevant library reference before writing code; compatible names can still differ in
-defaults, dtypes, output types, and supported arguments.
-
-### 4. Keep a coherent GPU data path
-
-- Transfer inputs once and keep intermediates device-resident.
-- Reuse allocations and prefer `out=` or in-place forms when semantics allow.
-- Batch small operations; fuse elementwise work when it removes intermediate arrays.
-- Use pinned host memory and non-default streams only after profiling shows transfer overlap matters.
-- Choose `float32`, mixed precision, or reduced-precision storage only when the contract permits it.
-
-### 5. Validate semantics before speed
-
-- Compare CPU and GPU outputs on small deterministic fixtures and representative data.
-- Use explicit tolerances for floating-point results and test edge cases, NaNs, ordering, and dtypes.
-- For approximate nearest-neighbor indexes, report recall@k against exact search; do not compare an
-  exact CPU algorithm with an approximate GPU algorithm as if they were equivalent.
-- Check accelerator warnings and logs for CPU fallback.
-
-### 6. Benchmark GPU code correctly
-
-GPU work is asynchronous, so a CPU timer around an unsynchronized call measures enqueue time.
-Warm up context creation and JIT compilation, then use CUDA events or a library-aware timer:
-
-```python
-from cupyx.profiler import benchmark
-
-print(benchmark(gpu_function, (arg1, arg2), n_warmup=10, n_repeat=100))
-```
-
-Use `%gpu_timeit` in notebooks, Nsight Systems (`nsys`) for end-to-end timelines, and Nsight
-Compute (`ncu`) for kernel analysis. Report both synchronized kernel/region time and realistic
-end-to-end latency; include transfer and conversion costs when production pays them.
-
-### 7. Keep, revise, or reject the port
-
-Retain the GPU path only when it passes correctness checks and improves the metric the user cares
-about on representative data. If it does not, explain whether the limiting factor is problem size,
-transfers, unsupported fallback, memory pressure, launch granularity, or the algorithm itself.
-
-## Important Notes
-
-- Provide a CPU fallback when the application requires portability; otherwise fail early with a
-  clear hardware and dependency error.
-- Test numerical correctness against CPU results (GPU floating point may differ slightly due to operation ordering)
-- GPU memory is limited — for datasets larger than GPU memory, consider chunking or using RAPIDS Dask for multi-GPU
-- Prefer the CUDA Array Interface or DLPack for supported zero-copy interchange, but verify device,
-  dtype, contiguity, ownership, and stream semantics rather than assuming every conversion is free.
-
-## Reference Files
-
-Before writing any GPU optimization code, read the relevant reference file(s):
-
-| File | When to Read |
-|------|-------------|
-| `references/cupy.md` | User has NumPy/SciPy code, or needs array operations on GPU |
-| `references/numba.md` | User has existing Numba-CUDA code or needs explicit SIMT kernels; note the migration path to Numba-CUDA-MLIR |
-| `references/cudf.md` | User has pandas code, or needs dataframe operations on GPU |
-| `references/cuml.md` | User has scikit-learn code, or needs ML training/inference/preprocessing on GPU |
-| `references/cugraph.md` | User has NetworkX code, or needs graph analytics on GPU |
-| `references/warp.md` | User needs GPU kernels for simulation, spatial computing, mesh/volume queries, differentiable programming, or robotics; use Newton for a high-level physics engine |
-| `references/kvikio.md` | User needs high-performance file IO to/from GPU, GPUDirect Storage, reading S3/HTTP to GPU, or Zarr on GPU |
-| `references/cuxfilter.md` | User maintains or explicitly requests cuxfilter (sunset — 26.06 is the final release) |
-| `references/cucim.md` | User has scikit-image code, or needs image processing, digital pathology, or WSI reading on GPU |
-| `references/cuvs.md` | User needs vector search, nearest neighbors, similarity search, or RAG retrieval on GPU |
-| `references/cuspatial.md` | User maintains or explicitly requests cuSpatial (archived — frozen at 25.04 and isolated from current RAPIDS) |
-| `references/raft.md` | User needs sparse eigensolvers, device memory management, or multi-GPU primitives |
-
-Read the specific reference before writing code — they contain detailed API patterns, optimization techniques, and pitfalls specific to each library.

package/skills/owasp-top10/SKILL.md

@@ -1,48 +0,0 @@
----
-name: owasp-top10
-description: "OWASP Top 10 Web & API Security Checklist - Guidelines, code patterns, and automated remediation for modern web application vulnerabilities."
-risk: low
-source: built-in
----
-
-# OWASP Top 10 Security Checklist
-
-## 1. Broken Access Control (A01)
-- **Check**: Are access control decisions enforced server-side on every request?
-- **Remedy**: Implement centralized authorization middleware and verify tenancy on every query.
-
-## 2. Cryptographic Failures (A02)
-- **Check**: Are sensitive data in transit and at rest encrypted? Are deprecated algorithms (MD5, SHA1, DES) avoided?
-- **Remedy**: Use Argon2id/bcrypt for passwords, AES-GCM for encryption, and TLS 1.3 for transport.
-
-## 3. Injection (A03)
-- **Check**: Are SQL, NoSQL, OS command, and LDAP queries parameterized?
-- **Remedy**: Never concatenate user input into database queries or shell execution strings.
-
-## 4. Insecure Design (A04)
-- **Check**: Are threat modeling and defense-in-depth principles applied?
-- **Remedy**: Enforce least privilege, strict input boundaries, and rate limits.
-
-## 5. Security Misconfiguration (A05)
-- **Check**: Are default passwords, unnecessary features, and debug error messages disabled in production?
-- **Remedy**: Disable detailed stack traces in production API responses and enforce strict CSP headers.
-
-## 6. Vulnerable and Outdated Components (A06)
-- **Check**: Are dependencies monitored for known CVEs (`npm audit`, `bun audit`)?
-- **Remedy**: Regularly update dependencies and pin exact versions.
-
-## 7. Identification and Authentication Failures (A07)
-- **Check**: Is multi-factor authentication supported? Are session identifiers secure?
-- **Remedy**: Implement exponential backoff for failed logins and enforce strong password policies.
-
-## 8. Software and Data Integrity Failures (A08)
-- **Check**: Are plugins, libraries, and CDNs verified with integrity hashes?
-- **Remedy**: Enforce subresource integrity (SRI) and signed package downloads.
-
-## 9. Security Logging and Monitoring Failures (A09)
-- **Check**: Are login attempts, access failures, and sensitive transactions logged?
-- **Remedy**: Centralize structured security logs without logging plaintext credentials or PII.
-
-## 10. Server-Side Request Forgery - SSRF (A10)
-- **Check**: Do servers make HTTP requests to user-supplied URLs without validation?
-- **Remedy**: Whitelist permitted target domains and reject private/internal IP ranges.

package/skills/pacsomatic/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 Beifang Niu
-
-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.