@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/gin-golang/references/validation.md

@@ -1,273 +0,0 @@
-# Gin Validation
-
-## Binding and Validation Overview
-
-Gin uses `go-playground/validator/v10` for struct validation. Request data is bound to structs using `ShouldBind*` methods, and validated through `binding` tags on struct fields.
-
-## ShouldBind vs Bind
-
-Always use `ShouldBind*` methods. They return the error for you to handle. `Bind*` methods write a 400 response automatically and call `c.Abort()`, removing your control over error formatting.
-
-```go
-// CORRECT: ShouldBind returns the error
-func createProduct(c *gin.Context) {
-    var req CreateProductRequest
-    if err := c.ShouldBindJSON(&req); err != nil {
-        handleValidationError(c, err) // You control the response
-        return
-    }
-    // Process valid request...
-}
-
-// WRONG: Bind writes 400 and aborts automatically
-func createProduct(c *gin.Context) {
-    var req CreateProductRequest
-    if err := c.BindJSON(&req); err != nil {
-        return // 400 already sent with gin's default format
-    }
-}
-```
-
-## Binding Methods
-
-| Method | Content-Type | Source |
-| --- | --- | --- |
-| `ShouldBindJSON(&obj)` | `application/json` | Body |
-| `ShouldBindXML(&obj)` | `application/xml` | Body |
-| `ShouldBindYAML(&obj)` | `application/yaml` | Body |
-| `ShouldBind(&obj)` | Auto-detect | Body |
-| `ShouldBindQuery(&obj)` | N/A | Query string |
-| `ShouldBindUri(&obj)` | N/A | Path parameters |
-| `ShouldBindHeader(&obj)` | N/A | Headers |
-
-## Common Binding Tags
-
-```go
-type CreateProductRequest struct {
-    // Required field
-    Name string `json:"name" binding:"required"`
-
-    // String length constraints
-    Description string `json:"description" binding:"required,min=10,max=1000"`
-
-    // Numeric constraints
-    Price    float64 `json:"price" binding:"required,gt=0,lte=999999.99"`
-    Quantity int     `json:"quantity" binding:"required,min=0,max=99999"`
-
-    // Enum / oneof
-    Category string `json:"category" binding:"required,oneof=electronics books clothing food"`
-    Status   string `json:"status" binding:"oneof=draft active archived"`
-
-    // Format validators
-    Email   string `json:"email" binding:"required,email"`
-    Website string `json:"website" binding:"omitempty,url"`
-    SKU     string `json:"sku" binding:"required,len=10,alphanum"`
-
-    // UUID
-    OwnerID string `json:"owner_id" binding:"required,uuid"`
-
-    // Nested struct validation
-    Address Address `json:"address" binding:"required"`
-
-    // Slice validation
-    Tags []string `json:"tags" binding:"max=10,dive,min=1,max=50"`
-
-    // Optional field (skip validation if empty)
-    Notes *string `json:"notes" binding:"omitempty,max=500"`
-}
-
-type Address struct {
-    Street  string `json:"street" binding:"required"`
-    City    string `json:"city" binding:"required"`
-    Country string `json:"country" binding:"required,iso3166_1_alpha2"`
-    Zip     string `json:"zip" binding:"required"`
-}
-```
-
-## Custom Validators
-
-Register custom validation functions for domain-specific rules.
-
-```go
-import (
-    "github.com/gin-gonic/gin/binding"
-    "github.com/go-playground/validator/v10"
-)
-
-func setupValidators() {
-    if v, ok := binding.Validator.Engine().(*validator.Validate); ok {
-        // Custom slug validator
-        v.RegisterValidation("slug", validateSlug)
-
-        // Custom currency code validator
-        v.RegisterValidation("currency", validateCurrency)
-
-        // Custom phone number validator
-        v.RegisterValidation("phone", validatePhone)
-
-        // Custom date range validator
-        v.RegisterStructValidation(validateDateRange, DateRangeRequest{})
-    }
-}
-
-func validateSlug(fl validator.FieldLevel) bool {
-    slug := fl.Field().String()
-    matched, _ := regexp.MatchString(`^[a-z0-9]+(?:-[a-z0-9]+)*$`, slug)
-    return matched
-}
-
-func validateCurrency(fl validator.FieldLevel) bool {
-    valid := map[string]bool{"USD": true, "EUR": true, "GBP": true, "JPY": true}
-    return valid[fl.Field().String()]
-}
-
-func validatePhone(fl validator.FieldLevel) bool {
-    phone := fl.Field().String()
-    matched, _ := regexp.MatchString(`^\+[1-9]\d{1,14}$`, phone)
-    return matched
-}
-
-// Cross-field validation
-func validateDateRange(sl validator.StructLevel) {
-    req := sl.Current().Interface().(DateRangeRequest)
-    if !req.EndDate.After(req.StartDate) {
-        sl.ReportError(req.EndDate, "end_date", "EndDate", "gtfield", "start_date")
-    }
-}
-```
-
-## Structured Validation Error Response
-
-Transform `validator.ValidationErrors` into a client-friendly JSON format.
-
-```go
-type ErrorResponse struct {
-    Code    string       `json:"code"`
-    Message string       `json:"message"`
-    Details []FieldError `json:"details,omitempty"`
-}
-
-type FieldError struct {
-    Field   string `json:"field"`
-    Tag     string `json:"tag"`
-    Value   interface{} `json:"value,omitempty"`
-    Message string `json:"message"`
-}
-
-func handleValidationError(c *gin.Context, err error) {
-    var ve validator.ValidationErrors
-    if errors.As(err, &ve) {
-        fields := make([]FieldError, len(ve))
-        for i, fe := range ve {
-            fields[i] = FieldError{
-                Field:   toSnakeCase(fe.Field()),
-                Tag:     fe.Tag(),
-                Value:   fe.Value(),
-                Message: formatFieldMessage(fe),
-            }
-        }
-        c.JSON(http.StatusBadRequest, ErrorResponse{
-            Code:    "VALIDATION_ERROR",
-            Message: "Request validation failed",
-            Details: fields,
-        })
-        return
-    }
-
-    // JSON syntax errors (malformed body)
-    var je *json.SyntaxError
-    if errors.As(err, &je) {
-        c.JSON(http.StatusBadRequest, ErrorResponse{
-            Code:    "INVALID_JSON",
-            Message: "Request body contains invalid JSON",
-        })
-        return
-    }
-
-    // Unmarshal type errors (wrong type for field)
-    var ute *json.UnmarshalTypeError
-    if errors.As(err, &ute) {
-        c.JSON(http.StatusBadRequest, ErrorResponse{
-            Code:    "TYPE_ERROR",
-            Message: fmt.Sprintf("Field '%s' must be of type %s", ute.Field, ute.Type.String()),
-        })
-        return
-    }
-
-    c.JSON(http.StatusBadRequest, ErrorResponse{
-        Code:    "BAD_REQUEST",
-        Message: err.Error(),
-    })
-}
-
-func formatFieldMessage(fe validator.FieldError) string {
-    field := toSnakeCase(fe.Field())
-    switch fe.Tag() {
-    case "required":
-        return fmt.Sprintf("%s is required", field)
-    case "min":
-        return fmt.Sprintf("%s must be at least %s", field, fe.Param())
-    case "max":
-        return fmt.Sprintf("%s must be at most %s", field, fe.Param())
-    case "oneof":
-        return fmt.Sprintf("%s must be one of: %s", field, fe.Param())
-    case "email":
-        return fmt.Sprintf("%s must be a valid email address", field)
-    case "url":
-        return fmt.Sprintf("%s must be a valid URL", field)
-    case "uuid":
-        return fmt.Sprintf("%s must be a valid UUID", field)
-    case "slug":
-        return fmt.Sprintf("%s must be a valid URL slug (lowercase, hyphens only)", field)
-    default:
-        return fmt.Sprintf("%s failed %s validation", field, fe.Tag())
-    }
-}
-```
-
-## Partial Update Validation
-
-Use pointer fields for PATCH/PUT with optional fields.
-
-```go
-type UpdateProductRequest struct {
-    Name        *string  `json:"name" binding:"omitempty,min=1,max=200"`
-    Description *string  `json:"description" binding:"omitempty,min=10,max=1000"`
-    Price       *float64 `json:"price" binding:"omitempty,gt=0"`
-    Category    *string  `json:"category" binding:"omitempty,oneof=electronics books clothing food"`
-}
-
-func updateProduct(c *gin.Context) {
-    var req UpdateProductRequest
-    if err := c.ShouldBindJSON(&req); err != nil {
-        handleValidationError(c, err)
-        return
-    }
-
-    // Only update fields that are present (non-nil)
-    updates := make(map[string]interface{})
-    if req.Name != nil {
-        updates["name"] = *req.Name
-    }
-    if req.Price != nil {
-        updates["price"] = *req.Price
-    }
-    // ...
-}
-```
-
-## Validation Quick Reference
-
-| Tag | Description | Example |
-| --- | --- | --- |
-| `required` | Field must be present and non-zero | `binding:"required"` |
-| `omitempty` | Skip validation if empty | `binding:"omitempty,email"` |
-| `min`, `max` | Length/value range | `binding:"min=1,max=100"` |
-| `gt`, `gte`, `lt`, `lte` | Numeric comparison | `binding:"gt=0"` |
-| `oneof` | Enum values | `binding:"oneof=a b c"` |
-| `email` | Email format | `binding:"email"` |
-| `url` | URL format | `binding:"url"` |
-| `uuid` | UUID format | `binding:"uuid"` |
-| `len` | Exact length | `binding:"len=10"` |
-| `alphanum` | Alphanumeric only | `binding:"alphanum"` |
-| `dive` | Validate slice elements | `binding:"dive,min=1"` |

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/git-workflow/evals/assertions.md

@@ -1,48 +0,0 @@
-# Git Workflow Eval Assertions
-
-## Eval 1: Branching Strategy Selection
-
-This eval tests whether the skill can analyze team context and recommend an appropriate branching strategy with a concrete migration plan.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                          |
-|---|----------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| 1 | contains | `trunk-based` — Recommends trunk-based dev      | A team deploying twice weekly with merge pain needs fewer long-lived branches, not more ceremony.       |
-| 2 | contains | `feature flag` — Feature flag strategy           | Trunk-based development without feature flags leads to half-built features in production.               |
-| 3 | contains | `short-lived` — Short-lived branch emphasis      | The root cause of merge conflicts is branch lifetime. This must be explicitly called out.               |
-| 4 | contains | `migration` — Migration plan included            | Telling a team to "use trunk-based" without a migration path is useless advice.                         |
-| 5 | contains | `branch protection` — Protection rules           | Any branching strategy without branch protection is incomplete. CI gating prevents regressions.         |
-
-### What a passing response looks like
-
-- Identifies that GitFlow is overkill for a SaaS team deploying twice weekly.
-- Recommends trunk-based development or GitHub Flow with clear rationale.
-- Provides a phased migration plan: freeze GitFlow, create new branch protection, migrate one team first.
-- Includes feature flag strategy for incomplete work.
-- Specifies GitHub branch protection settings (required reviews, status checks, merge queue).
-- Addresses the 3-5 day PR cycle with concrete suggestions (smaller PRs, review SLAs, CODEOWNERS).
-
----
-
-## Eval 2: Commit Message Writing
-
-This eval tests whether the skill produces correctly typed, well-structured conventional commit messages.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                          |
-|---|----------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| 1 | contains | `feat` — Correct type for new feature            | Rate limiting is new functionality. Mistyping it as `fix` or `chore` breaks automated changelogs.       |
-| 2 | contains | `fix` — Correct type for bug fix                 | The null avatar crash is clearly a bug. Using `refactor` here would hide a user-facing fix.             |
-| 3 | contains | `refactor` — Correct type for internal change    | The connection pool change has no user-visible effect. Using `feat` would mislead changelog readers.    |
-| 4 | contains | `ci` — Correct type for CI change                | Pipeline changes are CI concerns, not build or chore. Correct typing enables filtered changelogs.       |
-| 5 | contains | `imperative` — Imperative mood guidance          | Conventional commits require imperative mood. Past tense is the most common mistake.                    |
-
-### What a passing response looks like
-
-- Four commit messages, each with the correct conventional commit type.
-- Subject lines under 72 characters in imperative mood.
-- Body text explaining WHY each change was made (traffic spike, null crash, per-request pools, sequential slowness).
-- Optional scope in parentheses (e.g., `feat(api):`, `fix(profile):`, `refactor(db):`, `ci(pipeline):`).
-- No mixing of concerns — each commit message matches exactly one change.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/git-workflow/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "branching-strategy-selection",
-    "description": "Validate that the skill recommends an appropriate branching strategy based on team context, with clear rationale and actionable configuration steps.",
-    "input": "Our team has 8 developers working on a B2B SaaS product. We deploy to production twice a week. We currently use GitFlow with develop, release, and hotfix branches, but PRs are taking 3-5 days to merge and we have frequent merge conflicts. We want to move faster. What branching strategy should we adopt and how do we migrate?",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "trunk-based",
-        "description": "Must recommend trunk-based development or GitHub Flow for a team that wants to ship faster, not double down on GitFlow."
-      },
-      {
-        "type": "contains",
-        "value": "feature flag",
-        "description": "Must mention feature flags as the mechanism for handling incomplete work on main, since trunk-based development requires merging frequently."
-      },
-      {
-        "type": "contains",
-        "value": "short-lived",
-        "description": "Must emphasize short-lived branches (1-2 days) as the key practice change, since the current 3-5 day PR cycle is the root cause of merge conflicts."
-      },
-      {
-        "type": "contains",
-        "value": "migration",
-        "description": "Must provide a migration plan from GitFlow to the recommended model, not just describe the target state."
-      },
-      {
-        "type": "contains",
-        "value": "branch protection",
-        "description": "Must include branch protection configuration as part of the recommendation, since unprotected branches undermine any branching strategy."
-      }
-    ]
-  },
-  {
-    "name": "commit-message-writing",
-    "description": "Validate that the skill produces properly formatted conventional commit messages with meaningful descriptions that explain intent.",
-    "input": "I made the following changes and need help writing commit messages:\n1. Added rate limiting middleware to the Express API routes (max 100 requests per minute per IP) to prevent abuse after we saw a spike in traffic last week.\n2. Fixed a bug where the user profile page crashed when the user had no avatar URL (it was passing null to the Image component).\n3. Refactored the database connection pool to use a singleton pattern instead of creating a new pool per request.\n4. Updated the CI pipeline to run tests in parallel across 4 workers instead of sequentially.\nWrite conventional commit messages for each change.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "feat",
-        "description": "The rate limiting middleware is a new feature and must use the feat type, not fix or chore."
-      },
-      {
-        "type": "contains",
-        "value": "fix",
-        "description": "The avatar null crash is a bug fix and must use the fix type with a clear description of what was broken."
-      },
-      {
-        "type": "contains",
-        "value": "refactor",
-        "description": "The database connection pool change is a refactor (no behavior change) and must use the refactor type."
-      },
-      {
-        "type": "contains",
-        "value": "ci",
-        "description": "The pipeline parallelization is a CI change and must use the ci type, not build or chore."
-      },
-      {
-        "type": "contains",
-        "value": "imperative",
-        "description": "Must use or explain imperative mood in commit subjects (add, fix, refactor) rather than past tense (added, fixed, refactored)."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/go-fiber/SKILL.md

@@ -1,80 +0,0 @@
----
-name: go-fiber
-description: "Use when building Go Fiber services, including routing, middleware, WebSockets, request validation, structured errors, and performance tuning."
-allowed-tools: Read Grep Glob Bash Edit Write
-user-invocable: true
-argument-hint: "Fiber handler, middleware, or route to work on"
----
-
-# Go Fiber v3
-
-## Purpose
-
-Production-grade guidance for building high-performance HTTP APIs and real-time services using Go Fiber v3. Fiber is built on top of fasthttp, delivering Express-inspired ergonomics with Go's concurrency model and near-zero allocation routing.
-
-## When to Use
-
-- Building REST or JSON APIs with Go Fiber v3.
-- Configuring middleware stacks for logging, auth, CORS, rate limiting, and recovery.
-- Setting up WebSocket endpoints alongside HTTP routes.
-- Structuring large Fiber applications with route groups and modular handlers.
-- Optimizing request throughput, reducing allocations, and benchmarking Fiber services.
-- Migrating from Express.js or net/http to Fiber.
-
-## Instructions
-
-1. **Initialize the Fiber app with explicit configuration** -- create the app with `fiber.New(fiber.Config{...})` and set `ErrorHandler`, `ReadTimeout`, `WriteTimeout`, `IdleTimeout`, and `BodyLimit` explicitly. Leaving these at defaults in production leads to resource exhaustion under load.
-
-2. **Use the Fiber v3 context API, not fasthttp directly** -- access request data through `c.Params()`, `c.Query()`, `c.Body()`, and `c.JSON()`. Reaching into `c.Context()` for raw fasthttp access breaks Fiber's middleware chain and makes code fragile across version upgrades.
-
-3. **Structure routes with `app.Group()` and mount sub-routers** -- group related endpoints under a common prefix (e.g., `/api/v1`) and attach group-level middleware for auth or rate limiting. This keeps route registration readable and lets you apply cross-cutting concerns at the right scope without global middleware bloat.
-
-4. **Build middleware as `fiber.Handler` functions that call `c.Next()`** -- each middleware must either call `c.Next()` to continue the chain or return an error/response to short-circuit. Place recovery middleware first, then logging, then auth, then route-specific middleware. Order determines execution sequence and matters for correctness.
-
-5. **Validate request bodies with a dedicated validator** -- use `go-playground/validator/v10` or a similar library and bind it through a reusable `validate()` helper that calls `c.BodyParser()` then validates the struct. Return `400` with structured field errors. Do not scatter validation logic across handlers because it becomes inconsistent and hard to test.
-
-6. **Return structured error responses with a custom `ErrorHandler`** -- define an `ErrorHandler` in the app config that maps `*fiber.Error`, sentinel errors, and validation errors to consistent JSON envelopes with `code`, `message`, and optional `details`. This centralizes error formatting and prevents handlers from inventing their own response shapes.
-
-7. **Use `c.Locals()` to pass request-scoped data through middleware** -- store authenticated user, request ID, or trace context in locals. Retrieve with type-safe helper functions. Do not use global variables or package-level state for per-request data because fasthttp reuses contexts across connections.
-
-8. **Handle WebSocket connections with `websocket.New()`** -- register WebSocket routes using `app.Get("/ws", websocket.New(handler))` and guard them with an upgrade-check middleware. Manage connection lifecycles with ping/pong deadlines, read limits, and graceful close. Do not mix WebSocket handler logic with REST handlers.
-
-9. **Implement graceful shutdown with `os.Signal` and `app.ShutdownWithTimeout()`** -- listen for `SIGINT`/`SIGTERM` in a goroutine, then call `app.ShutdownWithTimeout(timeout)` to drain in-flight requests. This prevents dropped connections during deploys and lets health checks report the correct state.
-
-10. **Write handler tests using `app.Test()` with `httptest.NewRequest`** -- construct a Fiber app in the test, register the handler under test, build an `*http.Request`, and call `app.Test(req)`. Assert status codes, headers, and JSON bodies. This avoids spinning up a real server and keeps tests fast and deterministic.
-
-11. **Benchmark with `testing.B` and Fiber's built-in test helper** -- write benchmarks that exercise the full middleware chain per request. Use `b.ReportAllocs()` to track allocation regressions. Profile with `pprof` for CPU and heap hotspots before optimizing.
-
-12. **Configure CORS, Helmet, and Rate Limiter middleware from the official packages** -- use `fiber/middleware/cors`, `fiber/middleware/helmet`, and `fiber/middleware/limiter` with explicit allow-lists and limits. Do not rely on permissive defaults (`AllowOrigins: "*"`) in production because it disables credential-based CORS.
-
-13. **Use `fiber/middleware/recover` as the outermost middleware** -- recover catches panics inside handlers and converts them to 500 responses. Without it, a panic in any handler crashes the entire process. Place it before all other middleware so it wraps the full chain.
-
-14. **Serve static files and templates through Fiber's built-in engines** -- use `app.Static()` for file serving with cache headers and `fiber/template/*` engines for server-side rendering. Configure `MaxAge` and `Compress` to reduce bandwidth. Do not serve static files through custom handlers because it bypasses Fiber's optimized file serving.
-
-15. **Propagate `context.Context` for downstream service calls** -- extract the request context with `c.UserContext()` and pass it to database queries, HTTP clients, and gRPC calls. This ensures cancellation propagates when clients disconnect or timeouts fire.
-
-16. **Keep Fiber-specific code at the boundary** -- handlers should parse the request, delegate to a service layer, and format the response. Business logic must not import `gofiber/fiber`. This separation makes logic testable without HTTP concerns and portable across frameworks.
-
-## Output Format
-
-Produces Go source files with Fiber v3 handler signatures, grouped route registration, middleware chains, structured error types, and table-driven handler tests. Includes `go.mod` dependencies and configuration constants where applicable.
-
-## References
-
-Load only what the current step needs.
-
-| File | Load when |
-| --- | --- |
-| `references/routing.md` | Route registration, groups, parameter parsing, or sub-router mounting needs detail. |
-| `references/middleware.md` | Middleware authoring, ordering, or built-in middleware configuration is in scope. |
-| `references/error-handling.md` | Custom error handler, structured errors, or panic recovery patterns are needed. |
-| `references/testing.md` | Handler testing, integration tests, or benchmark setup is needed. |
-| `references/performance.md` | Allocation profiling, fasthttp tuning, or throughput optimization is in scope. |
-
-## Claude Platform Notes
-
-- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
-- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
-- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
-- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
-- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/go-fiber/evals/assertions.md

@@ -1,37 +0,0 @@
-# Go Fiber Eval Assertions
-
-## Eval 1: REST API with Middleware Stack
-
-### fiber-app-config
-Verifies the Fiber application is initialized with explicit production configuration rather than defaults. The response must show `fiber.New(fiber.Config{...})` with a custom `ErrorHandler` function, timeout settings (`ReadTimeout`, `WriteTimeout`), and a `BodyLimit`. This ensures the service is hardened against resource exhaustion and has centralized error formatting from the start.
-
-### route-grouping-middleware
-Verifies routes are organized under a versioned group (`/api/v1`) and middleware is layered in the correct order. Recovery must come first to catch panics, followed by request ID injection, logging, and authentication. Rate limiting should be scoped to specific endpoints, not applied globally. This tests that the response understands middleware ordering semantics and does not apply everything globally.
-
-### validation-binding
-Verifies request payloads are validated through struct tags and a validator library, not through ad-hoc checks in the handler. The handler must call `c.BodyParser()` to bind the request body, run validation, and return structured 400 errors with per-field detail. This assertion catches responses that skip validation, validate only at the handler level, or return unstructured error strings.
-
-### custom-error-handler
-Verifies a centralized `ErrorHandler` exists that handles different error types (Fiber errors, validation errors, sentinel errors) and maps them to a consistent JSON shape. The response must not have handlers formatting their own error responses in different ways. This tests for production-quality error consistency.
-
-### handler-tests
-Verifies tests use Fiber's `app.Test()` helper with `httptest.NewRequest` and follow a table-driven pattern. Tests must cover both create and list endpoints, assert on HTTP status codes and JSON response bodies. This catches responses that skip testing, write only happy-path tests, or spin up a real server for unit tests.
-
----
-
-## Eval 2: WebSocket Endpoint
-
-### websocket-setup
-Verifies the WebSocket route uses the Fiber WebSocket package (`websocket.New()`) and includes an upgrade-check middleware that validates the request is a genuine WebSocket upgrade before allowing connection establishment. This prevents non-WebSocket requests from reaching the handler.
-
-### connection-lifecycle
-Verifies WebSocket connections are configured with read limits and ping/pong handlers for liveness detection. The response must set `SetReadLimit` to prevent oversized messages and configure pong/ping handlers with deadlines. This ensures connections do not hang indefinitely or accept unbounded payloads.
-
-### broadcast-pattern
-Verifies a hub or registry pattern manages active connections with thread safety. The REST endpoint must be able to push messages to all connected WebSocket clients through this shared structure. This tests that the response correctly bridges HTTP and WebSocket communication without race conditions.
-
-### graceful-disconnect
-Verifies the handler properly cleans up when a client disconnects. The connection must be removed from the hub, close frames should be sent, and the read loop must break on error. This catches responses that leak connections or fail silently on client disconnect.
-
-### rest-and-ws-tests
-Verifies both the REST health endpoint and the WebSocket upgrade path are tested. The health test should use `app.Test()` and assert 200. The WebSocket test should verify upgrade behavior or middleware rejection for non-WebSocket requests. This ensures both transport mechanisms have test coverage.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/go-fiber/evals/evals.json

@@ -1,74 +0,0 @@
-[
-  {
-    "id": "go-fiber-rest-middleware",
-    "prompt": "Build a Go Fiber v3 REST API for a task management service with the following requirements: Create CRUD endpoints for tasks under /api/v1/tasks with proper route grouping. Include a middleware stack with recovery, request ID injection, structured JSON logging, JWT authentication, and rate limiting. Validate request bodies using go-playground/validator. Return structured JSON error responses from a custom ErrorHandler. Implement graceful shutdown. Include table-driven tests for the create and list endpoints.",
-    "assertions": [
-      {
-        "id": "fiber-app-config",
-        "type": "contains_concept",
-        "expected": "Fiber app is created with fiber.New(fiber.Config{...}) including a custom ErrorHandler, ReadTimeout, WriteTimeout, and BodyLimit configuration",
-        "weight": 1.0
-      },
-      {
-        "id": "route-grouping-middleware",
-        "type": "contains_concept",
-        "expected": "Routes are organized with app.Group('/api/v1') and middleware is applied in the correct order: recovery first, then request ID, logging, and auth middleware on the group, with rate limiter on specific routes",
-        "weight": 1.0
-      },
-      {
-        "id": "validation-binding",
-        "type": "contains_concept",
-        "expected": "Request structs have validate tags, c.BodyParser() is called to parse the body, and a validator instance validates the struct with structured field-level error responses returned as 400 JSON",
-        "weight": 1.0
-      },
-      {
-        "id": "custom-error-handler",
-        "type": "contains_concept",
-        "expected": "A custom ErrorHandler function is defined that checks for *fiber.Error, validation errors, and sentinel errors, mapping each to a consistent JSON envelope with code, message, and optional details fields",
-        "weight": 1.0
-      },
-      {
-        "id": "handler-tests",
-        "type": "contains_concept",
-        "expected": "Tests use app.Test() with httptest.NewRequest to exercise the create and list endpoints, asserting on status codes and JSON response bodies in a table-driven pattern with t.Run subtests",
-        "weight": 1.0
-      }
-    ]
-  },
-  {
-    "id": "go-fiber-websocket",
-    "prompt": "Create a Go Fiber v3 service that serves both REST endpoints and WebSocket connections. The REST part should have a GET /api/health endpoint and a POST /api/messages endpoint that publishes messages. The WebSocket part at /ws should upgrade connections with a middleware check, manage connection lifecycles with ping/pong, broadcast messages from the REST endpoint to all connected WebSocket clients, handle client disconnection gracefully, and set read limits. Include tests for both the REST health endpoint and a test that verifies the WebSocket upgrade handshake.",
-    "assertions": [
-      {
-        "id": "websocket-setup",
-        "type": "contains_concept",
-        "expected": "WebSocket route is registered with app.Get('/ws', websocket.New(handler)) and an upgrade-check middleware verifies the websocket upgrade header before allowing the connection",
-        "weight": 1.0
-      },
-      {
-        "id": "connection-lifecycle",
-        "type": "contains_concept",
-        "expected": "WebSocket handler sets read deadline, read limit (SetReadLimit), and configures ping/pong handlers with SetPongHandler or SetPingHandler for connection liveness detection",
-        "weight": 1.0
-      },
-      {
-        "id": "broadcast-pattern",
-        "type": "contains_concept",
-        "expected": "A connection hub or registry manages active WebSocket connections with thread-safe add/remove operations using a mutex or channel, and the REST POST endpoint publishes messages through this hub to all connected clients",
-        "weight": 1.0
-      },
-      {
-        "id": "graceful-disconnect",
-        "type": "contains_concept",
-        "expected": "The WebSocket handler defers connection removal from the hub and connection close, handles read errors by breaking the read loop, and sends close frames before disconnecting",
-        "weight": 1.0
-      },
-      {
-        "id": "rest-and-ws-tests",
-        "type": "contains_concept",
-        "expected": "Tests verify the health endpoint returns 200 with app.Test(), and a separate test verifies the WebSocket upgrade path returns 101 or tests the upgrade middleware rejection for non-WebSocket requests",
-        "weight": 1.0
-      }
-    ]
-  }
-]